On Jun 5, 2020, at 10:37 AM, Wessels, Duane <dwessels=40verisign....@dmarc.ietf.org> wrote: > > The essence of this draft is the addition of once sentence to RFC 1034: > > "If glue RRs do not fit set TC=1 in the header." > > I worry that this is too ambiguous. Does it mean all glue? One glue? As > much as will fit? > > AFAIK most software today is designed to fill up the additional section with > as much glue as possible. Is the name server allowed to add only some glue > RRs, even if more would fit (without truncating, or in a TCP response)? > > Is the name server allowed to fill the additional with all records of one > type, AAAA or A, when the resolver might only have connectivity of the other > type? > > There is also the question of in-domain vs sibling-domain glue. RFC 8499 > (Terminology) notes that "Glue records for sibling domains are allowed, but > not necessary." Should in-domain glue take priority over sibling-domain > glue? Can sibling-domain glue be omitted even if it would fit?
The current document is indeed ambiguous. I propose that it be changed to: If all glue RRs do not fit, set TC=1 in the header. Given Duane's questions above, we can do better with another change to RFC 1034 in this document. In this same paragraph from RFC 1034, it says: Put whatever addresses are available into the additional section, using glue RRs if the addresses are not available from authoritative data or the cache. That could instead be: Put at least one available address into the additional section, using glue RRs if the addresses are not available from authoritative data or the cache. I don't think it is worthwhile to go into more detail about how to choose how many to put in (because RFC 1034 didn't explicitly talk about message size), or the mix of A and AAAA (because RFC 1034 didn't anticipate more than one address type). --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop