10.6 Good 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 DNSLint, available with the Windows Server 2003 Support Tools.

DNSLint makes it easy to check delegation. With DNSLint, you can look up the NS records for your zone on one of your zone's authoritative name servers and 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, DNSLint 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 DNSLint 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 9, 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 zone data, your name server will favor it because of its proximity to your network.

10.6.1 Using DNSLint

If our little lecture has convinced you of the importance of maintaining correct delegation, you'll be eager to learn how to use DNSLint to ensure that you don't join the ranks of the miscreants.

The first step is to use nslookup 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:\> nslookup -type=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     nameserver  = bladerunner.fx.movie.edu fx.movie.edu     nameserver  = 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 DNSLint's "lame delegation 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:\> dnslint /d fx.movie.edu. -s 192.249.253.2

We have to use the /s switch to tell DNSLint the IP address of one of the authoritative name servers for fx.movie.edu. Normally it would get this from whois, but whois doesn't contain information about zones as far down in the namespace as fx.movie.edu.

This command produces HTML output that tells us the status of the fx.movie.edu name servers. Here's the text equivalent of that output (which you get by using DNSLint's /t switch):

DNSLint Report System Date: Sat Jul 05 18:58:05 2003 Command run: dnslint /d fx.movie.edu /t /s 192.253.254.2 Domain name tested: fx.movie.edu DNS servers were identified as authoritative for the domain: DNS server: bladerunner.fx.movie.edu IP Address: 192.253.254.2 UDP port 53 responding to queries: YES TCP port 53 responding to queries: Not tested Answering authoritatively for domain: YES SOA record data from server: Authoritative name server: bladerunner.fx.movie.edu Hostmaster: administrator.fx.movie.edu Zone serial number: 10 Zone expires in: 1.00 day(s) Refresh period: 900 seconds Retry delay: 600 seconds Default (minimum) TTL: 3600 seconds Additional authoritative (NS) records from server: outland.fx.movie.edu   192.253.254.3 bladerunner.fx.movie.edu   192.253.254.2 Mail Exchange (MX) records from server (preference/name/IP address): 100 wormhole.movie.edu 192.253.253.1 10 starwars.fx.movie.edu 192.253.254.4 DNS server: outland.fx.movie.edu IP Address: 192.253.254.3 UDP port 53 responding to queries: YES TCP port 53 responding to queries: Not tested Answering authoritatively for domain: YES SOA record data from server: Authoritative name server: bladerunner.fx.movie.edu Hostmaster: administrator.fx..movie.edu Zone serial number: 10 Zone expires in: 1.00 day(s) Refresh period: 900 seconds Retry delay: 600 seconds Default (minimum) TTL: 3600 seconds Additional authoritative (NS) records from server: outland.fx.movie.edu   192.253.254.3 bladerunner.fx.movie.edu   192.253.254.2 Mail Exchange (MX) records from server (preference/name/IP address): 10 starwars.fx.movie.edu 192.253.254.4 100 wormhole.movie.edu 192.253.253.1 -------------------------------------------

If one of the fx.movie.edu name servers outland, for example were misconfigured, we might see this:

DNS server: outland.fx.movie.edu IP Address: 192.253.254.3 UDP port 53 responding to queries: YES TCP port 53 responding to queries: Not tested Answering authoritatively for domain: NO SOA record data from server: Authoritative name server: Unknown Hostmaster: Unknown Zone serial number: Unknown Zone expires in: Unknown Refresh period: Unknown Retry delay: Unknown Default (minimum) TTL: Unknown

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:

DNS server: outland.fx.movie.edu IP Address: 192.253.254.3 UDP port 53 responding to queries: NO TCP port 53 responding to queries: Not tested Answering authoritatively for domain: Unknown SOA record data from server: Authoritative name server: Unknown Hostmaster: Unknown Zone serial number: Unknown Zone expires in: Unknown Refresh period: Unknown Retry delay: Unknown Default (minimum) TTL: Unknown

In this case, the UDP port 53 responding to queries: NO message indicates that DNSLint sent outland a query and didn't get a response back in an acceptable amount of time.

Although we could have checked the fx.movie.edu delegation using nslookup, DNSLint makes the task especially easy. We'll see more of DNSLint in Chapter 15.

10.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 9 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 [e-mail] ----- 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 previously in Figure 10-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 [e-mail] (administrator of the 192.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.

10.6.2.1 Managing delegation with stubs

In the Windows Server 2003 version of the Microsoft DNS Server, Microsoft now supports stub zones, which offer an automatic way to track changes to delegation. A name server that's configured as a stub for a zone periodically sends discrete queries for the zone's SOA and NS records, as well as any necessary glue A records. The name server then uses the NS records to delegate the zone from its parent, and the SOA record governs how often the name server sends these queries. Now, when the administrators of a subdomain make changes to the subdomain's name servers, they simply update their NS records (and increment the serial number in the SOA record, of course). The parent zone's authoritative name servers, configured as stub for the child zone, pick up the updated records within the refresh interval.

To make the movie.edu name servers stubs for fx.movie.edu, we'd right-click on Forward Lookup Zones in the left pane of the DNS console and choose New Zone. In the second window of the New Zone Wizard, we'd choose Stub zone, as shown in Figure 10-9.

Figure 10-9. Adding a stub zone

The next window would prompt us for the name of the stub zone, fx.movie.edu, and the following for the name of the zone datafile, where we'll accept the default. In the next-to-last window, we'll add the address of an authoritative name server for fx.movie.edu, which our stub name server can query for the full list of the zone's NS records. (We can list more than one authoritative name server for robustness, if we like.)

Note that we must configure all movie.edu name servers including secondaries as stubs for fx.movie.edu. Since the fx.movie.edu NS records are part of the fx.movie.edu zone, they won't be included in movie.edu zone transfers.