Tobias, Working in the same time zone is so efficient 😉
Unsure whether you can submit a revised ID and whether I can review it before the telechat 😉 but I am sure that in the coming days all be cleared. Thanks for the work done! -éric From: Tobias Fiebig <[email protected]> Date: Thursday, 22 January 2026 at 14:46 To: Eric Vyncke (evyncke) <[email protected]>, The IESG <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: Éric Vyncke's Discuss on draft-ietf-dnsop-3901bis-11: (with DISCUSS and COMMENT) Hello Eric, Thanks for the quick reply. Again, inline, with some filler text removed. > > ### Section 3.2 > > > > `DNS servers SHOULD follow [RFC9715]` this makes RFC 9715 a > > normative > > reference (and create a downref). > > This combination is used in multiple places. I think this can either > be > resolved by removing the BCP14 language dependence on 9715, or by > accepting the downref. > > For the first option, I would reformulate the text as follows: > > "DNS servers SHOULD avoid packet fragmentation. Examples on how to do > this for UDP transports can be found in [RFC9715]." > > What are your thoughts on this? > > EV> The above text is addressing one instance, unsure whether it > could be done in all instances though. Checking in with Med, we converged to rather have 9715 become normative; He will file a downref. > > ### 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 > > ? > > The cause here is the nature of RFC9715 as informational. See also my > suggestions on re-wording above to remove the 9715 dependence, and > making it a clear option example. > > EV> the use of SHOULD must come with consequences or when to bypass > it though. > > 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. > Yes, this needs to be clarified; What should happen is that the > authoritative NS should cap received EDNS0 sizes, i.e., always act as > if a maximum of 1400/1232 was received. > > EV> clarifications would be welcome (like MSS 'clamping') The text now clarifies this (making explicit that the authoritative NS uses 1400/1232 as the maximum EDNS(0) size received, even if a query has a higher EDNS(0) size set. > > `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 ? > > This is a MAY, because there were various strong opinions on the > ideal MSS (see also 9715 with 1400 vs. 1280). > > EV> what about using "IS RECOMMENDED" ? I can live with that. Changing. > > > ### Section 4.2 > > > > This SHOULD has the companion statements: `Every recursive DNS > > resolver SHOULD be dual-stack` :-) > > I cannot parse this comment. Could you maybe clarify what you mean > with > this? > > EV> every SHOULD must have some text about either what are the > consequences if not followed or when it can be bypassed (especially > in a BCP). Ah, makes sense. Adding that: -Every recursive DNS resolver <bcp14>SHOULD</bcp14> be dual-stack. +To ensure robust DNS resolution even when facing namespace fragmentation, every recursive DNS resolver <bcp14>SHOULD</bcp14> be dual-stack. +Exceptions apply if one of the below methods to prevent namespace fragmentation are in place. 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]
