Why do some parent NSs "lie" about delegation records?

[Len Conrad]

>As Mark has pointed out, these servers are not lying. It's the servers
>that you've called "honest" that are the ones who are lying.

ok, thanks. I'm amazed that such key, ancient infrastructure such as the 
roots and generic TLDs, cannot agree to behave the same.

Is there some kind of religious war preventing agreement?

Why doesn't the organization that authorizes the registries impose a 
standard behavior?

>A zone's NS records should go in the Authority Section of a reply from the
>parent zone's servers, not the Answer Section

In a referral, in response to a "child.parent.tld non-NS" query, yes.

But in response to  "child.parent.tld NS" query, almost none of the 
root-servers.net, and none of the gtld-servers.net, put the NS records in 
the ANS section, and are therefore broken.   Just goes to show you can't 
trust anybody :))

>After all it's the child that's definitive for the delegation, not the parent.

ok, fine, but in practice, the parent zone's NSs provide a much higher of 
volume of delegation/glue records as referrals than do the AUTH NSs provide 
as 'aa' answers.

I also note an analogous discrepancy when querying for a glue 
record.  Sometimes the A record is returned in the ANS section, and 
sometimes in the ADD section as part of a referral.

>     Len> Is there a BIND parameter for that com.au. behavior, er,
>     Len> behaviour?
>
>What makes you think this is or could be a BIND issue?

I don't think it's a BIND "issue".  I just asked if the two widespread 
behaviors were supported by BIND as a param switch, and the answer is 
apparently "no":  BIND doesn't respond with delegation or glue records in 
the ANS section, but only in the AUTH or ADD sections.

Thanks
Len


_____________________________________________________________________
http://MenAndMice.com/DNS-training : London; San Jose; Chicago
http://IMGate.MEIway.com : free anti-spam gateway, runs on 1000's of sites