13.5.1 Zone Transfer Fails Because of Proprietary WINS Record

When a Microsoft Windows DNS Server is configured to consult a WINS server for names it can't find in a given zone, it inserts a special record into the zone data file. The record looks like this:

@               IN      WINS            &IP address of WINS server

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[386]: "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.

Figure 13.1: "Settings only affect local server" checkbox

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.

13.5.2 Name Server Reports "No NS Record for SOA MNAME"

You'll only see this error on BIND 8.1 servers:

May 8 03:44:38 terminator named[11680]: 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.

13.5.3 Name Server Reports "Too Many Open Files"

On hosts with many IP addresses, or a low limit on the maximum number of files a user can open, BIND will report:

Dec 12 11:52:06 terminator named[7770]: socket(SOCK_RAW): Too many open files

and die.

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:

• Configure BIND to listen on only one or a few of the host's network interfaces using the listen-on substatement. If terminator is the host we're having this problem with:

  options {
                  listen-on { 192.249.249.3; };
  };

  will tell named on terminator to bind() only to the IP address 192.249.249.3.

• Reconfigure your operating system to allow a process to open more file descriptors concurrently.

13.5.4 Resolver Reports "Looked for PTR, Found CNAME"

This is another problem related to BIND's strictness. On some lookups, the resolver will log:

Sep 24 10:40:11 terminator syslog: gethostby*.getanswer: asked for
     "37.103.74.204.in-addr.arpa IN PTR", got type "CNAME"
Sep 24 10:40:11 terminator syslog: gethostby*.getanswer: asked for
     "37.103.74.204.in-addr.arpa", got "37.32/27.103.74.204.in-addr.arpa"

What happened here is that the resolver asked the name server to reverse map the IP address 204.74.103.37 to a domain name. The server did, but in the process found that 37.103.74.204.in-addr.arpa was actually an alias for 37.32/27.103.74.204.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.

13.5.5 Name Server Startup Fails Because UDP Checksums Disabled

On some hosts running SunOS 4.1.X, you'll see this error:

Sep 24 10:40:11 terminator named[7770]: 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).

13.5.6 SunOS Resolver Is Configured, but Host Doesn't Use DNS

The last of these problems is implementation-specific. Some administrators on SunOS 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 SunOS 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.

13.5.7 Other Name Servers Don't Cache Your Negative Answers

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.