[tsvwg] Re: [v6ops] Carrying large DNS packets over UDP in IPv6 networks

[Suresh Krishnan <[e-mail]>]

> On Jun 17, 2024, at 11:49 AM, Warren Kumari <[e-mail]> wrote:
> 
> 
> 
> 
> 
> On Mon, Jun 17, 2024 at 6:28 AM, Suresh Krishnan <[e-mail]> wrote:
> Hi Mike, 
> On Jun 16, 2024, at 7:30 PM, C. M. Heard <[e-mail]> wrote: 
> On Sun, Jun 16, 2024 at 1:03 PM Brian E Carpenter wrote: 
> I don't think a v6ops document should venture into DNS transport recommendations - especially as the question "TCP or QUIC" is, basically, independent of the underlying IP protocol (IPv4 fragments are not safe from eaten by intermediate grue). 
> From Geoff's observations, I'm not sure that's true - that is, the best practice for DNS/IPv4 probably differs from the best practice for DNS/IPv6. 
> That is correct, and one can see the evidence not just in Geoff's excellent presentation at IETF 119 (https://datatracker.ietf.org/meeting/119/materials/slides-119-v6ops-operational-issues-00.pdf for those who missed it) but in https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-avoid-fragmentation#name-on-path-fragmentation-on-ip 
> Also, whether the final document(s) come out of v6ops or dnsop (or even tsvwg) is secondary to whether they say the right things. Perhaps we could ask the various WG chairs to coordinate? 
> Excellent idea; it might help to push draft-ietf-dnsop-avoid-fragmentation out the door. 
> Looking at the datatracker, I think that document might be ready to go out of the soon since the IESG evaluation is done and the positions indicate that the document is ready to move forward.
> 
> 
> Actually, there is still some work to be done on this document — there is much (convoluted) history here.
> A very quick summary:
> It is a BCP document, and was sent to the IESG with a number of unqualified MAYs. The IESG felt that it was not really appropriate for a BCP to be this "wishy-washy" and so some of these were "upgraded" to SHOULD e.g: 
> "R2.  UDP responders MAY set IP "Don't Fragment flag (DF) bit" [RFC0791] on IPv4."
> became
> "R2.  Where supported, UDP responders SHOULD set IP "Don't Fragment flag (DF) bit" [RFC0791] on IPv4."
> 
> and
> "R7.  UDP requestors MAY drop fragmented DNS/UDP responses without IP reassembly to avoid cache poisoning attacks."
> became
> "R6.  UDP requestors SHOULD drop fragmented DNS/UDP responses without IP reassembly to avoid cache poisoning attacks."
> 
> However, the handling of DF bits is, um, inconsistent between operating systems (and even different versions within an operating system), and so implementations are not currently  following these recommendations  - and if they could/did follow these recommendations, we are not at all sure that they would work well. Implementers are, understandably, very reluctant to have a **Best Current** Practices document which contains things that are not Current, and which we are not sure would be Best even if they were. 
> 
> And so I have asked the authors and implementers to work together to address this - the document will end up Informational, and hopefully will be republished after some time as a BCP, once we have some additional experience. There was an email to the DNSOP list recently with new proposed text, and we hope to have a new version of the document published soon.

Thanks for the update Warren! Greatly appreciate the background on this.

Regards
Suresh