In recent years, the number of free and commercial DNS service providers has grown. Alongside traditional providers, such as Google Public DNS and OpenDNS, there are various others, including 1.1.1.1 and Quad9. As a result, end users can be tempted to shop around if problems arise. After all, if a domain is incorrectly configured for DNSSEC, it can't be reached via a validating resolver, but it will be reachable via a resolver that doesn't support validation. Switching to a non-validating DNS service will get around the acute problem of not being able to reach the domain, but will seriously undermine security. And there are better ways of making problematic domains available.
Validation errors occur when there's something wrong with a domain's DNSSEC configuration. There might be a mismatch between the public key published in the domain's zone file and the key material registered with the parent domain, for example -- maybe because something went wrong when the domain was transferred to a new registrar. Or the problem might be a digital signature whose validity period has expired, perhaps because of an issue with the domain's authoritative server. If internet users can't reach a domain because of a validation error, they're liable to blame their validating resolver's operator. However, the operator can't usually fix the underlying problem: only the domain's owner can put right a faulty DNSSEC configuration.
False alarm?
A user who wants to reach a problematic domain quickly will often be tempted to switch their resolver to a DNS service that doesn't support validation. Google, 1.1.1.1 and Quad9 do all validate, but Quad9 offers alternative addresses with no filtering or validation. OpenDNS (Cisco Umbrella) and various less popular public services, such as Comodo and Yandex.DNS don't support validation at all. Although switching to a different DNS service is the easiest way to get around the problem of an unreachable domain, users are strongly advised against that approach. First of all, because how do you know that the issue with the domain is a false alarm? Second, because switching to a non-validating resolver means disabling DNSSEC security for all the domains you visit.
Configuration problems
About seven years ago, an excessive number of domains in the .nl zone had configuration problems. As a result, access providers were reluctant to enable validation for their users. We therefore took action to address the issue, and the number of validation errors soon came down. Now the number of problematic DNSSEC-enabled .nl domains is negligible. The latest available data indicates that such domains represent 0.1 per cent of the total, and most of those are likely to be low-traffic domains or domains with transient issues. So validation errors are no longer an obstacle to access providers and network operators enabling validation.
Negative trust anchors
If you do nevertheless find that a validation problem is preventing you reaching a really important domain – on one of those rare occasions when a popular internet service is affected, for example – what you should do is set a negative trust anchor (NTA). An NTA is simply a (temporary or permanent) exception, allowing an error with a particular domain to be disregarded (taking account of the TTL of the DNS records). Validation continues as usual for all other domain names. If you do your own validation (e.g. using Unbound), you can set an NTA in your own resolver configuration. Otherwise, you'll need to ask your network operator to set one in their resolver infrastructure. On our DNSSEC page, the configuration of various validating resolvers is fully explained in a series of hands-on articles for both professional and private users. The articles include details of how to set NTAs. If you'd like to trace a validation issue, try DNSViz and the Verisign DNSSEC Debugger.