> On Jan 31, 2024, at 5:57 PM, Paul Hoffman <paul.hoff...@icann.org> wrote: > >> As Mark just clarified. This isn't glue, so perhaps the text just needs >> updating. > > The current text is: > > <t>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.</t> > > <t>Note that <xref target="RFC9471"/> updates <xref target="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."</t> > > Maybe we should add to the second paragraph: > > Note, however, the root server addresses are not glue records, so setting the > TC bit in truncated responses from > the root servers is not required by RFC 9471. > > Does this solve your and Warren's issues?
I have to confess that “root server addresses are not glue records” is a very subtle point that was lost on me, and maybe lost on a lot of us, as evidenced by this discussion. I’m not particularly comfortable with the terseness of the statement above. The terminology RFC doesn’t really help here because it doesn’t provide a definition of what glue is glue or what is not glue. It just references semi-conflicting statements in other RFCs. So I think if 8109bis is going to make the statement that root server addresses are not glue, it deserves more explanation of why that is the case. I also worry that it creates a new problem, which is what sort of truncation policy applies to a priming response? If RFC 9471 does not apply, does RFC 2181 Section 9 apply? Is a priming response with zero root server IP addresses acceptable? DW
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
