UNIX System Administration Handbook - Evi Nemeth [264]
See page 455 for more information about delegation.
A records
A (address) records are the heart of the DNS database. They provide the mapping from hostnames to IP addresses that was formerly specified in the /etc/hosts file. A host must have one A record for each of its network interfaces. The format is
hostname [ttl] IN A ipaddr
For example:
anchor IN A 128.138.243.100
A machine with multiple network interfaces can use a single hostname associated with all interfaces or have separate hostnames for each interface.
PTR records
PTR (pointer) records perform the reverse mapping from IP addresses to hostnames. As with A records, a host must have one for each network interface. Before we describe PTR records, however, we need to digress and talk about a special top-level domain called in-addr.arpa.
Fully qualified hostnames can be viewed as a notation in which the “most significant part” is on the right. For example, in the name anchor.cs.colorado.edu, anchor is in cs, cs is in colorado, and colorado is in edu. IP addresses, on the other hand, have the “most significant part” on the left. In the address 128.138.243.100, host 100 is on subnet 243, which is part of network 128.138.
The in-addr.arpa domain was created to allow one set of software modules and one naming tree to map from IP addresses to hostnames as well as from hostnames to IP addresses. Domains under in-addr.arpa are named like IP addresses with their bytes reversed. For example, the zone for our 243 subnet is 243.138.128.in-addr.arpa.
The general format of a PTR record is
addr [ttl] IN PTR hostname
For example, the PTR record in the 243.138.128.in-addr.arpa zone that corresponds to anchor’s A record above is
100 IN PTR anchor.cs.colorado.edu.
The name 100 does not end in a dot and therefore is relative. But relative to what? Not “cs.colorado.edu.”. For this sample record to be accurate, the default domain has to be “243.138.128.in-addr.arpa.”.
You can set the domain by putting the PTR records for each subnet in their own file, as in this example. The default domain associated with the file is set in named’s configuration file. Another way to do reverse mappings is to include records such as
100.243 IN PTR anchor.cs.colorado.edu.
with a default domain of 138.128.in-addr.arpa. Some sites put all reverse records in the same file and use $ORIGIN directives to specify the subnet. Note that the hostname anchor.cs.colorado.edu must end with a dot to prevent 138.128.in-addr.arpa from being appended to its name.
Since cs.colorado.edu and 243.138.128.in-addr.arpa are different regions of the DNS namespace, they constitute two separate zones. Each zone must have its own SOA record and RRs. In addition to defining an in-addr.arpa zone for each real network, you also need a zone that takes care of the loopback network, 127.0.0.0.
This all works fine if the subnets are on byte boundaries. But how do you handle the reverse mappings for a subnet such as 128.138.243.0/26? An elegant hack defined in RFC2317 exploits CNAME resource records to accomplish this feat; see page 445.
The reverse mappings provided by PTR records are used by any program that authenticates inbound network traffic. For example, sshd may allow remote logins without a password if the machine of origin is listed, by name, in a user’s ~/.shosts file. When the destination host receives a connection request, it knows the source machine only by IP address. It uses DNS to convert the IP address to a hostname, which is then compared to the appropriate file. netstat, tcpd, sendmail, sshd, X Windows, syslogd, fingerd, ftpd, and rlogind all do reverse mappings to get hostnames from IP addresses.
It is important that A records match their corresponding PTR records. Mismatched and missing PTR records cause authentication failures that can slow your system to a crawl. This problem is annoying in itself; it can also