| I l@ve RuBoard |
|
9.6 Good ParentingNow that the delegation to the fx.movie.edu name servers is in place, we—responsible parents that we are—should check that delegation using host. What? We haven't given you host yet? A version of host for Unix is available via anonymous FTP from ftp.nikhef.nl as /pub/network/host.tar.Z. To build host, first extract it: % zcat host.tar.Z | tar -xvf - Then build it on your system: % make hostmakes it easy to check delegation. With host, you can look up the NS records for your zone on your parent zone's name servers. If those look good, you can use hostto query each 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, host checks the reply to see whether the aa—authoritative answer—bit in the reply message is set. If it is, the name server checks to make sure that the message 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 host reports an error. Why all the fuss over bad delegation? Incorrect delegation can slow name resolution or 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 zone the name server knows. (We mentioned this briefly in Chapter 8, 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 zone (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 root hints 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: % nslookup Default 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.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 zones are the closest ancestors of most in-addr.arpasubdomains, and name servers very seldom cache NS records of either in-addr.arpa or arpa. (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, nonroot name server that is close to your network. Even though it won't return authoritative root data, your name server will favor it because of its proximity to your network. 9.6.1 Using hostIf our little lecture has convinced you of the importance of maintaining correct delegation, you'll be eager to learn how to use host to ensure that you don't join the ranks of the miscreants. The first step is to use host to look up your zone's NS records on a name server for your parent zone and make sure they're correct. Here's how we would check the fx.movie.edu NS records on one of the movie.edu name servers: % host -t ns fx.movie.edu. terminator.movie.edu. If everything's okay with the NS records, we'll simply see them in the output: fx.movie.edu NS bladerunner.fx.movie.edu fx.movie.edu NS outland.fx.movie.edu This tells us that all the NS records delegating fx.movie.edufrom terminator.movie.eduare correct. Next, we'll use host 's "SOA check" mode to query each of the name servers in the NS records for the fx.movie.edu zone's SOA record. This will also check whether the response was authoritative: % host -C fx.movie.edu. Normally, this produces the NS records just listed, along with the contents of the fx.movie.eduzone's SOA record: fx.movie.edu NS bladerunner.fx.movie.edu bladerunner.fx.movie.edu hostmaster.fx.movie.edu (1 10800 3600 608400 3600) fx.movie.edu NS outland.fx.movie.edu bladerunner.fx.movie.edu hostmaster.fx.movie.edu (1 10800 3600 608400 3600) If one of the fx.movie.edu name servers—say outland—were misconfigured, we might see this: fx.movie.edu NS bladerunner.fx.movie.edu fx.movie.edu NS outland.fx.movie.edu fx.movie.edu SOA record currently not present at outland.fx.movie.edu fx.movie.edu has lame delegation to outland.fx.movie.edu This indicates that the name server on outlandis running, but it's not authoritative for fx.movie.edu. If one of the fx.movie.edu name servers weren't running at all, we'd see: fx.movie.edu NS bladerunner.fx.movie.edu bladerunner.fx.movie.edu hostmaster.fx.movie.edu (1 10800 3600 608400 3600) fx.movie.edu NS outland.fx.movie.edu fx.movie.edu SOA record not found at outland.fx.movie.edu, try again In this case, the try again message indicates that hostsent outlanda query and didn't get a response back in an acceptable amount of time. While we could have checked the fx.movie.edudelegation using nslookup, host 's powerful command-line options make the task especially easy. 9.6.2 Managing DelegationIf 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/24. This network has a passel of new, high-powered graphics workstations. One of them, alien.fx.movie.edu, will act as the new network's name server. The administrators of fx.movie.edu (we delegated it to the folks in the lab) send their parent zone's 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 administrators is straightforward: add the NS and A records to db.movie.edu. 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 noc@netsol.com (the administrator of the in-addr.arpa zone), requesting that the 20.254.192.in-addr.arpa subdomain be delegated to alien.fx.movie.edu, bladerunner.fx.movie.edu, and outland.fx.movie.edu. 9.6.2.1 Stubs: another way to manage delegationIf you're running BIND 4.9 or later name servers, you don't have to manage delegation information manually. BIND 4.9 and later name servers support an experimental feature called stub zones, which enables a name server to pick up changes to delegation information automatically. Name servers that act as stubs for a zone periodically perform discrete queries for the zone's SOA and NS records, as well as any necessary glue A records. The name server uses the NS records to delegate the zone from its parent, and the SOA record governs how often the name server does these queries. 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 pick up the updated records within the refresh interval. On the movie.edu name servers, here's what we'd add to named.conf: zone "fx.movie.edu" {
type stub;
masters { 192.253.254.2; };
file "stub.fx.movie.edu";
};
On a BIND 4.9 name server, we'd use this directive: stub fx.movie.edu 192.253.254.2 stub.fx.movie.edu Note that we should configure all 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.[4] Making all the movie.edu name servers stubs for the subdomain will keep them synchronized.
 |
| I l@ve RuBoard |
|
