BUG: status: SERVFAIL, but then resolves (BIND 8.3.7)

[Kevin Darcy]

Pavel V. Knyazev wrote:

>>>Hi, everybody.
>>>
>>>Please, take a look at this. For a first time named
>>>returns SERVFAIL, but if i query it once again, it
>>>happily returns the answer. Is it a bug?
>>>
>>>BIND 9 always return the answer, no matter does
>>>it find any misconfigured servers or doesn't.
>>>
>>>"packet" is a log file, category packet.
>>>
>>>10:56pm phobos:log# /usr/sbin/named -d 99 -u bind -g bind -t /etc/namedb
>>>/etc/named.conf
>>>10:56pm phobos:log# dig 186.194.in-addr.arpa ns
>>>
>>>; <<>> DiG 8.3 <<>> 186.194.in-addr.arpa ns
>>>;; res options: init recurs defnam dnsrch
>>>;; got answer:
>>>;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58502
>>>;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>>>;; QUERY SECTION:
>>>;;      186.194.in-addr.arpa, type = NS, class = IN
>>>
>>>;; Total query time: 1585 msec
>>>;; FROM: phobos.surnet.ru to SERVER: 127.0.0.1
>>>;; WHEN: Fri Feb 20 22:56:54 2004
>>>;; MSG SIZE  sent: 38  rcvd: 38
>>>
>>>10:56pm phobos:log# ndc stop
>>>10:58pm phobos:log#
>>>      
>>>
>
>  
>
>>Looks like the only glue A record being provided in referrals for
>>186.194.in-addr.arpa is for ns.ripe.net, and that happens to be the only
>>nameserver of the set returning SERVFAIL for the zone. BIND 8 wasn't
>>very smart about backtracking and fetching necessary glue in such
>>situations -- it lacked the so-called "query restart" feature, instead
>>relying on the client to retry the query so that resolution can be
>>completed based on the partial results already obtained. BIND 9 has
>>"query restart" so it just chugs along. Bottom line: if stuff like this
>>matters to you at all, then upgrade to BIND 9.
>>    
>>
>
>Thanks for your explanation. Yes, i know, BIND 9 has no such stupid
>bugs of BIND 8, as it was completely rewritten from scratch. But it still
>consumes a lot of memory and CPU time. ISC promised to make it
>better in the future, i'm going to wait till that moment.
>
>Tell me, do you really know how to read that statistics file or you just
>queried all up-level servers and found the misconfiguration?
>
The debug output had some clues in it, but yes, mostly I used queries to 
determine the exact problem.

>I think such bugs are critical, how do you know, would my sendmail
>start another query to DNS if it didn't find the answer or not?
>
I believe the default configuration of sendmail will retry queries. In 
relatively-modern versions, you can even tune this behavior to a great 
degree (see all of the Timeout.resolver.* options).

                                                                         
                                                - Kevin