Chris's Wiki :: blog/tech/DANEIsNotGoodDNSUse

I feel that DANE is not a good use of DNS

April 20, 2025

DANE is commonly cited as as "wouldn't it be nice" alternative to the current web TLS ('PKI') system. It's my view that DANE is an example of why global DNS isn't a database and shouldn't be used as one. The usual way to describe DANE is that 'it lets you publish your TLS certificates in DNS'. This is not actually what it does, because DNS does not 'publish' anything in the sense of a database or a global directory. DANE lets some unknown set of entities advertise some unknown set of TLS certificates for your site to an unknown set of people. Or at least you don't know the scope of the entities, the TLS certificates, and the people, apart from you, your TLS certificate, and the people who (maybe) come directly to you without being intercepted.

(This is in a theoretical world where DNSSEC is widely deployed and reaches all the way to programs that are doing DNS resolution. That is not this world, where DNSSEC has failed.)

DNS specifically allows servers (run by people) to make up answers to things they get asked. Obviously this would be bad when the answers are about your TLS certificates, so DANE and other things like it try to paper over the problem by adding a cascading hierarchy of signing. The problem is that this doesn't eliminate the issue, it merely narrows who can insert themselves into the chain of trust, from 'the entire world' to 'anyone already in the DNSSEC path or who can break into it', including the TLD operator for your domain's TLD.

There are a relatively small number of Certificate Authorities in the world and even large ones have had problems, never mind the one that got completely compromised. Our most effective tool against TLS mis-issuance is exactly a replicated, distributed global record of issued certificates. DNS and DANE bypass this, unless you require all DANE-obtained TLS certificates to be in Certificate Transparency logs just like CA-issued TLS certificates (and even then, Certificate Transparency is an after the fact thing; the damage has probably been done once you detect it).

In addition, there's no obvious way to revoke or limit DNSSEC the way there is for a mis-behaving Certificate Authority. If a TLD had its DNSSEC environment completely compromised, does anyone think it would be removed from global DNS, the way DigiNotar was removed from global trust? That's not very likely; the damage would be too severe for most TLDs. One of the reasons that Certificate Authorities can be distrusted is that what they do is limited and you can replace one with another. This isn't true for DNS and TLDs.

DNS is extremely bad fit for a system where you absolutely want everyone to see the same 'answer' and to have high assurance that you know what that answer is (and that you are the only person who can put it there). It's especially bad if you want to globally limit who is trusted and allow that trust to be removed or limited without severe damage. In general, if security would be significantly compromised should people received a different answer than the one you set up, DNS is not what you want to use.

(I know, this is how DNS and email mostly work today, but that is historical evolution and backward compatibility. We would not design email to work like that if we were doing it from scratch today.)

(This entry was sparked by ghop's comment mentioning DANE on my first entry.)

Comments on this page:

By ghop at 2025-04-22 12:39:02:

unless you require all DANE-obtained TLS certificates to be in Certificate Transparency logs just like CA-issued TLS certificates

In theory, one could require all DNSSEC signatures to be logged that way. Revocation remains a concern. At least there's some inherent limitation of scope, whereas most public Certificate Authorities can issue for any domain.

If a TLD had its DNSSEC environment completely compromised, does anyone think it would be removed from global DNS, the way DigiNotar was removed from global trust? … One of the reasons that Certificate Authorities can be distrusted is that what they do is limited and you can replace one with another. This isn't true for DNS and TLDs.

I think we have "too large to fail" situations either way. For example, it'll be less disruptive to remove the .io domain entirely than to distrust Let's Encrypt. (People aren't gonna go back to paying for certificates, and while there are other free providers, there are reports of "shady" behavior from some—such as charging for revocation or renewal.)

Anyway, if a domain registry gets compromised, there are going to be a lot of seemingly legitimate certificates issued in error, from many CAs. Do we have any practical mechanism for a mass revocation under such circumstances?

By cks at 2025-04-22 14:01:39:

The current CA/Browser Forum baseline requirements require free revocation (by requiring CAs to promptly revoke compromised certificates that they're notified about, and I expect browsers would be extremely unimpressed if a CA refused to accept notifications; there may even be a CAB requirement for it). Let's Encrypt and other parties are working on things that would be necessary for mass revocation, such as the ability for clients to proactively check if the CA wants them to renew right now.

By ghop at 2025-04-22 14:30:02:

Ah, well, that's all very good news then. Perhaps that requirement was a response to exactly what I mentioned. I still feel like revoking Let's Encrypt would be technically and socially impractical; site operators wouldn't know who to switch to, or how, and stuff would just fall apart. The DigiNotar thing wasn't entirely smooth, and they were not nearly as ubiquitous.

Historically, people have believed that the Certificate Revocation List mechanism would just fall apart if they grew to millions of entries. I know browser vendors were working on some "minimized" version, with sharding and such, but I don't know whether we're there yet.

By Evert Pot at 2025-04-22 16:22:24:

I'm curious in what way you would expect discovery of mailservers for a domain to be different if it were designed today.

My first thought went to SRV records or perhaps /.well-known HTTP endpoints, but I'm curious if you had something else in mind.

By cks at 2025-04-22 17:56:07:

My off the cuff version of mail discovery is that it would be one of two things:

something like SRV records in DNS, but then you'd have to require that the target mail servers be able to present a TLS server certificate for the original mail domain when you asked (with SNI). So there would be a mail SRV for 'example.org' and when you contacted one of those hosts for SMTP delivery, it would have to present an example.org TLS certificate to you before you'd deliver email.

a /.well-known endpoint that you queried over HTTPS (not HTTP) at the email domain, so https://example.org/.well-known/... would tell you what host to deliver email to, and then you'd require that host to have a valid TLS certificate in its own name.
(This endpoint could give you a TTL/valid-to value in its response so you could cache it.)

My security goal for both of these is to make it so that inserting or altering the DNS data your mail sending machine sees is not enough for an attacker to divert your email to me to their mail server; it either goes to mine or it fails TLS certificate checks somewhere.

I think that the second version would be more popular because it means that you don't need to have a high-value 'example.org' TLS certificate in so many places. You can leave it only on your website and then have specific TLS certificates on your receiving hosts.

Written on 20 April 2025.

«	Tailscale's surprising interaction of DNS settings and 'exit nodes'

My Cinnamon desktop customizations (as of 2025)