Reed Media Services

Some error messages and problems with DNS (or BIND or named)...

sysquery: findns error (NXDOMAIN) on NS1.BOGUS.DOMAIN?

It means that NS1.BOGUS.DOMAIN is the target of an NS record somewhere, but there's no A record for that name. The server that was asked about the address claims it doesn't even exist.

NXDOMAIN means no such host or domain.

Err/TO getting serial# for "the-domain.tld"

Your secondary (or slave) is having trouble getting a valid answer to the SOA query for the "the-domain.tld" zone. In order to know whether a zone transfer is necessary, a slave will do an SOA query to get the serial number for the zone, and see if it has changed. (This is the refresh check.)

Do you have the right addressed configured in your "masters { }" clause?

There is probably a problem with the master. Maybe the master(s) are not authoritative (or not configured as a master) for the zone. Maybe it couldn't load the zone because of a syntax error. Or maybe the master is unavailable or the connection timed out. Make sure that the slaves can connect to the primary on TCP port 53. (Also, you may want to check the log file on the master to see why the transfer is being refused.)

Are you really a secondary? (If not, remove the entries from the configuration so your not the secondary for those zones.)

has CNAME and other data (invalid)

CNAMEs can't co-exist with other records (it defeats the purpose of defining a CNAME in the first place)

You cannot combine CNAME with anything else (except SIG when we are doing DNSSEC)

CNAMEs can't co-exist with other record types, so, by inference, you can't have a CNAME be the same as a zone name, since a zone has at least an SOA record (and, arguably, at least one NS record as well), and the CNAME can't co-exist with it. Just use an A record and be happy.

Indicates that you have a domain name in your zone data that owns both a CNAME record and a record of another type.

named-xfer: connect for zone failed: No route to host

Maybe a firewall or router is blocking TCP connections.

nslookup says "Can't find server name for address"

*** Can't find server name for address 63.91.101.54: Non-existent host/domain
*** Default servers are not available

This may mean that in-addr.arpa reverse lookups for the IP address don't work. It appears that if you setup the reverse lookup on your own server, the name server will begin to work for that IP -- even if your uplines don't provide a way (and the IP doesn't resolve in the outside world).

It appears to be a problem with nslookup.

named-xfer: record too short

Jul 12 09:17:12 sigmahosting named-xfer[1028]: [[63.145.197.240].2109] record too short from [63.145.197.178], zone toprecruits.com

Check the logs on the other server: most likely the zone transfer was denied. Make sure the zone transfer is allowed -- or don't try it.

NOTIFY for non-secondary name

A zone file has a NS record that points to another nameserver that does not know about the zone.

ns_req: no address for root server

And nslookup said "Server failed." This problem was caused when "forward only" was on, but no forwarders listed.

sysquery: nlookup error on ?

Caused when the root server can't be reached. Probably caused by a missing hint file. (On a variety of systems, it has different names: db.root, cache.db, named.root, and root.cache.)

Or maybe your named configuration doesn't have a zone statement for type hint (used to be "cache") for ".". For example:

zone "." {
   type hint;
   file "root.cache";
  };

This hints file (root.cache) can be retrieved by doing: "dig @m.root-servers.net . ns > root.cache". (Which may not help if it can't resolve that -- you may need to use IP or search on web.)

sysquery: no addrs found for root NS

Maybe similar to above (missing hints file or bad A records for them).

Or forwarders points to another DNS server with problems? The named server may report something like:

Feb 24 17:49:30 ns3 named[362]: sysquery: no addrs found for root NS
(G.ROOT-SERVERS.NET)

Response from unexpected source

Nov 15 09:50:08 ns2 named[413]: Response from unexpected source 
([10.0.32.12].53)

BIND ignores answers that don't come from where it sent its query to. BIND doesn't want "spoofed" answers. It appears that the answer came back on a different IP -- the source address didn't match the destination address. This can happen if the other server didn't bind to all of its IP addresses, so the response was sent back using a different IP. Or, maybe the server has multiple internet connections (multi-homed), so the response went back via a different interface than it came in on. This is known to happen if the remote DNS server has multiple NICs and is running a BIND older than 4.9.3.

Or the server's IP addresses aren't listed in the glue records for the parent zone.?

dig(1) reports "connection timed out" (maybe with "no servers could be reached").

Check the server's logs, it is possible that it is just not configured -- a lame server. Once the zone is configured, it won't report bogus "connection timed out".

check_hints: no A records for

Errors like:

Oct 16 11:40:53 bns named[8598]: check_hints: no A records for
F.ROOT-SERVERS.NET class 1 in hints
Oct 16 11:40:53 bns named[8598]: check_hints: no A records for
B.ROOT-SERVERS.NET class 1 in hints

indicate old hints file style. Fixed with "dig @m.root-servers.net . ns > root.cache".

check_hints: A records for J.ROOT-SERVERS.NET class 1 do not match hint records

J.ROOT-SERVERS.NET changed around November 5th, 2002. (As of this writing, the correct A record is 192.58.128.30.) Consider getting a newer root servers hints file. It is available at ftp://rs.internic.net/domain/named.root or you can fetch it with:

dig ns . @M.ROOT-SERVERS.NET.

Database error near ()

The line number is at beginning of log with the zone name, like:

Oct 16 11:31:20 bns named[284]: db.mediservltd.com:4: Database error near ()

This usually has hostname in the parenthesis. If it is blank, then probably some typo, like a colon instead of semicolon.

no current owner name

In your named logs, "no current owner name" means that that zone doesn't have a valid SOA.

non-authoritative answer

Nov 11 13:33:21 secure named[21371]: refresh_callback: zone
 foobarsolutions.com/IN: non-authoritative answer from 192.168.208.3#53

For some reason, the authoritative server isn't configured or serving the zone (except from cache).

query (cache) denied

Aug 31 01:53:56 antelope named[157]: client 207.46.150.16#36789: query (cache)
denied

In this case, the server was supposed to be authoritative, but named was not configured as a slave (or master) for the zone. (Notice that the record asked about was not logged.) Some client resolvers give up when it didn't give an answer (and didn't try the other nameservers).

NOTIFY(SOA) for non-slave zone

The src/bin/named/ns_req.c source says:

This can come if a user did an AXFR of some zone somewhere and that zone's server now wants to tell us that the SOA has changed. AXFR's always come from nonpriv ports so it isn't possible to know whether it was the server or just "dig". This condition can be avoided by using secure zones since that way only real secondaries can AXFR from you.

---

Also check out:
http://www.acmebw.com/askmrdns/bind-messages.htm

Fri Oct 28 21:23:27 PDT 2005
Wed Sep 3 23:05:21 PDT 2003
Thu Jul 3 12:12:18 PDT 2003
Mon Nov 4 10:19:24 PST 2002
Wed Oct 16 09:52:53 PDT 2002
Mon Jun 24 14:22:28 PDT 2002
Mon Jun 24 14:03:17 PDT 2002
Fri Feb 15 08:48:27 PST 2002
Thu Nov 15 13:35:47 PST 2001
Mon Aug 13 14:22:43 PDT 2001
Mon Aug 6 16:34:51 PDT 2001
Thu Jul 12 09:29:02 PDT 2001
Fri Jan 12 12:23:27 PST 2001
Thu Jan 11 08:38:30 PST 2001
Thu Nov 16 08:37:19 PST 2000