Delegation Problems

As should be clear from Chapters 1, "DNS Concepts," and 2, it is vital that your authoritative servers have gotten your domains delegated to them. Lack of delegation can result in problems ranging from servers being incapable of looking up hostnames from the IP address to everyone outside your own network being unable to look up your hostnames. This is a problem mainly when the domains and networks are new and delegations are not propagated yet. Reverse delegations have proven to be especially difficult to get right. Unfortunately, it seems that some ISPs simply don't understand them or their uses. In that case, you will either need to educate your ISP or change ISPs.

Tools such as dnswalk and DOC (see Chapter 7) should be able to detect delegation problems. Run the tool on both your forward and reverse zones. Another way to check delegation problems is to use a Web-based DNS tool, such as DigIt, which will show you what DNS looks like from a vantage point other than your usual one (see Chapter 7).

Another thing that can cause problems is that you didn't pay your domain registration to your registrar's satisfaction. This has happened to several large corporations in the first half of 2000. If your domain suddenly disappears from the outside world, you had better check with your registrar. If it has expired, just pay the bill quickly, no matter who FUBARed. It takes as much as 24 hours to get things back in order, after you've paid, if the delegation from your TLD has been yanked.

There is also an inverse problem here. When a nameserver is listed in the zone or the parent zone, but is not authoritative for the zone in other words, it is not a slave or master server for the zone even though DNS data says it is a situation known as a lame server exists. (The NS records for the zone inside the zone itself and in the parent zone should match.) Lame servers are rife on the Internet. Usually, a lame server situation is temporary and is caused by the removal or moving of a nameserver before the updated NS records are available all around the network. In reverse zones, the problem is often more permanent. Older versions of BIND didn't make any noise about this, but newer versions do. They log messages similar to these:

 Lame server on 'xx.xxx.xxx.xxx.in-addr.arpa' (in         'xxx.xxx.xxx.in-addr.arpa'?): [xxx.xx.xxx.xxx].53'NS.xxx.NET' ns_forw: query(xx.xx.xxx.xxx.in-addr.arpa) All possible A RR's lame 

The IP numbers and names have been changed to protect the innocent. The first message means that the server that should now have the PTR record (presumably) for xx.xxx.xxx.xxx.in-addr.arpa does not give authoritative answers for that zone. The second message means that no authoritative servers could be found, and that BIND has to give up resolving the name.