Bind-9 strangeness ?

[Jonathan de Boyne Pollard]

p>     Transaction ID: 0x2f87  ( *** NOTE 1 )
p>     Transaction ID: 0x2f87  ( *** NOTE 1 )
p> *** NOTE 1 ; TransactionID does not match, but these are the same question.
 
JdeBP> It looks very much like it _does_ match.

p> Nope, it does not match the ID in the etherreal log, [...]

Those were the IDs _from_ the etherreal log that you gave.

p> Why should bind-9 behaviour be considered "better" ?

BIND 9 receives a back-end response saying that the domain name
"folkuniversitetet.se." does not exist at all, and so proceeds to 
respond with "no such name" errors to all ensuing front end queries 
against that name; and you want to know why that is _better_ ?  What 
_else_ would you have it do ?  Would you have it ignore what it had
just learned ?  Would you have it return inconsistent answers in the
responses that it itself sends ?

A more salient question would be to ask what reason any proxy DNS
server software, having just been told that the domain name 
"folkuniversitetet.se." does not exist at all, would have for 
continuing to answer as if it did exist.

p> The failing nameserver is a netware, and it seems to be a known 
p> problem that it answers NXDOMAIN when in fact NOERR + #answers=0 
p> should be the correct one. 

Not _yet another_ broken content DNS server software!

p> From a functional standpoint, bind-8 will allow "wheels to 
p> turn" while bind-9 will block the same wheels.

On the contrary: From a functional standpoint, BIND 9 brings the 
problem with the "folkuniversitetet.se." content DNS server at 
212.73.12.10 to light earlier.  Glossing over the error in
order to "allow wheels to turn", leaving us all to suffer from 33
year TTLs and peculiar "AAAA" responses, is worse than highlighting 
it so that it is then actually fixed by the administrator and
things then function properly.