Something has gone awry with Internet governing body ICANN’s timetable for changing the cryptographic root key used by DNSSEC (Domain Name System Security Extensions), a technology first deployed in 2010 to protect the global DNS system from cache poisoning attacks.
Scheduled to happen on 11 October, this important event has now been postponed until the first quarter of 2018 after ICANN discovered a number of ISPs were having trouble with the automated key update process.
Posted in July, ISPs using DNSSEC were supposed to have installed the new Root Zone Key Signing Key (KSK) that lies at the heart of the system within 90 days.
ICANN’s research suggested around 5-8% of ISPs hadn’t.
It’s the first time the key has ever been changed in DNSSEC’s short history, so perhaps problems were to be expected. Explained ICANN:
There may be multiple reasons why operators do not have the new key installed in their systems: some may not have their resolver software properly configured and a recently discovered issue in one widely used resolver program appears to not be automatically updating the key as it should, for reasons that are still being explored.
In other words, ISPs may have thought they’d implemented it but hadn’t because of an undetected technical glitch. Had ICANN not halted final deployment, domains managed by these providers would suddenly have become unreachable next week.
But is DNSSEC that important?
The technology’s origins go back to 2008 when a researcher called Dan Kaminsky discovered a problem with the DNS protocol used by websites to resolve human-readable domains into computer-friendly IP addresses.
The gist was that an attacker could redirect users looking for a real domain to a spoofed one by compromising the domain record held in a DNS cache. Users would be sent to the fake site for as long as the spoofed record remained in the cache.
The answer experts came up with was to verify every level of the DNS hierarchy cryptographically – a chain of trust – but that meant there had to be an ultimate authority: a key sitting on root servers at the apex of the system. This is the Root Zone KSK.
The changing of the KSK began with an almost religious ceremony in a windowless room in California last year but there is in fact no fundamental reason why it has to be completed this month.
When DNSSEC started, ICANN committed to changing the KSK every five years, a timetable that has already slipped. Nevertheless, everyone knows it has to be changed at some point simply to demonstrate “cryptographic hygiene”.
Naked Security understands that ICANN will now monitor uptake in the coming weeks before, as a last resort, publishing a list of providers that have failed to apply the new key correctly.
The bigger picture here is DNSSEC. This is still not adopted by a swathe of Internet providers, wary perhaps of the management complexity of its cryptographic design. It is, however, mandatory for the new generic Top-Level Domains (gTLDs) that started appearing in 2013.
Uptake of DNSSEC will surely increase over time and a smooth transition from the old to the new Root Zone Key Signing Key (KSK) can only help with adoption.
4 comments on “DNSSEC master key change delayed after ISPs struggle”
“But is DNSSEC that important?”
You’re right; probably not–since we’re moving toward full web encryption anyway. A forged site with fraudulent DNS would (should?) still fail the check for a valid certificate.
There are far too many people out there with the right to sign https certs for that system to be trusted against someone who has compromised DNS, even assuming big businesses are willing to lose sales to forcing https in the first place.
Good points. Comment rescinded. 😉
Its not enough to go to an encrypted web (and email and various other protocols).
The web browsers currently do HTTP request first for most addresses entered, allowing people to steal and forge cookies. They can do this remotely more easily if DNSSEC stays out of the way.
Whilst I do run a site where we deploy defences against someone using the wrong certificate authority (HPKP), that DNS is rewrite-able on the wire opens up all sorts of attack possibilities that will take further effort to squash than just ensuring website use HTTPS.
Email is the big black hole here – how many emails have you had returned because the certificate was expired or the wrong domain name was used, now compare that to your browsing experience, anything stand out?