> On Jun 5, 2020, at 11:56 AM, Paul Hoffman <paul.hoff...@icann.org> wrote: > > 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.
I believe this is contrary to how most authoritative DNS software works today, isn't it? > > 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. And that sounds like the opposite of what you suggested above? DW
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
