UNIX System Administration Handbook - Evi Nemeth [261]
A name can be either relative or absolute. Absolute names end with a dot and are complete. Internally, the software deals only with absolute names; it appends the current domain and a dot to any name that does not already end in a dot. This feature allows names to be shorter, but it also invites mistakes.
For example, in the cs.colorado.edu domain, the name “anchor” would be interpreted as “anchor.cs.colorado.edu.”. If the name were entered as “anchor.cs.colorado.edu”, the lack of a final dot would still imply a relative name, and the default domain would be appended, resulting in the name “anchor.cs.colorado.edu.cs.colorado.edu.”. This is a very common mistake.
The ttl (time to live) field specifies the length of time, in seconds, that the data item can be cached and still be considered valid. It is often omitted, except in the root server hints file. It defaults to the value set by the $TTL directive at the top of the data file for the zone. In BIND 9, the $TTL directive is required. If there is no $TTL directive in BIND 8, the ttl defaults to a per-zone value set in the zone’s SOA record.
Increasing the value of the ttl parameter to about a week reduces network traffic and DNS load substantially. However, once records have been cached outside your local network, you cannot force them to be discarded. If you plan a massive renumbering, set the $TTL value low so that stale records that have been cached elsewhere on the Internet expire quickly.
See Chapter 18 for more information about NIS.
The class specifies the network type. Three values are recognized: IN for the Internet, CH for ChaosNet, and HS for Hesiod. ChaosNet is a nearly obsolete network protocol formerly used by Symbolics Lisp machines. Hesiod is a database service built on top of BIND. The default value for the class is IN. It is often specified explicitly in zone data files even though it is the default. Today only one piece of data is normally tucked away in the Chaos class: the version number of the running named, which can be extracted with dig as shown on page 403.
Many different types of DNS records are defined, but fewer than 10 are in common use; IPv6 adds a few more. We divide the resource records into four groups:
• Zone records – identify domains and their name servers
• Basic records – map names to addresses and route mail
• Security records – add authentication and signatures to zone files
• Optional records – provide extra information about hosts or domains
The contents of the data field depend on the record type. Table 16.9 on the next page lists the various record types.
Table 16.9 DNS record types
a. The LOC record is not well supported in NT (querying for LOC records crashes NT servers).
A few additional record types are obsolete, experimental, or not widely used. See the BIND documentation for a complete list.
The order of resource records is almost arbitrary. The SOA record for a zone should be first. The subsequent records can be in any order, but NS records usually come right after the SOA. The records for each host are usually kept together. It’s a common practice to sort by the name field.
As we describe each type of resource record in detail, we inspect some sample records from cs.colorado.edu’s data files. The default domain is “cs.colorado.edu.” throughout, so a host specified as “anchor” really means “anchor.cs.colorado.edu.”.
The SOA record
An SOA record marks the beginning of a zone, a group of resource records located at the same place within the DNS namespace. This node of the DNS tree is also called a delegation point or zone cut. As we discuss in greater detail on page 442, the data for a DNS domain usually includes at least two zones: one for translating hostnames to IP addresses, and others that map in the reverse direction. The DNS tree has a forward branch organized by name and a reverse branch organized by IP