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

[Pavel V. Knyazev]

> > 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?

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?

--
Pavel V. Knyazev