On Jan 31, 2024, at 17:39, Paul Wouters <p...@nohats.ca> wrote: > > On Wed, 31 Jan 2024, Paul Hoffman wrote: > >> On Jan 31, 2024, at 15:15, Paul Wouters <p...@nohats.ca> wrote: >>> Can they write a draft with why they are going against the RFC? >> >> Yes, that is possible. However, I think it would be unfair to the DNS >> community to hold up draft-ietf-dnsop-rfc8109bis waiting for that to happen, >> and it would be a bad policy to make draft-ietf-dnsop-rfc8109bis less honest >> about the current and possible future waiting for that to happen. > > 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? > It raises another question why some root servers do set the TC > bit though. If I read 1035 correctly, it specified the TC bit for all truncation, not just for truncated glue records. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
