Introduction
The Domain Name System (DNS) is one of the most fundamental components of today’s Internet. In fact, most Internet applications, including e-mail and WWW, depend on the DNS in some way. This is also the case for applications that support IPv6 and for new IPv6 specific applications.
DNS is flexible enough to support IPv6 with straightforward extensions. Still, there are some nontrivial issues regarding IPv6. This is partly because the DNS itself is an Internet application, and the use of the DNS over IPv6 introduces a new level of complexities which are not seen with only IPv4. Also, there are known misbehaviors in some existing DNS implementations that handle IPv6 extensions to the DNS in an inappropriate way, causing trouble not only for IPv6 users but also for those who do not use IPv6. It is therefore important for all kinds of Internet users and developers to understand how the DNS operates with IPv6.
This topic describes the DNS protocol specification and implementation, focusing on IPv6-specific topics. It begins with a general description of the DNS protocol, followed by an explanation of extensions for IPv6 along with discussions on IPv6-specific issues.Together, these two topics will provide a comprehensive view of the complicated library. The latter half of this topic talks about BIND, the most widely deployed DNS server implementation. It describes how to operate DNS with IPv6 using the latest version of BIND, BIND9, as well as explains common pitfalls and issues that come from implementation characteristics of BIND9.
This section provides some basic background to help understand the later discussion in this topic. It explains fundamental concepts of the DNS, which are not specific to IPv6, so that those who are not familiar with the DNS can better understand the rest of this topic. To understand the DNS in more detail, other materials cited in the text are recommended. Beginners may also want to consult general guides about the DNS such as [Liu06].
DNS, Domains, and Zones
DNS is a global database system which provides a mapping from a host name1 (such as www.kame.example) to an IP address (such as 192.0.2.1 or 2001 :db8::1), or vice versa. It is a distributed and hierarchical system, ensuring coherency as well as avoiding a single point of failure. The results of database lookups are often cached, reducing network traffic and server load, and increasing lookup efficiency.
From the data structure point of view, the database system of the DNS is represented as a labeled tree called the domain name space. Figure 3-1 shows a part of the tree structure. The strings associated with tree nodes are called DNS labels, which consist of alphabets, numeric numbers, and the dash character (-). A domain is a sub-tree whose root is an arbitrary node in the entire tree. The domain name of a domain is a string concatenating all labels from the domain’s root to the root of the entire name space, separated with periods.
In Figure 3-1, example, wide, ftp, and www are labels. Strings ftp.kame.net., wide.example., and jp. are domain names. Technically, the terminating period is a part of a domain name, but it is often omitted when the context makes it clear. For example, people often say the example domain, instead of the example, domain, as does this topic.
As will soon be seen, domains starting at a top level (i.e., near the root) are particularly important for DNS operation. These domains are generally called Top Level Domains (TLDs), and TLDs are often referred to by specific names. The entire name space is called the root domain, and some common first-level domains are called generic top level domains or gTLDs. Examples of gTLDs are the com, net, and org domains. At the first level, there are also per-country domain names, which are called country code top level domains (or ccTLDs). There is no technical difference between gTLDs and ccTLDs in terms of the DNS protocol; the difference is in who manages the corresponding name space.
An arbitrary connected subset of the name space can be a notion called a zone. Every node in the name space belongs to one and only one of the zones, which allows a zone to define an administration boundary of a particular part of the name space. Note that a zone is not necessarily a sub-tree, and does not necessarily equal the domain of the same name. In fact, the corresponding zones for most top-level domains are not equal to the domains; in particular, the root zone effectively consists of the root node only.
Each zone is served by one or more nameservers. A nameserver of a zone maintains domain names within the zone, and responds to database queries for the names. Nameservers are often called authoritative (DNS) servers. Nameservers of the root zone and gTLD zones are called the root servers and the gTLD servers, respectively. One single nameserver can serve for multiple different zones. For example, com and net zones are served by the same set of nameservers.
FIGURE 2-24
Many zones have more than one authoritative server, particularly in the case of top-level zones, to provide redundancy and improve stability. Usually only one of them maintains the master database, which is called the primary (or master) server of the zone. Other nameservers, called secondary (or slave) servers, periodically synchronize with the primary server to provide coherent behavior. This process is called a zone transfer.
There are several techniques to make the zone transfer mechanism more timely and efficient, but the details of those techniques are beyond the scope of this topic.
In general, an upper level (called parent) zone delegates the administration authority for some lower-level domains to lower level (called child) zones. Figure 3-2 shows an example of the delegation relationship. In this example, the authority for the example domain is delegated to a separate zone from the root zone. The example domain contains several subdomains, each of which forms a separate zone. That is, the example zone is not equal to the example domain. This also applies to the com zone and domain. On the other hand, the kame.example and wide.example domains are each managed with the same single authority, even though the wide.example domain contains a subdomain, child.wide.example. In these cases, the zone equals the domain.
FIGURE 2-24
Resource Records and Zone Files
Resource records (often abbreviated as RRs) are database entries in the DNS. When it is obvious from the context, a resource record will be referred to as just a record in the rest of this topic. A resource record consists of the following six fields:
NAME A domain name, which is a lookup key for this resource record. This field is also referred to as owner name.
TYPE The type of the resource record (2 bytes). For example, a type A record means a mapping from a domain name to an IPv4 address.
CLASS The identifier of a protocol family or instance of a protocol (2 bytes). For normal DNS operation, only the IN (Internet) class is used.
TTL The time to live of this resource record represented in seconds (4 bytes). This determines how long a resource record is allowed to exist in a cache.
RDLENGTH The length of RDATA represented in bytes (2 bytes).
RDATA Type dependent data. For a type A resource record, RDATA is an IPv4 address (and RDLENGTH is 4).
Some of the fields have a fixed length, which is specified in the above description. These fields appear in this order in DNS messages.
Table 3-1 shows a list of some major resource records. A set of the resource records constructs a zone. In a valid zone, there must be exactly one SOA resource record and one or more NS records that represent the authoritative servers of the zone. The NAME field of these records must be the zone’s name, which corresponds to the topmost node in the zone.
A zone file (or a master file) is a textual representation of a zone as a set of resource records. In a zone file, each record of the zone is represented in the following format:
For example, an A record specifying a mapping from www.kame.example to 192.0.2.1 with the TTL of 3600 seconds can be represented as follows:
TTL and CLASS can be omitted. In particular, the CLASS field will often be omitted in the examples in the rest of this topic, since they are all of the IN class.
TABLE 3-1
|
Type |
RDLENGTH |
RDATA |
Description |
|
A |
4 |
An IPv4 address |
Provides a mapping from a host name (the owner name) to an IPv4 address. |
|
NS |
variable |
A domain name |
Provides a host (nameserver) name of a zone’s authoritative server. |
|
CNAME |
variable |
A domain name |
Defines an alias of the owner name, that is, the RDATA of a CNAME RR is another name of the owner name. |
|
SOA |
variable |
Seven-tuple values |
Defines zone’s property. |
|
PTR |
variable |
A domain name |
Points to some location in the name space. The RDATA of a PTR RR has no official semantics in the DNS protocol definition, but it commonly provides a mapping from an IP address to a host name. |
|
MX |
variable |
A set of a 16-bit integer and a domain name |
Provides a host name of a mail server for a domain specified by the owner name. The integer defines the preference among multiple servers. |
|
AAAA |
16 |
An IPv6 address |
Provides a mapping from a host name (the owner name) to an IPv6 address. More details of the AAAA RR will be discussed in Section 3.3.1. |
FIGURE 2-24
Multiple resource records for the same owner name, class, and type can usually coexist in a single zone with some exceptions such as SOA and CNAME records. The entire set of resource records that share the same owner name, class, and type is called a resource record set, which is often abbreviated to RRset.
