It doesn't seem to actually require DNSSEC. Let's Encrypt will happily use these new fields to restrict issuance, the same way they were checking CAA records previously, for domains with and without DNSSEC.
Without DNSSEC this requires an attacker to 'global MITM' letsencrypt's DNS queries. That is a higher bar than before this change.
Before, an attacker only needed to 'global MITM' http requests. Your ISP could trivially do that. But your ISP couldn't just global MitM DNS queries for your domain unless you happen to use them as your registrar.
That is much harder than having an attacker use HTTP verification and global MITM the end user.
In this context, I think "requires DNSSEC" is an opinion at best. "Requires" is probably the wrong word.
You are welcome to use CAA accounturi without DNSSEC and it will be effective.
Your zone may be vulnerable to an active man-in-the-middle DNS attack (which is hard to pull off), but it will still be protected against somebody figuring out how to upload an /.well-known/acme-challenge/ file on your domain and issue an unauthorized certificate from a foreign ACME account. This attack is much easier - I did it against a popular mail provider a few years ago.
In 2014 Rob Mueller wrote: "Our future DNS plans include DNSSEC support (which then means we can also do DANE properly, which allows server-to-server email sending to be more secure), DMARC record support, and ideally one day Anycast support to make DNS lookups faster."
Too many ISPs hijacking requests to user configured DNS servers and too many ISPs providing default servers that 'helpfully' redirect to a placeholder domain with ads rather than just an NX record.
It's about security. It keeps intermediate hops from hijacking your query and providing their own response.
Unfortunately, it offers no privacy. DNS is usually the precursor to a tls connection, and the domain name is sent in cleartext during the tls handshake. So the same people who would hijack your DNS queries are still privy to them if you use DoH (routers, ISPs, governments, etc).
There's a lot of different DoH providers. And don't most people who aren't using DoH send all of their DNS requests to the same actor (usually their ISP) anyway?
Centralized servers run by trusted [0] third parties is the foundation that most of the industry is built on. Surveillance dollars flow in, and mindshare follows.
DNS seems eminently easy to secure against eavesdropping, given it is just distributed database, and a slowly consistent one at that. Someone just needs to step up to the plate and make a p2p resolver that communicates with a secure protocol, rather than the naive one spelled out in rfc1035. And with DNSSEC you wouldn't even have to worry about trusting/verifying other peers.
[0] The formal definition of someone who can break you, not the common usage that implies "trustworthy".
Every time people bring this project up, I have to say this again, so here goes:
The purpose of a naming system is to give users a common way to consistently reference specific things. Anyone should be able to mention a name for a thing, and know that any other user will be able to look up that name and resolve it to the same thing.
GNS missed this lesson. Under GNS, every user has their own, slightly different view of naming; a name which one user is able to resolve may not be resolvable for another user, or (even worse) other users might see it resolve to something completely different.
There are many ways of defining how a "decentralized" naming system should work. This is one of them, and I'm sure it sounds cool, but it is not a good idea. Try again.
Remember, if you can censor traffic at the network level, so can Comcast and China. Hopefully, there will eventually be a day when Microsoft, Google, Amazon, and CloudFlare all serve DoH from the same IPs they serve the rest of the websites they host from, so that it won't be feasible to block them anymore.
But they can run DoH on any server, they don't have to use CloudFlare or Google or whatever. So any port 80 connection is suspect. Same for any port 443 connection with DoT. Or any port whatsoever if they run their DNS (on any transport) on a "non-standard" port, which is not unheard of for such devices. DNS works on port 5353 just as well as it does on port 53. Redirecting outbound port 53 to your own servers has never been an effective way to stop devices from using their own DNS. DoH and DoT do make it harder to block (since they're authenticated), but even classic DNS can evade simple port-based redirection.
Why should anybody? DNSSEC is almost irrelevant for the majority of domains. I've worked at a place that was pioneering it and found it over complicated and fragile, so haven't touched it since.
If you implement it correctly you are slightly more secure but there are better ways to spend your time.
No, it wasn't. I've been working in security since 1995. People have at times said that HTTPS was unnecessary for things like static content sites and blogs, sure. There has been pushback against the idea of doing HTTPS everywhere. But no serious person has ever pushed back against the need for HTTPS in some places. HTTPS and DNSSEC are not comparable. We've spent 25 years trying to have DNSSEC and not having it, and for a lot of us, the verdict is in: DNSSEC isn't necessary for a secure Internet.
This is a big problem. I feel like the security world is trusting DNSSEC to close the unencrypted / unsigned DNS record shaped security hole. If its not something people actually want to implement because its a mess, what do we do? Do we need something better than DNSSEC? Is DoH good enough?
On the contrary; the work is only for DNS server operators (registrars). As a domain admin, you simply get DNSSEC for free if your registrar supports it.
If you are instead running your own DNS server, you're probably big enough that you can afford spending some time on configuring DNSSEC.
> As a domain admin, you simply get DNSSEC for free if your registrar supports it.
How is a registrar holding your keys in any aspect better than WebPKI right now?
> If you are instead running your own DNS server, you're probably big enough that you can afford spending some time on configuring DNSSEC.
And as the parent comment said, it's complicated and brittle, while offering little benefit. Plus you are still forced to trust your registrar, because it's doubtful you will go into the effort of interfacing with the TLD registry directly.
> How is a registrar holding your keys in any aspect better than WebPKI right now?
In this context, the question is more "how is a registrar holding your keys in any aspect worse?" There are a couple of mostly availability-related risk models where having DNSSEC at all is probably nets negative but your registrar generally has de facto control over your domain under the no-DNSSEC PKI anyway. There is a wide range of viable use-cases where telling your registrar that yeah turn on DNSSEC is nearly free and gets you ... well, the extremely minor benefit of being able to use DNS as a verifiable public kvmap.
> In this context, the question is more "how is a registrar holding your keys in any aspect worse?"
I find it fairly obvious that such an extra operator in the middle of the trust chain between your webserver and your end-user is worse.
> but your registrar generally has de facto control over your domain under the no-DNSSEC PKI anyway.
Yes-ish. The issue is that DANE+DNSSEC would give the registrars control over the keys, which door they belong to and nobody could determine otherwise. A registrar trying to do the same right now with WebPKI would most likely be pathetically caught in the act, either by trying to redirect traffic without a valid certificate or trying to issue a certificate and it getting logged.
The pattern has recurred for over a decade: someone says DNSSEC is, at last, easy to deploy, and then some huge company tries to turn it on and falls off the entire Internet for a day. Last time, I think, it was Slack. I wonder who it'll be this time.
Almost not a week goes by on HN where there's a headline about some well-known company or government organization that did something (or didn't do something) to either get themselves knocked off the internet or were compromised.
While companies screwing up DNSSEC has gotten some companies knocked of the net, it pales in comparison to other reasons for companies getting knocked off the net.
But whatever.
A more nuanced take on the ease of deploying DNSSEC: it's easy to do for the weekend hobbyist working on a side project or a homelab. Or a small organization whose registrar and internet host both support DNSSEC.
Deploying DNSSEC is definitely not easy if you're running at Facebook, Twitter, Apple, etc. scale. There are other reasons too, but there's no need to rehash once again.
> How is a registrar holding your keys in any aspect better than WebPKI right now?
You can use both DNSSEC and HTTPS. And actually, if your registrar and hosting provider are the same (e.g. Cloudflare, AWS), they might hold your keys anyway.
> And actually, if your registrar and hosting provider are the same (e.g. Cloudflare, AWS), they might hold your keys anyway.
Sure, but you have the ability to choose if they're the same or not. Although an untrustworthy registrar right now would be quite bad, it wouldn't trivially compromise the security of your WebPKI TLS connections. One would not be able to say the same if we would have had deployed and built everything on top of DNSSEC+DANE.
