Re: [dnsext] zone cut semantics

[Brandon Black <[e-mail]>]

On Sun, Feb 20, 2011 at 8:43 PM, Jim Reid <[e-mail]> wrote:
>> The root servers are authoritative for everything, that's why we believe
>> their delegation answers.
>
> No they are not. The root servers are authoritative for the root zone*.
> Which largely holds pointers to where we can find authoritative data about
> other names in the DNS. The root zone cannot be authoritative for those
> pointers (delegations) because they live beneath the zone cuts for the TLDs.
>
> I'm not sure what you mean by "believe delegation answers". No, please don't
> try to explain... But you seem to be wrong about that too. The root servers
> may well tell us there's a delegation for .brandon. But a resolving name
> server won't "believe" that until it gets an authoritative answer from one
> of the .brandon name servers, confirming the TLD's existence. And hopefully
> validates all of that with DNSSEC.

Fine, I won't use the word Authoritative in way that doesn't conform
to the specifications, that's fair.

The only way the resolver knows to believe the answer from the
.brandon name servers is based on glue it believed from the root
server.  One way or another, you cannot avoid the fact that the root
servers control .brandon's resolution, directly or indirectly.  The
root servers make a poor example though, because they're universal.
Let's look at example.com. vs example.org. again, assuming the root
delegates com. and org. to different sets of nameservers.

If the org. nameservers answer www.example.org. with:

example.org. NS ns1.example.com.
ns1.example.com. A 192.0.2.1

I thought it was part of avoiding cache poisoning, etc, that org.
nameservers are not to be believed for glue outside of its authority,
and that the resolver should query ns1.example.com. separately.  Or is
it the view of the RFCs that ns1.example.com. is basically
functionally a "temporary" name that ties those two response RRs
together just to be used once to contact 192.0.2.1 for this one
delegation and never cached, and that this doesn't need to be
independently verified through the com. servers?  I was under the
impression this is why it matters whether example.org.'s nameserver
glue is or isn't within org., and hence my whole point about why this
matters for glue.  An un-snarky correction on this would be
appreciated :P