UNIX System Administration Handbook - Evi Nemeth [260]
zone "cs.colorado.edu" {
type master;
file "forward/cs.colorado.edu";
};
# CS reverse records (128.138.X.X)
zone "250.138.128.in-addr.arpa" {
type master;
file "reverse/250.138.128";
};
zone "245.138.128.in-addr.arpa" {
type master;
file "reverse/245.138.128";
};
# ... many, many reverse zones omitted
# Slaves
zone "colorado.edu" { # colorado.edu top level
type slave;
file "secondary/colorado.edu";
allow-transfer { none; };
masters { 128.138.240.1; };
};
zone "openbsd.org" { # openbsd project
type slave;
file "secondary/openbsd.org";
masters { 199.45.131.58; };
};
zone "233.in-addr.arpa" {# experimental multicast addresses
type slave;
file "secondary/233.in-addr.arpa";
masters { 128.223.32.35; };
};
# lots more zones omitted
A web hosting company
Our next example is from a company that does web design and web hosting; they run DNS services for their clients. The master server deals with almost 2,000 zones, about half as master and half as slave. Most of the zones are not large (typically 10–30K, with the largest being 160K), but there are a lot of them. The server is a SPARC 20 running SunOS 4.1.3 and BIND 8.2.2-P5. It has two network interfaces and about 512MB of memory.
Here, we show only a few snippets from the master configuration file. No slave configurations are shown; they’re the same as the master configurations except for the zone type and a masters line that indicates where to get the zone data. The root server hint zone and the localhost reverse mapping zone have been deleted; they are the same as in previous examples.
With so many zones, many of them loaded from off-site servers, the log files are full of “zone expired” and “not authoritative for zone” messages. The remote sites have often not kept their secondary DNS provider up to date on changes.
// XOR master server
options {
directory "/var/domain";
query-source address 192.225.33.1 port 53;
also-notify 192.108.21.2;
};
// XOR, internal, forward zones
zone "xor.com" {
type master;
file "xor.com";
};
zone "creative.xor.com" {
type master;
file "creative.xor.com";
};
// ... more internal zones deleted
// XOR, reverse zones
zone "21.108.192.in-addr.arpa" {
type master;
file "xor.rev";
};
zone "2.168.192.in-addr.arpa" { // hidden backlan for backups
type master;
file "backlan-2.rev";
};
// ... many reverse zones deleted
// Customer forward zones
// = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
// Boulder Community Hospital setup:01/21/2000
// = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
zone "boulderhospital.com" {
type master;
file "boulderhospital.com";
};
zone "boulderhospital.org" {
type master;
file "boulderhospital.com";
};
// Another 1750 or so zones were deleted from this example.
// Most were product names, not organization names.
16.11 THE DNS DATABASE
A domain’s DNS database is a set of text files maintained by the system administrator on the domain’s master name server. These text files are often called zone files. They contain two types of entries: parser commands (things like $ORIGIN and $TTL) and “resource records,” or RRs as they are sometimes called. Only the resource records are really part of the database; the parser commands just provide some shorthand ways to enter records.
We start this section by describing the DNS resource records, which are defined in RFCs 882, 1035, 1183, 2065, 2181, 2308, and 2535. We defer discussion of the parser commands until page 453.
Resource records
Each zone of the DNS hierarchy has a set of resource records associated with it (the set might be empty). The basic format of a resource record is
[name] [ttl] [class] type data
Fields are separated by whitespace (tabs or spaces) and can contain the special characters shown in Table 16.8.
Table 16.8 Special characters used in RRs
a. See page 444 for some cautionary statements.
The name field identifies the entity (usually a host or domain) that the record describes.