Archive for the ‘DNSSEC’ Category

DNSSEC is but one link in the security chain

Monday, July 12th, 2010

By Chris Wright

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.

AusRegistry International’s Domain Name Registry software provides full support for DNSSEC-signed zones, including real-time DNS updates, for both signed and unsigned zones.

Review of APTLD meeting in Beijing

Monday, August 31st, 2009

By Jon Lawrence

As mentioned previously, AusRegistry International staff attended the Asia Pacific Top Level Domain Association (APTLD) Members meeting held in Beijing last week (20th and 21st of August).

The meeting, hosted by CNNIC (the .CN registry), was attended by over 50 people representing ccTLDs from around the region as well as a number of associate members and representatives from ICANN.  CNNIC were warm and gracious hosts and on the first evening attendees enjoyed an interesting tour of the Summer Palace followed by some impressive local entertainment and a traditional Chinese banquet.

Highlights of the conference included:
•     a status update on the IDN ccTLD Fast Track program from ICANN
•    an update from the Chinese Domain Name Consortium (CDNC) on the issue of IDN variants
•    presentations from members on various topics including DNSSEC and the Conficker worm

AusRegistry International presentations
AusRegistry International staff also presented to the conference on two topics:
•    Jon Lawrence presented Implementing an IDN Registry
•    CEO Adrian Kinderis presented How to write an RFP

IDN ccTLD Fast Track update – ICANN
The update from ICANN’s Tina Dam on the IDN ccTLD Fast Track program indicated that they are working to finalise the remaining outstanding issues to facilitate a vote by the ICANN Board at the Seoul ICANN meeting in October 2009.  Should that vote be successful, ICANN Staff are working to have the first batch of IDN ccTLDs live in Q4 of 2009.

This is great news for our international ccTLD clients who are eagerly awaiting the ability to implement their new IDN TLD via the Fast Track process. Many are currently trialling our recently completed IDN Registry Platform in preparation for ‘go-live’.

IDN Variants – CDNC
Lucy Wang gave an interesting presentation on behalf of the CDNC on the issue of Handling of Variants.  In this she argued for the implementation of variants at the root level due to their importance, particularly within the Chinese language community.

This is a topic close to our heart as our international ccTLD clients work through the process of how to best resolve and/or block names in their registries to ensure the easy adoption and clear end user understanding with IDN domain names. We look forward to reviewing ICANN staff’s approach to dealing with this tricky subject.

To review the other presentations from the meeting please visit the APTLD website.