single domain fails lookup?

[Jim Reid]

>>>>> "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.