Home / Blogs

DNSSEC is But One Link in the Security Chain

As the implementation of DNSSEC continues to gather momentum and with a number of ccTLDs, and the .org gTLD having deployed it into their production systems, I think it is worth pausing to take a look at the entire DNSSEC situation.

Whilst it is absolutely clear that DNSSEC is a significant step forward in terms of securing the DNS, it is but one link in the security chain and is therefore not, in itself, a comprehensive solution to fully securing the DNS system.

The first issue, which is likely to be only a short to medium term problem, is that there are currently no generally available applications, including web browsers that utilise DNSSEC. This means that even where DNSSEC has been implemented and is in active use, there is at present no straightforward means by which users can knowingly benefit from it.

It is possible to configure a DNS service to reject any records that fail DNSSEC validation, but this is an unsophisticated approach that will not differentiate to the user between DNSSEC failures and other DNS errors. Additionally there are currently no applications that (by default) will indicate the ‘success’ of any such validation to the user.

A more serious issue however is the fact that while DNSSEC provides the ability to certify that requested DNS records have come from an authoritative source and have not been tampered with in transit, it does not mean that those authoritative DNS records are themselves legitimate.

As the saying goes, a chain is only as strong as its weakest link. In this case, the chain includes a number of factors, including the registrant themselves, their registrar (and hosting provider, if different) and the registry, each of which is (at least theoretically) a potential route through which malicious DNS records can be introduced.

Arguably the greatest risk sits with the registrant (which may of course be an individual or a large corporation or anything in between), where a variety of threat vectors exist, including insecure passwords, malware and social engineering. Service providers, including registrars and hosting providers should (and, of course, in the vast majority of cases, do) provide relatively high levels of security including secure logins, however with increasing automation comes increasing risk – with a fully automated system, a compromised login provides a malicious user with the freedom to make changes at will, including updating DNS records to divert traffic to phishing or other malicious sites.

Registries are also not immune from security risks and should be held to the highest security standards. In short, in order to ensure a completely secure chain of trust for the DNS, all the links in the chain on both the lookup and provisioning sides need be as secure as possible.

While this may seem to be stating the obvious, the real issue here, as I see it, is the risk that the introduction of DNSSEC may create an unwarranted sense of security. Malicious DNS records, if entered into a DNSSEC-signed zone through a compromised registrant account or via a hacking attack on a hosting provider will potentially be considered to be more ‘secure’ than legitimate, but unsigned DNS records.

Another significant concern is that there are currently no standards in existence relating to the implementation of DNSSEC, with respect to the provisioning side of the equation. Without agreed implementation standards, especially in the area of security and verification, it is likely that a variety of implementation methods will be adopted, leading to a confusing, potentially unworkable and ultimately costly environment for hosting and other service providers, that will only hamper the adoption of DNSSEC at this crucial level. This will be particularly true in the case of transferring DNSSEC-signed domains between hosting providers.

There is currently little evidence of user demand for DNSSEC, making for a challenging business case for most providers without the added complexity of having to cater for a variety of implementations. There are likely to be a small number of niche providers that will recognise an opportunity to provide DNSSEC services to their clients and are forward thinking enough to know that they are ahead of the curve by implementing now, however the success of DNSSEC requires widespread adoption. For a majority of providers, operating on tight margins, implementing DNSSEC will only start to make business sense when not supporting it starts to impact their market share.

ICANN is realistically the only organisation capable, through its gTLD Registry and Registrar contracts, of effectively mandating implementation and security standards for DNSSEC that will be adopted at all levels of the DNS supply chain, so I would encourage the development of such standards as part of ICANN’s ongoing policy development work.

Filed Under


One simple step towards greater mainstream appreciation Oliver Cam  –  Jul 15, 2010 4:09 AM

One simple step towards greater mainstream appreciation of the benefits of DNSSEC is to get the major browsers (IE, Mozilla, Chromium, Opera, Safari, etc.) to embed DNSSEC status of a site similar to what we have for SSL-enabled sites. Thus far, I’ve been using the DNSSEC Validator add-on/extension developed by labs.nic.cz which can be installed on most Mozilla-based browsers like Firefox. It would be great to eventually see this feature as a standard functionality in the near future. It may not solve the other problems/issues that you pointed out but at least this a step in the right direction. Great article!

Oliver – thanks for your comment. Chris Wright  –  Jul 16, 2010 6:45 AM

Oliver – thanks for your comment. We are looking forward to seeing certificate validation information move into the DNS and eventually replacing the need for separate Certification Authorities.

And how is that going to work for the registrars? Phillip Hallam-Baker  –  Jul 18, 2010 11:02 PM

So you are proposing that the registrars invest in developing an infrastructure that is going to cannibalize their SSL reseller revenues? Has anyone discussed this part of the program with the registrars? Or is the basic idea here that they have absolutely no choice but to promote this scheme regardless of whether it is in their commercial interests to do so. ICANN is pursuing its commercial interests (not profit or not). VeriSign is pursuing its commercial interests. Has anyone told the registrars that they are expected to be the ones taking the hit so that VeriSign can re-establish its dominance in the market they just sold to Symantec for $1.4 Bn? Come to that, do Symantec realize what they are being sold here?

