Hello Tim, thanks for your review.
> It appears that the -11 version does address the issues raised in the > previous DNSDIR review. > > I do feel like the document is disjointed in the target audience. > For example, section 3.1 discusses all the various misconfigurations, > if the target audience is DNS Operators, I would hope a BCP would > have examples both good and bad perhaps in an appendix. Or maybe the > target audience is more advanced? This text was very explicitly requested to be in the document during WG discussions. > Section 4: > > 4.2 Guidelines for Recursive DNS Resolvers > > Every recursive DNS resolver SHOULD be dual-stack. > > Why not MUST? This is a BCP, It should be a MUST or should explain > why it is not? There were very vocal voices claiming that a must would be too strong. With additional feedback from the IESG, we will now move this to "MUST", though. > Having zones served only by name servers reachable via one IP > address > family would fragment the DNS. Hence, the need for a way to avoid > this fragmentation. > > Not just fragment the DNS, but cause resolution failures. I feel > referring to it as fragmentation and not resolution failures isn't > ideal. But I can't come up with better wording. Yes, we agree. We imported the terminology from 3901, iirc. > "Avoiding IP Fragmentation" > > Questions about discussion of Fragmentation. This is brought up in > sections 3.2 > and 4.1 and seem to be mostly aligned but reading them: > > 3.2 - Avoiding IP Fragmentation: > > Therefore, IP fragmentation SHOULD be avoided by following > guidance on maximum DNS payload sizes [RFC9715] and providing > TCP > fall back options [RFC7766]. 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. > > either 1388 or 1220.... > > 4.1 - DNS-over-UDP packets requiring fragmentation > > In general, DNS servers SHOULD follow [RFC9715], which provides > additional guidance on preventing fragmentation by ensuring > that > the maximum DNS/UDP payload size does not exceed 1400 octets. > This can be accomplished by setting a corresponding EDNS(0) > size, > with most implementations using a lower EDNS(0) size of 1232 > octets as per the suggestions made by the [DNSFlagDay2020] > initiative, to ensure that generated packets always fit into > lower > bound of the IPv6 MTU of 1280 octets, as defined in [RFC8200]. > Hence, DNS servers MAY also opt to set an EDNS(0) size of 1232 > octets as suggested by the [DNSFlagDay2020] initiative. > > ...does not exceed 1400...using a lower size of 1232 per ... or 1280 > or 1232 > > If I was an operator looking at this, I would be wondering why the > differences? > There are reasons, but they should be either be more descriptive or > combine the guidance in one place, and refer to it. This is just me. > > I will not hold up the document based on this, but it feeds back to > my thoughts on the target audience. The challenge here is that implementations and operators went for 1232 / 1280, while RFC9715 suggests 1400 / 1448. The above is an attempt at reconciling both sides. > 5 Security considerations > > * Two resolvers handle queries for a set of clients, each of > these > resolvers support one and only one address family that is > distinct > from the address family supported by the other resolver; > > Should this not be "Two recursive resolvers" ? It would make sense > if you are making security considerations for authoritative servers, > you should do so separately. Yes, we will add recursive to the text above. 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]
