Why do browsers or operating systems not have default DNSSEC validation?

Question

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?

Answer 1

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!

Answer 2

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.