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:@ IN WINS &IP address of WINS server
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 14-1.May 23 15:58:43 terminator named-xfer[386]: "fx.movie.edu IN 65281" - unknown type (65281)
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 to upgrade to a newer version of BIND 8. Upgrading is the better option since BIND 8.1 is so old. The check was removed at BIND 8.1.1.May 8 03:44:38 terminator named[11680]: no NS RR for SOA MNAME "movie.edu" in zone "movie.edu"
and die.Dec 12 11:52:06 terminator named[7770]: 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 possible solutions are:
options { listen-on { 192.249.249.3; }; };
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 namespace. 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. And, believe it or not, some operating systems ship with the BIND 4.9.3-BETA resolver as their system resolver.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"
The only solution to this problem is to upgrade to a newer version of the BIND resolver.
named checked to make sure UDP checksumming was turned on on this system, and it wasn't, so named exited. named is insistent on UDP checksumming for good reason: it makes copious use of UDP and needs those UDP datagrams to arrive unmolested.Sep 24 10:40:11 terminator named[7770]: ns_udp checksums NOT turned on: exiting
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).
auth-nxdomain is an options substatement that tells a BIND 8 or 9 name 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 feature is sometimes necessary is that some name servers check to make sure that negative responses (like an NXDOMAIN return code or 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 could come from the cache. To make sure that older servers don't ignore such answers, though, or consider them errors, BIND 8 and 9 let you falsely flag those responses as authoritative. In fact, that's the default behavior for a BIND 8 name server, so you shouldn't see remote queriers ignoring your BIND 8 server's negative responses unless you've explicitly turned off auth-nxdomain. BIND 9 name servers, on the other hand, have auth-nxdomain offby default, so queriers may ignore their responses even if you haven't touched the config file.
If you upgrade to a BIND 8 name server newer than 8.2 without adding the necessary $TTL control statements to your zone data files, you'll see messages like this one in your name server's syslog output:
BIND 8 generously assumes that you just haven't read RFC 2308 yet and is content to use the last field of the SOA record as both the zone's default TTL and its negative caching TTL. BIND 9, however, isn't so forgiving:Sep 26 19:34:39 terminator named[22116]: Zone "movie.edu" (file db.movie.edu): No default TTL ($TTL <value>) set, using SOA minimum instead
So before upgrading to BIND 9, be sure that you add the necessary $TTL control statements.Sep 26 19:35:54 terminator named[22124]: dns_master_load: db.movie.edu:7: no TTL specified Sep 26 19:35:54 terminator named[22124]: dns_zone_load: zone movie.edu/IN: database db.movie.edu: dns_db_load failed: no ttl Sep 26 19:35:54 terminator named[22124]: loading zones: no ttl Sep 26 19:35:54 terminator named[22124]: exiting (due to fatal error)