[DNSOP]Requesting final comments on draft-ietf-dnsop-rfc8109bis

[Tim Wicinski <[e-mail]>]

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