8.3 Registering Name Servers

When you get around to setting up more and more name servers, a question may strike you—do I need to register all of my primary master and slave name servers with my parent zone? No, only those servers you want to make available to name servers outside your zone need to be registered with your parent. For example, if you run nine name servers for your zone, you may choose to tell the parent zone about only four of them. Within your network, you use all nine servers. Five of those nine servers, however, are queried only by resolvers on hosts that are configured to query them (in resolv.conf, for example). Their parent zone's name servers don't delegate to them, so they'll never be queried by remote name servers. Only the four servers registered with your parent zone are queried by other name servers, including caching-only and partial-slave name servers on your network. This setup is shown in Figure 8-2.

Figure 8-2. Registering only some of your name servers

Besides being able to pick and choose which of your name servers are hammered by outside queries, there's a technical motivation for registering only some of your zone's name servers: there's a limit to how many servers will fit in a UDP response message. In practice, around 10 name server records should fit. Depending on the data (how many servers are in the same domain), you could get more or fewer.^[10] There's not much point in registering more than 10 name servers, anyway—if none of the 10 servers can be reached, it's unlikely the destination host can be reached.

^[10] The domain names of the Internet's root name servers were changed because of this. All of the roots were moved into the same domain, root-servers.net, to take the most advantage of domain name compression and store information about as many roots as possible in a single UDP packet.

If you set up a new authoritative name server and decide it should be registered, make a list of the parents of the zones it's authoritative for. You'll need to contact the administrators for each of these parent zones. For example, let's say we want to register the name server we just set up on zardoz.movie.edu. In order to get this slave registered in all the right zones, we'll need to contact the administrators of eduand in-addr.arpa. (For help determining who runs your parent zones, turn back to Chapter 3 )

When you contact the administrators of a parent zone, be sure to follow the process they specify (if any) on their web site. If there's no standard modification process, you'll have to send them the domain name of the zone (or zones) that the new name server is authoritative for. If the new name server is in the new zone, you'll also need to give them the IP address(es) of the new name server. In fact, if there's no official format for submitting the information, it's often best just to send your parent the complete list of registered name servers for the zone, plus any addresses necessary, in zone data file format. That avoids any potential confusion.

Since our networks were originally assigned by the InterNIC, we used the web-based process at http://www.arin.net/cgi-bin/amt.pl to change our registration. (If we'd preferred to do things manually, we could have sent them the form at http://www.arin.net/regserv/templates/modifytemplate.txt.) If they hadn't had a template for us to use, our message to the administrator of in-addr.arpa might have read something like this:

Howdy!

I've just set up a new slave name server on
zardoz.movie.edu for the 249.249.192.in-addr.arpa
and 253.253.192.in-addr.arpa zones.  Would you
please add NS records for this name server to the
in-addr.arpa zone?  That would make our delegation
information look like:

253.253.192.in-addr.arpa. 86400 IN NS terminator.movie.edu.
253.253.192.in-addr.arpa. 86400 IN NS wormhole.movie.edu.
253.253.192.in-addr.arpa. 86400 IN NS zardoz.movie.edu.

249.249.192.in-addr.arpa. 86400 IN NS terminator.movie.edu.
249.249.192.in-addr.arpa. 86400 IN NS wormhole.movie.edu.
249.249.192.in-addr.arpa. 86400 IN NS zardoz.movie.edu.

Thanks!

Albert LeDomaine
al@robocop.movie.edu

Notice that we specified explicit TTLs on the NS and A records? That's because our parent name servers aren't authoritative for those records; our name servers are. By including them, we're indicating our choice of a TTL for our zone's delegation. Of course, our parent may have other ideas about what the TTL should be.

In this case, glue data—A records for each of the name servers—isn't necessary, since the domain names of the name servers aren't within the in-addr.arpa zones. They're within movie.edu, so a name server that was referred to terminator.movie.edu or wormhole.movie.edu could still find their addresses by following delegation to the movie.edu name servers.

Is a partial-slave name server a good name server to register with your parent zone? Actually, it's not ideal, because it's only authoritative for some of your in-addr.arpa zones. Administratively, it may be easier to register only servers that back up all the local zones; that way, you don't need to keep track of which name servers are authoritative for which zones. All of your parent zones can delegate to the same set of name servers: your primary master and your "full" slaves.

However, if you don't have many name servers or if you're good at remembering which name servers are authoritative for what, go ahead and register a partial-slave.

Caching-only name servers, on the other hand, must never be registered. A caching-only name server rarely has complete information for any given zone, just the bits and pieces of it that it has looked up recently. If a parent zone's name server were mistakenly to refer a foreign name server to a caching-only name server, the foreign name server would send the caching-only name server a nonrecursive query. The caching-only name server might have the data cached, but then again, it might not. If it didn't have the data, it would refer the querier to the best name servers it knew (those closest to the domain name in the query)—which might include the caching-only name server itself! The poor foreign name server might never get an answer. This kind of misconfiguration—actually, delegating a zone to any name server not authoritative for that zone—is known as lame delegation.