Chapter 11. Name Resolution and the Domain Name System (DNS)

To identify hosts, IP addresses (especially IPv6 addresses) are cumbersome for humans to use and remember. The Internet supports the use of host names to identify hosts, both clients and servers. In order to be used by protocols such as TCP and IP, host names are converted into IP addresses using a process known as name resolution. There are different forms of name resolution in the Internet, but the most prevalent and important one uses a distributed database system known as the Domain Name System (DNS). DNS runs as an application on the Internet, using IPv4 or IPv6 (or both). For scalability, DNS names are hierarchical, as are the servers that support name resolution.

DNS is a distributed client/server networked database used by TCP/IP applications to map between host names and IP addresses (and vice versa), to provide capabilities like electronic mail routing information and service naming. The DNS provides the protocol that allows clients and servers to communicate with each other and also a protocol for allowing servers to exchange information. [p511]

From an application’s point of view, access to the DNS is through an application library called a resolver. An application must convert a host name to an IPv4 and/or IPv6 address before it can ask TCP to open a connection or send a unicast datagram using UDP. The TCP and IP protocol implementations know nothing about the DNS; they operate only with the addresses.

This chapter covers:

The DNS Name Space

The DNS name space is the set of all names used with DNS. This space is partitioned hierarchically and is case insensitive.

The current DNS name space is a tree of domains with an unnamed root at the top. The top echelons of the tree are the so-called top-level domains (TLDs), which include:

These form the top levels of a naming tree with the form shown below.

The DNS name space forms a hierarchy with an unnamed root at the top. The top-level domains (TLDs) include generic TLDs (gTLDs), countrycode TLDs (ccTLDs), internationalized TLDs (IDN ccTLDs), and a special infrastructure TLD called ARPA.

There are five commonly used groups of TLDs, and one group of specialized domains being used for internationalized domain names (IDNs). [p512]

The gTLDs are grouped into categories:

The generic gTLDs (generic appears twice) are open for unrestricted use. The others (generic-restricted and sponsored) are limited to various sorts of uses or are constrained as to what entity may assign names from the domain.

There is a "new gTLD" program in the works that may significantly expand the current set, possibly to several hundred or even thousand. This program and policies relating to TLD management in general are maintained by the Internet Corporation for Assigned Names and Numbers (ICANN).

Because some of these two-letter country codes of ccTLDs are suggestive of other uses and meanings, various countries have been able to find commercial windfalls from selling names within their ccTLDs. For example, the domain name cnn.tv is really a registration in the Pacific island of Tuvalu, which has been selling domain names associated with the television entertainment industry. This is called a domain hack.

DNS Naming Syntax

The names below a TLD in the DNS name tree are further partitioned into subdomains, which is very common practice, especially for the ccTLDs.

Fully qualified domain name (FQDN) *

The example names we have seen so far are known as fully qualified domain names (FQDNs). They are sometimes written more formally with a trailing period (e.g., mit.edu.). This trailing period indicates that the name is complete; no additional information should be added to the name when performing a name resolution.

Unqualified domain name *

An unqualified domain name, which is used in combination with a default domain or domain search list set during system configuration, has one or more strings appended to the end. During configuration, system is typically assigned a default domain extension and search list using DHCP. For example, the default domain cs.berkeley.edu might be configured in systems at the computer science department at UC Berkeley. If a user on one of these machines types in the name vangogh, the local resolver software converts this name to the FQDN vangogh.cs.berkeley.edu. before invoking a resolver to determine vangogh’s IP address.

A domain name consists of a sequence of labels separated by periods. The name represents a location in the name hierarchy, where the period is the hierarchy delimiter and descending down the tree takes place from right to left in the name.

The hierarchical structure of the DNS name space allows different administrative authorities to manage different parts of the name space. For example, creating a new DNS name elevator.cs.berkeley.edu wouldrequire dealing with the owner of the cs.berkeley.edu subdomain only. The berkeley.edu and edu portions of the name space would not require alteration, so the owners of those would not need to be bothered. This feature of DNS is one key aspect of its scalability. No single entity is required to administer all the changes for the entire DNS name space. [p516]

Name Servers and Zones

A person responsible for managing part of the active DNS name space is supposed to arrange for at least two name servers or DNS servers to hold information about the name space so that Internet users can perform queries on the names.

The DNS (formed by servers) is a distributed system whose primary job is to provide name-to-address mappings; however, it can also provide a wide array of additional information.

A zone, as the unit of administrative delegation, is a subtree of the DNS name space that can be administered separately from other zones. Every domain name exists within some zone (even the TLDs that exist in the root zone). Whenever a new record is added to a zone, the DNS administrator for the zone allocates a name and additional information (usually an IP address) for the new entry into the name server’s database. For example:

