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 and secondary name servers with my parent zone? The answer is no. Only those servers you want to make available to name servers outside of 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. Their parent 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-secondary name servers on your network. This setup is shown in Figure 9-6.
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 10 name server records should fit. Depending on the data (how many servers' names are in the same domain), you can get more or fewer. There's not much point in registering more than 10 servers, anyway?if none of those 10 servers can be reached, it's unlikely the destination host can be reached.
 The domain names of the Internet's root name servers were changed because of this. All the roots were moved into the same domain, root-servers.net, to take the most advantage of domain-name compression and to allow information about as many roots as possible to be stored 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 for which it's authoritative. 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. To get this secondary 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, see 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) for which the new name server is authoritative. 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 datafile format. That avoids any potential confusion.
Since our networks were originally assigned by the InterNIC, we used the Network Modification form at http://www.arin.net/library/templates/netmod.txt 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 secondary 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@example.com
Notice that we specified explicit TTLs on the NS 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-secondary name server a good name server to register with your parent zone? Actually, it's not ideal because it's authoritative for only 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 master and your "full" secondaries.
If you don't have many name servers, though, or if you're good at remembering which name servers are authoritative for which zones, go ahead and register a partial-secondary.
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; it just has the bits and pieces of the zone that it has looked up recently. If a parent name server were to mistakenly 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.