8.3 Registering Name Servers

When you get around to setting up more and more name servers, a question may strike you - must I register all of my primary and slave name servers with my parent zone? No, only those servers you want to make available to servers outside of your zone need to be registered with the parent. For instance, if you run nine name servers for your zone, you may choose to tell the parent zone about only four of them. Within your zone, all nine servers are used. Five of those nine servers, however, are only queried by resolvers on hosts that are configured to query them (in resolv.conf, for example). Their parent name servers will never delegate to them, since they're not registered in the domain name space. Only the four servers registered with your parent zone are queried by other name servers, including caching-only and partial-slave name servers within your domain. 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 is a limit to how many servers will fit in a UDP response packet. In practice, around ten name server records should fit. Depending on the data (how many servers are in the same domain), you could get more or fewer.[9] There's not much point in registering more than ten servers, anyway - if none of the ten servers can be reached, it's unlikely the destination host can be reached.

[9] 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 as many roots as possible in a single UDP packet.

If you've set up a new authoritative name server, and you 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 set up on zardoz above. In order to get this slave registered in all the right zones, we'll need to contact the administrators of edu and in-addr.arpa. (For help determining who runs your parent zones, turn back to Chapter 3, Where Do I Start?)

When you contact the administrators of a parent zone, be sure to fill out the form they specify (if any) on their web site. If there's no standard form, give them the domain name of the zone 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 data file format. That avoids any potential confusion.

Since our networks were originally assigned by the InterNIC, we submitted the form at http://www.arin.net/templates/inaddrtemplate.txt to [email protected], per their web site, to change our registration. 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
[email protected]

Notice 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 - aren'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 or wormhole 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 backing 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 and your "full" slaves.

If you don't have many name servers, though, 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 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 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.