A DNS server can contain information for more than one zone. At any hierarchical change point in a domain name (i.e., wherever a period appears), a different zone and containing server may be accessed to provide information for the name. This is called a delegation. A common delegation approach uses a zone for implementing a second-level domain name, such as berkeley.edu. In this domain, there may be individual hosts (e.g., www.berkeley.edu) or other domains (e.g., cs.berkeley.edu). Each zone has a designated owner or responsible party who is given authority to manage the names, addresses, and subordinate zones within the zone. Often this person manages not only the contents of the zone but also the name servers that contain the zone’s database(s).

For redundancy, zone information is supposed to exist in at least two places: there should be at least two servers containing information for each zone. All of these servers contain identical information about a zone. Among the servers, a primary server contains the zone database in a disk file, and one or more secondary servers obtain copies from the primary using a process called a zone transfer. DNS has a special protocol for performing zone transfers, but copies of a zone’s contents can also be obtained using other means (e.g., the rsync utility).

Caching

Name servers contain information (e.g. name-to-IP-address mappings) that may be obtained from three sources:

  1. Directly from the zone database,
  2. As the result of a zone transfer (e.g., for a slave server),
  3. From another server in the course of processing a resolution.

In the first case, the server is said to contain authoritative information about the zone and may be called an authoritative server for the zone. Such servers are identified by name within the zone information.

Most name servers (except some root and TLD servers) also cache zone information they learn, up to a time limit called the time to live (TTL). They use this cached information to answer queries. This greatly decreases the amount of DNS message traffic on the Internet. When answering a query, a server indicates whether the information it is returning has been derived from its cache or from its authoritative copy of the zone. When cached information is returned, it is common for a server to also include the domain names of the name servers that can be contacted to retrieve authoritative information about the corresponding zone.

Each DNS record has its own TTL, which are set and altered by the zone administrator when necessary. If a zone changes, there still may exist cached data within the network, leading to incorrect DNS resolution behavior until expiry of the TTL. For this reason, some zone administrators, anticipating a change to the zone contents, first reduce the TTL before implementing the change. This reduces the window for incorrect cached data to be present in the network.

Caching is applied both for successful and unsuccessful resolutions (called negative caching). If a request for a particular domain name fails to return a record, this fact is also cached. This reduces Internet traffic when errant applications repeatedly make requests for names that do not exist.

In some network configurations, the cache is maintained in a nearby name server, not in the resolvers resident in the clients. Placing the cache in the server allows any hosts on the LAN that use the nearby server to benefit from the server’s cache but implies a small delay in accessing the cache over the local network. In Windows and more recent systems, the client can maintain a cache, and it is made available to all applications running on the same system. In Windows, this happens by default, and in Linux, it is a service that can be enabled or disabled.

nscd(8) and nsswitch.conf(5) *

In Linux , the Name Service Caching Daemon (NSCD) provides a client-side caching capability. It is controlled by the /etc/nscd.conf file that can indicate which types of resolutions (for DNS and some other services) are cached, along with some cache parameters such as TTL settings. T

The file /etc/nsswitch.conf controls how name resolution for applications takes place. It also controls whether local files, the DNS protocol, and/or NSCD is employed for mappings.

The DNS Protocol

The DNS protocol consists of two main parts:

It has other functionalities:

DNS name resolution is the process of mapping a domain name to an IPv4 address, although IPv6 addresses mappings work in essentially the same way. DNS query/response operations are supported over the distributed DNS infrastructure consisting of servers deployed locally at each site or ISP, and a special set of root servers. There is also a special set of generic top-level domain servers used for scaling some of the larger gTLDs, including COM and NET.

As of mid-2011, there are:

Some of them are not a single physical server but a group of servers (over 50 for the J root server) that use the same IP address (i.e., using IP anycast addressing; Chapter 2).

Recursive query *

A full resolution that is unable to benefit from preexisting cached entries takes place among several entities, as shown in the figure below:

 A typical recursive DNS query for EXAMPLE.COM from A.HOME involves up to ten messages. The local recursive server (GW.HOME here) uses a DNS server provided by its ISP. That server, in turn, uses an Internet root name server and a gTLD server (for COM and NET TLDs) to find the name server for the EXAMPLE.COM domain. That name server (A.IANA-SERVERS.NET here) provides the required IP address for the host EXAMPLE.COM. All of the recursive servers cache any information learned for later use.

Here's what happened:

From A.HOME's side it seems the local name server was able to perform the request. What really happened is a recursive query, where the GW.HOME and ISP-provided servers in turn made additional DNS requests to satisfy A.HOME’s query. In general, most name servers perform recursive queries such as this. The notable exceptions are the root servers and other TLD servers that do not perform recursive queries. These servers are a relatively precious resource, so encumbering them with recursive queries for every machine that performs a DNS query would lead to poor global Internet performance.

Default domain search list *

