Éric Vyncke has entered the following ballot position for draft-ietf-dnsop-3901bis-11: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-3901bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Éric Vyncke INT AD comments for draft-ietf-dnsop-3901bis-11 CC @evyncke Thank you for the work put into this document. Let's polish this draft to make it very useful as it should be. Please note as well that I am still on sick leave, i.e., I may not have read all the multiple recent threads about this I-D. Please find below some blocking DISCUSS points (some trivial to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education). Special thanks to Ondřej Surý for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status. I also note that there have been several cross-posting with the V6OPS mailing list by the responsible AD and the authors. These were a good and sensible actions. I hope that this review helps to improve the document, Regards, -éric Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues. ## DISCUSS (blocking) As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise. ### Title As the document is about mixed IPv4/IPv6 environments, then the title is incorrect as it only mention IPv6. Suggest using "Operational Guidelines for DNS UDP/TCP Transport in Mixed IPv4/IPv6 Environment" or something similar. ### Section 2 RFC 5375 must be a normative reference even if it is itself an informational RFC. I am also puzzled by the focus on GUA and ignoring ULA while there are nearly no words about RFC 1918 addresses. While there are some words in section 3.2 about RFC 1918, there are none about ULA. ### Section 3.2 `DNS servers SHOULD follow [RFC9715]` this makes RFC 9715 a normative reference (and create a downref). ### Section 4.1 `To avoid reachability issues, authoritative DNS servers SHOULD NOT use IPv4-embedded addresses` is really looking for trouble, please use "MUST NOT". (this is basically the "Widespread deployment would be damaging to the Internet" point in the IESG DISCUSS criteria list). Same issue about `Both IPv4 and IPv6 transports SHOULD serve identical DNS data` else this is a recipe for big troubles. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## COMMENTS (non-blocking) ### Load balancing & DNS Should there be some text about CDN selecting the 'closest' server by serving different RR based on the resolver IP ? Does it have any impact on this document? ### Abstract and section 2 Unsure what is a `native IPv6 address`, suggest using 'plain IPv6 address' at least in the abstract or simply "global unicast address". ### Section 3.1 `The following name-related misconfigurations` is this an exhaustive list ? Strongly suggest to add a text similar to RFC 9471 `At the time of this writing, addresses (A or AAAA records) for a delegation's authoritative name servers are the only type of glue defined for the DNS.` when discussing glue records as I hope that DELEG will produce another, related, delegation system. ### Section 3.2 `DNS servers SHOULD follow [RFC9715]`, per https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/, especially in a BCP, when can the SHOULD be bypassed ? Why not a MUST ? There is also a contradiction between `DNS servers SHOULD follow [RFC9715]` and `This can be accomplished by setting a corresponding EDNS(0) size` as the EDNS(0) is set by the resolver AFAIK. `Hence, DNS servers MAY set an MSS of no more than 1388 octets for TCP connections.` why not something stronger than a MAY ? Should there be guidance as well for the resolvers ? s/Guidance in this *document* focuses on IP address family support/Guidance in this *section* focuses on IP address family support/ ? ### Section 4.1 As noted before, please explain when the SHOULD can be bypassed or what are the consequences of bypassing it. While the main part of the section recommends 2 name server per address family, the final list only mentions 1. Is it on purpose ? Again a 'dangling' SHOULD. ### Section 4.2 This SHOULD has the companion statements: `Every recursive DNS resolver SHOULD be dual-stack` :-) ### Section 5 Unsure whether the text about PREF64 is relevant in this section or even in this document. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
