[DNSOP] Re: [Ext] [DNSOP]Requesting final comments on draft-ietf-dnsop-rfc8109bis
Paul On Wed, Jun 5, 2024 at 12:28 PM Paul Hoffman wrote: > Tim jumped the gun by about an hour: we just submitted the -05. It > incorporates the suggested text from below; you can see the diff at: > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-rfc8109bis-05 I am guilty as charged. But our comment on we would like people to review the changes. > > > FWIW, this new text is somewhat based on the findings from NLnetLabs and > SIDN on a project supported by ICANN. You can see the report, and an > earlier report on a related topic, at: > > https://www.icann.org/resources/pages/octo-commissioned-documents-2020-11-05-en > > Please let us know if you have any issues with the changed text in the new > version. > Thank you for incorporating those changes. However, I do have one small nit: ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) thanks tim > --Paul Hoffman > > > On Jun 5, 2024, at 08:25, Tim Wicinski wrote: > > > > 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/ [ > mailarchive.ietf.org] > > 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 [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
[DNSOP] Re: [DNSOP]Re: [Ext] Requesting final comments on draft-ietf-dnsop-rfc8109bis
Paul Hoffman: Tim jumped the gun by about an hour: we just submitted the -05. It incorporates the suggested text from below; you can see the diff at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-rfc8109bis-05 this changed text is much more clear to me. Andreas ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: Secdir last call review of draft-ietf-dnsop-zoneversion-06
Hi Shawn, Thank you for the review and comments. We’ve fixed the editorial comments you identified. Regarding “decimal integer” — we use that phrase only when describing the presentation format (versus, say, hexadecimal) so we think it is appropriate. However, we would defer to the advice or suggestion of the RFC editor or other experts on this, if they have an opinion. DW > On Jun 5, 2024, at 11:55 PM, Shawn Emery via Datatracker > wrote: > > Caution: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > Reviewer: Shawn Emery > Review result: Has Nits > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments > were written primarily for the benefit of the security area directors. > Document > editors and WG chairs should treat these comments just like any other last > call > comments. > > This draft specifies an extension in DNS for providing zone version > information > for the associated query name. This data allows callers to better correlate > the queried name to a zone version that it belongs, in order to better > diagnose > synchronicity issues. > > The security considerations section does exist and describes that this EDNS > extension does not protect against an active attacker and therefore should > only > be used for diagnostic purposes only. The section continues, if zone version > information is to protected against an active attacker then the user should > use > TSIG (RFC 8945) or SIG(0) (RFC 2931) to authenticate and provide integrity > protection. In addition, there are no new privacy issues introduced by the > new > extension given that version information is already provided publicly. I > agree > with the aforementioned assertions. > > General Comments: > > What's an unsigned decimal integer vs. unsigned integer? > > Editorials Comments: > > s/and and/and/ > s/correspond do/correspond to the/ > > smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: draft-ietf-dnsop-avoid-fragmentation-17.txt - implementer notes
Hi all, Speaking as one of the DNS implementers and as part of providing feedback on the current draft revision, we have reformulated recommendation R2. It expresses the intention not to fragment UDP packets and points out that different operating systems have different ways of achieving this. The current concern of open-source software DNS developers is with Linux that the IP_MTU_DISCOVER is not well documented, it has changed over time, one has to look into the kernel code to see what is really going on, and it is fragile. New text for R2: - R2. UDP responders should configure their systems to prevent fragmentation of UDP packets when sending replies, provided it can be done safely. The mechanisms to achieve this vary across different operating systems. For BSD-like operating systems, the IP "Don't Fragment flag (DF) bit" [RFC0791] can be used to prevent fragmentation. In contrast, Linux systems do not expose a direct API for this purpose and require the use of Path MTU socket options (IP_MTU_DISCOVER) to manage fragmentation settings. However, it is important to note that enabling IPv4 Path MTU Discovery for UDP in current Linux versions is considered harmful and dangerous. For more details, refer to Appendix C. - On 06/05/2024 15:59, Petr Špaček wrote: Hello dnsop, Warren asked implementers to provide feedback on the current text, so I'm doing just that. I'm not an apt copywriter but hopefully following notes will provide material for other people to formulate commentary to supplement the recommendations. Cheers, -- Benno ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
