Basics of DNS Definitions and Protocols (DNS for IPv6) Part 2

DNS Transaction and Packet Format

From the database transaction point of view, DNS is a network protocol based on the server-client model, in which servers are nameservers, and clients are called resolvers. A server waits for queries on the well-known UDP and TCP ports of 53. A resolver first sends a query over UDP, rather than TCP, to the well-known port of an appropriate server as required in [RFC1123], and the server sends a response to the client over UDP. TCP is used for some special cases such as zone transfer or when the message is too large to carry over UDP (see Section 3.3.4).

Regardless of whether it is carried over UDP or TCP, a DNS query or response begins with a common Header section.2 Other sections follow as shown in Figure 3-3, some of which may be empty.

Each section that follows the Header section carries the following information per [RFC1034]: Question Carries the query name

Answer Carries the answer resource records to the query name

Authority Carries resource records which describe authoritative servers. The nameserver information that has the authority of the response is provided in this section.

Additional Carries resource records which may be helpful in using the records in the other sections.

Figure 3-4 details the format of the Header section.

FIGURE 2-24

[RFC1035] defines some fields of the Header section as follows:

Query ID A 16-bit identifier assigned by the program that generates a query. This identifier is copied to the corresponding reply and can be used by the requester to match up replies to outstanding queries.

QR A 1-bit field that specifies whether this message is a query (0), or a response (1).

OPCODE A 4-bit field that specifies the type of query in this message. This value is usually zero, which means a standard query.

AA Authoritative Answer bit. This bit is only valid in responses, and specifies that the responding nameserver have an authority for the domain name in the Question section.

TC Truncation bit. This specifies that this message was truncated due to a length greater than that permitted on the transmission channel (see Section 3.3.4).

RD Recursion Desired bit. This bit may be set in a query and is copied into the response. When set, it directs the responding server to pursue the query recursively (see Section 3.2.4 for recursive query).

RA Recursion Available bit. This bit is set or cleared in a response and denotes whether recursive query support is available in the responding server.

Z Reserved for future use. This field must be zero in all queries and responses.

RCODE A 4-bit Response Code. This field is set as part of responses. The available RCODE values are listed in Table 3-2.

QDCOUNT An unsigned 16-bit integer specifying the number of entries in the Question section.

ANCOUNT An unsigned 16-bit integer specifying the number of resource records in the Answer section.

NSCOUNT An unsigned 16-bit integer specifying the number of (nameserver) resource records in the Authority section.

ARCOUNT An unsigned 16-bit integer specifying the number of resource records in the Additional section.

TABLE 3-2

Value	Description
0	No error condition.
1	Format Error—The server was unable to interpret the query.
2	Server Failure—The server was unable to process this query due to a problem with the name-server.
3	Name Error—Meaningful only for responses from an authoritative nameserver, this code signifies that the domain name of any resource record type referenced in the query does not exist. This code is also known as NXDOMAIN, the term derived from widely deployed implementations.
4	Not Implemented—The server does not support the requested kind of query.
5	Refused—The server refuses to perform the specified operation for policy reasons.
6-15	Reserved for future use.

FIGURE 3-5  

In addition, [RFC2535] defines the AD and CD bits for the security extensions to the DNS (DNSSEC). DNSSEC is beyond the scope of this topic; therefore, these bits are not referred to in the following discussion.

The format of the Question section is shown in Figure 3-5. This section is simple and intuitive: QNAME is a domain name of the query or response, and QTYPE and QCLASS specify the type and class of the queried resource records, respectively.

Each of the remaining sections consists of a sequence of 0 or 1 or more resource records as indicated in the corresponding COUNT field of the header.

Name Resolution and Caching

Name resolution (or simply resolution) is the lookup process in the DNS. Resolution of an IP address from a host name is called forward resolution or forward lookup; resolution of a host name from an IP address is called a reverse resolution or reverse lookup. Likewise, a subset of the domain name space that is used for forward resolution is often called the forward tree, and a subset for reverse resolution is sometimes called the reverse tree; the mapping provided by the DNS for forward and reverse resolution is called forward mapping and reverse mapping, respectively.

How does a resolver perform the resolution process? Before answering the question, the notion of caching should be introduced. A resolver implemented in a host operating system, often called a stub resolver, usually does not send a query directly to authoritative DNS servers. Instead, it uses a more powerful resolver, called recursive (or iterative) resolver or caching server, which performs the essential part of name resolution. It thus makes more sense to describe the resolution process with a caching server.

Figure 3-6 shows examples of the name resolution process with stub resolvers and a caching server. The stub resolvers only interact with the caching server, and the caching server communicates with authoritative servers. Queries from a stub resolver to the caching server set the RD bit of the Header section, asking the caching server to perform the full resolution process, and are called recursive queries. Also, the procedure that the caching server performs is sometimes called recursive resolution.

The following describes a common resolution process, as shown in Figure 3-6.

1. Stub resolver A sends a recursive query for name www.kame.example to the caching server.

2. The caching server begins the recursive resolution process with a root server by sending a nonrecursive query for www.kame.example to the root server.

Note: To resolve the bootstrap problem, the addresses of the root servers are usually provided as a hint zone file or hardcoded in the caching server implementation. The example shown in Figure 3-6 assumes the hint is provided as a file named root.cache.

3. In general, when an authoritative server receives a query for a domain name, it searches for the zone that best matches the queried name, and, if found, responds with the corresponding resource records stored in the zone.

FIGURE 3-6

The response may be a determinate one stored in the zone or, in case the queried name belongs to a zone for which the server does not have authority, a referral to the another zone.

In this example, since the root zone delegates the authority for the example domain to the example zone, the root server returns a referral, in the form of an NS RRset in the Authority section, to the caching server. The NS RRset would be described as follows:

This means the nameservers that maintain the delegated zone are identified by the name of nsl.example and ns2.example. As shown in the next steps, the caching server will then need to send queries to these servers, so it will need to know the IP (v4 or v6) addresses of these names. Although the addresses would be given via A and AAAA resource records of these names, the records belong to the example domain that the caching server is now going to explore.

To resolve the chicken and egg problem, the nameserver at the parent zone (the root server in this case) maintains a copy of such A and AAAA RRsets3 associated with each NS record for delegation from the parent zone, and includes these A or AAAA RRsets in the Additional section. For example, the Additional section of the referral answer would be something like this:

This way the caching server can send further queries to the nameservers of the delegated zone. These A or AAAA resource records are called glue (resource) records.

4. The caching server caches the result, and sends the same query to one of the specified authoritative servers. Again, since the example zone delegates the authority of the kame.example domain to the kame.example zone, it in turn returns a referral (NS RRset) with glue records for the child zone.

5. The caching server caches the result, and sends the same query to a specified authoritative server of the kame.example zone. This time, the authoritative server has a record for the query name in its zone file, and sends the result to the caching server.

6. The caching server caches the result, and forwards it to stub resolver A.

7. Next, assume that a different stub resolver (B) asks the caching server for the same name www.kame.example. Since the caching server has already cached the result, it simply returns the cached response without asking the authoritative servers.

8. Finally, another stub resolver (C) asks a slightly different name ftp.kame.example.

9. The caching server does not have a cache for this name, but knows where to ask for names under the kame.example domain (as a result of step 4). It can directly query an authoritative server of the kame.example zone, and the authoritative server returns a response from its zone file.

10. The caching server caches the result, and forwards it to stub resolver C.