All The chairs are requesting some final comments on draft-ietf-dnsop-rfc8109bis. As you might recall, this document has already been through WGLC and had consensus to advance, but our AD reviewed it and raised some additional questions. (Warren Kumari, “AD Review of draft-ietf-dnsop-rfc8109bis,” email to the list on 31 January.)
Here are specific things we particularly want feedback on: -Discussion on the list suggested a change regarding the use of the TC bit in the context of a priming response, which appears in the -04 (current) version of the document but hasn’t been reviewed by the full WG: OLD: 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." 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 [RFC9471]. NEW: 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." Because the priming response is not a referral, root server addresses in the priming response are not considered glue records. Thus, [RFC9471] does not apply to the priming response and root servers are not required to set the TC bit if not all root server addresses fit within message size constraints. There are no requirements on the number of root server addresses that a root server must include in a priming response. Willem's email to the list which suggests changes to section 3.3 to better explain what is signed when; the chairs feel that these changes should be incorporated into the draft as well https://mailarchive.ietf.org/arch/msg/dnsop/D2Ha-Hk2lpvvkcXx7k4RILpgaPQ/ The addition of a reference to RSSAC 0028 ( https://www.icann.org/en/system/files/files/rssac-028-03aug17-en.pdf, “Technical Analysis of the Naming Scheme Used For Individual Root Servers,” as an informative reference; it discusses the rationale for not signing root-servers.net. We liked to hear from the WG on this by Friday June 14, 2024. Thanks tim, et al
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
