On Wed, 3 Jul 2019, Mark Andrews wrote:
Defeating fragmentation attacks requires more than a BCP.
https://tools.ietf.org/html/draft-andrews-dnsop-defeat-frag-attack-00
Sure, so you have an RFC already then. great. No need for a flag day
event reference, as you will have a proper RFC reference.
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”.
Winding back the default EDNS buffer size will break interoperability
with servers that now send TC=1 responses that otherwise didn’t happen
and do not accept TCP.
The key point of a flag day is that it is the day after which
interoperability fails, not the rate at which it is deploy which
you appear to be concentrating on.
But again,
We turn off old things on the internet all the time. It breaks
ancient stuff all the time too. We try to steer that process from the
IETF by gradually obsoleting/replacing code. But we don't do that in a
vaccum. We observe deployment statistics and try to push a little harder
to move the market when it is being slow.
And it is not a "flag day" because it depends on downstream release schedules
The DNS 2019 not only had ON THE DAY changes (thanks to Google changing
their 8.8.8.8 service on the day)
So even pumping up the hype didn't actually help inform the people that
needed it the most. To me that is more an argument that flagdaying does
not do much good to begin with, and it is not woth the bad things it does
to the reputation of DNS by making the DNS appear worse than it is.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
