Re: [dnsext] Failure to add glue MUST cause TC to be set.

[Brandon Black <[e-mail]>]

On Sun, Feb 20, 2011 at 4:47 PM, Mark Andrews <[e-mail]> wrote:
>> the same single server to trust the suspicious cross-zone
>> glue from.
>
> Your trusting the parent to supply glue for names beneath it.  You
> *have* to trust the parent when it gives you this information.
> These names are all within the baliwick of the parent.

Yes, I was thinking incorrectly when I wrote that, re: A.net. and
B.net.  In the terms of the glue clarification draft James linked, I
guess narrow glue is pretty much required to function if it exists,
and wide glue can work (and is often necessary in examples like your
A.net. vs B.net. one), although it does require some security policy
and management on the part of the parent registrar.  For an easy
general-case rule, you'd probably only want to allow those authorized
to make updates related to B.net.'s NS records to register other glue
address records underneath B.net. upstream, but still allow A.net.
admins to reference existing B.net. glue in their NS records.

The case I was confusing this with (re: optimization, etc) was the
case where there was no immediate common parent domain to host the
cross-zone glue (e.g. A.net. NS ns1.B.org. + B.org. NS ns1.A.net.).
In the special case that the org. and net. nameservers shared IP
addresses (and were in fact the same namservers) and handed out
cross-zone glue addresses for those cases, a smart enough resolver
might figure it out and believe them based on the shared nameserver
IPs ("I already know 192.0.2.3 is authoritative for org. from earlier,
and now during a query for A.net to the same IP address, I'm seeing
B.org. glue records and it's ok to believe them"), but a dumber
resolver would be unable to see records in either domain if it
implemented a sane basic security model (bailiwick of QNAME).  I think
we have to assume the simpler resolver behavior rather than try to
construct schemes that rely on the "smarter" behavior, right?

The optimization part is on the authoritative servers' part.  Should
an authoritative server ever serve glue that's outside the bailiwick
of the delegation's parent zone, just because it knows those glue
addresses are part of other "unrelated" zones it serves, and a
resolver might be smart enough to figure out the relationship?  I
think the answer is no, it's not worth serving that glue.  Most
resolvers are going to send you a second query for it anyway based on
the simple bailwick of QNAME security model.

In general I think the smartest policy in light of all of this is to
always put the NS names for a zone beneath that zone itself, even if
the IPs refer to 3rd-party nameservers, but it certainly doesn't have
to be a requirement to function.
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext