| IPv6 Network - The DNS |
For us humans, it’s difficult and not very pleasant to work with IP addresses, especially with IPv6 addresses. Fortunately, the Domain Name System (DNS) allows us to work with much more user-friendly symbolic names most of the time.1 Because the DNS translates from names to IP addresses for us (and the other way around), the DNS itself needs to be updated to support IPv6. Due to its distributed nature, making the Domain Name System IPv6-aware is much more complex than upgrading a single application. Later in this chapter, we’ll look at the Berkeley Internet Name Domain (BIND) DNS server software, but before that, I’ll provide a refresher on how the DNS works and the changes that were necessary (and the changes that were not so necessary) for IPv6. Figure 5-1 shows the interaction between different parts of the Domain Name System.
DNS and BIND, by Paul Albitz and Cricket Liu (O’Reilly & Associates),
is an excellent guide to the subject. Unfortunately, the fourth edition was published in 2001, so it is outdated on the subject of IPv6 in the DNS.
When an application wants to communicate over the network, it takes the full name of the destination, such as www.example.com (this is often called the “fully qualified domain name,” or FQDN),2 and finds the matching IP address in the DNS. The application does this by calling on the resolver library. This is step 1 in Figure 5-1. The resolver library knows enough about the DNS protocol to be able to send a request for the required information to a “caching” or “recursive” DNS server using the DNS protocol (step 2). If the caching server just started and hasn’t had the chance yet to live up to its name by caching the answers to previous requests in its memory, it will have no idea where to find the requested information.
So it contacts one of the root DNS servers (step 3). The root servers don’t know the address for www.example.com either, but they do have pointers to the DNS servers responsible for all “top-level domains” (TLDs), such as .com, so in step 4, the root server sends back pointers to the .com TLD nameservers. Information received from remote nameservers such as this is kept in the local cache if it was received from a server that’s part of the authoritative delegation chain. The caching nameserver proceeds to contact one of the .com TLD servers and repeats the question about the address that goes with www.example.com in step 5. Like the root server, the TLD server doesn’t know the answer, but it supplies pointers to the nameservers that are responsible for the example.com domain name in step 6. In step 7, the caching server once again asks for the address information for www.example.com, and this time the answer finally contains the requested information (step 8). The caching server can now send back a response to the resolver library in step 9, which in turn relays the information to the application (step 10). The application now has the information it needs to (for instance) set up a TCP connection to www.example.com.
| Users' Comments (0) |
|
No comment posted
