BIND 8.2.2 can return referral for recursive query

[Ian Jackson]

In article <Z_fW4.30$sR4.2069 at burlma1-snr2>,
Barry Margolin  <barmar at genuity.net> wrote:
>In article <Uir*XrKso at news.chiark.greenend.org.uk>,
>Ian Jackson  <ijackson at chiark.greenend.org.uk> wrote:
>>I've discovered that BIND 8 (and perhaps other versions of BIND) can
>>sometimes return a referral (ie, a reply with no answers, no error,
>>and some NS records and no SOA record in the authority section) even
>>if recursion is desired and available.
>
>It's simply forwarding the answer it got from the authoritative server when
>it recursed.  Notice:

Well, quite, but (i) the AA bit isn't set, meaning BIND must have
cached this gibberish or transferred it from some other part of some
other response, and in any case (ii) surely BIND should protect its
client resolvers from such nonsense ?

If the answer to (i) is `that's fine' and the answer to (ii) is that
it's the resolver's problem then I can and should change adns not to
produce a warning when it gets a referral, and just to return to the
application the error code for `Nameserver sent bad response'.

My question is really whether this is a bug in BIND.  If it's a bug in
BIND then I'll leave the warning in, because I can tell people who
(eg) use adnslogres on their webserver logs that the warning is
reporting a symptom of a minor BIND bug which I hope will be fixed at
some point - and of course then I can use the usual channels to try to
get the bug fixed.

If it's reasonable for a recursive nameserver to forward nonsense
answers to its client stub resolvers then obviously I have to deal
with it without producing alarming diagnostics (after all, the DNS is
full of sh*t and having applications doing general-purpose lookups
produce warnings on stderr about remote configuration errors is
generally unhelpful).

>% dig -x 209.121.196.1 ptr @pri1.dns.psi.ca
...
>;; AUTHORITY SECTION:
>*.121.209.in-addr.arpa.  1D IN NS  pri1.dns.psi.ca.
>*.121.209.in-addr.arpa.  1D IN NS  pri2.dns.psi.ca.
>
>Wildcards in delegation records aren't really allowed.  Read the lookup
>algorithm in RFC 1034 -- the server only recognizes a zone cut if it
>encounters an explicit NS record for a suffix of the name being looked up.

Quite so.  Let me make it clear: that DNS data has nothing to do with
me, it just belongs to someone who happened to access my webserver.  I
use adnslogres, adns's replacement for Apache's logresolve, to do the
reverse lookups, and adns didn't like the response you see a copy of
there in dig - it disliked it so much it printed a complaint about it
to stderr, rather than just returning a failure code to the
application.

Usually adns will only issue a diagnostic for things it thinks are
problems with the local nameserver, rather than problems with the data
in the DNS - eg, if it gets replies with RA=0, or corrupted packets,
etc.  The question is whether this particular response is one of
those.

-- 
Ian Jackson, at home.           Local/personal: ijackson at chiark.greenend.org.uk
ian at davenant.greenend.org.uk       http://www.chiark.greenend.org.uk/~ijackson/