Advantages and Disadvantages of DNSSEC – Should your organization implement DNSSEC yet or Not? Second in a Three-Part Series on DNSSEC Deployment (Read Part One Here)
To begin DNSSEC implementation or not: that is the question facing a host of enterprises, notably any that engage in e-commerce or online financial transactions (online retailers, banks, investment firms, hospitality and travel, etc.). These businesses find themselves in a catch 22; there are obvious security benefits to adopting Domain Name System Security Extensions or DNSSEC, but there are some severe downsides to being too early in the adoption curve – downsides that are becoming more and more apparent every day.
DNSSEC will help protect the Domain Name System (DNS, which is the address book of the Internet) from cache poisoning exploits. These attacks can allow malicious entities to intercept an Internet users’ request to access a website, send e-mail, or transact with a domain, and redirect or eavesdrop on the user without their knowledge. And with no ability to reassert control, organizations run the risk of losing millions of dollars in lost reputation, stolen transactions, recovery costs and more. DNSSEC introduces digital signatures to the DNS infrastructure and is supposed to automatically ensure that users are not hijacked en-route and taken to an unintended destination.
DNSSEC has gotten a big boost recently from some prominent figures. In fact, in July 2010 U.S. Department of Commerce Secretary Gary Locke announced that the Commerce Department is one step closer to making “significant progress in helping the Internet become more robust and secure” by deploying DNSSEC at the root of the Domain Name System. “This action will essentially give a ‘tamper proof seal’ to the address book of the Internet—a seal that gives Internet users confidence in their online experience,” he said.
While DNSSEC is getting rave reviews for successful deployment at the foundation levels of the DNS, problems are lurking just ahead, since very few widely utilized end-user applications are able to actually utilize DNSSEC at all. Simply put, DNSSEC can only work if it is supported throughout the hierarchy from publisher to visitor, and it’s the application layer that we’ll take a close look at in this, the second of our three-part series on DNSSEC deployment.
DNSSEC In the Wild
It is those pesky applications that people or automated transactions actually use and interact with where DNSSEC will thrive or fail. These include browsers, e-mail and chat clients, transaction processes, authentication/login tools, and all the backend systems that support those applications. It is at this layer that the final authenticated online connection will occur. Or not. It all comes down to a single bit.
That bit, the AD (authenticated data) bit, is a simple binary on/off indication that DNSSEC verification has happened. It does not carry any information about the connection, such as why a failure occurred; just that DNSSEC verification happened or failed.
An application that is verifying DNS data using DNSSEC must request that the resolver it is using provides the AD bit as an answer along with the DNS resolution data it receives. The resolver then passes that data along to the application when it receives an answer. If an application does not make that request (as a vast majority of applications are configured today) then a resolver using strict DNSSEC checking, by default, will “protect” the user from DNSSEC failing responses by telling a “little white lie” to the application. And there lies the problem – the application and thus the user, will be told the domain name configuration is broken. Unfortunately, there is no way for users to know any better, so the assumption will be that something is badly wrong. Functionally, that is probably okay, if the problem was actually a malicious cache poisoning.
However, most of the authentication errors we see today are caused by simple mistakes or configuration errors you would expect with the rather complex management challenge that publishing DNSSEC records entails.
Unlike today’s DNS configuration errors, which are usually easy to spot, DNSSEC errors are often far harder to spot, and can involve arcane interactions between incompatible methods used by publishing and resolving nameservers. This makes DNSSEC implementation a much higher risk proposition than the “good old reliable” DNS we’re accustomed to today.
The good (and bad) news right now, if a failure occurs… nothing much happens, as applications by and large do not support DNSSEC. Even more importantly, ISPs (Internet Service Providers) and enterprises aren’t enforcing strict resolution of DNSSEC in their DNS resolvers, so failures aren’t even being seen, much less reported. The person or machine trying to access your system is not blocked from access and typically just connects to whatever standard DNS says is the answer anyway – even if that is a spoofed address. So functionally, not much is being done yet with the DNSSEC technology.
However, that is all changing as ISPs and other infrastructure players begin to adopt, support and implement DNSSEC resolution verification. For example, Comcast has started rolling out DNSSEC validation for a large subset of its user base this month. As they do, something very different will happen at the DNS resolver given current application software versions that are DNSSEC unaware: a DNSSEC failure will be communicated through the network and interpreted by the ISP’s recursive DNS servers as a general DNS failure. In other words, the DNS will not resolve, and to the end-user or process, it will seem as though the domain is down or did not exist at all. The online connection simply will not be made.
How will inevitable failures without notification affect the end user trying to access, say, the website of a retailer or bank? They will behave in exactly the same way as if the entire site was down:
1. “The site is down, so maybe I’ll try again later.”
2. “The site is down, so I’ll call their tech support line and let them know.”
3. “The site is down, so this organization must be incompetent and I’ll take my business elsewhere.”
Note that, while none of these reactions are good, they get progressively worse from the business’s perspective. The reaction of the management of a company that experiences a DNSSEC key roll-over problem, or other esoteric DNSSEC failure that causes a large drop-off in visitors is eminently predictable – “rip that junk out of there.”
But that is just the tip of the iceberg, as DNS and DNSSEC impacts most every application that connects via the Internet, including enterprise backend systems. Take the example of a major financial institution conducting large, complicated transactions online. If that organization has a DNSSEC failure, the resolver on the other end of that transaction will say “nope, not valid” and block the connection. That could mean multi-million dollar transactions suddenly stop occurring, even if, as we have seen in the first article in this series, the DNSSEC failure was due to a simple error. DNSSEC probably will not get a “second chance” in that kind of scenario.
Application Apathy
What should happen instead? DNSSEC is a warning to the resolver that something suspicious is occurring. And it should be communicated as just that: a warning. “The DNS of the site you are connecting to cannot be verified, are you sure you want to connect?” We see this type of warning all the time with expired security certificates. The browser or other application does not just throw up its hands and fail, it warns the user about the occurrence and lets them choose whether to proceed. Some of the few open-source applications that have had contributors build DNSSEC aware add-ons for act in this manner already.
Yet from the application vendor’s perspective, this is a development cost with no clearly attached benefit. There is not a lot of demonstrated demand for DNSSEC-aware applications, so why commit development resources? Further, ISPs in general are not providing DNSSEC aware resolvers yet, so what’s the rush to spend the development effort today?
ISP Conundrum
Speaking of ISPs, we have another major chicken and egg problem. Ideally, you would like to pass DNSSEC authentication data (especially failures) along to the user so they can deal with the results. However, without DNSSEC aware applications, you are forced to “lie” to your customers and provide a completely failing answer for DNSSEC authentication problems, and that lie looks like the domain isn’t there. That will inevitably create a lot of customer-service inquiries, as people will assume their ISP has a problem or the “Internet is broken”. That creates real costs for little perceived benefit to the ISP, so the natural reaction may be to wait for most applications to become DNSSEC aware so they don’t have to bear those costs.
What about the OS?
One proposed solution to some of these issues with DNSSEC validation is to enable DNSSEC validation in the operating system. This certainly could help, but applications will still have to look to information provided by the OS in order to pass along useful information to the user, so embedding in the OS doesn’t really solve problems, it just shifts them. That said, putting DNSSEC validation into standard OS calls may make it easier for applications providers to build DNSSEC aware software, providing a potential win here, just not a full solution. So who stands the most to gain from end-to-end DNSSEC validation? The institutions who are being spoofed, which is where the enterprise community comes in.
Enterprise Demand
It is that e-commerce or online financial enterprise we identified earlier who stands to most greatly benefit from the security protections of DNSSEC – or most directly harmed by haphazard implementation. And as such, it is precisely these organizations that should be screaming loudest about application support. Fortunately, it is also these large enterprise organizations that have the outsized pull necessary to get software vendors moving quickly.
And quick movement is necessary, as 2011 will be the beginning of broad DNSSEC deployment with the signing of the .com zone. Enterprises and other organizations must begin advocating for correspondingly broad application support; both with the vendors they interface with directly, and through industry organizations and in the pages of publications just like this one. The open source community is already churning out several DNSSEC aware applications and this can be used as an example to spur on the major application vendors.
In the meantime, any enterprise should be cautious about DNSSEC implementation before application support is in place. We can make three recommendations here:
First, if you are going to implement DNSSEC, you want to be very direct about the implementation with the extended enterprise partners that connect to you – and their role in it. These organizations should not only be verifying DNSSEC, they should also have a notification process in place to inform you of failure (and vice-versa). It is almost certain that you will need help here with identifying the partners, communicating to them about the implementation, and establishing and maintaining notification procedures. Fortunately, there are various consulting and service organizations that can help.
Second, you should ensure that there is a feedback loop and clear procedure internally regarding a failure notification. What happens? Who do you alert internally and externally?
And finally, you should make sure you have a stringent traffic monitoring and logging process in place before even considering DNSSEC. As we have seen, the challenge with implementation is that when you publish your new or updated key signature, you often do not know whether there is a problem until after the fact. If applications just fail with a “no such site” error, the only way you may find out is if people start calling, which can be a slow, reactive process with a substantial negative impact. The preferred strategy is to be proactively monitoring traffic and various resolvers, with an automated alert if there is a sudden and substantial drop in traffic volumes or large numbers of errors detected.
Bottom Line
The takeaway for the enterprise and the industry is that a hard fail at the application layer just does not work. If that is all there is, then few organizations will risk their business by implementing DNSSEC, and as a result the technology will suffer a slow death. Those parties that are most interested in, and stand to best benefit from, DNSSEC deployment should be pushing hard for graceful application support. Let’s make sure every application is AD bit-aware.
In the meantime, organizations looking to move ahead need to carefully weigh the risk, reward and strategy around DNSSEC deployment. But that’s a topic for our next article.
Related Reading: Do Recent BGP Anomalies Shed a Light on What’s to Come?
Related Reading: Trouble Ahead – The Implementation Challenges for DNSSEC
Related Reading: Deploying DNSSEC – Four Ways to Prepare Your Enterprise for DNSSEC
Related Reading: Five Strategies for Flawless DNSSEC Key Management and Rollover
Related Reading: The Missing Ingredients for DNSSEC Success
