bad answers from BIND9 ?

[Kevin Darcy]

Konrad Madej wrote:

>Kevin Darcy <kcd at daimlerchrysler.com> wrote:
>
>  
>
>>To a non-recursive query, a BIND nameserver will give either a) an answer, if
>>it is authoritative for the zone or happens to have the answer cached, b) a
>>referral, if it is not authoritative for the zone, c) some sort of error
>>message, if something has gone wrong.
>>    
>>
>
>  
>
>>The difference between the servers is that the BIND 8 nameserver happens to
>>have the answer cached. So it gives an answer. The BIND 9 nameserver
>>apparently doesn't. So it gives a referral. The respective versions of
>>BIND that these nameservers are running has no apparent bearing on the
>>contents of their responses.
>>    
>>
>
>Have you checked this?
>The answer _really_ depends on what version of BIND you use.
>For example dns3.atman.pl is non-recursive server at all and running
>BIND8 so it can't have any data in cache and gives answer i ANSWER secion:
>
><---------------------------------------------------------------------------->
>$ host -t ns -d -r ee.pl  dns3.atman.pl
>;; res_send()
>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28379
>;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>;;      ee.pl, type = NS, class = IN
>;; Querying server (# 1) udp address = 217.17.34.50
>;; got answer, 98 bytes:
>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28379
>;; flags: qr; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
>;;      ee.pl, type = NS, class = IN
>ee.pl.                  1D IN NS        name2.gi.pl.
>ee.pl.                  1D IN NS        name1.gi.pl.
>name2.gi.pl.            1D IN A         62.89.98.235
>name1.gi.pl.            1D IN A         62.89.98.234
>;; Query done, 2 answers, status: no error
>ee.pl                   NS      name2.gi.pl
>ee.pl                   NS      name1.gi.pl
><---------------------------------------------------------------------------->
>
>Moreover I've checked tinydns from djbdns and it gives answer as BIND8 do.
>So what is the correct (RFC compliant) behaviour in this case?
>
Okay, I see your point. BIND 8 gives glue records as answers to explicit 
NS queries, whereas BIND 9 gives them as referrals. I was thinking that 
caching was involved here somehow, but apparently it is irrelevant.

I think BIND 9's behavior is "correct" in the case because the "real" NS 
records reside in the child zone, so a resolver should be directed to 
the child zone's nameservers in order to get the "best" answer. BIND 8 
had major issues with zone cuts and this is just one of the 
manifestations of that.

                                                                        
                                        - Kevin