The conclusion is correct, but you omit George Barwood  –  Jul 15, 2010 6:05 AM

The conclusion is correct, but you omit the main problem, which is that although the lookup of the IP address can now be secured, the subsequent application traffic is not secured unless SSL is used ( in which case the security of the IP lookup doesn’t matter ).

There is still value in this first step though, since cache poisoning allows a large number of users to be attacked simultaneously, and this can now be fixed.

The benefit of DNSSEC in the longer term is that it allows certificates to be cheaply and securely distributed. Browsers, email clients and other applications will need to be modified to use certificates validated by DNSSEC. This will take time.

The signing of the root later today is a major milestone.

Thanks George. You’re correct that I Chris Wright  –  Jul 16, 2010 6:45 AM

Thanks George.  You’re correct that I haven’t addressed this important part of the end to end security process, but I wanted to focus on end to end security of the DNS in this article.  There are many other aspects of online security that are of course also vitally important.

Thank you for the well written and simplified overview concerning DNSSEC George Pongas  –  Jul 17, 2010 1:20 AM

Thanks Chris for taking the time to pen this well written and easy to understand overview about DNSSEC.

Whenever DNSSEC is brought up in conversation, in my experience the discussion can become quite confusing and rather animated. People’s opinions are polarized, and I find it challenging to examine the issues constructively. Especially true for the non technical people in our industry, like myself, that know enough about DNS to be dangerous, but not enough to debate this topic at the required detailed and technical level.

I find those trying to market or commercialize DNSSEC as a product/service quote benefits verbatim and deliver the ‘sell’, however when they are challenged with any technical questions their faces go blank and they embarrassingly admit they have no clue.

When you confront technical people (propeller heads), they become all animated and start throwing techno babble comments your way about why there are shortcomings to DNSSEC. There seems to be a prevailing attitude that unless the problem can be fixed completely, then any solution short of 100% is not worth exploring.

Chris, your blog helped me crystallize and better understand the DNSSEC issues as they relate to our industry. I have saved this article and plan to reference it whenever I need to refresh the topic, as well as point others to your contribution that are similarly challenged about the issues concerning DNSSEC.

Thanks again!
George Pongas

How do the keys get into .com? Phillip Hallam-Baker  –  Jul 18, 2010 7:37 PM

I have been asking this question for over a year now. And nobody will answer it. How do I get a key for my domains into the TLD registry?

It is not just a matter of the technical mechanism, there is the question of what criteria are applied to ensure that the keys are inserted by the legitimate registrant for the domain and who is going to stand behind the project by accepting liability.

It is pretty clear that ICANN is not going to address these issues. They won’t even admit the question exists.

Why are the browser providers going to implement DNSSEC? As presently specified it does considerably less than SSL. It is not an end-to-end protocol, only the DNS->IP mapping is protected, not the IP->Endpoint.

the same way the NS records currently get into .com Carl Byington  –  Jul 19, 2010 4:22 AM

> the question of what criteria are applied to ensure that the keys are inserted by the legitimate registrant for the domain and who is going to stand behind the project by accepting liability.

The same criteria that are currently used to ensure that the NS records are inserted by the legitimate registrant, and the liability issues are identical. Registrars already insert NS records on behalf of registrants - they will soon also insert DNSKEY records on behalf of registrants.

> Why are the browser providers going to implement DNSSEC? As presently specified it does considerably less than SSL. It is not an end-to-end protocol, only the DNS->IP mapping is protected, not the IP->Endpoint.

DNSSEC complements SSL, in that the browser can (eventually) securely fetch a certificate and prove that it was authorized by the owner of the target domain, and therefore third party signatures are not needed.

No, the liability is totally transformed.With an Phillip Hallam-Baker  –  Jul 19, 2010 5:01 AM

No, the liability is totally transformed. With an NS record the registrar is saying 'X is the address of Fred' With a DNSKEY record the registrar, registry and ICANN are each jointly and severally acting in the legally recognized role of a trusted third party and is warranting that 'Y is the means by which anyone may authenticate Fred for any purpose'. The design of the SSL CA infrastructure was very carefully considered to ensure that the statement made by the CA was instead 'I have applied process Z, according to which Y is the means that Fred may be authenticated for the purposes described therein'. Now of course the registries and ICANN will leap to assure us that they are doing no such thing, that the liability is firmly on the registrar. But their saying so does not make it so. >DNSSEC complements SSL, in that the browser can (eventually) securely fetch a certificate and prove that it was authorized by the owner of the target domain, and therefore third party signatures are not needed. So ICANN is not a third party? The registry is not a third party? Third party signatures are very clearly still required here. It is just that you are choosing not to recognize them as such. And if the answer to the liability question is that absolutely nobody is on the hook for anything ever, then just what does the security of DNSSEC amount to? A statement only has value in my view when someone somewhere is willing to stand behind it.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



Domain Names

Sponsored byVerisign

New TLDs

Sponsored byRadix

Threat Intelligence

Sponsored byWhoisXML API

Brand Protection

Sponsored byCSC


Sponsored byDNIB.com


Sponsored byVerisign

IPv4 Markets

Sponsored byIPv4.Global