9.6 Good Parenting | DNS on Windows 2000


Team-Fly

	DNS on Windows 2000, 2nd Edition By Matt Larson, Cricket Liu
	Table of Contents

	Chapter 9. Parenting

9.6 Good Parenting

Now that the delegation to the fx.movie.edu name servers is in place, weresponsible parents that we areshould check that delegation using host . What? We haven't given you host yet? A version of host that works on Windows 2000 is available via anonymous ftp from ftp://ftp.nikhef.nl/pub/network/host_970908.exe.Z. To uncompress host, you'll need WinZip or a similar Windows utility. WinZip is available from http://www.winzip.com.

Once you uncompress host_970908.exe , install it as host.exe somewhere on your computer. (We install it in the same directory as nslookup.exe .) Next, set up a resolv.conf file in your %WINDIR% directory. (If you're not sure where %WINDIR% is, type set from a DOS prompt . )

host makes 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 host to 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 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 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 for which it is not authoritative, 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:

 C:\>  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.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 zones are the closest ancestors of most in-addr.arpa subdomains, and name servers very seldom cache either in-addr.arpa 's or arpa 's NS records. (The roots rarely give them out since they delegate directly to lower-level subdomains.) Once your name server has cached bad root NS records, your name resolution will almost certainly suffer: your name server won't be contacting the "official" root name servers, and who knows what information they will hand out?

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 of its proximity to your network.

9.6.1 Using host

If 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'd check the fx.movie.edu NS records on one of the movie.edu name servers:

 C:\>  host -t ns fx.movie.edu. terminator.movie.edu.

If everything's okay with the NS records, we'll simply see the NS records 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.edu from terminator.movie.edu are 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:

 C:\>  host -C fx.movie.edu.

Normally, this will produce the NS records above, along with the contents of the fx.movie.edu zone'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 serverssay 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 outland is 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 host sent outland a query and didn't get a response back in an acceptable amount of time.

While we could have checked the fx.movie.edu delegation using nslookup , host 's powerful command-line options make the task especially easy.

9.6.2 Managing Delegation

If 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. They have 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 administrator is straightforward: add the NS and A records to movie.edu . Once again, it's the New Delegation Wizard to the rescue: select the gray fx.movie.edu folder in the DNS console's left pane and then double-click on any of the NS records in the right pane. You'll see a window like the one shown back in Figure 9-6. Select Add... to add the new NS record for alien.fx.movie.edu .

The final step for the fx.movie.edu administrator is to send a similar message to hostmaster@arin.net (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 .


Team-Fly

Top