9.1.1 being *very* unhelpful.

Jim Reid jim at rfc1035.com
Tue Apr 10 20:52:38 UTC 2001


>>>>> "Christopher" == Christopher L Barnard <cbar44 at tsg.cbot.com> writes:

    >>  What do you mean "it pauses for a few moments"? What pauses?

    Christopher> The binary.  Run a tiny program like /bin/false, then
    Christopher> run a huge program like emacs or bind.  On huge
    Christopher> programs, there is a pause while it loads into
    Christopher> memory.  I thought that was common knowledge.

It is, but your previous mail implied that this was unexpected
behaviour. I quote "and then...nothing. It does not start up".
Now you seem to be saying the server does start and runs OK.

    .... lots of not very relevant dig output snipped ...

dig looks up the name it was given, as-is. It doesn't append a default
domain name or follow any search directive in resolv.conf. The output
from dig you posted showed the name it was looking up. On my cursory
scan, there was nothing untoward there. For example:

	>> dig @srvns2 mozart.tsg
	;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34978
	...
	;; QUESTION SECTION:
	;mozart.tsg.
	;
	;; AUTHORITY SECTION:
	.                       10800   IN      SOA     A.ROOT-SERVERS.NET. hostmaster.nsiregistry.NET. 2001041000 1800 900 604800 86400

In other words dig looked up mozart.tsg in the root zone and got an
NXDOMAIN reply because that name does not exist. Nothing wrong there:
this is exactly what should happen.

The output from other DNS tools you showed doesn't matter. In fact I
think it's confusing you. Stick to one consistent tool: dig. Sometimes
other lookup tools silently "help" by appending domain names from
resolv.conf. Sometimes they use a different resolver library,
especially if you use stuff shipped with the vendor's OS. These can
have unpredictable results and you can't always tell what names are
actually being looked up.

The SERVFAIL error when you looked up srvagd.info.cbot.com is
interesting. It suggests you have a broken name server or a bad
delegation: the server finds that it's supposed to be authoritative
for some zone when it isn't.


More information about the bind-users mailing list