In the previous query example, if the A.HOME system is configured with a default domain search list, there may be additional queries. For example, if .HOME is a default search domain used by A.HOME, the first DNS query may be for the name EXAMPLE.COM.HOME, which will fail at the GW.HOME name server, which is authoritative for .HOME. A subsequent query will typically remove the default extension, resulting in a query for EXAMPLE.COM.

DNS Message Format

There is one basic DNS message format used for all DNS operations (queries, responses, zone transfers, notifications, and dynamic updates), as illustrated in the figure below:

The DNS message format has a fixed 12-byte header. The entire message is usually carried in a UDP/IPv4 datagram and limited to 512 bytes. DNS UPDATE (DNS with dynamic updates) uses the field names ZOCOUNT, PRCOUNT, UPCOUNT, and ADCOUNT. A special extension format (called EDNS0) allows messages to be larger than 512 bytes, which is required for DNSSEC (see Chapter 18).

The basic DNS message begins with a fixed 12-byte header followed by four variable-length sections:

All but the first section (question section) contain one or more resource records (RRs), which is detailed in Section 11.5.6. The question section contains a data item that is very close in structure to an RR. RRs can be cached; questions are not.

Value Name Reference Description and Purpose
0 NoError [RFC1035] No error
1 FormErr [RFC1035] Format error; query cannot be interpreted
2 ServFail [RFC1035] Server failure; error in processing at server
3 NXDomain [RFC1035] Nonexistent domain; unknown domain referenced
4 NotImp [RFC1035] Not implemented; request not supported in server
5 Refused [RFC1035] Refused; server unwilling to provide answer
6 YXDomain [RFC2136] Name exists but should not (used with updates)
7 YXRRSet [RFC2136] RRSet exists but should not (used with updates)
8 NXRRSet [RFC2136] RRSet does not exist but should (used with updates)
9 NotAuth [RFC2136] Server not authorized for zone (used with updates)
10 NotZone [RFC2136] Name not contained in zone (used with updates)

The next four fields are 16 bits in size and specify the number of entries in the question, answer, authority, and additional information sections that complete the DNS message.

Questions have a name, type, and class. All of the other sections contain zero or more RRs. RRs contain a name, type, and class information, but also the TTL value that controls how long the data can be cached. [p521]

Names and Labels

The variable-length sections at the end of a DNS message contain a collection of:

Each question and each RR begins with a name (called the domain name or owning name) to which it refers. Each name consists of a sequence of labels. There are two categories of label types:

Data Labels

Each data label begins with a 1-byte count that specifies the number of bytes that immediately follow. The name is terminated with a byte containing the value 0, which is a label with a length of 0 (the label of the root).

DNS names are encoded as a sequence of labels. This example encodes the name www.pearson.com, which (technically) has four labels. The end of the name is identified by a 0-length label of the nameless root.

Compression Labels

A DNS response may carry information in the answer, authority, and additional information sections relating to the same domain name. For data labels the same characters would be repeated in the DNS message when referring to the same name. To avoid this redundancy and save space, a compression scheme is used.

The following figure illustrates how to encode the domain names usc.edu and ucla.edu using compression labels.

 A compression label can reference other labels to save space. This is accomplished by setting the 2 high-order bits of the byte preceding the label contents. This signals that the following 14 bits are used in providing an offset for the replacement label. In this example, usc.edu and ucla.edu share the edu label.

In the above figure, common label edu can be shared by the two domain names:

This example shows a savings of only 4 bytes, but it is clear how compression of larger common labels can result in more substantial savings.

The DNS Extension Format (EDNS0)

An extension mechanism called EDNS0 (because there could be future extensions beyond the index 0) is specified in [RFC2671]. It is necessary for supporting DNS security (DNSSEC; see Chapter 18).

EDNS0 specifies a particular type of RR (called an OPT pseudo-RR or meta-RR) that is added to the additional data section of a request or response to indicate the use of EDNS0; at most one such record may be present in any DNS message. If a UDP DNS message includes an OPT RR, it is permitted to exceed the 512-byte length limitation and may contain an expanded set of error codes.

EDNS0 also defines an extended label type (extending beyond the data labels and compression labels mentioned earlier). Extended labels have their first 2 bits in the label Type/Length byte set to 01, corresponding to values between 64 and 127 (inclusive). [p525]

UDP or TCP

The well-known port number for DNS is 53, for both UDP and TCP. The most common format uses the UDP/IPv4 datagram structure is shown below:

DNS messages are typically encapsulated in a UDP/IPv4 datagram and are limited to 512 bytes in size unless TCP and/or EDNS0 is used. Each section (except the question section) contains a set of resource records

When a secondary name server for a zone starts up, it normally performs a zone transfer from the primary name server for the zone. Zone transfers can also be initiated by a timer or as a result of a DNS NOTIFY message (Section 11.5.8.3).

