At this point, you might as well just have the CABForum come up with a new blessed verification method based on RDAP. That might actually happen, unlike DNSSEC, which will not. DNSSEC has lost signed zones in North America over some recent intervals.

I do like that the threat model you propose is coherent only for sites behind Cloudflare, though.

If people were serious about this, they'd start by demanding that every DNS provider accept U2F and/or Passkeys, rather than the halfhearted TOTP many of them do right now. But it's not serious; it's just motivated reasoning in defense of DNSSEC, which some people have a weird stake in keeping alive.

For starters you could try `dig +short ds google.com`. It'll give you a flavor of what to expect.

DCV is CA/B speak for domain-control validation; CAA = these are my approved CAs.

This seems to be optional in the sense that: if a DNS zone has DNSSEC, then validation must succeed. But if DNSSEC is not configured it is not required.

Sadly, we live in this reality for now, so we do what we can with what we have. We have DNSSEC.

I saying say I agree with the statement "I am saying it is dishonest to discount the real security threat of not having DNSSEC."

I believe we do need some way to secure/harden DNS against attacks, we can't pretend that DNS as it stands is OK. DNSSEC is trying to solve a real problem - I do think we need to go back to the drawing board on how we solve it though.

(Actually getting it to work reliably without downgrade attacks would be more work, but notably, that's work DNSSEC would have had to do too --- precisely the work that caused DANE-stapling to founder in tls-wg.)

So far your response to this has been "attackers can't do this to Cloudflare". I mean, stipulated? Good note? Now, can you draw the rest of the owl?

The sequence there is:

1. I hijack traffic destined for an IP address

2. Anything whose DNS resolves to that IP, regardless of whether or not they use DNSSEC, starts coming to me

In this model, I don't bother trying to hijack the IP of a DNS server: that's a pain because with multi-perspective validation, I plausibly have to hijack a bunch of different IPs in a bunch of different spots. So instead I just hijack the IP of the service I want to get a malicious cert for, and serve up responses to let me pass the ALPN ACME challenge.

If we accept this thesis, it means that the only reason we are able to have a secure internet is because we also have a monopoly on browser technology; and like, we don't want there to be a monopoly on browser technology, right? That means the current situation is unstable at best until we finally manage to regulate that monopoly out of existence... or, and maybe you feel this is the worst case scenario, attempt to turn it into a public good.

> Governments run the roots of the DNS hierarchy.

That this is true has some devastating consequences that I feel as if I've never seen you discuss, as TLS has not, does not, (seemingly) will not, and potentially even cannot fix the problem that a government is in a position to subvert the DNS hierarchy: it is just a fundamental property of deciding to build the web on top of a federated namespace managed by governments. We need to fix this at the web-protocol level by ditching the current TLD authority for something that isn't governmental (and is more distributed, not federated).

I mean, let's look at surveillance that doesn't even require a certificate: 1) governments are in a position to redirect traffic to websites within their namespace by forging the DNS records anywhere under their TLD; 2) IP doesn't provide any protection against someone forwarding the encrypted packets; and 3) TLS only encrypts the content, but doesn't have any mechanism to encrypt the metadata of the communication channel (timing and length)...

...this is already devastating, as not only does it let you target small regions of people and determine if they are accessing a website, it also (and this is the thing that I find not enough people really internalize correctly) let's you know exactly what those users are accessing with high certainty, as you can see the approximate size of the responses to their requests. This technique has been successfully implemented in the past to figure out not merely which page of a site you are visiting, but what region of Google Maps you are looking at (based on patterns of map tile sizes), what video on YouTube you are looking at (based on patterns of video chunk sizes), and (maybe the most incredible) what your search query is (based on patterns of type-ahead suggestion lists: every keystroke causes a new request with a new JSON response of a different size; I think they did it for PornHub).

> Finally, as I keep saying: we're never going to get "DNS transparency".

I think you're throwing up your hands in defeat at something that we actually can fix in the browser stacks: simply add a new TLD that stores all of its second-level records on a blockchain. We already have some of these... they aren't designed well, as they don't have people who actually know much about the needs of internet protocols involved (the level of "defeat snatched from the jaws of victory" in this space is simply insane), but if people like us constantly point in the correct direction, we can pull this off.

Or like, hell: maybe you find distributed blockchain tech distatesful... what if the EFF partnered with Google to manage a new TLD? Hell: Google already manages a TLD in a similar conceptual space (the one where Chrome requires HTTPS on all connections)! And then, what if they decided that DNS transparency was important enough to implement a scheme similar to the CA transparency lists for it? It would take some effort to come up with the correct design for this, but it isn't as if CA transparency was easy to pull off or is in any way perfect even today: it is a shaky system that only sometimes helps, but you care anyway!

That isn't going to happen if you just write off DNS transparency as so impossible that it isn't even worth discussing. If you, instead, consistently said DNS transparency is really important, even though it is hard, maybe people at Google, EFF, Apple, Mozilla, or who all else might be relevant for this might suddenly get inspired to work on it... and, sure: to do it as a new TLD doesn't fix the problem immediately, but new websites are launched all the time, new TLDs already are successfully booted (even by Google), developers seemingly like to jump on fad TLDs, and if you start somewhere, maybe the pressure will slowly cause some of the existing TLDs to do something similar.

Sure, DNSSEC might be a non-starter... but like, replacing DNSSEC is equivalent to fixing it, if you are willing to take a long-enough term approach to your advocacy efforts.