draft-ietf-dnsop-avoid-fragmentation

[wkumari]

Link:

https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/

Authors:

• Kazunori Fujiwara
• Paul A. Vixie

Related drafts

[wkumari]

Benno to check with implementors on the document track / status.

[bjovereinder]

Feedback received. Preparing a reply.

[moonshiner]

The TL;DR is to make this Informational, with a paragraph towards the beginning saying something along the lines of:
"This document was originally targeted as a BCP, but due to operating and socket option limitations some of the recommendations have not yet gained real world experience, and so the document is being published as Informational. It is hoped and expected that, as operating systems and implementations evolve, we will gain more experience with the recommendations, and plan to publish an updated document as a Best Current Practice."
After we have some more experience with deploying the recommendations we can use this to oublish a BCP version of the doc.

Longer:
It was generally agreed that while most of the recommendations sound reasonable on paper, many of them are not currently implemented in the real world for a variety of reasons.
As an example, I had always assumed that it would be trivial to set the DF bit on all OSs by simply setting the IP_DONTFRAG sockopt - but this turns out not to be true — with many OS you can set socket options asking for specific handling, but the combination of options and what you actually get differs vastly depending on OS and version of OS, etc[0]. This means that implementations have been trying hard to not generate fragments, but by using mechanisms more complex than just setting DF.
Seems as most implementations have considered / tried setting DF and don't ship with it on, it doesn't seem like it is can be a BCP yet.

Another example is "UDP requestors SHOULD drop fragmented DNS/UDP responses without IP reassembly to avoid cache poisoning attacks." - I don't think that OSs generally allow an application to signal that the OS should not perform IP reassembly, and so it seems incorrect to have a SHOULD level Best Current Practice that nameserver software cannot realistically implement (unless "UDP requestor" here is intended to cover both the nameserver software, and also the nameserver administrator putting a "firewall" or similar in front of the software? There has previously been a fairly strong pushback against having stateful devices in front of nameservers, so…)

Much of how we ended up here is that we had many MAYs without clear guidance as to how to evaluate between the options. This lack of specificity in a BCP made the IESG twitch, and so many got changed to SHOULD — but now these don't really align with the real wold / real world implementations, and that seems even worse.
To help address this, the implementers will contribute more text documenting why they took one path for a MAY (or SHOULD) versus the other.

I think that the process plan for this is that, once we have a new version which we are happy with, I will do a short concenus call on DNSOP (there have been a number of significant changes, including track), and then another IETF concensus call.

[moonshiner]

Petr's comments

https://mailarchive.ietf.org/arch/msg/dnsop/elxvZIi8qNgF0eBcu-5AANNlKAo/

[moonshiner]

Sent an email to the authors about some suggested changes with respect to changing from BCP to informational