>From the status updates today, I see this draft has expired. I really like it (and it is quite simple), and would like to see it picked up and completed (adopted, rough consensus reached, published).
Having reread it and the discussion, I am wondering if useful guidance can be provided regarding the TC=1 and records added. If as much glue as will fit is included, but not all glue fits, add all the glue that fits, and set TC=1. The resolver SHOULD attempt to use the available glue, but retry over TCP if none of the servers found via the available glue respond. I.e. How is TC=1 interpreted currently by different implementations, and is THAT an issue that could/should be clarified, either in this document, or in a separate document? Is it necessary (at all) to mention keeping the glue that fits before setting TC=1? I don't think so, but maybe some commentary to that effect would be helpful? Brian On Fri, Jun 5, 2020 at 11:57 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. > > 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_______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
