|
|
|
 Lame delegation, and other DNS problems
By Joel Snyder Because a lot of e-mail depends on DNS I have been doing a series of columns on debugging DNS. Last week I wrote about some tools for DNS troubleshooting; this week I'll walk you through some recent problems I've had. The first one is the most common, and goes by the name of "lame delegation." Lame delegation occurs when someone higher up in the DNS tree delegates name service to a name server, but that name server either doesn't exist or doesn't believe that it has authority for that domain. Lame delegation is a subtle problem for most people, because the DNS is so fault tolerant. Even though new domains (in the .COM/.ORG/.NET space) require a fault-tolerant setup, with multiple nameservers, there is no enforcement of this rule. This means that many domains come up with no fault tolerance. They may operate happily for years until something goes wrong, and then things get flakey very fast. A typical example of lame delegation happens when a lame ISP sets up a domain name improperly, or more commonly, when someone sets up a name without coordinating with the ISP. There are many different kinds of lame delegation. Here's a complex example, with a domain called "weba2z.net." (If you want a simple example, go to the end of this column.) First, to see where the DNS is supposed to be pointed, you need to ask the root nameservers. That's because delegation goes down from the top. Some domains are pointed to directly from the root nameservers; others are more indirect. For a simple .COM or .NET, you'll see the pointer at the root. So, start with nslookup and find out who the root nameservers are. First, your normal beginning to nslookup: $ nslookup Default Server: LOCALHOST Address: 127.0.0.1 ÿ set type=any Now, ask for the "root" of the DNS tree by putting in a single period and hitting return. > . Server: LOCALHOST Address: 127.0.0.1 Non-authoritative answer: (root) nameserver = A.ROOT-SERVERS.NET (root) nameserver = H.ROOT-SERVERS.NET (root) nameserver = C.ROOT-SERVERS.NET [a bunch of output deleted] > This tells you the preferred root nameservers for the server you're talking to. If you don't see a list like this, then either the nameserver you're talking to is not connected to the Internet, or their list of root nameservers is horribly out of date. In either case, you're not getting good answers, so pick some other server. Once you see the list of root servers, take the first one and make it your current server: >server a.root-servers.net. (notice how I put a dot at the end of "a.root-servers.net.") Then ask it: what do you know about "weba2z.net" by simply typing in "weba2z.net." (with the trailing dot) at the NSLOOKUP prompt:
> weba2z.net.
Non-authoritative answer:
Authoritative answers can be found from: It tells us two things: first, who the nameservers for this domain name are and second, what their IP addresses are. Those IP addresses are hard-wired into the DNS as "glue records" in the root nameservers. This means that nameservers, unlike most other computers, cannot change their IP addresses with impunity because the DNS itself hangs together with hardwired IP addresses going from the root servers down to individual nameservers. Now, to detect whether the delegation is lame, you go to each of those nameservers in turn and ask it about the domain. Notice that I use the IP address of the name server to be sure that I'm looking at the right host. If I used the name, depending on my configuration, I might be seeing a different host.
> server 216.161.154.11
> weba2z.net.
weba2z.net nameserver = dns1.weba2z.net Well, this looks pretty good. The interesting thing here, though, is that there are four nameservers listed in the "weba2z.net" record: the two we already know about, and two more: dns1.internethosting.com and ns1.uswest.net. This is not strictly an error, because as long as the nameserver records in a domain are a superset of the pointers down from the top, there is no inconsistency. But it does mean that now we have four potential nameservers to look at when looking up names in the weba2z.net domain. Depending on what system is asking the question and how it got there, all four could be called upon to resolve names in that domain. So let's check them out. First, go to the other official one:
> server 216.161.154.12
> weba2z.net.
*** Request to dns1.weba2z.net timed-out Ohhh. Well, that's a bad sign. It says that one of the nameservers for this domain is offline. This is not strictly a lame delegation, because that server could just be out for maintenance or temporarily unavailable. But it does mean that there is no longer any fault tolerance for this domain: if the first server hiccups, then that domain is off the air - people won't be able to get the Web site, mail won't get through, etc. Bad news. Even worse, because DNS lookups are not ordered (i.e., the first shown server is not tried first), some people will see this domain (or the Web site) as "slow." They will take a long time to figure out what the IP address is because some of the time the second server will be queried first and it will be slow to respond. People often mistake the ordering in the InterNIC database or the terms "primary" and "secondary" as having something to do with DNS lookups - they don't. "Primary" and "secondary" have everything to do with how nameservers synchronize among themselves; they have nothing to do with which nameserver is queried first. Anyone who thinks that their secondary nameservers somehow can be out of synch or off the air is wrong, and is doing their domain name an extreme disservice. But there's actually more to look at. There are two other nameservers listed. Let's try US West first:
> server ns1.uswest.net.
> weba2z.net.
weba2z.net nameserver = dns1.weba2z.net This looks good, although you need to check one more thing to be sure: the serial numbers. If the US West nameserver had a different serial number in the Start Of Authority (SOA) record for this domain, then that would indicate that the two nameservers were out of synch, which would be a sign of a bigger problem. In this case, the serial number in both nameservers is "1999101203," which is good. This means that they are synched up. You might ask: which is the master (primary) and which the slave (secondary)? In this case, you can see a hint in the SOA record: the field marked as "origin" is supposed to have the name of the server which is the true master. It's not always correct and this information is purely advisory, but we can guess that "dns1.weba2z.net" is the primary, and "ns1.uswest.net" is the secondary. OK so far; let's look at the fourth nameserver for this domain. Now there is something very fishy about this one. If you notice, in the US West nameserver, there is no IP address for the nameserver. Usually, a good BIND server will try and put information like the IP address of nameservers in a response to a query. By trying to anticipate the next query you will make, it saves bandwidth and network traffic. But there is no IP address there. However, if you look back in the response from dns1.weba2z.net, there is an IP address. Let's go to a neutral third party and ask it:
> server a.root-servers.net.
> set type=ns
Non-authoritative answer:
Authoritative answers can be found from:
> dns1.internethosting.com.
*** ns1.infinetways.net can't find dns1.internethosting.com.: Well, there is no "dns1.internethosting.com," that's for sure. So what's at the IP address passed out by the first server, 216.161.154.13? Let's find out:
> server 216.161.154.13
> weba2z.net.
*** Request to dns1.internethosting.com timed-out Well, that one's dead too. So in this case there are a number of things wrong. First, there is a mismatch between the higher-level server information and the lower-level server information. This isn't a problem, if it's intentional. It's pretty clear in this case that it's not. Second, of the nameservers in this domain, half are off-the-air, including one of the two pointed to from higher-up. This is a serious problem. Nameservers aren't supposed to go down. All of these should be fixed for this domain to operate properly in all cases. Here's a simpler example. In this case, the server is on the air, but it does not have an "authoritative" answer. Any nameserver that is a primary or secondary server for a domain will always return authoritative answers for that domain. Thus:
> server a.root-servers.net.
> zsazsas.com.
Non-authoritative answer:
Authoritative answers can be found from:
The root servers say that there are two authoritative servers:
> server ns.opus1.com.
> zsazsas.com.
Non-authoritative answer:
Authoritative answers can be found from: Here, the ns.opus1.com server is SUPPOSED to be authoritative, but in fact has no authoritative information. It has no SOA record, no nameserver records, nothing. Just information it got back from another nameserver about this name. That's a true lame delegation. This column has gone on a little long, but these examples are all a little long. More later in the week!
Joel Snyder is a senior partner with Opus One, a consulting firm in Tucson, Arizona. He spends most of his time on the road helping people build larger, faster, better, and more reliable networks. His professional travels have taken him from San Francisco to St. Petersburg, where he always carries his trusty Macintosh and modem, neither of which have cute names. He is also a member of the Network World Test Alliance and writes extensively on networking topics. Reach him at joel.snyder@opus1.com.
|
 |
 About the author
Help Desk: The best way to connect to the Internet
Help Desk: Should we run our own DNS servers Archive of Network World Fusion Focus on Groupware and Messaging newsletters
Today's breaking news
California firm promises free DSL service
| 
Feedback |
Network World, Inc. |
Advertiser Index
Home | News | Reference | Newsletters | Forums | Opinions Copyright, 1995-2000 Network World, Inc. All rights reserved. |