Domain system security: too much, too little, too hard, a waste of time, or all of the above?

« Back to the news page

Written by Kieren McCarthy.

More importantly – what do we do to fix it in future?

Last month, one of the most important improvements in security of the domain name system – the KSK rollover – was cancelled.

Why? Because those preparing to flip the switch realized that as many as eight per cent of DNS validators were going to spit out error messages the moment the key was changed - and cause as many as 60 million internet users to fall offline. 

What makes that situation all the more troubling is that the problem stems from a security protocol approved more than a decade ago. 

DNSSEC has had a long and painful journey to adoption: even the discovery of a dangerous flaw in the DNS back in 2008, and a requirement for new internet registries to include it as standard in 2012, has not resulted in the kind of take-up people hoped for. 

Internet engineers estimate that, even now, just one-in-four internet users are benefitting from the additional security that DNSSEC provides. And, as we now know, nearly ten percent of them are relying on flawed implementations.

Of course, the internet is a huge and varied place. It is, by design, not supposed to act as a coherent whole. But the truth is that this stretching out of the internet's connective tissue is becoming an ever larger problem. 

Even as some parts of the network are building the equivalent of Japanese bullet trains by laying out protocols that sit on top of DNSSEC – DANE, DNScrypt, DNScurve, DKIM, DMARC - many millions of users are still riding wagons on dirt roads.

It is tempting to see this as simple technological advancement but the KSK rollover delay reveals things are riskier than that: the slow rollout of older technologies can cause newer ones to stutter or stall. 

It's not just DNSSEC either. After a wave of domain name hijacks, ICANN's Security and Stability Advisory Committee (SSAC) back in 2005 came up with a series of recommendations for how to make sure these critical addresses couldn't be snatched away. 

https://www.icann.org/en/system/files/files/ssac-lux-12jul05-en.pdf

And yet 12 years later one of the largest companies in the world - and one synonymous with the internet for many - Google, lost control of one its names: 'google.ie.' How is that even possible?

In July this year, billion-dollar marketing company Marketo lost control of its domain name. Marketo.com wasn't just a corporate site with a few dozen webpages, it was the focal point for millions of hyperlinks, web forms and online reports for tens of thousands of other companies – all of which promptly disappeared without warning.

Just imagine the impact if 'google.com' went off the reservation. Or WellsFargo.com.

We already have a system - multiple systems in fact - for protecting these valuable online assets. Most have heard of "registrar lock" where the company you pay to register your domain will lock it down. But what about "registry lock" – where the company running the internet registry makes sure that name is going nowhere? Take-up of registry lock is bafflingly low considering the extra security it provides for little cost. 

Adding to these issues is the fact that the DNS is going to become more of a target for cybersecurity attacks in future. Not to mention ransomware, phishing sites, fake news, spamming – all of which can be mitigated with improved DNS security.

So why are we failing to secure the DNS, especially when we have the tools to do so? And how do we shift the dynamic so we don't end up dragging out important security improvements over decades? 

According to one man who has spent most of his life trying to improve internet security, Netnod's head of engineering and former SSAC chair Patrik Fältström, economics are a fundamental driver. "Like many other IETF technologies, whoever makes the investment do not get the gain," he notes. 

When it comes to DNSSEC – the critical foundation on which many hope to build more services – there are two aspects: validation and signing. Validation is a no-brainer, says Fältström: "People should 'just turn it on'."

But signing is more complicated. "When you sign your zone, you have to pass the so-called DS record to the parent zone, just like the NS record," he notes. But your DNS provider may not be your registrar, and the two may not be good at communicating with each other. The IETF is working on an automation solution (RFC 7344). 

https://tools.ietf.org/html/rfc7344

Plus there is the fact that not everyone does DNSSEC the same way. The internet's in-built flexibility can be a little too flexible at times, reducing interoperability and increasing complexity. 

Michele Neylon, CEO of Irish registrar and hosting company Blacknight, says a cost-benefit analysis of DNSSEC is not good. "The cost of implementing it at the registrar level is high compared to the demand and the revenue it generates. Also, due to the way it's designed it's completely unforgiving, so if you make a tiny mistake the domain will stop working entirely. I've seen it happen – it's not pretty."

DNSSEC may be technically complex but that isn’t the case for registry lock. 

"The registry lock is an interesting feature for whomever believes their portfolio is worth something and who wants to minimize the risks," notes Dirk Jumpertz, security manager for EURid, the registry that runs .eu and charges 10 euros a year for its lock service. At that price "not only big corporations should use it but anyone who makes a living off their website, e-commerce shop or domain name portfolio," he argues. 

But, despite calling it "the perfect weapon against domain hijacking" take-up is "slow to say the least." Why? According to Jumpertz, three main reasons: economics, hassle and awareness. 

"I can imagine that registrars see the registry lock as a competing feature that gives them less control over their customers," he notes. In addition, if you are dealing with a large portfolio of domains, the need to go direct to the registry for each name can prove an additional barrier. 

Neylon confirms the second point: "The registry lock is a manual process and it isn’t available across all TLDs. Enabling it involves lots of manual work. It's not a high volume service. We offer it, but the uptake is very low."

Which leads to the last point: awareness. Jumpertz argues that "even though the domain name business is not very complex, it is quite unknown to the general public. Today no one actually sees the inner workings and supporting layers of the internet anymore."

Which leads to the all-important question: how do we go from the current situation where security is stretched further and thinner to one where we can keep building and raising up the foundation of security?

There are lots of ideas but most fit into one of four main categories: Education, Requirement, Simplification and Visibility.

Education – and hence awareness - applies to everyone. If IETF engineers were more aware of the problems that others were having with their protocols, it would move things along faster. There is a feedback loop – the IETF's plan to automate DNSSEC delegation trust maintenance being a case in point – but the process is slow and siloed. 

Education can also help drive demand. If companies were aware of registry lock, more would ask for it and that would drive others to offer it, creating a virtuous circle. Likewise, if more people understood why DNSSEC was important to their business, it would prompt them to ask their IT department about it. 

But the truth is that education can only go so far. There needs to be a stick with the carrot. Some companies and governments have taken a step forward by making DNSSEC mandatory – the US government is a good example - but they remain in the minority. Education directed at governments can help drive requirement and with it, greater implementation.

Simplification is key. If the internet is anything it is a stunning example of how enormously complex systems can be made to work simply. You can, right now, type something into your smart phone and receive a flood of information about it within seconds. The way that actually happens is enormously complex but so seamless that we take it for granted. The same needs to happen with security. 

It should be possible to have DNSSEC and registry lock (and other future security improvements) turned on and working within seconds. Every discussion about DNS security should be viewed in the context of whether it moves us all closer to the goal of instant implementation.  

And last, visibility. It may not be enough to be secure if no one can see it. The take-up of HTTPS was helped by the little padlock symbol in your browser. Some have proposed a similar simple and clearly indicator for DNSSEC (again, there are already solutions but they require manual implementation.)

Giving people a sign that something is going on that they were previously unaware of can be an extremely effective way to drive everything else: awareness and education leading to requirement and encouraging simplicity. 

Visibility also means people making themselves visible. It is not enough for issues to be kept within ICANN meetings and IETF meet-ups. The broader world needs to know why domain name security is not something that someone else has to deal with but a key thing for you and your team to understand and push. 

If all those things happen then, with luck, the next KSK rollover will happen without anyone even noticing - but with everyone benefitting.