On Tue, 2 Jul 2019, Petr Špaček wrote:
Let me clarify that we (as DNS flag day organizers) are not even touching any RFC language because all the necessary pieces are already standardized (madatory TCP support + mechanism to handle EDNS buffer size).
If there is a security issue with fragmented DNS packets, perhaps that warrants a new RFC document, possibly a BCP, that instructs implementers what to do.
Some people claim that IETF cannot put requirements on operators, only on implementations. We (as software and service vendors) are now saying "if you want to interoperate, you as an operator have to follow standards mandated for implementations", because in the end, what's mandated for implementation does not matter if operators ignore these requirements.
That is not different from the examples I gave earlier for those RFCs. You can encourage/discourage or obsolete features. The good thing of doing that in an RFC is that organizations and goverments and vendors can point to it for compliance or policy and explain why it is done a certain way.
Of course it has to be explained to non-IETFers in many more words to eliminate requirement to read all the RFCs, but that's it.
If you think that, you haven't properly informed implementers via existing RFCs. A new one is apparently needed. I don't see why this should not be done here. This is dnsops. If you find an operational issue, you write a clarifying or correcting RFC.
Changing default EDNS buffer size is, I believe, in competency of individual implementations, so we as implementors will do a thing we deem sensible.
No one is saying you are not sensible. My point was that none of this is a flag day, and the promotion to reach a few implementations via "flag days" is better directed at writing a new or updated RFC that explains the issue and recommends implementors what (not) to do. That also helps downstream with customers wanting RFC ABC compliance, which is a much stronger signal than compliance to "dnsflagday.net/2020".
Let's continue discussion about dns flag day 2020 at mailing list dns-operati...@lists.dns-oarc.net, please.
I'd rather not. Operational issues related to the DNS protocol (mis)implementations or standard behaviour are well within the charter of this group. DNS-OARC is a good venue to look at what is happening, discuss why certain operational things are happening, maybe brainstorm on how to fix it. Then coming to this group with a proposal for a document to inform everyone and improve everything is the right venue. It seems the problem and solution are already well defined. It just needs to be written down in an RFC, and then gradually software can implement the new behaviour. And again, if for reasons vendors decide to implement it all on the same day to ensure strict vendors are not unreasonably punished by being blamed for failures, that's a reasonable goal. But seeing how upstream vendors have no control over when downstream vendors pick up new versions, the term "flag day" is just not the correct term to use, and only brings up negative connotations in people being misled into thinking IETF protocols needs flag days to continue running. Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
