In message <[email protected]>, Paul Vixie writes:
> On Thursday, October 27, 2011 10:06:25 Havard Eidnes wrote:
> > I wonder if I could please have someone say whether they agree
> > with me on this one:
> > ...
> > My claim is that it is a "Registry Error" for the operator of the
> > registry for the 'z' domain to permit this to happen, as it
> > violates the basic idea of what a "delegation" means.
> > ...
>
> i'm +1 with this interpretation. not just because implementations do not all
> do the same thing in the presence of this data pattern, but because in recent
> decades we've adopted a "mount point semantics" view of dns delegations. this
> should be written down somewhere, because the rfc 1034 rules about "scan down
> the tree looking for a delegation" logic does not mesh well with the "closest
> enclosure" logic that most implementations actually follow.
RFC 1034 does mount point to find the zone (step 2) and scan down
within the zone to find the delegation within the zone (step 3).
It's when you try to merge multiple zones into one database and
just scan down that you get problems (BIND 4 and BIND 8 did this
and mangled the zone content in the process).
RFC 1034, Section 4.3.2. Algorithm
2. Search the available zones for the zone which is the nearest
ancestor to QNAME. If such a zone is found, go to step 3,
otherwise step 4.
3. Start matching down, label by label, in the zone. The
matching process can terminate several ways:
The DNS has always had the concept of occulted data. Glue is
occulted data and is only returned in referrals. You can't look
for glue directly and it is visible in axfr.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
