×

Uh-oh, it looks like your Internet Explorer is out of date.

For a better shopping experience, please upgrade now.

Networking CD Bookshelf: 6 Bestselling Books on CD-ROM
     

Networking CD Bookshelf: 6 Bestselling Books on CD-ROM

by Jon Orwant Ph.D., Cricket Liu, Mike Loukides (Editor), Cricket Liu
 

Network Administrators increasingly rely on the Web, online help, and other online information sources to solve information pain. Now O'Reilly's Networking CD Bookshelf gives you convenient online access to your favorite books from your CD-ROM drive.The Networking CD Bookshelf contains a powerhouse of O'Reilly Animal Guides for network administrators.

Overview

Network Administrators increasingly rely on the Web, online help, and other online information sources to solve information pain. Now O'Reilly's Networking CD Bookshelf gives you convenient online access to your favorite books from your CD-ROM drive.The Networking CD Bookshelf contains a powerhouse of O'Reilly Animal Guides for network administrators. Included are complete, unabridged versions of TCP/IP Network Administration, 2nd Edition; sendmail, 2nd Edition; sendmail Desktop Reference;DNS and BIND, 3rd Edition;Practical UNIX & Internet Security, 2nd Edition; and Building Internet Firewalls. As a bonus, the new hardcopy version of DNS and BIND, 3rd Edition is also included.Never has it been easier to learn, or look up, what you need to know online. Formatted in HTML, The Networking CD Bookshelf can be accessed with any Web browser. The books are fully searchable and cross-referenced. In addition to individual indexes for each book, a master index for the entire library is provided.

Product Details

ISBN-13:
9781565925236
Publisher:
O'Reilly Media, Incorporated
Publication date:
03/10/1999
Pages:
456
Product dimensions:
7.16(w) x 9.30(h) x 1.15(d)

Read an Excerpt


Chapter 2: How Does DNS Work?

Types of Name Servers

The DNS specs define two types of name servers: primary masters and secondary masters. A primary master name server for a zone reads the data for the zone from a file on its host. A secondary master name server for a zone gets the zone data from another name server that is authoritative for the zone, called its master server. Quite often, the master server is the zone's primary master, but that's not required: a secondary master can load zone. data from another secondary. When a secondary starts up, it contacts its master name server and, if necessary, pulls the zone data over. This is referred to as a zone transfer. Nowadays, the preferred term for a secondary master name server is a slave, though many people (and much software, including Microsoft's DNS Manager) still call them secondaries.

Both the primary master and slave name servers for a zone are authoritative for that zone. Despite the somewhat disparaging name, slaves aren't second-class name servers. DNS provides these two types of name servers to make administration easier. Once you've created the data for your zone and set up a primary master name server, you don't need to fool with copying that data from host to host to create new name servers for the zone. You simply set up slave name servers that load their data from the primary master for the zone. Once they're set up, the slaves will transfer new zone data when necessary.

Slave name servers are important because it's a good idea to set up more than one name server for any given zone. You'll want more than one for redundancy, to spread the load around, and to make sure that all the hosts in the zone have a name server close by. Using slave name servers makes this administratively workable.

Calling a particular name server a primary master name server or a slave name server is a little imprecise, though. We mentioned earlier that a name server can be authoritative for more than one zone. Similarly, a name server can be a primary master for one zone and a slave for another. Most name servers, however, are either primary for most of the zones they load or slave for most of the zones they load. So if we call a particular name server a primary or a slave, we mean that it's the primary master or a slave for most of the zones it loads.

Data Files The files from which primary master name servers load their zone data are called, simply enough, zone data files or just data files. We often refer to them as db files, short for database files. Slave name servers can also load their zone data from data files. Slaves are usually configured to back up the zone data they transfer from a master name server to data files. If the slave is later killed and restarted, it will read the backup data files first, then check to see whether the data are current. This both obviates the need to transfer the zone data if it hasn't changed and provides a source of the data if the master is down.

The data files contain resource records that describe the zone. The resource records describe all the hosts in the zone and mark any delegation of subdomains. BIND also allows special directives to include the contents of other data files in a data file, much like the #include statement in C programming.

Resolvers

Resolvers are the, clients that access name servers. Programs running on a host that need information from the domain name space use the resolver. The resolver handles:

  • Querying a name server
  • Interpreting responses (which may be resource records or an error)
  • Returning the information to the programs that requested it

In BIND, the resolver is just a set of library routines that is linked into programs such as telnet and ftp. It's not even a separate process. It has the smarts to put together a query, to send it and wait for an answer, and to resend the query if it isn't answered, but that's about all. most of the burden of finding an answer to the query is placed on the name server. The DNS specs call this kind of resolver a stub resolver.

Other implementations of DNS have had smarter resolvers, which can do more sophisticated things such as build up a cache of information already retrieved from name servers. But these aren't nearly as common as the stub resolver implemented in BIND.

Resolution

Name servers are adept at retrieving data from the domain name space. They have to be, given the limited intelligence of some resolvers. Not only can they give you data about zones for which they're authoritative, they can also search through the domain name space to find data for which they're not authoritative. This process is called name resolution or simply resolution.

Because the name space is structured as an inverted tree, a name server needs only one piece of information to find its way to any point in the tree: the domain names and addresses of the root name servers (is that mote than one piece?). A name server can issue a query to a root name server for any name in the domain name space and the root name server will start the name server on its way.

Root Name Servers

The root name servers know where there are authoritative name servers for each of the top-level domains. (In fact, most of the root name servers are authoritative for the generic top-level domains.) Given a query about any domain name, the root name servers can at least provide the names and addresses of the name servers that are authoritative for the top-level domain that the domain name is in. And the toplevel name servers can provide the fist of name servers that are authoritative for the second-level domain that the domain name is in. Each name server queried gives the querier information about how to get "closer" to the answer it's seeking, or it provides the answer itself.

The root name servers are clearly important to resolution. Because they're so important, DNS provides mechanisms - such as caching, which we'll discuss a little later - to help offload the root name servers. But in the absence of other information, resolution has to start at the root name servers. This makes the root name servers crucial to the operation of DNS; if all the Internet root name servers were unreachable for an extended period, all resolution on the Internet would fail. To protect against this, the Internet has thirteen root name servers (as of this writing)spread across different parts of the network. Two are on the MILNET, the U.S. military's portion of the Internet; one is on SPAN, NASA's internet; two are in Europe; and one is in Japan.

Being the focal point for so many queries keeps the roots busy; even with thirteen, the traffic to each root name server is very high. A recent informal poll of root name server administrators showed some roots receiving thousands of queries per second.

Despite the load placed on root name servers, resolution on the Internet works quite well. Figure 2-12 shows the resolution process for the address of a real host in a real domain, including how the process corresponds to traversing the domain name space tree.

The local name server queries a root name server for the address of girigiri. gbrmpa.gov.au and is referred to the au name servers. The local name server asks an au name server the same question, and is referred to the gov.au name servers. The gov.au name server refers the local name server to the gbrmpagov.au name servers. Finally, the local name server asks a gbrmpa.gov.au name server for the address and gets the answer....

Meet the Author

Jon Orwant founded The Perl Journal and received the White Camel lifetime achievement award for contributions to Perl in 2004. He's Engineering Manager at Google, where he leads Patent Search, visualizations, and digital humanities teams. For most of his tenure at Google, Jon worked on Book Search, and he developed the widely used Google Books Ngram Viewer. Prior to Google, he was CTO of O'Reilly, Director of Research at France Telecom, and a Lecturer at MIT. Orwant received his doctorate from MIT's Electronic Publishing Group in 1999.

Customer Reviews

Average Review:

Post to your social network

     

Most Helpful Customer Reviews

See all customer reviews