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

[Jim Reid]

>>>>> "Len" == Len Conrad <LConrad at Go2France.com> writes:

    >> 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.

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

Diversity in critical internet infrastructure like the root servers is
a Highly Desirable Thing.

    Len> Is there some kind of religious war preventing agreement?

What makes you think agreement is needed here? The answers the servers
are returning to your hypothetical queries are not breaking anything
-- apart from some script of yours? -- so nobody cares about the issue.

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

This is a very naive and rather stupid question. First define "a
standard behaviour". Secondly, there is no real registry for the root
in the way "registry" is understood in the context of most TLDs. A
whole bunch of organisations are involved in updating the root zone:
ICANN, Verisign, IANA, the US Department of Commerce, etc. Thirdly,
there can only be exactly one registry (singular) for any given
zone. Finally, there is no organisation or DNS police which controls
the root servers: diversity is a good thing, remember?

And if you're talking about an authority imposing something on gTLD
and ccTLD registries, well..... ICANN has enough problems to contend
with already. Even if they had the will and clout to impose some sort
of standards for DNS implementation and server operation, this gets
into nasty issues of National Sovereignty. It's up to the Republic of
Lenconradia how they want to run their TLD, not ICANN.

    Len> But in response to "child.parent.tld NS" query, almost none
    Len> of the root-servers.net, and none of the gtld-servers.net,
    Len> put the NS records in the ANS section

This simply not true. As running the following script will show:

	foreach i ( {a,b,c,d,e,f,g,h,i,j,k,l,m}.root-servers.net )
	echo $i
	dig @$i child.parent.fr ns
	end

ALL of the root servers return an empty Answer Section and 8 NS
records in the Authority section for these queries: referrals in other
words. Similar referrals are returned by ALL of the gtld-servers when
they're queried for child.parent.example.com. However the gtld-servers
do seem to get a little confused when the query name matches a
delegation. This time, they populate the Answer Section instead of the
Additional Section in the reply even though the QNAME lives below the
zone cut.

BTW, as a general rule name servers don't explicitly query for NS
records when they are resolving. The NS records usually get supplied
in the Authority Section of replies when the resolver is looking up
some other name. Think of it as a beneficial side-effect. I've just
check my server's query logs. Of the 1M+ queries it received in the
last month, 28 were for NS records. 26 of them were ones I asked the
server to resolve when troubleshooting problems. In other words, my
name server got only two non-local explicit queries for NS records.
And they appear to have come from a stub resolver rather than a
resolving name server.

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

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

Have you any data to support this claim? Have you done any
measurements and traffic analysis at non-trivial TLD servers and
compared that against the traffic to some of their child delegations?
AFAIK, nobody's done that. It would be an interesting research project
for someone.

    >>  What makes you think this is or could be a BIND issue?

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

You don't seem to have understood my earlier reply. I said BIND9 gets
does that, not "BIND". This is an important distinction. BIND8, like
Verisign's Atlas gets this wrong. They put stuff in the Answer Section
that belongs in the Authority Section. BIND8 doesn't get the
semantics of a zone cut right -- and so does Atlas it seems.