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.