Many resolvers (including TLDs and Root TLDs) support DNSSEC, also Google's OpenDNS servers support it.

Yet it isn't checked on the client side by default. Why is this?

2 Answers 2


The Chromium security team say:

DNSSEC and DANE (types 2/3) do not measurably raise the bar for security compared to alternatives, and can be negative for security. DNSSEC+DANE (types 0/1) can be accomplished via HTTP Public Key Pinning to the same effect, and with a much more reliable and consistent delivery mechanism.

(see https://bugs.chromium.org/p/chromium/issues/detail?id=50874#c22)

They've spent quite a lot of time and effort working on HPKP support, and Firefox have been making use of a lot of the tools they produced (e.g. the built in pinning lists). Therefore, they probably don't see much point in supporting a different method, when they have one which they consider better. Microsoft have also been investigating it, but haven't made any particular stand (although they don't appear to have been investigating DNSSEC). That's the main players in the current browser market leaning towards an alternative.

However, HPKP is built on HTTP - it's designed purely for the web. DNSSEC doesn't have that restriction, so can be used for other applications. It can verify that DNS records actually come from the domain owner, which can be useful for mail servers, or for small scale DNS resolvers, ensuring that a malicious actor able to modify traffic can't tamper with the records in an undetectable fashion. Because of this, it's still considered important to deploy - DNS is used for a lot more that just web pages!


From here:

Disadvantages of DNSSEC

  • DNSSEC can add significant load to DNS servers – increasing costs and reducing efficiency of current DNS systems. It requires significant investment of resources on the part of TLD registry operators, domain name registrars, ISPs and hosting providers.
  • “Bootstrap problem” – a minimum level of deployment is required before ANY users receive a benefit greater than their costs.
  • DNSSEC deployment requires software on BOTH the server and client side – how can you get buy-in from end users to use operating systems and browser add-ons that support DNSSEC, especially when the increased complexity of DNSSEC may introduce frequent lookup errors or diminished performance, negatively impacting the overall internet experience for end users?
  • DNSSEC is needlessly complicated and a pain for even experienced DNS administrators to implement – DNSSEC adds complexity to a system that is intrinsically simple. There is a potential for lack of backward compatibility with some non-DNSSEC systems, which also creates concern.
  • Very few top-level domains support DNSSEC and some governments may even try to ban DNSSEC-backed encryption key distribution – countries are concerned about U.S. control of the internet, and may reject any centralized keying. Deploying DNSSEC in the absence of a signed root diminishes protection against DNS cache poisoning and similar attacks.

So it appears browsers could support DNSSEC by default, at the expense of browser performance.

It appears that take-up of DNSSEC makes it not worth it at the moment of writing. Any DNSSEC lookups that don't exist will have to fallback to normal DNS, increasing latency.

Also there's a user experience problem here - how does a browser convey the fact that a domain was looked up via DNSSEC? Many users won't understand how this extra flag works in combination with the padlock. I guess it could block DNSSEC responses that haven't been correctly signed and refuse to navigate there, however the certificate is already meant to verify that you've reached the correct server. And with HPKP you can check there's no certificate issued by any rogue Certification Authority.

Edit: now HPKP is now dead, we now look to this like certificate transparency to achieve this.

  • I can't buy "needlessly complicated and a pain for even experienced DNS administrators to implement". I set it up using Cloudflare and hover.com in less than 10 mins and I'm no "administrator". It's pretty straightforward if you have sufficient access to your DNS records and domain management tools.
    – cottsak
    Feb 25, 2019 at 2:12
  • I don't even think you realise what you've just said: Using a service that does all the "needlessly complicated" stuff for you is not the same as implementing it yourself. This question is regarding why browsers do not have dnssec validation by default. Tying yourself into Cloudflare is not something every organisation can do. Setting up one domain in dnssec using an automated service is indeed not "system administrator" work, as you say, but setting up custom zones for organisational infrastructure over large enterprises is. Not everyone can or wants to let a 3rd party manage their keys. Feb 25, 2019 at 7:01
  • Great points @SilverlightFox. But just as there are some large orgs, there are also small operators too. And for them, maybe the keys and automated tools are not a problem. In those cases, there is no needless complexity, or complexity of any sort as far as I can tell. And sure, "This question is regarding.." something else and that's why my comment was a comment and not an answer. Jus trying to be helpful to those who may be using services similar to mine, and have wanted to give DNSSEC a go and were possibly put off by a point in this answer.
    – cottsak
    Feb 25, 2019 at 13:06
  • The last point isn't a big thing any more. The root zone is signed and looking at en.wikipedia.org/wiki/List_of_Internet_top-level_domains suggests that more than half of the TLDs support DNSSEC (I didn't count though). Mar 7, 2019 at 8:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.