 | Chapter 9 Parenting |  |
| Chapter 9 Parenting | |
Now that the delegation to the fx.movie.edu name servers is in place, we - responsible parents that we are - should check that delegation using check_del. What? We haven't given you check_del yet? Unfortunately, check_del is too long to include in this book, but we've made it available via anonymous ftp. See the preface for details. Feel free to snatch the code there and compile it if you want to follow along.
check_del "knows" delegation. check_del reads NS records. For each NS record, check_del issues a query to the name server listed for the zone's SOA record. The query is nonrecursive, so the name server queried doesn't query other name servers to find the SOA record. If the name server replies, check_del checks the reply to see whether the aa - authoritative answer - bit in the reply packet is set. If it is, the name server checks to make sure that the packet contains an answer. If both these criteria are met, the name server is flagged as authoritative for the zone. Otherwise, the name server is not authoritative, and check_del reports an error.
Why all the fuss over bad delegation? Incorrect delegation can cause the propagation of old and erroneous root name server information. When a name server is queried for data in a zone it isn't authoritative for, it does its best to provide useful information to the querier. This "useful information" comes in the form of NS records for the closest ancestor domain the name server knows. (We mentioned this briefly in Chapter 8, Growing Your Domain, when we discussed why you shouldn't register a caching-only name server.)
For example, say one of the fx.movie.edu name servers mistakenly receives an iterative query for the address of carrie.horror.movie.edu. It knows nothing about the horror.movie.edu domain (except for what it might have cached), but it likely has NS records for movie.edu cached, since those are its parent name servers. So it would return those records to the querier.
In that scenario, the NS records may help the querying name server get an answer. However, it's a fact of life on the Internet that not all administrators keep their cache files up to date. If one of your name servers follows a bad delegation and queries a remote name server for records it doesn't have, look what can happen:
%nslookupDefault Server: terminator.movie.edu Address: 192.249.249.3 >set type=ns>.Server: terminator.movie.edu Address: 192.249.249.3 Non-authoritative answer: (root) nameserver = D.ROOT-SERVERS.NET (root) nameserver = E.ROOT-SERVERS.NET (root) nameserver = I.ROOT-SERVERS.NET (root) nameserver = F.ROOT-SERVERS.NET (root) nameserver = G.ROOT-SERVERS.NET (root) nameserver = A.ROOT-SERVERS.NET (root) nameserver = H.ROOT-SERVERS.NETNIC.NORDU.NET (root) nameserver = B.ROOT-SERVERS.NET (root) nameserver = C.ROOT-SERVERS.NET (root) nameserver = A.ISI.EDU - These three name (root) nameserver = SRI-NIC.ARPA - servers are no longer (root) nameserver = GUNTER-ADAM.ARPA - roots
A remote name server tried to "help out" our local name server by sending it the current list of roots. Unfortunately, the remote name server was corrupt, and returned NS records that were incorrect. And our local name server, not knowing any better, cached that data.
Queries to misconfigured in-addr.arpa name servers often result in bad root NS records, because the in-addr.arpa and arpa domains are the closest ancestors of most in-addr.arpa subdomains, and name servers very seldom cache either in-addr.arpa or arpa's NS records. (The roots seldom give them out, since they delegate directly to lower-level subdomains.) Once your name server has cached bad root NS records, your name resolution may suffer.
Those root NS records may have your name server querying a root name server that is no longer at that IP address, or a root name server that no longer exists at all. If you're having an especially bad day, the bad root NS records may point to a real, non-root name server that is close to your network. Even though it won't return authoritative root data, your name server will favor it because it will have a low RTT due to its proximity to your network.
If our little lecture has convinced you of the importance of maintaining correct delegation, you'll be eager to learn how to use check_del to ensure that you don't join the ranks of the miscreants.
check_del usually takes two arguments: the name of a data file to check, and the default origin in the data file. The default origin tells check_del the domain name to append to relative names in the file. (When named reads the db file, it learns the default origin in the named.conf or named.boot file; it's at the beginning of the zone statement, and always the second field in a primary or secondary directive. check_del doesn't read the conf or boot file, though, so you need to specify the domain name on the command line. If it read the conf or boot file, it'd be limited to checking only db files listed in it.)
To check whether the db.movie file contains proper delegation to fx.movie.edu (and any other subdomains), we'd run:
%check_del -o movie.edu -f db.movie
If the delegation is correct, we'd see this:
5 domains properly delegated
Actually, it's one domain delegated to three authoritative servers (movie.edu delegated to terminator, wormhole, and zardoz), and one subdomain delegated to two authoritative servers (fx.movie.edu delegated to bladerunner and outland), but check_del doesn't know that. The point is that all the NS records in db.movie are correct.
If one of the fx.movie.edu name servers - say outland - were misconfigured, we'd see this:
Server outland.fx.movie.edu is not authoritative for fx.movie.edu 4 domains properly delegated 1 domains improperly delegated
Okay, check_del doesn't really understand plurals, either.
If one of the fx.movie.edu name servers weren't running at all, we'd see:
4 domains properly delegated
1 servers not running
Servers not running:
outland.fx.movie.eduIn this case, not running really means that check_del tried to send the name server a query and got an ICMP port unreachable error back, which indicated that nothing was listening on the name server port.
And if the name server didn't answer in an acceptable amount of time, you'd see:
4 domains properly delegated
1 servers not responding
Servers not responding:
outland.fx.movie.eduIf the special effects lab gets bigger, we may find that we need additional name servers. We dealt with setting up new name servers in Chapter 8, and even went over what information to send to the parent zone's administrator. But we never explained what the parent needed to do.
It turns out that the parent's job is relatively easy, especially if the administrators of the subdomain send complete information. Imagine that the special effects lab expands to a new network, 192.254.20. They have a passel of new, high-powered graphics workstations. One of them, alien.fx.movie.edu, will act as the network's name server.
The administrators of fx.movie.edu (we delegated it to the folks in the lab) send their parent zones' administrators (that's us) a short note:
Hi! We've just set up alien.fx.movie.edu (192.254.20.3) as a name server for fx.movie.edu. Would you please update your delegation information? I've attached the NS records you'll need to add. Thanks, Arty Segue ajs@fx.movie.edu ----- cut here ----- fx.movie.edu. 86400 IN NS bladerunner.fx.movie.edu. fx.movie.edu. 86400 IN NS outland.fx.movie.edu. fx.movie.edu. 86400 IN NS alien.fx.movie.edu. bladerunner.fx.movie.edu. 86400 IN A 192.253.254.2 outland.fx.movie.edu. 86400 IN A 192.253.254.3 alien.fx.movie.edu. 86400 IN A 192.254.20.3
Our job as the movie.edu administrator is straightforward: add the NS and A records to db.movie.
What if we're using h2n to create our name server data? We can stick the delegation information into the spcl.movie file, which h2n $INCLUDEs at the end of the db.movie file it creates.
The final step for the fx.movie.edu administrator is to send a similar message to hostmaster@internic.net (administrator for the in-addr.arpa domain), requesting that the 20.254.192.in-addr.arpa domain be delegated to alien.fx.movie.edu, bladerunner.fx.movie.edu, and outland.fx.movie.edu.
If you're running BIND 4.9 or BIND 8 name servers, you don't have to manage delegation information manually. BIND 4.9 and BIND 8 name servers support an experimental feature, called stub, which enables a name server to pick up changes to delegation information automatically.
Name servers that act as stubs for a subdomain do periodic zone transfers of the subdomain's data, but they ignore everything in it except for the NS records and the SOA record. The NS records are "promoted" into the parent zone, and the SOA record governs how often the stub does zone transfers. Now, when the administrators of a subdomain make changes to the subdomain's name servers, they simply update their NS records. The parent zone's authoritative name servers will pick up the updated records within the refresh interval.
On the movie.edu name servers running BIND 8, here's what we'd add to named.conf:
zone "fx.movie.edu" {
type stub;
file "db.fx";
masters { 192.253.254.2; };
};On a BIND 4.9 name server, we'd use this directive:
stub fx.movie.edu 192.253.254.2 db.fx
Note that we should configure all of the movie.edu name servers as stubs for fx.movie.edu, because if the fx.movie.edu delegation information changes, that won't change the movie.edu zone's serial number.
|  | |
| 9.5 Subdomains of in-addr.arpa Domains |  | 9.7 Managing the Transition to Subdomains |