single domain fails lookup?

[Jim Warren]

yes, i noticed that it seems to return good information with the dig...any
argument, but if you use the "a" or"mx" or "hinfo" it still fails, and
nslookup fails, and then the root of the problem, sendmail fails with a
"transient parse error -- nameserver timeout" ....which is the real reason
i've got a problem.. we cant send mail to them....

actually dig with any reports the ns records only....and with "soa", i get
the servfail, but ns.utah.edu gets the root-servers returned...the root
servers shouldnt come back as soa, should they?


Jim Warren					Connecting America
jim at coam.net					www.coam.net
	   Phone: 702-648-0390	   Fax:  702-631-3303
			Direct:  648-2712

On Wed, 6 Sep 2000, Jim Reid wrote:

> Date: Wed, 06 Sep 2000 09:28:10 +0100
> From: Jim Reid <jim at rfc1035.com>
> To: Jim Warren <jim at coam.net>
> Cc: bind-users at isc.org
> Subject: Re: single domain fails lookup? 
> 
> >>>>> "Jim" == Jim Warren <jim at coam.net> writes:
> 
>     Jim> I am having the same kind of problem with this domain:
>     Jim> omniairintl.com with dig @dns.coam.net omniairintl.com i get
>     Jim> a SERVFAIL id: 6 interestingly, i have the same results from
>     Jim> my secondary dns, ns1.espire.net
> 
> If there was a problem with your name servers looking up this domain,
> it has gone away:
> 
> 	% dig @dns.coam.net omniairintl.com any
> 
> 	; <<>> DiG 9.0 <<>> @ns1.espire.net omniairintl.com any
> 	;; global options:  printcmd
> 	;; Got answer:
> 	;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6577
> 	;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0
>         ... rest of answer snipped ...
> 	% dig @ns1.espire.net omniairintl.com any
> 
> 	; <<>> DiG 9.0 <<>> @dns.coam.net omniairintl.com any
> 	;; global options:  printcmd
> 	;; Got answer:
> 	;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28709
> 	;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0 
> 	... rest of answer snipped ...
> 
>     Jim> is there some widespread, but "intermittent" problem that
>     Jim> anyone is aware of?  does anyone have any ideas about where
>     Jim> to start trying to fix this?
> 
> SERVFAIL errors tend to get returned when two very bad things happen.
> The first is resource starvation: for instance the name server can't
> allocate memory to construct a reply or temporary working space when
> resolving a query. These conditions tend to be transient, but easily
> identified because the OS will be complaining and other applications
> which need memory or OS buffers will be failing. The second cause of
> SERVFAIL is forwarding/resolving loops: the name server detects a
> query for some name coming from another name server that should be
> authoritative for the zone containing the name being looked up. These
> are harder to pin down. In this case, it doesn't help that the problem
> appears to have been fixed.
> 
> The source of a SERVFAIL error can usually be found by querying all of
> the name servers for some zone with dig and looking at the status
> field of the replies. Configurations with forwarding name servers
> complicate matters. Suppose server A forwards to B which forwards to
> C. Someone queries A and gets a SERVFAIL reply. They don't know that A
> is a forwarding server and can't even tell that it's one, so how could
> they trace the source of the error? Is it A that's broken or does the
> fault lie in B or C that are lurking behind the scenes? This is one of
> the reasons why I'm not fond of forwarding name servers.
> 
> Finding out the reason why a name server returns SERVFAIL is another
> story... The zone's NS records sometimes help. For instance they might
> say that foo is the only name server for bar. But foo isn't configured
> to serve bar. When someone queries foo for bar, foo finds the NS
> records as it tries to resolve the name. Then it discovers it would be
> sending queries to itself. Result: SERVFAIL.
>