I'm trying to understand the benefits of DNSSEC.

If a user goes to my site example.com and the DNS cache was poisoned redirecting the user to the bad guy's IP, what would happen?

I've enabled HSTS.

My understanding is the user would see the 'Your connection is not private screen' and would not be able to continue (unless they are using an older browser like IE 10 which doesn't support HSTS).

Could the bad guy redirect my site to another domain bypassing the HSTS protection or does HSTS stop the redirect happening because it can't find a valid cert?

With DNSSEC enabled would this stop the bad guy poisoning the cache and the user would be none the wiser or would they see a different error page?

I know DNSSEC doesn't protect the last hop.

  • 2
    You forgot one very important point: the Internet is not just the Web! HSTS only helps for web browsing but there is a lot of other things happening through TCP/IP (or UDP), and for all of those you need DNSSEC if you want authentication and integrity in DNS replies. Also take a look at DANE, that should potentially help many protocols and that requires DNSSEC. May 13, 2018 at 18:51

2 Answers 2


These are very different technologies and they do not really rely on each other. In fact, some arguments find DNSSEC unnecessary in general. I would say no, DNSSEC is not needed if HSTS is used properly (long duration, preloaded). Most clients don't even use DNSSEC, so effects of having it may be minimal.

I think you are correct in observing that the effects of DNSSEC on a website served over HTTPS with HSTS configured are minimal. In this case, whether or not the DNS response is correct, the browser will refuse to load the website unless it supplies a valid certificate (assuming the website is in the HSTS preload list or the browser has already seen it).

Also note that these technologies work at different layers on the client. While the browser is aware of the HTTPS/HSTS situation, it does not know or care about the state of DNS/DNSSEC, as this is typically handled by the OS's resolver or an upstream server. Without using a browser extension for DNSSEC, it only can be told whether or not a response came back.

DNSSEC shines in other, non-web scenarios. One example, in the mail realm, is DANE (DNS-based Authentication of Named Entities). It uses DNS to retrieve certificate information for various servers. DNSSEC is critical here to protect the DNS traffic from tampering, since such tampering would allow an adversary to substitute their certificate fingerprint. Other non-web applications may have similar requirements for DNS integrity.

  • Thanks Multithr3at3d. I agree about the benefits of DNSSEC for email. I believe it could also replace the CA issued certs in the long term but the pros and cons seem evenly matched. Just to confirm the pro of DNSSEC over just HSTS is the user wouldn't have the problem of the browser refusing to load as the resolver wouldn't be fooled into providing the wrong IP in the first place. May 13, 2018 at 14:26
  • "I think you are correct in observing that the effects of DNSSEC on a website served over HTTPS with HSTS configured are minimal." I disagree. Without DNSSEC you have no guarantee where you are connecting to... even if you do HTTPS later. If you added DANE into the mix (that is HSTS + DANE) then you had better guarantees. (or maybe if you added HPKP). But obviously DANE requires DNSSEC... As counter intuitive it may be, authentication is more important (and also difficult) than transport integrity. May 13, 2018 at 18:53
  • " the browser will refuse to load the website unless it supplies a valid certificate" this does not prevent an evil guy to supply a wrong website with a certificate, even selfsigned and it will get accepted by clients. See the recent BGP hijack for myetherwallet. You need DANE or HPKP to protect against that case (different certificates) May 13, 2018 at 18:57
  • " it [the brower] does not know or care about the state of DNS/DNSSEC" more or less true, it depends on how it does DNS resolving, it may do it on its own. Also some newer APIs like getdnsapi gives more information to the caller. But of course the problem is on where the DNSSEC validation takes place, locally or not. If not, you need to trust the third party to do the cryptographic computations honestly. May 13, 2018 at 18:58

Let's say you are visiting www.mybank.com

DNSSEC ensures that the IP address you are going to, for www.mybank.com, actually belongs to MyBank. This happens cryptographically of course.

Once you have the correct IP address, now your browser sends an HTTP request to the (trusted) IP. HSTS now ensures that when the HTTP query is made, non-SSL based communication is prevented. This is done through the HSTS flag. Therefore, if a rogue actor is Man-In-The-Middling your traffic, they cannot force communication over non-SSL HTTP.

Not the answer you're looking for? Browse other questions tagged .