zlacker

Honestly, Cloudflare choosing not to hastily slap a band-aid on a problem like this just makes me feel more compelled to continue using 1.1.1.1.

I hesitate to compare this to Apple calling themselves “courageous” when removing the headphone jack, but in this case, I think the word is appropriate. I’ll happily stand behind you guys if you take some PR hits while forcing the rest of the industry to make DNS safer – since it is understandable, admittedly, for users to conclude that “Cloudflare is blocking websites, sound the alarms!” at first glance.

>>jakeja+(OP)
For the moment, I also do trust CloudFlare's intentions, but it's wrong to classify this as some kind of stoic resolve in not "slapping a band-aid on a problem" since that's exactly what they did after their business decision about not responding to "any" queries.

>>fapjac+op
What do you mean with this? Refuse ANY is now a proposed RFC https://datatracker.ietf.org/doc/rfc8482/ How is that a band aid?

>>jakeja+(OP)
Please note that incentive to "hastily slap a band-aid" did appear, but was overcome by the team. At least, they deserve praise for honesty.

>>lmb+EJ
Just for another voice in this sub-discussion: I'm an authdns software implementer ( https://github.com/gdnsd/gdnsd ) with no connection to Cloudflare, and I like Refuse ANY. It's maybe hard to see all the issues with traditional ANY clearly unless you're implementing this stuff, but IMHO RFC 8482 is a really good path forward that I'm supportive of and have also implemented.

>>lmb+EJ
Well, I can't say I didn't anticipate it happening exactly like this, with someone from Cloudflare trying to retcon "the ANY query episode" by linking to the proposal drafted after the fact. As though a formal "here is our proposed change" document somehow magically excuses the fact that Cloudflare did "violate the integrity of DNS" in its unilateral decision to abandon parts of the DNS specification in favor of its own modifications in order to cut operating costs by reducing the workload on its servers. [0]

Your boss is talking about not "violating the integrity of DNS" and presents this case where upstream archive.is name servers return unexpected data. He proposes that CloudFlare cannot "just fix it" because doing so "would violate the integrity of DNS and the privacy and security promises we made to our users when we launched the service". However, Cloudflare chose to "just fix it" back then by "slapping a bandaid" on something your team saw as a problem instead of abiding by the proper change process. And Cloudflare did so not because of some critical security flaw, but as a cost-cutting measure.

Even if we limit what it means to "violate the integrity of DNS" to the first definition mentioned above (and completely ignore this second definition), Cloudflare "slapped a bandaid" on a PR problem it had a couple of years ago and decided to "just fix it" and "block a domain" by removing the domain and its assets from Cloudflare's infrastructure. [1]

Cloudflare has "violated the integrity of DNS" on more than one occasion using more than one of its own definitions.

Cloudflare "MUST" either adhere to the specification and its change process, or not adhere to the specification and its change process. Cloudflare "CANNOT" choose for both of these statements to be true, and one of them constitutes "violating the integrity of DNS".

[0] https://blog.cloudflare.com/deprecating-dns-any-meta-query-t...

[1] https://blog.cloudflare.com/why-we-terminated-daily-stormer/