DNS cache poisoning, bit flips, and other such attacks. It does nothing for your site's confidentiality or availability, but it ensures the validity of the DNS records.
Scummy DNS providers like commercial ISPs tend to hijack certain DNS queries for their own gain. With DNSSEC they cannot do so.
Furthermore, with the slow but soon irreversible switch over to DNS over HTTPS, with all the DNS centralisation it brings, knowing for sure that nobody tampered with DNS records is a necessity.
Additionally, DNS records are also used in technologies like encrypted eSNI headers. If you are able to supply bad or old eSNI data to another site's cache, that might cause slowdowns or even breakages when eSNI or its successor eventually rolls out. Alternative PKI solutions also store TLS public keys in DNS records, so those are essential to get right as well.
DNSSEC does not protect your scummy commercial ISP DNS server from lying to you. Your stub resolver trusts that scummy ISP DNS server to validate DNSSEC for it.
People have a lot of funny ideas about what problems DNSSEC solves. This is demonstrably not one of them.
> DNS cache poisoning, bit flips, and other such attacks. It does nothing for your site's confidentiality or availability, but it ensures the validity of the DNS records.
Sure, but at what cost? It's hilariously easy to misconfigure effictively removing the entire domain from anyone who decides to enfirce DNSSEC validation, and DNSSEC gives you no choice in who to trust (Verisign own .com I think, state governments tend to own a lot of the national TLDs etc.)
If your threat is a poisoned DNS cache then... don't use a DNS cache?
> Scummy DNS providers like commercial ISPs tend to hijack certain DNS queries for their own gain. With DNSSEC they cannot do so.
The problem here is that as an end user, I want to resolve gmail.com to the correct endpoint. If my upstream DNS cache is giving me the wrong results, DNSSEC doesn't help me - NXDOMAIN'ing a valid DNS request leaves me in the same position as without DNSSEC. I still can't get my email!
In the face of a malicious upstream handing out the wrong DNS records, a far more sensible solution is to bypass that upstream, optionally encryping the transport so that they can't fiddle with the results in-flight. This actually gets me what I need - the correct DNS record for my request.
> Furthermore, with the slow but soon irreversible switch over to DNS over HTTPS, with all the DNS centralisation it brings, knowing for sure that nobody tampered with DNS records is a necessity.
> Additionally, DNS records are also used in technologies like encrypted eSNI headers. If you are able to supply bad or old eSNI data to another site's cache, that might cause slowdowns or even breakages when eSNI or its successor eventually rolls out. Alternative PKI solutions also store TLS public keys in DNS records, so those are essential to get right as well.
If you care strongly about the integrity of your DNS records, there are better solutions. DNS-over-TLS/HTTPS should in theory let you trust only the owner of the authoritative DNS server, if you can make a direct connection to it to ask questions. DNSSEC forces me to trust a whole load of intermediaries forever. I'm not sure why the latter is better.
Maybe it's better to stop designing things for which the security rests on being able to fully trust DNS? Gmail (and everything else etc.) seems to work quite well right now without depending on DNS being 100% trustworthy, mostly because if I do somehow get an evil-controlled DNS record back, my browser's going to start sounding alarm bells when the TLS cert doesn't work.
Scummy DNS providers like commercial ISPs tend to hijack certain DNS queries for their own gain. With DNSSEC they cannot do so.
Furthermore, with the slow but soon irreversible switch over to DNS over HTTPS, with all the DNS centralisation it brings, knowing for sure that nobody tampered with DNS records is a necessity.
Additionally, DNS records are also used in technologies like encrypted eSNI headers. If you are able to supply bad or old eSNI data to another site's cache, that might cause slowdowns or even breakages when eSNI or its successor eventually rolls out. Alternative PKI solutions also store TLS public keys in DNS records, so those are essential to get right as well.