With the move to BIND 8 and the introduction of Microsoft Windows DNS Server, more interoperability problems are cropping up between name servers. There are also a handful of problems that are unique to one version or another of BIND or the underlying operating system. Many of these are easy to spot and correct, and we would be remiss if we didn't cover them.
@ IN WINS &
Unfortunately, WINS is not a standard record type in the IN class. Consequently, if there are BIND slaves that transfer this zone, they'll choke on the WINS record and refuse to load the zone:
May 23 15:58:43 terminator named-xfer: "fx.movie.edu IN 65281" - unknown type (65281)
The workaround for this is to configure the Microsoft DNS Server to filter out the proprietary record before transferring the zone. You do this by selecting the zone in the left-hand side of the DNS Manager screen, right clicking on it and selecting Properties. Click on the WINS Lookup tab in the resulting Zone Properties window, shown in Figure 13.1 .
Checking "Settings only affect local server" will filter out the WINS record for that zone. However, any Microsoft DNS Server slaves won't see the record, even though they could use it.
May 8 03:44:38 terminator named: no NS RR for SOA MNAME "movie.edu" in zone "movie.edu"
The 8.1 server was a real stickler about the first field in the SOA record. Remember that one? In Chapter 4, Setting Up BIND , we said that it was, by convention, the domain name of the primary master name server for the zone. BIND 8.1 assumes it is, and checks for a corresponding NS record pointing the zone's domain name to the server in that field. If there's no such NS record, BIND emits that error message. It will also prevent NOTIFY messages from working correctly. The solution is either to change your MNAME field to the domain name of a name server listed in an NS record or upgrade to a newer version of BIND 8. The check was removed at BIND 8.1.1.
Dec 12 11:52:06 terminator named: socket( SOCK_RAW ): Too many open files
Since BIND tries to bind() to and listen on every network interface on the host, it may run out of file descriptors. This is especially common on hosts that use lots of virtual interfaces, often in support of web hosting. The two possible solutions are:
Sep 24 10:40:11 terminator syslog: gethostby*.getanswer: asked for "18.104.22.168.in-addr.arpa IN PTR ", got type " CNAME " Sep 24 10:40:11 terminator syslog: gethostby*.getanswer: asked for "22.214.171.124.in-addr.arpa", got "37.32/126.96.36.199.in-addr.arpa"
What happened here is that the resolver asked the name server to reverse map the IP address 188.8.131.52 to a domain name. The server did, but in the process found that 184.108.40.206.in-addr.arpa was actually an alias for 37.32/220.127.116.11.in-addr.arpa . That's almost certainly because the folks who run 103.74.204.in-addr.arpa are using the scheme we described in Chapter 9, Parenting , to delegate part of their name space. The BIND 4.9.3- BETA resolver, however, doesn't understand that, and flags it as an error, thinking it didn't get the domain name or the type it was after.
The only solution to this problem is to upgrade to a newer version of the BIND resolver.
Sep 24 10:40:11 terminator named: ns_udp checksums NOT turned on: exiting
named checked to make sure UDP checksumming was on on this system, and it wasn't, so named exited. named is so insistent on UDP checksumming being on for good reason: it makes copious use of UDP , and needs those UDP datagrams to arrive unmolested.
The solution to this problem is to enable UDP checksums on your system. The BIND distribution has documentation on that in shres/sunos/INSTALL and shres/sunos/ISSUES (in the BIND 4 distribution) or src/port/sunos/shres/ISSUES (in the BIND 8 distribution).
The last of these problems is implementation-specific. Some administrators on Sun OS 4 hosts configure their resolvers with resolv.conf and naively assume that ping , telnet , and their brethren should work right away. However, in Chapter 7, Maintaining BIND , we discussed how Sun OS 4 implements the resolver (in ypserv , if you recall). If the host isn't running NIS , configuring the resolver won't do it. The administrator will either have to set up at least an empty hosts map or replace the resolver routines. For details on both of these options, see Chapter 7 .
You'd need a keen eye to notice this problem, and you'd also have to have turned off an important BIND 8 feature to have caused the problem. If you're running a BIND 8 name server and other resolvers and servers seem to ignore your server's cached negative responses, you just might have turned off auth-nxdomain .
auth-nxdomain is an options substatement that tells the BIND 8 server to flag cached negative responses as authoritative, even though they're not. That is, if your name server has cached the fact that titanic.movie.edu does not exist from the authoritative movie.edu name servers, auth-nxdomain tells your server to pass along that cached response to resolvers and servers that query it as though it were the authoritative name server for movie.edu .
The reason this is necessary is because some name servers check to make sure that negative responses, like NXDOMAIN and no records with a NOERROR return code, are marked authoritative. In the days before negative caching, negative responses had to be authoritative, so this was a sensible sanity check. With the advent of negative caching, however, a negative response may come from the cache. To make sure that older servers don't ignore such answers, though, or consider them errors, BIND 8 lets you falsely flag those responses as authoritative. In fact, that's the default behavior, so you shouldn't see remote queriers ignoring your server's negative responses unless you turn off auth-nxdomain .