Anne-Marie Eklund Löwinder
Anne-Marie Eklund Löwinder

When the Domain Name System (DNS), the internet's ‘phone directory' or registry, was developed 30 years ago security and confidentiality were not considered issues - the aim was to be a scalable distributed system that was open and accessible.

Anne-Marie Eklund Löwinder, CISO at .SE and one of the crypto-officers with a key to manage DNSSEC for the internet root zone, explained to SC: “We were all pioneers who just wanted to do the best for the internet, but by 1994/95 we had found that it was easy to cheat the DNS, to put false information in between the sender and the receiver,” and this led to development of DNS Security Extensions (DNSSEC). DNSSEC provides DNS clients (resolvers) with origin authentication of DNS data, authenticated denial of existence, and data integrity, but not availability or confidentiality.  

Sweden was the first country to adopt DNSSEC and Eklund Löwinder explained her role: “I'd been interested in DNSSEC since 1999, when I was with the Swedish government in their ICT commission and we had a first workshop project, a prototype to make it work, and I was impressed. I just wanted it to happen.”

The protocol and specifications were re-written and Eklund Löwinder was now working for the Internet Infrastructure Foundation (.SE) running the top-level domain for Sweden, which she described as the perfect place to implement it. “By 2003 we started to run and adopt DNSSEC ‘in a parallel universe' where we played separately that we were the internet. Friendly users were adding on and using DNSSEC to see what happened, and we concluded, this is good, it works.  It was more like a guerrilla movement - we didn't ask for permission.  We just said, ‘We have to do this' so we just did it.

 “We decided that six months from the protocol standards being accepted by the Internet Engineering Task Force (IETF) our name servers should be ready, and they were. We just started. And in the first six months, again, we had friendly users. We signed a contract with them with a disclaimer saying, ‘you are playing with us on your own responsibility – don't blame us.'   Then we implemented it fully.”


James Galvin, director, strategic relationships and technical standards at Afilias, in his blog summarised below, reports that DNSSEC technology standards have been stable and mature since 2007, with only updates, clarifications, and new functionality added since then. Yet only 12 percent of global DNS queries involved some kind of DNSSEC validation by October last year, leading Galvin to assert that “waiting until the standards are final” is no longer a valid reason to delay deployment.

Major stumbling blocks identified are that: “The new ICANN policy for gTLDs (generic top level domains) mandates signed TLD zones, but not signed second level delegation. In addition, the 2013 Registrar Accreditation Agreement (RAA) requires registrars to offer “DNSSEC services,” but only for those registries that require it.  (Also) It is not possible for a gTLD domain name registration with active DNSSEC to be transferred from one registrar to another without breaking the security chain of trust.”

Galvin adds: “DNSSEC is not just about protecting the DNS, it is about building a secure infrastructure foundation upon which new and innovative services and applications can be built to benefit us all.  Registrars are the linchpins to advancing the deployment of DNSSEC.” 

Usually the registrar registers and hosts a domain, but where domain name owners use a third-party DNS service provider for DNS hosting, or host the names themselves, for the domain name owner to sign their name, the DNS service provider must do the DNSSEC signing for them, thereby creating what Galvin describes as a ‘functionality gap.'  The registrar can potentially bear an administrative burden for a service the domain name owner chose to obtain from a third-party. 

Galvin concludes: “We cannot let these critical yet granular key-passing processes impede the deployment of DNSSEC and its promise to deliver a more secure internet infrastructure for every internet user.”

The IETF worked with every new protocol or protocol version to ensure they would be backwardly compatible. At that time SSL (now called TLS) security existed, but, TLS and certificates are ‘a different story', on a higher level in the infrastructure – in the software in the application to protect the communication between the server and the client, where the web browser is the client. Part of the communication is protected with encryption, while DNSSEC is protecting the signalling system in all the internet, which is DNS traffic.  So they are seen as complementary, not competing technologies.

Eklund Löwinder comments, “DNS with DNSSEC is an infrastructure the PKI (Public Key Infrastructure) industry can only dream of.  If you put your keys in DNS, you sign it with DNSSEC and voila, you have it distributed globally. You don't even have to think about it.  And that is what's happening now. People are putting their security credentials within their DNS system using DANE to get it distributed in a safe way. And it is not reliant on certificate authorities – and they have had some issues lately. There has been fraudulent behaviour within their staff, or they have been issuing certificates to people who shouldn't have them.”

DNSSEC also has a role in the smart grid environment and the Internet of Things, from voice over IP to automated cars and connected fridges. It's communication – you need to look up function, thus IP address to connect you to the domain.  So a refrigerator can have the serial number as the domain, and @ .uk.  Lack of human involvement means it's difficult – requiring excellent monitoring, and constant scrutinising of log information - to detect if something is going on.

If DNSSEC is so good, why isn't it more widely implemented? Eklund Löwinder responds: “One of the ‘problems' is that there has been no huge incident - though there have been smaller ones. You are adding a complexity to DNS that we are not used to. DNS itself, in the original version, is very forgiving.  You can do a lot of things wrong but it still works – its amazing, really amazing.”

Will such complexity not have both cost and performance issues? Eklund Löwinder says not, adding: “People who argue against DNSSEC always say, ‘It will affect the performance of my systems; it will cost a lot to implement; it will need more people,' but we have proved that's not true. This is a natural evolution. Meaning that you have the infrastructure which needs to be updated, you need to replace old servers with new servers, old software with new software. It's just business as usual.”

Not everyone is convinced.  In fact there is an entire website devoted to cataloguing problems with DNSSEC ( – but defenders of DNSSEC say that some of the information on the site is clearly wrong, and some of the incidents on the list have nothing to do with DNSSEC.

Issues include: some faults in DNS are only visible in DNSSEC – and then only when validating; several faults exist in DNS software that apply only to DNSSEC – and this has led to disruptions detailed in the website above; the DNS software must be updated more frequently; it is more difficult to debug DNS with DNSSEC; DNSSEC requires keeping track of additional details; in certain cases, different types of DNS software do not work together and it can be difficult to locate the fault.

Dan York at the Internet Society's Deploy360 Programme adds: “There are two sides to DNSSEC – signing of domain names and validation.  You can enable DNSSEC validation by changing just a single configuration line for a DNS server. Many of the issues that may have caused outages in the past are not as prominent today.”

Signing can be more complex, but some DNS operators and registrars have made it as simple as a single checkbox. There are some 600 TLDs signed with DNSSEC and millions of individual domains. York says: “DNSSEC requires network operators to pay more attention to DNS and add new operational practices. As DNSSEC deployment continues, these practices are being documented so that over time the level of education within network operators will ensure that DNSSEC operations run even smoother.”

York concludes: “The reality is that despite the additional requirements, DNSSEC provides the best mechanism we have today to add more trust and security to DNS.”

Also, DNS allows you to find the right IP for a domain, so you can't make it secret or confidential.  But when implementing DNSSEC, you need to be able to tell someone if they are looking for something that doesn't exist, you need to give a reply which is signed, but has not accepted the connection and this has proven very hard to do.