11.2 Domain Name System (DNS)

11.2 Domain Name System (DNS)

The DNS is used primarily to map between hostnames and IP addresses. A hostname can be either a simple name , such as solaris or freebsd , or a fully qualified domain name '(FQDN), such as solaris.unpbook.com .

Technically, an FQDN is also called an absolute name and must end with a period, but users often omit the ending period. The trailing period tells the resolver that this name is fully qualified and it doesn't need to search its list of possible domains.

In this section, we will cover only the basics of the DNS that we need for network programming. Readers interested in additional details should consult Chapter 14 of TCPv1 and [Albitz and Liu 2001]. The additions required for IPv6 are in RFC 1886 [Thomson and Huitema 1995] and RFC 3152 [Bush 2001].

Resource Records

Entries in the DNS are known as resource records (RRs). There are only a few types of RRs that we are interested in.

A	An A record maps a hostname into a 32-bit IPv4 address. For example, here are the four DNS records for the host freebsd in the unpbook.com domain, the first of which is an A record: [View full width] freebsd IN A 12.106.32.254 IN AAAA 3ffe:b80:1f8d:1:a00:20ff :fea7:686b IN MX 5 freebsd.unpbook.com. IN MX 10 mailhost.unpbook.com.
AAAA	A AAAA record, called a "quad A" record, maps a hostname into a 128-bit IPv6 address. The term "quad A" was chosen because a 128-bit address is four times larger than a 32-bit address.
PTR	PTR records (called "pointer records") map IP addresses into hostnames. For an IPv4 address, then 4 bytes of the 32-bit address are reversed , each byte is converted to its decimal ASCII value (0 “255), and in-addr.arpa is the appended. The resulting string is used in the PTR query.
	For an IPv6 address, the 32 4-bit nibbles of the 128-bit address are reversed, each nibble is converted to its corresponding hexadecimal ASCII value ( 0 “9a “f ), and ip6.arpa is appended.
	For example, the two PTR records for our host freebsd would be 254.32.106.12.in-addr.arpa and b.6.8.6.7.a.e.f.f.f.0.2.0.0.a.0.1.0.0.0.d.8.f.1.0.8.b.0.e.f.f.3.ip6.arpa . Earlier standards specified that IPv6 addresses were looked up in the ip6.int domain. This was changed to ip6.arpa for consistency with IPv4. There will be a transition period during which both zones will be populated .
MX	An MX record specifies a host to act as a "mail exchanger " for the specified host. In the example for the host freebsd above, two MX records are provided: The first has a preference value of 5 and the second has a preference value of 10. When multiple MX records exist, they are used in order of preference, starting with the smallest value. We do not use MX records in this text, but we mention them because they are used extensively in the real world.
CNAME	CNAME stands for "canonical name." A common use is to assign CNAME records for common services, such as ftp and www . If people use these service names instead of the actual hostnames, it is transparent when a service is moved to another host. For example, the following could be CNAMEs for our host linux : ftp IN CNAME linux.unpbook.com. www IN CNAME linux.unpbook.com.

It is too early in the deployment of IPv6 to know what conventions administrators will use for hosts that support both IPv4 and IPv6. In our example earlier in this section, we specified both an A record and a AAAA record for our host freebsd . One possibility is to place both the A record and the AAAA record under the host's normal name (as shown earlier) and create another RR whose name ends in -4 containing the A record, another RR whose name ends in -6 containing the AAAA record, and another RR whose name ends in -611 containing a AAAA record with the host's link-local address (which is sometimes handy for debugging purposes). All the records for another of our hosts are then

 aix IN A 192.168.42.2 IN AAAA 3ffe:b80:1f8d:2:204:acff:fe17:bf38 IN MX 5 aix.unpbook.com. IN MX 10 mailhost.unpbook.com. aix-4 IN A 192.168.42.2 aix-6 IN AAAA 3ffe:b80:1f8d:2:204:acff:fe17:bf38 aix-611 IN AAAA fe80::204:acff:fe17:bf38 

This gives us additional control over the protocol chosen by some applications, as we will see in the next chapter.

Resolvers and Name Servers

Organizations run one or more name servers , often the program known as BIND (Berkeley Internet Name Domain). Applications such as the clients and servers that we are writing in this text contact a DNS server by calling functions in a library known as the resolver . The common resolver functions are gethostbyname and gethostbyaddr , both of which are described in this chapter. The former maps a hostname into its IPv4 addresses, and the latter does the reverse mapping.

Figure 11.1 shows a typical arrangement of applications, resolvers, and name servers. We now write the application code. On some systems, the resolver code is contained in a system library and is link-edited into the application when the application is built. On others, there is a centralized resolver daemon that all applications share, and the system library code performs RPCs to this daemon. In either case, application code calls the resolver code using normal function calls, typically calling the functions gethostbyname and gethostbyaddr .

Figure 11.1. Typical arrangement of clients, resolvers, and name servers.

The resolver code reads its system-dependent configuration files to determine the location of the organization's name servers. (We use the plural "name servers" because most organizations run multiple name servers, even though we show only one local server in the figure. Multiple name servers are absolutely required for reliability and redundancy.) The file /etc/resolv.conf normally contains the IP addresses of the local name servers.

It might be nice to use the names of the name servers in the /etc/resolv.conf file, since the names are easier to remember and configure, but this introduces a chicken-and-egg problem of where to go to do the name-to-address conversion for the server that will do the name and address conversion!

The resolver sends the query to the local name server using UDP. If the local name server does not know the answer, it will normally query other name servers across the Internet, also using UDP. If the answers are too large to fit in a UDP packet, the resolver will automatically switch to TCP.

DNS Alternatives

It is possible to obtain name and address information without using the DNS. Common alternatives are static host files (normally the file /etc/hosts , as we describe in Figure 11.21), the Network Information System (NIS) or Lightweight Directory Access Protocol (LDAP). Unfortunately, it is implementation-dependent how an administrator configures a host to use the different types of name services. Solaris 2.x, HP-UX 10 and later, and FreeBSD 5.x and later use the file /etc/nsswitch.conf , and AIX uses the file /etc/netsvc.conf . BIND 9.2.2 supplies its own version named the Information Retrieval Service (IRS), which uses the file /etc/irs.conf . If a name server is to be used for hostname lookups, then all these systems use the file /etc/resolv.conf to specify the IP addresses of the name servers. Fortunately, these differences are normally hidden to the application programmer, so we just call the resolver functions such as gethostbyname and gethostbyaddr .