Q: I've been getting the following messages lately from bind-4.9.2..
ns_req: no address for root server
We are behind a firewall and have the following for our named.cache file -
; list of servers
. 99999999 IN NS POBOX.FOOBAR.COM.
99999999 IN NS FOOHOST.FOOBAR.COM.
foobar.com. 99999999 IN NS pobox.foobar.com.
You can't do that. Your nameserver contacts POBOX.FOOBAR.COM, gets
the correct list of root servers from it, then tries again and fails
because of your firewall.
You will need a 'forwarder' definition, to ensure that all requests are forwarded to a host which can penetrate the firewall. And it is unwise to put phony data into 'named.cache'.
Q: We are getting logging information in the form:
Apr 8 08:05:22 gute named[107]: sysquery: no addrs found for root NS
(A.ROOT-SERVERS.NET)
Apr 8 08:05:22 gute named[107]: sysquery: no addrs found for root NS
(B.ROOT-SERVERS.NET)
Apr 8 08:05:22 gute named[107]: sysquery: no addrs found for root NS
(C.ROOT-SERVERS.NET)
...
We are running bind 4.9.5PL1 Our system IS NOT behind a firewall. Any ideas ?
This was discussed on the mailing list in November of 1996. The short
answer was to ignore it as it was not a problem. That being said, you
should upgrade to a newer version at this time if you are running a
non-current version :-)
Q: I've received errors before about "No root nameservers for class XX" but they've been because of network connectivity problems. I believe that Class 1 is Internet Class data. And I think I heard someone say that Class 4 is Hesiod?? Does anyone know what the various Class numbers are?From RFC 1700:
DOMAIN NAME SYSTEM PARAMETERS
The Internet Domain Naming System (DOMAIN) includes several
parameters. These are documented in [RFC1034] and [RFC1035]. The
CLASS parameter is listed here. The per CLASS parameters are
defined in separate RFCs as indicated.
Domain System Parameters:
Decimal Name References
-------- ---- ----------
0 Reserved [PM1]
1 Internet (IN) [RFC1034,PM1]
2 Unassigned [PM1]
3 Chaos (CH) [PM1]
4 Hesoid (HS) [PM1]
5-65534 Unassigned [PM1]
65535 Reserved [PM1]
DNS information for RFC 1700 was taken from
ftp.isi.edu : /in-notes/iana/assignments/dns-parameters
Hesiod is class 4, and there are no official root nameservers for
class 4, so you can safely declare yourself one if you like. You might want
to put up a packet filter so that no one outside your network is
capable of making Hesiod queries of your machines, if you define yourself to
be a root nameserver for class 4.
Question 6.3. Bind 4.9.x and MX querying?
Date: Sun Nov 27 23:32:41 EST 1994
If you query a 4.9.x DNS server for MX records, a list of the MX
records as well as a list of the authorative nameservers is returned.
This happens because bind 4.9.2 returns the list of nameserver that
are authorative for a domain in the response packet, along with their IP
addresses in the additional section.
Question 6.4. Do I need to define an A record for localhost
?
Date: Sat Sep 9 00:36:01 EDT 1995
Somewhere deep in the BOG (BIND Operations Guide) that came with 4.9.3 (section 5.4.3), it says that you define this yourself (if need be) in the same zone files as your "real" IP addresses for your domain. Quoting the BOG:
... As implied by this PTR
record, there should be a ``localhost.my.dom.ain''
A record (with address 127.0.0.1) in every domain
that contains hosts. ``localhost.'' will lose its
trailing dot when 1.0.0.127.in-addr.arpa is queried
for;...
The sample files in the BIND distribution show you what needs to be
done (see the BOG).
Some HP boxen (especially those running HP OpenView) will also need
"loopback" defined with this IP address. You may set it as
a CNAME record pointing to the "localhost." record.
Question 6.5. MX records, CNAMES and A records for MX
targets
Date: Sun Nov 27 23:32:41 EST 1994
The O'Reilly "DNS and Bind" book warns against using non-canonical names in MX records, however, this warning is given in the context of mail hubs that MX to each other for backup purposes. How does this apply to mail spokes. RFC 974 has a similar warning, but where is it specifically prohibited to us an alias in an MX record ?
Without the restrictions in the RFC, a MTA must request the A records for every MX listed to determine if it is in the MX list then reduce the list. This introduces many more lookups than would other wise be required. If you are behind a 1200 bps link YOU DON'T WANT TO DO THIS. The addresses associated with CNAMES are not passed as additional data so you will force additional traffic to result even if you are running a caching server locally.
There is also the problem of how does the MTA find all of it's IP addresses. This is not straight forward. You have to be able to do this is you allow CNAMEs (or extra A's) as MX targets.
The letter of the law is that an MX record should point to an A record.
There is no "real" reason to use CNAMEs for MX targets or separate As for nameservers any more. CNAMEs for services other than mail should be used because there is no specified method for locating the desired server yet.
People don't care what the names of MX targets are. They're invisible to the process anyway. If you have mail for "mary" redirected to "sue" is totally irrelevant. Having CNAMEs as the targets of MX's just needlessly complicates things, and is more work for the resolver.
Having separate A's for nameservers like "ns.your.domain" is pointless too, since again nobody cares what the name of your nameserver is, since that too is invisible to the process. If you move your nameserver from "mary.your.domain" to "sue.your.domain" nobody need care except you and your parent domain administrator (and the InterNIC). Even less so for mail servers, since only you are affected.
Q: Given the example -
hello in cname realname
mailx in mx 0 hello
Now, while reading the operating manual of bind it clearly states
that this is *not* valid. These two statements clearly contradict
each other. Is there some later RFC than 974 that overrides what is
said in there with respect to MX and CNAMEs? Anyone have the
reference handy?
A: This isn't what the BOG says at all. See below. You can have a CNAME
that points to some other RR type; in fact, all CNAMEs have to point
to other names (Canonical ones, hence the C in CNAME). What you
can't have is an MX that points to a CNAME. MX RR's that point to
names which have only CNAME RR's will not work in many cases, and
RFC 974 intimates that it's a bad idea:
Note that the algorithm to delete irrelevant RRs breaks if LOCAL has
a alias and the alias is listed in the MX records for REMOTE. (E.g.
REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This
can be avoided if aliases are never used in the data section of MX
RRs.
Here's the relevant BOG snippet:
aliases {ttl addr-class CNAME Canonical name
ucbmonet IN CNAME monet
The Canonical Name resource record, CNAME, speci-
fies an alias or nickname for the official, or
canonical, host name. This record should be the
only one associated with the alias name. All other
resource records should be associated with the
canonical name, not with the nickname. Any
resource records that include a domain name as
their value (e.g., NS or MX) must list the canoni-
cal name, not the nickname.
Can I do this ? Is it legal ?
@ SOA (.........)
NS ns.host.this.domain.
NS second.host.another.domain.
ns CNAME third
third IN A xxx.xxx.xxx.xxx
No. Only one RR type is allowed to refer, in its data field, to a
CNAME, and that's CNAME itself. So CNAMEs can refer to CNAMEs but
NSs and MXs cannot.
BIND 4.9.3 (Beta11 and later) explicitly syslogs this case rather than simply failing as pre-4.9 servers did. Here's a current example:
Dec 7 00:52:18 gw named[17561]: "foobar.com IN NS" \
points to a CNAME (foobar.foobar.com)
Here is the reason why:
Nameservers are not required to include CNAME records in the
Additional Info section returned after a query. It's partly an
implementation decision and partly a part of the spec. The
algorithm described in RFC 1034 (pp24,25; info also in RFC 1035, section 3.3.11, p 18) says 'Put whatever addresses are available
into the additional section, using glue RRs [if necessary]'.
Since NS records are speced to contain only primary names of
hosts, not CNAMEs, then there's no reason for algorithm to
mention them. If, on the other hand, it's decided to allow CNAMEs
in NS records (and indeed in other records) then there's no
reason that CNAME records might not be included along with A
records. The Additional Info section is intended for any
information that might be useful but which isn't strictly the
answer to the DNS query processed. It's an implementation
decision in as much as some servers used to follow CNAMEs in
NS references.
Question 6.7. Nameserver forgets own A record
Date: Fri Dec 2 16:17:31 EST 1994
Q: Lately, I've been having trouble with named 4.9.2 and 4.9.3. Periodically, the nameserver will seem to "forget" its own A record, although the other information stays intact. One theory I had was that somehow a site that the nameserver was secondary for was "corrupting" the A record somehow. A: This is invariably due to not removing ALL of the cached zones when you moved to 4.9.X. Remove ALL cached zones and restart your nameservers. You get "ignoreds" because the primaries for the relevant zones are running old versions of BIND which pass out more glue than is required. named-xfer trims off this extra glue.
Paul Vixie says:
I'm always interested in hearing about cases where BIND dumps core. However, I need a stack trace. Compile with -g and not -O (unless you are using gcc and know what you are doing) and then when it dumps core, get into dbx or gdb using the executable and the core file and use "bt" to get a stack trace. Send it to me <paul@vix.com> along with specific circumstances leading to or surrounding the crash (test data, tail of the debug log, tail of the syslog... whatever matters) and ideally you should save your core dump for a day or so in case I have questions you can answer via gdb/dbx.
We have replaced malloc on our DECstations with a malloc that is more compact in memory usage, and this helped the operation of bind a lot. The source is now available for anonymous ftp from
ftp.cs.wisc.edu : /pub/misc/malloc.tar.gz
Question 6.10. Can't resolve names without a
"."
(Answer written by Mark Andrews) You are not using a
RFC 1535 aware resolver. Depending upon the age of your resolver you could try
adding a search directive to resolv.conf.
e.g. domain <domain> search <domain> [<domain2> ...]If that doesn't work you can configure you server to serve the parent and grandparent domains as this is the default search list.
"domain langley.af.mil" has an implicit "search langley.af.mil af.mil mil" in the old resolvers, and you are timing out trying to resolve the address with one of these domains tacked on.
When resolving internic.net the following will be tried in order.
internic.net.langley.af.mil
internic.net.af.mil
internic.net.mil
internic.net.
RFC 1535 aware resolvers try qualified address first.
internic.net.
internic.net.langley.af.mil
internic.net.af.mil
internic.net.mil
RFC 1535 documents the problems associated with the old search
algorithim, including security issues, and how to alleviate some of
the problems.
The question was:
I've been diagnosing a problem with BIND 4.9.x (where x is usually 3BETA9 or 3REL) for several months now. I finally tracked it down to swap space utilization on the unix boxes. This happens under (at least) under Linux 1.2.9 & 1.2.13, SunOS 4.1.3U1, 4.1.1, and Solaris 2.5. The symptom is that if these machines get into swap at all bind quits resolving most, if not all queries. Mind you that these machines are not "swapping hard", but rather we're talking about a several hundred K TEMPORARY deficiency. I have noticed while digging through various archives that there is some referral to "bind thrashing itself to death". Is this what is happening ?And the answer is:
Yes it is. Bind can't tolerate having even a few pages swapped out. The time required to send responses climbs to several seconds/request, and the request queue fills and overflows. It's possible to shrink memory consumption a lot by undefining STATS and XSTATS, and recompiling. You could nuke DEBUG too, which will cut the code size down some, but probably not the data size. If that doesn't do the job then it sounds like you'll need to move DNS onto a separate box. BIND tends to touch all of its resident pages all of the time with normal activity... if you look at the RSS verses the total process size, you will always see the RSS within, usually, 90% of the total size of the process. This means that *any* paging of named-owned pages will stall named. Thus, a machine running a heavily accessed named process cannot afford to swap *at all*. (Paul Vixie continues on this subject): I plan to try to get BIND to exhibit slightly better locality of reference in some future release. Of course, I can only do this if the query names also exhibit some kind of hot spots. If someone queries all your names often, BIND will have to touch all of its VM pool that often. (Right now, BIND touches everything pretty often even if you're just hammering on some hot spots -- that's the part I'd like to fix. Malloc isn't cooperating.)
When bind-8.1.1 is started the following informational message appears in the syslog...
Feb 13 14:19:35 ns1named[1986]:
"cannot set resource limits on this system"
What does this mean ?
A: It means that BIND doesn't know how to implement the "coresize", "datasize", "stacksize", or "files" process limits on your OS.
If you're not using these options, you may ignore the message.
Question 6.13. ERROR:ns_forw: query...learnt
Date: Sun Feb 15 23:08:06 EST 1998
The following message appears in syslog:
Jan 22 21:59:55 server1 named[21386]: ns_forw: query(testval) contains
our address (dns1.foobar.org:1.2.3.4) learnt (A=:NS=)
what does it mean ?
A: This means that when it was looking up the NS records for the domain
containing "testval" (i.e. the root domain), it found an NS record
pointing to dns1.foobar.org, and the A record for this is 1.2.3.4.
This is server1's own IP address, but it's not authoritative for the
root domain. The (A-:NS=) part of the message means that it didn't
learn these NS records from any other machine.
You may have listed dns1.foobar.org in your root server cache
file, even though it's not configured as a root server.
\question 09jul:linuxq ERROR:recvfrom: Connection refused
Date: Wed Jul 9 21:57:40 EDT 1997
DNS on my linux system is reporting the error
\verbatim
Mar 26 12:11:20 idg named[45]: recvfrom: Connection refused
When I start or restart the named program I get no errors.
What could be causing this ?
A: Are you running the BETA9 version of bind 4.9.3 ? It is a bug
that does no harm and the error reporting was corrected in later releases. You
should upgrade to a newer version of bind.
Question 6.14. ERROR:zone has trailing dot
Date: Wed Jul 9 22:11:51 EDT 1997
If syslog reports "zone has trailing dot", the zone information contains a trailing dot in the named.boot file where it does not belong.
example:
secondary domain.com. xxx.xxx.xxx.xxx S-domain.com
^
If syslog reports "Zone declared more then once",
A zone is specified multiple times in the named.boot file
example: secondary domain.com 198.247.225.251 S-domain.com secondary zone.com 198.247.225.251 S-zone.com primary domain.com P-domain.com domain.com is declared twice, once as primary, and once as secondary
If syslog reports "response from unexpected source",
BIND (pre 4.9.3) has a bug if implimented on a multi homed server.
This error indicates that the response to a query came from an address
other then the one sent to. So, if ace gets a response from an
unexpected source, ace will ignore the response.
Question 6.17. ERROR:record too short from [zone
name]
Date: Mon Jun 15 21:34:49 EDT 1998
If syslog report "record too short from [zone name]", The secondary server is trying to pull a zone from the primary server. For some reason, the primary sent an incomplete zone. This usually is a problem at the primary server.
To troubleshoot, try this: dig [zonename] axfr @[primary IP address] Often, this is caused by a line broken in the middle.When the primary server's "named.boot" file contains "xfrnets" entries for other servers and the secondary is not listed, this error can occur. Creating an "xfrnets" entry for the secondary will solve the error.
If syslog reports "sysquery: findns error (3)" or
"qserial_query(zonename): sysquery FAILED", there is no ns
record for the zone. or the NS record is not defined correctly.
Question 6.19. ERROR:Err/TO getting serial# for
XXX
Date: Wed Jul 9 22:18:41 EDT 1997
If syslog reports "Err/TO getting serial# for XXX", there could be a number of possible errors:
- An incorrect IP address in named.boot, - A network reachibility problem, - The primary is lame for the zone.An external check to see if you can retrieve the SOA is the best way to work out which it is.
If syslog reports "zonename IN NS points to a CNAME" or "zonename IN MX points to a CNAME", named is 'reminding' you that due to various RFCs, an NS or MX record cannot point to a CNAME.
EXAMPLE 1
---------
domain.com IN SOA (...stuff...)
IN NS ns.domain.com.
ns IN CNAME machine.domain.com.
machine IN A 1.2.3.4
The IN NS record points to ns, which is a CNAME for machine. This
is what results in the above error
EXAMPLE 2
---------
domain.com IN SOA (...stuff...)
IN MX mail.domain.com.
mail IN CNAME machine.domain.com.
machine IN A 1.2.3.4
This would cause the MX variety of the error.
The fix is point MX and NS records to a machine that is defined explicitly
by an IN A record.
If syslog reports "Masters for secondary zone [XX]
unreachable", the initial attempts to load a zone failed, and the name
server is still trying. If this occurs multiple times, a problem
exists, likely on the primary server. This is a fairly generic error,
and could indicate a vast number of problems. It might be that named
is not running on the primary server, or they do not have the correct
zone file. If this keeps up long enough a zone might expire.
Question 6.22. ERROR:secondary zone [XX]
expired
Date: Wed Jul 9 22:25:53 EDT 1997
If syslog reports "secondary zone [XX] expired", there has been a expiration of a secondary zone on this server.
An expired zone is one in which a transfer hasn't successfully been completed in the amount of time specified before a zone expires.
This problem could be anything which prevents a zone transfer: The
primary server is down, named isn't running on the primary, named.boot
has the wrong IP address, etc.
Question 6.23. ERROR:bad response to SOA query from
[address]
Date: Wed Jan 14 12:15:11 EST 1998
If syslog reports "bad response to SOA query from [address], zone [name]", a syntax error may exist in the SOA record of the zone your server is attempting to pull.
It may also indicate that the primary server is lame, possibly due to
a syntax error somewhere in the zone file.
Question 6.24. ERROR:premature EOF, fetching
[zone]
Date: Wed Jul 9 22:28:26 EDT 1997
If syslog reports "premature EOF, fetching [zone]", a syntax
error exists on the zone at the primary location, likely towards the End of File
(EOF) location.
Question 6.25. ERROR:Zone [XX] SOA serial# rcvd from [Y] is <
ours
Date: Wed Jul 9 22:30:03 EDT 1997
If syslog reports "Zone [name] SOA serial# rcvd from [address] is
< ours", the zone transfer failed because the primary machine has a lower
serial number in the SOA record than the one on file on this server.
Question 6.26. ERROR:connect(IP/address) for zone [XX]
failed
Date: Wed Jan 14 12:21:40 EST 1998
If syslog reports "connect(address) for zone [name] failed: No route to host" or "connect(address) for zone [name] failed: Connection timed out", it could be that there is no route to the specified host or a slow primary system. Try a traceroute to the address specified to isolate the problem. The problem may be a mistyped IP address in named.boot.
A very slow primary machine or a connection may have been initialized, then connectivity lost for some reason, etc. Try networking troubleshooting tools like ping and traceroute, then try connecting to port 53 using nslookup or dig.
If syslog reports "connect(address) for zone [name] failed:
Connection refused", the destination address is not allowing the connection.
Either the destination is not running DNS (port 53), or possibly
filtering the connection from you. It is also possible that the
named.boot is pointing to the wrong address.
Question 6.27. ERROR:sysquery: no addrs found for
NS
Date: Wed Jul 9 22:37:01 EDT 1997
If syslog reports "sysquery: no addrs found for NS" , the IN
NS record may be pointing to a host with no IN A record.
Question 6.28. ERROR:zone [name] rejected due to
errors
Date: Wed Jul 9 22:37:51 EDT 1997
If syslog reports "primary zone [name] rejected due to errors", there will likely be another more descriptive error along with this, like "zonefile: line 17: database format error". That zone file should be investigated for errors.
Chris Peckham - 16 July 1998