The implementation of DNSSEC has been gaining momentum recently as organisations and vendors implement and make available the systems and tools required to ensure the integrity of the DNS lookup process.
In 2012 the New Zealand Registry Service (NZRS) signed the second level domains under the .nz domain space, at which point New Zealand domains could be signed using DNSSEC. The policy authority for the Australian name space (the auDA) has recently announced that by the end of August 2014 they will have completed the implementation of DNSSEC for the .au namespace, with second level domains, such as .com.au, to follow at a later date.
Now that DNSSEC is available to New Zealand organisations and will soon to be available to those in Australia, should you be implementing DNSSEC? In this article I will explore the use of logical trust domains to help you answer this question.
What is a logical trust domain? The easiest and most simplistic way to think of it is as a zone from which data enters or exits. The relationship between trust domains is defined by the information flows between them. Defining logical trust domains enables you to identify the logical components, the information flows, and who has the ability to influence the security of an information system. Logical trust domains may exist at many levels. At the higher level a trust domain could be an entire organisation, or all public users of a service. However, they can also be more granular. For example, a three-tier web application is a trust domain that contains three sub-trust domains, or more granular still is the interaction between memory, cpu and storage, each of which could be considered a set of sub-trust domains within the information system trust domain.
DNSSEC must be deployed in two parts. First the authoritative DNS servers that host your domain name need to be configured to support DNSSEC. Secondly, the DNS servers that provide lookup (recursive) services to end-users also need to be configured to support DNSSEC.
The following logical trust domains have been identified and defined:
1. Authoritative DNS Services – the trust domain that contains the DNS Name Servers that host the authoritative records for your DNS zones.
2. Web Services – the trust domain that contains the web service supported by your authoritative DNS services.
3. Recursive DNS Services – this trust domain includes all recursive DNS servers (both private and on the Internet) that provide name resolution services to users.
4. Users – this trust domain includes all of the users of your web service regardless of their physical location.
Once the trust domains have been defined, the next step is to identify the information flows between them. The diagram below shows the four logical trust domains that have been identified (plus the organisational super-domain that contains the Authoritative DNS Services and Web Services) and the information flows between them.
This clearly shows that you do not have control of all systems involved in the DNS lookup process that are used by users trying to access your Internet services. This is due in part to the distributed nature of the Internet and the DNS service.
Home users typically use recursive DNS services provided by their ISP or a service provider (e.g. Telecom, Vodafone, Google, Yahoo!). Some DNS service providers provide a web filtering service that effectively perform a man-in-the-middle to return the IP address of a “safe” page rather than the address of the originally requested web site (e.g. OpenDNS, Dyn). These are all third parties who you have no ability to influence or control. In the case of the web filtering service provider, they have no reason to implement DNSSEC as it will likely break their ability to offer their web filtering services.
Google is the most widely used DNS resolution service in the world and supports DNSSEC, but just because a user of your web service is using Google DNS today does not mean they will be tomorrow. Users want their Internet access to work and may switch services for any number of reasons. For example, a recent BGP (network routing) attack took down the Google DNS service in parts of South America (see Ars Technica for details). However, due to the power of social media alternative DNS server IP addresses were quickly communicated and used by users. I am sure that no thought was given to who was actually providing the new DNS servers before they were used. A similar situation will likely occur if the signed DNS responses returned to a user indicate an issue with the DNS record. For example, if the key used to sign the zone has expired. Currently operating systems and applications provide no, or limited feedback, to end users that there is a security issue with a domain name. Even when they do a user may just decide to change their DNS servers to a non-DNSSEC capable server to make things work again.
So what does this mean to you and your deployment of DNSSEC? Unless you have control of the DNS resolvers that the users of your web services are using, and ultimately the end user, implementing DNSSEC could be an expensive exercise that returns minimal benefits in the short term. DNSSEC requires sound key management practices and increased technical skills to support. Where DNSSEC can offer increased assurance is when it is implemented in conjunction with your key business partners with whom you have close relationships and with whom you can work closely to implement DNSSEC capable systems together. DNSSEC can help to secure and ensure the integrity of business-to-business (B2B) transactions when both ends of the DNS lookup process are configured to use it.
For users of your public web services, DNSSEC secured name lookups and responses will not be guaranteed until all DNS servers are configured to use DNSSEC. And as I highlighted earlier, with DNS web filtering services there may be reasons why this is not viable or attractive for a service provider to implement DNSSEC.
Should you implement DNSSEC? Yes, but make sure you fully understand its limitations first.