Hello Gorry, thank you for your review. Please find responses in-line.
> --------------------------------------------------------------------- > - > 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? RFC9715 recommends an EDNS(0) size of 1400 to avoid fragmentation. However, and EDNS(0) size of 1232 ensures that DNS packets have a maximum size of 1280, i.e., the minimum MTU in IPv6. The MAY here allows operators to follow either, i.e., 9715, or the more strict 1232, which is also the default in many implementations. > ## 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?) The highlighting of IPv6 here is due to vocal concerns that packets requiring fragmentation and PMTUD for IPv6 are notably worse than for IPv4. I would be happy to remove the ", especially on IPv6,". "the PMTU" here refers to the actual PMTU supported by the path. > (b) What is the impact/prevalence of MSS Clamping in this case? MSS clamping is the suggested mitigation in the document, i.e., if we clamp the MSS to a value ensuring that packets do not exceed 1280, no MTU blackholes should occur. > ## 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? Please see Mark's reply on this point. In DNS, standard blackhole detection exceeds the timeframe for a query to time out. > ## 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). This MAY enables taking the same precautions as for UDP via capping the EDNS(0) size for TCP as well. RFC9715 suggests setting an EDNS0 size of 1400 (leading to packets of 1448 octets). Setting an MSS of 1388 should similarly lead to TCP packets of 1448 octets. > ## 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? This again follows the same rational as with RFC9715 for UDP, but translated to TCP. > ## 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? The benefit here is that this approach ensures that packets will not exceed PMTU. However, operators might see issues with settings this for DNS servers (as it may increase load). It, nevertheless is an option. Hence, the idea was to explicitly allow it with MAY, but not mandate it via SHOULD/MUST. > ## 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? We understand a link in a path whose MTU is smaller than the PMTU of the preceeding section of the path to be the point of an MTU break. We will add this to the terminology section. > ## 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. The may here is in place to allow setting either, while also not mandating this to be set. > --------------------------------------------------------------------- > - > 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?). This text has been added due to WG discussions highlighting the existence of other transports. I would personally like to improve the text here, but have been struggling to find a better formulation. If you can think of a better formulation, input would be greatly appreciated. What I'd want to say here is: "There may be new things we have not thought about yet. If these see issues with MTU blackholes, things should be done to limit the maximum packet size, similar to what we tried to do for TCP/UDP." > ## 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. We are already reworking this text in response to another comment. > > ## 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). We will clarify this text, and also remove the word 'fall back' (see changes to 5966 in Paragraph 3 of Section 5 for 7766). > ## 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? There might be additional things to do, e.g., trying to mandate a higher number of resolvers being supported in libs. However, while this point was vocally asked for to be in the document as a warning sign, there was also great clarity in the WG that making any requirements for libc implementers would significantly expand the documents scope. Hence, the current text. With best regards, Tobias -- My working day may not be your working day. Please do not feel obliged to reply to my email outside of your normal working hours. ----------------------------------------------------------------- Tobias Fiebig, Forschungsgruppe Internet Architecture (INET) Max-Planck-Institut für Informatik, Campus E14, 66123 Saarbrücken E1 4 - Raum 517 mobil: +31 616 80 98 99 _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
