Abley-san, thanks very much for your comments. > From: Joe Abley <jab...@hopcount.ca> > Fujiwara-san, > > On Sep 22, 2022, at 11:05, Kazunori Fujiwara <fujiw...@jprs.co.jp> wrote: > >> Thanks. "Path MTU Disovery" API and setting IP_DF API are complex and >> they often don't work as expected. >> >> However, it may be easy to avoid using the Fragment Header on IPv6. >> (limit IPv6 response packet smaller than interaface MTU.) >> (Or, is it not easy ?) > > I think it's easier if we just recommend a maximum message size for UDP > transport that is likely to avoid truncation in the majority of cases. > Perhaps that is the simplest formulation of your ultimate goal? Just update > the base specification and say it clearly. > > This will make UDP transport only usable for a subset of DNS messages that > are ever sent on the Internet. Other transports can remain as-is and do not > need this limitation. People who ignore the recommendation are on their own.
The minimum MTU on IPv6 is 1280. Then, for example, we can specify a maximum message size for UDP transport on IPv6 as 1232. However, the minimum MTU on IPv4 is 68 (Section 3.2 of RFC 791). We need to arbitarily specify the maximum message size for UDP/IPv4. For example, 512, 1232, or 1400. > UDP then becomes a convenient choice for DNS messages that are small and that > do not have requirements for confidentiality, bit not a default choice in the > protocol sense (despite the fact that it will probably remain the choice for > most messages). > The default transport becomes TCP, since that is the alternative, > must-implement transport available in all parts of the system. We can say that the standard transports for DNS are TCP/DoT/DoQ and the standard address family is IPv6, however, UDP transport for DNS and IPv4 will be used in reality, forever. I believe that the BCP document improves many current use cases. >> Then, to allow larger than 1232/1400 and smaller than interface MTU >> response packets, recommendations for UDP requestors are changed as: >> >> UDP responders can send reponses fit in both >> the result of path MTU discovery (if available), >> interface MTU and UDP requestor's payload size. > > I think a formulation to avoid magic numbers is probably better but to be > honest I don't find magic numbers to be so terrible if they make the advice > more clear. > > (I think the current draft's advice is not particularly clear since it > contains a lot of > if then else, but perhaps others think differently.) >From EDNS spec [RFC6891], response size <= UDP requestor's payload size. as new recommendations, Set IP_DF bit on IPv4, Compose response packet fit in interface MTU -> No Fragment header on IPv6. then we don't need the result of path MTU discovery. > The DNS is used in private networks as well as on the Internet. I think it's > ok to say simply that UDP transport is NOT RECOMMENDED for large messages > since fragmentation SHOULD be assumed to be unavailable. I agree. On that case, TC=1 responses will return. > That leaves wriggle room for implementations who have more knowledge of their > network path or who don't care about delivery failures (for example) to do > their own thing. I don't think we should spend too much time imagining what > those things should be. > >>>> 4. TCP implementations SHOULD set DF bit / not use FRAGMENT header. >>>> (many TCP implementations already set DF bit) >>> >>> I doubt we have control over this from the application. Is there even >>> API to control that on TCP sockets?m > > I don't think we should write as if UDP and TCP are the only transports > available. I also think it's a mistake to dive down into rabbit holes > relating to any particular transport other than UDP. I agree. But until draft-ietf-dprive-unilateral-probing will be published as a RFC, UDP and TCP are only transport to authoritative servers. > UDP is the only transport we have in which the DNS protocol needs to care > about message size. I think the current draft does a good job in restricting > its discussion to UDP. > >> At least, I would like to disable IPv6 fragmentation. >> and I would like to make "avoid IPv4 fragmetion" our goal. > > I think we should just be bold and declare a RECOMMENDED maximum message size > when using UDP transport and make TCP the default choice of transport. Minimal MTU size for IPv4 is 68. Then, 512 octet DNS response may be fragmented (without DF bit). > UDP becomes an acceptable alternative to TCP alongside other transports that > might be available, if suitable for a particular message, according to local > policy. > > The maximum that is specified could be a magic number (like the original > specification's 512 bytes) or it could be a formulation based on particular > address families' minimum capabilities. Clearly some people prefer the > latter. > > The question of how to construct a minimum sized response in cases where a > DNS responder really wants to avoid a trip through another transport might > ideally live in a separate document. > > I appreciate that it's a bit late in the process to be suggesting such a > change in approach to what is quite a mature document. Sorry about that. > > > Joe We need a document that as many people as possible can agree, or not disagree with. -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
