DNS (the Domain Name System) is a distributed system — it’s stored in pieces across the network; no single computer holds all the information. The core of DNS is the database that stores information about domain names and addresses. Think of the DNS database as a kind of Internet telephone directory. Instead of looking up a name and finding a telephone number, you look up a computer’s name in the DNS database and find its IP address (or look up an IP address and find its name).
The heart of the Internet consists of DNS cooperating with the BGP-4 protocol so that messages travel from source computers to their destinations. DNS lives a triple life, in the form of these three elements:
✓ Protocol
✓ Service
✓ Database
On the Internet, if DNS knows an IP address, the BGP-4 protocol figures out how to get the message there. Without collaboration between DNS and BGP-4, the Internet wouldn’t work.
Lots of pieces collaborate for DNS: hardware, software (programs and TCP/ IP protocols), data files, and people. Working together, these components provide the ability to take a computer’s FQDN (fully qualified domain name) and look up its IP address or take a computer’s IP address and look up its FQDN. Remember, people prefer to use names, and computers prefer to use numbers. Luckily for us, TCP/IP has quite a few services, including DNS, that let people use names while computers use numbers.
If you’re simply interested in what DNS does, but not how it does it. Feel free to move on to another topic.
Taking a Look at the DNS Components
Here’s a brief introduction to the DNS components discussed in this topic:
✓ Distributed database: Holds information about computers’ names and their addresses in domains on the Internet or on your intranet
✓ Domain: A logical collection of computers whose requests for name/ address lookups are handled by the same server or servers
✓ Name server: A program that implements DNS by accessing information from the database and responding to client queries
✓ Client: A program that requests name/address lookups from the name servers
✓ Resolver: Client software that asks name servers to convert Internet host names to their IP addresses and to convert IP addresses to their Internet host names
✓ Cache: Stores DNS data in memory for quick access
✓ Zone: A group of computers created by network administrators to make managing them easier
✓ System and network administrator: Set up everything and maintain the databases
DNS domains are different from — and unrelated to — Microsoft Windows Server domains. Please forget (or at least ignore) everything you know about the Microsoft definition of a domain while you read this topic.
Going Back to DNS Basics
All servers connected to the Internet use DNS to translate FQDNs into IP addresses and vice versa. If you have a small intranet that never accesses the Internet, you could do without DNS and rely on your local hosts file.For each fully qualified domain name, such as www.example.com, the DNS database stores the domain name/IP address pair.
The database structure is a hierarchy (an upside-down tree) of FQDNs. Figure 10-1 illustrates the tree starting with the root, which is a dot (.). DNS is organized into an upside down tree with the DNS root domains at the top.
Figure 10-1:
DNS is organized into an upside-down tree.
The DNS database is distributed (decentralized) so that hundreds of different organizations share database management. With more than 80,000,000 branches in the .com domain alone (and growing every day), a central database would be so large as to be unmanageable.
By default, DNS doesn’t think about DHCP and IP addresses leased on request. DNS assumes all IP addresses are stable and do not change. Remember, when DNS was designed, DHCP servers were just a gleam in some pre-teen whiz kid’s eye.
Whenever you register a domain, your registrar adds a record to the DNS database.
In techie terms, DNS is the Internet’s name/address resolver. It translates FQDNs into IP numbers and IP numbers into FQDNs.
Revisiting Client/Server with DNS
A service is functionality, such as resolving a name into an address. The server is the software that implements the functionality.
DNS runs in a client/server style. Clients such as an e-mail client or a browser pass their FQDN requests to your resolver software. The resolver is a client of the server software called a name server. The following sections describe how DNS clients and its various servers operate behind the scenes.
Dishing up DNS client/server definitions
Client and server software work together so that DNS can translate an FQDN, such as the fictional www.angelinachocolat.com, to its IP address. DNS client and server terminology includes these elements:
✓ The DNS client software is part of TCP/IP, so it runs on your client machine automatically.
✓ The resolver is a library of programs that make up the client software. The resolver software asks the name server software for IP addresses.
✓ The cache is memory. When DNS responds to a name/address query, the information gets put into the cache, so that the next time you ask for the name/address resolution, the answer already sits in memory. That makes for much faster access than traipsing all over the Internet to solve the query again.
✓ The name server program responds to queries from the resolver to translate a name to an address and vice versa. The most common DNS server software is bind (Berkeley Internet Name Daemon). Bind9 is the latest version, with added performance features. BIND is usually included in TCP/IP. In many Unixes and Linuxes, BIND is there, but you might have to build it before it’s available for use. The name server program is part of TCP/IP.
Usually name servers are managed by ISPs. No worries for you. If you take a look back at the ipconfig example shown in Figure 5-3, you can see the IP address for the DNS server.
Snacking on resolvers and name servers
You don’t need to worry about installing any special resolver software because the resolver is part of TCP/IP. You need it. You have it. No problem. Unless you’re a TCP/IP programmer, your resolver is invisible.
If you’re a programmer writing an application that needs to know a computer’s address, you need to call the resolver routines.
When you run an application, such as e-mail or a Web browser, your DNS resolver looks for the domain name/address translation in your computer’s cache. If the IP information is not in cache, your resolver queries its primary name server (which is probably at your ISP) for a computer name-to-IP address translation:
✓ If the name server can answer the query, it responds with the requested information and all is well.
✓ If the first name server can’t answer the query, it starts a process of forwarding to other name servers until one has the name/address resolution. Figure 10-2 shows how a query may need to go to more than one name server to get the information it requests. The references to SRV1 and SRV2 are not to the computer; the references are to the BIND9 name server programs that the computers are running.
If, for some reason, you don’t like BIND9, you can use other name server software, such as NSD (Name Server Daemon) from www.nlnetlabs.nl/ projects/nsd and PowerDNS from powerdns.com.
Figure 10-2:
You may have to query more than one DNS server to find the address you’re looking for.
All DNS queries, except those in its cache, get forwarded to DNS servers (in this case, the primary DNS server and/or secondary DNS server). Even those responses from the cache are not authoritative. (See the later section "Who’s Responsible for Name and Address Information?" for more on authority.) Therefore, a heavy dependence still exists on the primary and secondary DNS servers in the network. If a long DNS disruption occurs, the data in the cache eventually expires.
When your client asks the name server for a name/IP address, you’re usually asking a name server program at your ISP. Most DNS name serving happens at an ISP. Sometimes very large organizations will choose to run private DNS name servers on their intranets before going out to the ISP.
Who’s in charge here ?
In DNS, a name server can be in one of three different states when queried by a client:
✓ State 1: The name server knows the IP address authoritatively, meaning it’s responsible for the data and has the answer in the database on its hard drive. The network administrator maintains a set of the data files that comprise a DNS database.
✓ State 2: Because the name server knows the address, but not authoritatively, it has stored (cached) the data in memory from a previous query.
✓ State 3: The name server doesn’t know the address and has to ask another DNS server. Refer to Step 2 in Figure 10-2 for an example: The address isn’t in the name server’s cache (memory), and the name server doesn’t know the answer.
Serving a DNS client’s needs
If the client’s main name server can’t supply the information requested, two things may occur, depending on whether the name server is or is not responsible for the information (more on this in the next section):
✓ If the name server is responsible, it responds with a message that says the information doesn’t exist.
✓ If the name server isn’t responsible for the information, it forwards the query to, or at least toward, the name server that’s responsible. (The name server knows to do this based on how the network administrator sets things up.) When the answer comes back, it travels all the way back down the chain to the client.
When the client receives the IP address for angelinachocolat.com, it caches the address. If the client needs the address later, the address will be right there in the client’s memory. The client won’t have to find a name server.
Oops! Can’t help you
The chain of DNS servers can’t always satisfy the client’s request. There are two reasons this can happen:
✓ Your client times out — grows tired of waiting for a response — which is the same as receiving a "No Information" answer from the queried name server.
✓ Your client asks for a nonexistent Web site and IP address. If you try to browse www.angelinachocolat.com, you see this response on your screen:
If, at this point, you have timed out, too, hang in there. We clarify this "responsibility" thing next.
Who’s Responsible for Name and Address Information?
What does it mean for a server to be "responsible for" name and address information? The DNS term for responsibility is authority. Several different types of name servers may be deployed in your environment. In the DNS world, there is no single master server. Instead, various servers know, via the DNS database, the names and addresses of the computers in your organization. These name servers are responsible for this information, and the answers they give to client queries are said to be authoritative.
Because the DNS database is distributed (that is, stored in pieces across the network), no single computer has all the information you need about all the addresses. Can you imagine the number and size of the disks you’d need to hold the addresses of all the computers on the Internet? Not practical, even if it were possible. Therefore multiple name servers work together to translate names to addresses.
When you look at the DNS domain tree, at the very top is a dot (.). That dot is the root of the tree. There are 13 root name servers across the world that hold the master list of DNS records.
The root name servers send a file (the root zone file) to other DNS servers and clients on the Internet. The root zone file lists the IP addresses of the authoritative servers for the DNS top-level domains (TLDs), in other words: which servers store authoritative (totally trustworthy) data about the TLDs, such as .com, .org, .net, .nl or .au.
Each organization that operates the root name service is labeled with an ID consisting of a single letter. Table 10-1 lists the operators (administrators).
|
Table 10-1 |
Root Name Service Operators |
|
Alphabetical Designation |
Organization |
|
A |
VeriSign Global Registry Services |
|
B |
University of Southern California Information Sciences Institute |
|
C |
Cogent Communications |
|
D |
University of Maryland |
|
E |
NASA Ames Research Center |
|
F |
Internet Systems Consortium, Inc. |
|
G |
U.S. Dept. of Defense Network Information Center |
|
H |
U.S. Army Research Lab |
|
I Autonomica/NORDUnet |
|
|
J |
VeriSign Global Registry Services |
|
K |
RIPE NCC |
|
L |
ICANN |
|
M |
WIDE Project |
No there’s no mistake in the table: VeriSign operates two root name services, A and J. The Root-Servers Technical Operations Association, www.root-servers. org, displays a map of the locations of all the Root Name Service Operators and their IP addresses.
If you’re curious, but don’t want to browse the Web, you can get a very brief look at the root servers if you have access to a Windows Server 2008. Use the DNS Manager in the Microsoft Management Console to list the servers’ IP addresses. Figure 10-3 shows an excerpt of a list of root servers. The display is nowhere near as interesting as the map at www.root-servers.org, but it’s a quick-and-dirty look at root servers.
Figure 10-3:
The DNS Manager in Windows Server 2008 knows the root servers.
Understanding Servers and Authority
You can have three types of servers in your DNS domain:
✓ The primary name server
✓ The secondary name server(s)
✓ The caching name server(s)
Before we examine their roles in the scheme of things, be sure you know your authority figures. Read on.
Primary name server: Master of your domain
Primary name servers are the master authorities for their domains. Its database contains a list of registered domain names and a translation between each name and one or more IP addresses. No single name server holds the entire DNS database. Each primary name server maintains just one subset (zone) of the domain tree. A zone is often the same as a domain, but not always. (More on that in the section "Zoning Out: Understanding Domains and Zones," later in this topic.) The primary name server stores the database for its zone. Also, a primary name server can delegate authority to a secondary name server, to lessen the primary’s workload and to give it a backup. (Is this starting to sound like life at the office? To relieve stress, delegate!)
The primary server is the ultimate repository of truth — at least as far as the names and addresses in the domain are concerned. When the primary name server delegates authority, it ships the truth — in the form of the database (or at least part of it) — to the secondary name server. That action is called a zone transfer. So a zone can be the entire domain, or just a subsection. The more the primary can delegate, the more stress relief it gets.
For reliability and performance, every domain should have a primary and at least one secondary name server.
