On Fri, Mar 13, 2015 at 12:05 PM, Tony Finch <d...@dotat.at> wrote: > Shumon Huque <shu...@gmail.com> wrote: > > > > It might be worth also clarifying another thing. The definition states > > "These RRs are only necessary if", but doesn't clearly include or > > exclude the possibility that other address records for NS names that > > don't sit below the zone cut, and were gratuitously provided in the > > referral response, qualify to be called 'glue'. I think they should not > > be called glue (they don't meet my intuitive understanding of the > > meaning of 'glue', as gluing up a hole in the resolution path). But > > clarity on this point would be welcome. > > In the additional section of a referral, address records for name servers > that are not in the delegated zone are not glue records. This is implied > by RFC 1034 section 4.3.2: > > Copy the NS RRs for the subzone into the authority > section of the reply. Put whatever addresses are > available into the additional section, using glue RRs > if the addresses are not available from authoritative > data or the cache. Go to step 4. >
Ah, right. I see the implication. That's good. What I'd like to see is something clearer than the implication in the terminology draft definition. After all, one of the goals is to clear up confusion about the terms. > > Section 4.2.1 classifies zone data into authoritative data, apex > authoritative data, delegations, and glue, and says glue is > non-authoritative. It also says glue records are only used as part of a > referral response, which is not the case for authoritative name server > address records. But a nameserver could also return a referral with address records that aren't glue, but that they also aren't authoritative for (that sit in some other zone) - I believe these exist in the wild. I'm okay with not having a name for such things (Paul's desire), but it would be nice to definitively exclude them from the definition of glue records. Shumon Huque.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
