On Wed, Dec 15, 2021 at 09:17:42PM +0000, Wessels, Duane wrote: > Despite what the subject line says, I’d like to follow up on the > discussion about glue from today’s interim meeting. > > First, I think the definition of glue given in RFC 2181 is problematic > in a number of ways. It is overly broad (e.g., "any record ... that > is not properly part of that zone” and "any other stray data that > might appear”). It essentially says that all non-authoritative data > is glue, including NS, which is wrong IMO. > > If we can ignore what 2181 says, then the question is whether or not > glue is limited only to addresses. Historically it has only meant > addresses, since those address RRs were required for zones with > in-domain name servers. There are some new proposals in DPRIVE to > publish more record types in parent zones and have them considered as > glue. This has obvious implications server behavior given the > glue-is-not-optional draft. > > On one hand I think it would be a lot simpler to just say that only > address records can be glue. But I’m not sure that is defendable > given the directions things are going. Here’s a definition of glue > that I came up with: > > Glue is non-authoritative data in a zone that is transmitted in the > additional section of a referral response on the basis that the data > might be necessary for resolution to proceed at the referred name > servers. > > I also feel like we might be heading in a direction where there would > need to be a registry or some standardization of which RR types can be > treated as glue.
RFC 5936 (the AXFR RFC) section 3.5 calls names under a zonecut, but
part of the (parent) zone as "occluded names". It can happen with both
NS cuts and existence of DNAME:
> 3.5. Occluded Names
> Dynamic Update [RFC2136] operations, and in particular their
> interaction with DNAME [RFC2672], can have a side effect of occluding
> names in a zone. The addition of a delegation point via dynamic
> update will render all subordinate domain names to be in a limbo,
> still part of the zone but not available to the lookup process. The
> addition of a DNAME resource record has the same impact. The
> subordinate names are said to be "occluded".
> Occluded names MUST be included in AXFR responses. An AXFR client
> MUST be able to identify and handle occluded names. The rationale
> for this action is based on a speedy recovery if the dynamic update
> operation was in error and is to be undone.
Though records with occluded names are considered "glue", there is a
semantic difference in the context in which the term "glue" is used
vs. occluded names - in that "glue is used in connecting the zone cuts".
Clarification with extra description is good. I don't know if the
currently accepted liberal meaning should be restricted further.
Mukund
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