When UDP is used, both the resolver and the server application software must perform their own timeout and retransmission. RFC1536 suggests starting with a timeout of at least 4s, and that subsequent timeouts result in an exponential increase of the timeout (a bit like TCP’s algorithms; see Chapter 14). Linux and UNIX-like systems allow a change to be made to the retransmission timeout parameters by altering the contents of the /etc/resolv.conf file (by setting the timeout and attempts options).

Question (Query) and Zone Section Format

The question or query section of a DNS message lists the question(s) being referenced. The format of each question in the question section is shown the figure below. There is normally just one, although the protocol can support more. The same structure is also used for the zone section in dynamic updates (Section 11.5.7), but with different names.

Answer, Authority, and Additional Information Section Formats

The answer, authority, and additional information (final sections in the DNS message) sections contain sets of RRs. RRs in these sections can, for the most part, have wildcard domain names as owning names. These are domain names in which the asterisk label (a data label containing only the asterisk character) appears first.

The format of a DNS resource record. For DNS in the Internet, the Class field always contains the value 1. The TTL field gives the maximum amount of time the RR can be cached (in seconds).

The Resource Record Set (RRSet) is a set of resource records that share the same name, class, and type but not the same data. For example, RRSet occurs when a host has more than one address record for its name (e.g., because it has more than one IP address). TTLs for RRs in the same RRSet must be equal.

Resource Record Types

There are many types of resource records and a single name may have multiple matching RRs. The following table provides a listing of the most common RR types used with conventional DNS (i.e., DNS without the DNSSEC security extensions).

Value RR Type Reference Description and Purpose
1 A [RFC1035] Address record for IPv4 (32-bit IPv4 address)
2 NS [RFC1035] Name server; provides name of authoritative name server for zone
5 CNAME [RFC1035] Canonical name; maps one name to another (to provide a form of name aliasing)
6 SOA [RFC1035] Start of authority; provides authoritative information for the zone (name servers, e-mail address of contact, serial number, zone transfer timers)
12 PTR [RFC1035] Pointer; provides address to (canonical) name mapping; used with in-addr.arpa and ip6.arpa domains for IPv4 and IPv6 reverse queries
15 MX [RFC1035] Mail exchanger; provides name of e-mail handling host for a domain
16 TXT [RFC1035] [RFC1464] Text; provides a variety of information (e.g., used with SPF anti-spam scheme to identify authorized e-mail servers)
28 AAAA [RFC3596] Address record for IPv6 (128-bit IPv6 address)
33 SRV [RFC2782] Server selection; transport endpoints of a generic service
35 NAPTR [RFC3403] Name authority pointer; supports alternative name spaces
41 OPT [RFC2671] Pseudo-RR; supports larger datagrams, labels, return codes in EDNS0
251 IXFR [RFC1995] Incremental zone transfer
252 AXFR [RFC1035] [RFC5936] Full zone transfer; carried over TCP
255 (ANY) [RFC1035] Request for all (any) records

Dynamic Updates (DNS UPDATE)

Zone Transfers and DNS NOTIFY

Full Zone Transfers (AXFR Messages)
Incremental Zone Transfers (IXFR Messages)
DNS NOTIFY

Sort Lists, Round-Robin, and Split DNS

Consider what data is returned and in what order in response to a DNS query. A DNS server could return all matching data to any client in whatever order the server finds most convenient. However, special configuration options and behaviors are available in most DNS server software to achieve certain operational, privacy, or performance goals. Consider the the topology shown below:

In a small enterprise topology, DNS may be configured to return different addresses depending on the requesting IP address.

A host wishing to contact M performs a DNS lookup that returns two addresses: one associated with the internal network and one with the DMZ. It would be more efficient if A, B, and R reached M via the DMZ and C reached M via the internal network, which happens if the DNS server orders its returned address records based on the source IP address of the request (It could also use the destination IP address, especially if M uses multiple IP addresses from different subnets on the same network interface.):

Load-balancing *

A related situation arises when one service is offered using more than one server such that the incoming connections are load-balanced (i.e., divided among the servers).

In the preceding example, imagine that a service is offered on both A and B and such a service may be identified by the URL http://www.example.com:

However, this load balancing mechanism is far from perfect:

Split DNS

A final consideration regarding the data returned by a DNS server is support for privacy. In the previous example, we may wish to arrange for hosts within the enterprise to be able to retrieve resource records for every computer in the network, while we limit the set of systems that remain visible to R.

Split DNS is a technique for implementing this goal. In split DNS, the set of resource records returned in response to a query is dependent on the identity of the client and possibly query destination address. Most often, the client is identified by IP address or address prefix. With split DNS, we could arrange for any host in the enterprise (i.e., those sharing a set of prefixes) to be provided with the entire DNS database, whereas those outside are given visibility only to A and B, where the main Web service is offered.