Dutch name authority: DNSSEC validation errors can be eliminated

Service providers no longer have a reason to resist, yet DNSSEC adoption is declining

By Richard Chirgwin


DNSSEC, which secures the ancient domain name system, is important to Internet security and privacy, but as APNIC luminary Geoff Huston wrote last week, there's evidence that its use could be declining. “From the validation perspective, the use of DNSSEC appeared to have peaked in early 2016 and has been declining since then”, his post stated.

Now SIDN, the domain registration foundation for The Netherlands, which has spent four years on the issue, believes one key to improving DNSSEC uptake is to eliminate validation errors.

Validation errors occur when information in the authoritative nameserver doesn't match what's held by a registrar. When that happens users are told the lookup has failed (that is, they can't reach the site), and that's a bad look. They might believe someone's blocked a site, or they might blame the service provider's infrastructure.

According to a 2017 study (PDF) by the Asia-Pacific Network Information Centre (APNIC), only one per cent of .com, .net, and .org domains were signed, and even those had a 30 per cent misconfiguration rate. Those misconfigurations would return validation errors.

SIDN's approach, implemented over the last two years, was to document validation errors in the .nl namespace, to decide whether that country's ISPs could use a validation service.

As the country's DNSSEC partnership wrote: “In the period 2013-2014, validation errors were an important obstacle to the further development of DNSSEC in the Netherlands. The pioneering role that the .nl domain had (and has) in the signing of domain names has been at the expense of validation. The result is a strong imbalance between these two complementary components of DNSSEC.”

Too many domains, the post said, had registered information with SIDN that didn't match the information held on DNSSEC authoritative servers.

After contacting the registrars that generated the most errors, SIDN then launched a validation monitor in 2015 – yet, it complained, access providers were still citing validation problems as their reason for not supporting DNSSEC.

Which leads to the authority's final project, a two-year pilot of its own DNS resolver in partnership with broadband outfit OpenFibre, to collect hard data about validation errors.

Its conclusion: “The most important outcome of this pilot is that validation errors almost no longer occur,” SIDN's Sebastiaan ​​Assink says in the post. The rate of validation error is now 30 per million DNSSEC lookups.

Alas, even if validation errors no longer stand in the way of DNSSEC, SIDN claimed The Netherlands' biggest ISPs – KPN and Ziggo among them – still resist deployment. Assink said this is “a brake on innovation. New applications on DNS / DNSSEC - think of DANE , DKIM, DMARC and SPF - therefore do not come into their own”.

As APNIC noted in last year's study, registrars also remain another roadblock. As of December, among 20 major registrars only three – GoDaddy, NameCheap and OVH supported DNSSEC for domains they manage. Only 11 registrars (including the three already named) will let an external nameserver run DNSSEC.

Huston wrote that browser vendors are another roadblock, because they're “obsessed by wanting to shave off the few milliseconds that need to be spent in validating the name against the name’s public key when using DNS”.

Apart from the applications identified by Assink, DNSSEC also gives users an important protection against DNS spoofing (also known as DNS cache poisoning). It seems, however, that more incentives will be needed to get service providers to play along. ®

Sign up to our NewsletterGet IT in your inbox daily


More from The Register

WHOIS embarrassed about security? APNIC, after database leaks

Asia's internet numbers registry let some weakly-hashed passwords into the wild

BIND comes apart thanks to ancient denial-of-service vuln

No active exploits, but crashes are happening in the wild

Net's druids thrash out specs for an independent IETF

This matters because right now there's no formal structure, which makes things tenuous

Apache Hadoop spins cracking code injection vulnerability YARN

Loose .zips sink chips 2: Electric Boogaloo

IETF mulls adding geoblock info to 'Bradbury's code'

Proposal to extend Error 451

ISC squishes BIND packet-of-death bugs

DNS servers are crashable until they're patched

Oi! Not encrypting RPC traffic? IETF bods would like to change that

RPC over TLS: You know it makes sense

Updating Things: IETF bods suggest standard

Proposal offers proper authentication, verification and over-the-air delivery

April FAIL as IETF's funny-but-dodgy draft doc arrives a week early

Holy Hand Grenade proposes update to RFC 8140 but blows back on the court of King Arthur

IETF wants packets to prove where they've been, to improve trust

Virtualisation is creating traffic handoffs that don't depend on physical ports