Why do some parent NSs "lie" about delegation records?
LConrad at Go2France.com
Wed Jan 7 19:38:39 UTC 2004
>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
>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.
http://MenAndMice.com/DNS-training : London; San Jose; Chicago
http://IMGate.MEIway.com : free anti-spam gateway, runs on 1000's of sites
More information about the bind-users