Gorry Fairhurst 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: ---------------------------------------------------------------------- Thank for writing this document and the work that went into documenting DNS IPv6 Transport and thank you to Martin Duke for a TSV-ART review. I am not a DNS expert, but do have (mostly transport) topics that I would like to understand. I have some concerns about whether the broader remit of this document compared to that offered by BCP 91 (RFC 3901) is backed by the same of maturity and rigour as for the IPv6-related DNS topics. However, the following DISCUSS comments will mostly focus on the new transport topics. 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. I hope that this review helps to improve the document, DISCUSS (blocking) - after discussion/resolution I plan to change my position: ## Section 3.2: EDNS(0) size I do not really understand the requirement arising from: "Hence, DNS servers MAY also opt to set an EDNS(0) size of 1232 octets as suggested by the [DNSFlagDay2020] initiative." - I’m not a DNS expert, but please coulkd you explain what does this “MAY” permit relative to other options? ## Section 3.2: "However, similar to the case of DNS-over-UDP, DNS-over-TCP may encounter MTU discards, especially on IPv6, if PMTUD does not work, if the MSS honored by the authoritative DNS server leads to IP packets exceeding the PMTU. " (a) I am unable to understand what is special here for IPv6, and I would appreciate if this can be explained. It might be if the MSS allows more than the minimum IPv6 MTU that this results in packet discard? However, I am not sure then what is meant by the “PMTU” is that the server PMTU, or the actual PMTU supported by the path? (Is there data that can be used to show the case?) (b) What is the impact/prevalence of MSS Clamping in this case? ## Section 3.2: Transport Black Hole detection? "In that case, similar to the case of DNS- over-UDP, DNS resolution will time out when the recursive DNS resolver did not receive a response in time." - Several TCP stacks implement black-hole detection, would that influence the DNS result or not? ## Section 3.2: What is the effect of MAY? "...Hence, DNS servers MAY set an MSS of no more than 1388 octets for TCP connections." (a) I suggest TCP admins can already advertise any valid MSS, what does this “MAY” change? (b) I did not find an explanation for the value of 1388, please cite where this is explained? (I also could not find any explanation in RFC 9715, so please explain the use of this reference). ## Section 3.2: Impact of other headers (why “MAY) "DNS servers MAY ensure that a total packet size of 1280 octets is not exceeded by setting an MSS of 1220 octets." (a) I suggest this wording does not present a requirement, perhaps the "MAY" ought to be lower case "may" or "can". (b) Please explain why how this avoids a size of 1280 octets? (To me, the total packet size includes any other extension or encapsulation headers, and these could result in a packet greater than 1280 octets.) What use-case was intended? ## Section 3.2: MAY opt to not rely on PMTU discovery "Additionally, DNS servers MAY opt to not rely on PMTU discovery. " - As above, a TCP server can be setup to not rely on PMTU, etc, but I don’t understand the need for a formal requirement to permit this. Please explain the requirement and what is the impact of other in-built mechanism that a TCP stack would normally use, such as black-hole detection? ## Section 4.1: MTU break The document speaks of an “MTU break”, but I could not find an explanation of what was intended. Please could you explain? ## RFC 9715 "Furthermore, similar to the guidance in [RFC9715], authoritative DNS servers MAY set an MSS of either 1388 (analogous to [RFC9715]) or 1220 (analogous to the [DNSFlagDay2020] suggestions) in TCP sessions carrying DNS responses." - See above the MAY does not seem to imply a requirement to do anything here, please explain what is being allowed/required. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # COMMENTS (non-blocking) Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education). ## Section 3.2: I could not understand the "otherwise" in this: "Otherwise, if the protocol is not resilient to IP layer fragmentation related issues by default, the above guidance for TCP and UDP based connections SHOULD be applied analogously." - There is use of DNS over other transports and I do understand what is being called for by this requirement, please explain (and consider rephrasing?). ## Section 4.1. Guidelines for Authoritative DNS Server Configuration: "Every DNS zone SHOULD be served by at least two IPv4-reachable authoritative DNS servers to maintain name space continuity." - Because this is a "SHOULD", please explain the implications when the advice is not followed. I then read, the following: " To reduce the chance of DNS name space fragmentation, it is RECOMMENDED that at least two IPv4-reachable and two IPv6-reachable name servers are configured for a zone." - I think I may have been confused by the various recommendations and tried to see how to reconciled these two statements. I am a little concerned that the advice in this section might be complicated, and I wonder whether these (initial) statements are not intended to be normative, because the following bullets appear to define more specific requirements. More clarity would be appreciated. ## Section 4.1. fall back " and providing TCP fall back options [RFC7766]." - Please be more specific to which section of RFC7766 is being cited, I could only find one that is normative (and one informative). ## Section 4.3: What is required? “ When providing multiple DNS servers to stub resolvers, network operators SHOULD consider that various implementations can only configure a small set of possible DNS resolvers, e.g., only up to three for libc [MAN], and additional resolvers provided may be ignored by clients." - What is the protocol requirement here? I can see consideration might be important, but I expect it isn't sufficient to think about the problem and sort sort of action might be required/desired? - Gorry _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
