> On 1 Feb 2024, at 06:38, Warren Kumari <war...@kumari.net> wrote: > > Hi there, authors (and WG), > > Thank you for this document — I have some questions / comments before I can > progress it. > > Firstly, the (presumably) easy one: > The document says: > "This document, when published, obsoletes RFC 8109." - can you add something > along the lines of "Section 1.1 contains a list of changes from RFC 8109" or > similar…. > > Now the harder one… > Sec 4.2: > "If some root server addresses are omitted from the Additional section, there > is no expectation that the TC bit in the response will be set to 1. At the > time that this document is written, many of the root servers are not setting > the TC bit when omitting addresses from the Additional section.
Root server address are NOT glue. Glue only appears in a referral. The response to "dig NS ." is not a referral. Glue is added RFC 1034 4.3.2. Algorithm Step 3b. Root server addresses are added at Step 6. Step 3b [Paragraph one omitted] 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. vs Step 6 Using local data only, attempt to add other RRs which may be useful to the additional section of the query. Exit. This is why the root servers need to have a local copy of root-servers.net. It’s the data source for those address records. > Note that [RFC9471] updates [RFC1035] with respect to the use of the TC bit. > It says "If message size constraints prevent the inclusion of all glue > records for in-domain name servers, the server must set the TC (Truncated) > flag to inform the client that the response is incomplete and that the client > should use another transport to retrieve the full response." " > > IMO, this text is confusing…. > It sounds like it is saying "RFC9471 says you must set TC if you truncate the > glue. The root server folk are ignoring RFC9471, bad root server folk…" > > I have read the discussion in the WGLC ( inc > https://mailarchive.ietf.org/arch/msg/dnsop/wtjuoVqkKmww988Hyq2QDq_nKpA/ and > am assuming it was rewritten as "If some root server addresses are omitted > from the Additional section…".), but I don't really think that really > addresses my concern — it's easy to miss the subtleties and the "all glue > records" vs "some addresses" bit is tricky. > > It's also true that "At the time that this document is written, many of the > root servers are not setting the TC bit when omitting addresses from the > Additional section." — RFC9471 was only published at the end of September, > there is an open BIND bug to update this behavior (I think! - > https://gitlab.isc.org/isc-projects/bind9/-/issues/4540 ), and is planned to > change in 9.19.x (I think!) > > So, while what it written is all technically correct[0], the tone feels > weird. I think that some of this is because ot the timing of when this and > RFC9471 were written. > > RFC8109 was published 7 years ago, and I'm hoping that rfc8109bis will > survive at least that long. > > I don't know how we address my concern, but it feels like, in e.g 6 years, > this text will have aged poorly... > Can you see about some more massaging of this text? > > W > [0]: The best kind of correct…. > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
