Key Takeaways
- The Domain Name System (DNS) suffers from vulnerabilities that when exploited can have devastating effects on the affected institutions and their communities.
- DNS Security Extensions (DNSSEC) offers a counter to cache poisoning attacks against websites by creating a chain of trust.
- Louisiana State University tackled the process of implementing DNSSEC and explains some the hurdles it faced.
When the Internet first entered the public arena, proponents painted it as a communications medium that would usher in a new Utopian age of information, connectedness, and understanding. It has indeed met those expectations to varying degrees. Despite these positive results, it has also developed a darker side as an environment for competition and exploitation through hacking. One of the targets for this activity has been the Domain Name System (DNS).
The vulnerabilities of DNS have been known since the dawn of the Internet. While simple to understand, those vulnerabilities can potentially have a tremendous impact due to the central position DNS occupies as one of the core services that make the Internet work. Application servers can be patched, protected, and firewalled, and a successful DNS attack can still take them down. We all know what that can mean to our organizations. A successful DNS attack can result in financial losses for institutions and their communities, disruption of the business of education, and an accompanying impact on an institution's reputation. Imagine the sinking feeling of a university bursar responding to a phone call from a student or parent wanting to find out why scheduled classes were dropped when they had paid tuition and fees — and they have screenshots to prove it. The images they provide to the bursar look plausible, but they do not match the real application screens for the university's fee/bill application.
This short article walks you through our experiences at Louisiana State University as we strive to prevent the above scenario from becoming a reality on our campus. To do that we are using a relatively new counter tactic called DNS Security Extensions (DNSSEC).
DNSSEC: What the Heck Is It?
While DNS software vendors steadily pump out patches and administrators remain vigilant on their security watch, casual consumers of the DNS service have remained oblivious to the severity of DNS threats and to the commotion DNSSEC has caused on message boards across the nation for the past 15 years. Oblivious, that is, until research specialist Dan Kaminsky brought cache poisoning to the attention of many IT professionals outside the immediate DNS circle. Cache poisoning is an exploit of a DNS vulnerability where traffic is redirected from a legitimate website to a different one, usually with malicious intent, by providing false results to name queries (see Figure 1).
Figure 1. DNS Attack
Although somewhat lessened by patches from providers of DNS solutions, cache poisoning attacks have not been entirely thwarted. Such patches address port and transaction ids, the two key items used in a poisoning attack, by increasing their randomness, making it harder for ill-intended scripts to predict those ids. Given enough time, however, and a big enough pipe, a patient hacker can still do serious damage. We needed something extensive to counter these attacks. DNSSEC steps up to that challenge.
DNSSEC is designed to do three things while maintaining backwards compatibility. It needs to prove:
- Origin authenticity, a technical way of saying that we need to verify that the DNS server answering a query has the authority to answer that query.
- Denial of existence, a technical way of saying that when a "No Such Domain" (NXDOMAIN) response is received, we have the means to verify that it does not exist.
- Data integrity, a technical way of saying we need to be able to verify that responses were not modified in-transit.
DNSSEC does all this by creating a chain of trust using the hierarchical nature of the DNS infrastructure already established across the globe. VeriSign provides a more in-depth explanation, which varies depending on the viewer's knowledge of DNSSEC. For anyone specifically interested in .edu and plans that EDUCAUSE has made for implementing the extensions, Becky Granger, director of Information Technology and Member Services, together with host Steve Worona, put together a webinar stressing the importance of adopting the extensions and answering common newcomer questions.
Choreographing DNSSEC Success at LSU
LSU is no stranger to DNSSEC. Several years ago, DNS administrator Antonios Iliopoulos was charged with dissecting the technical aspects of DNSSEC to determine what steps needed to happen in order to create digital signatures for all data in the lsu.edu domain. It quickly became apparent that LSU had hurdles to navigate on a few different levels: global, internal, and campus adoption of DNSSEC. Each level came with its own timeline as well as a unique set of difficulties, some of which are still being dealt with today.
On the global front, our eyes were fixed on the 13 root name servers as we watched anxiously for any progress on signing, which creates digital signatures for all data within the top-most level of domains. Since a chain of trust (see Figure 2) is needed to tie up all the loose ends of DNSSEC, the signing of the root has always attracted much attention. Without this pivotal event taking place, we would be living in a sea of DNSSEC islands. Each university, for example, could sign the data within its own zones without the root servers doing so. The problem with this situation is that DNSSEC relies on a pyramid, or chain, of keys. We needed the level above us, .edu, to accept our keys, and they needed the top level, the root, to accept .edu keys. Now that this previously deemed impossible mission has taken place in a series of steps, dubbed ceremonies, culminating this summer, the tempo of signing zones and publishing keys across the globe is picking up. The Internet Assigned Numbers Authority (IANA) recorded the ceremonies, which can be downloaded from their DNSSEC page.
Figure 2. DNSSEC Chain of Trust
The focus now shifts to our own zone, lsu.edu. Signing and publishing the keys for our domain were actually the last of several steps in the DNSSEC deployment for the Baton Rouge campus. We have been deliberating, debating, and developing plans for several years, all in preparation for the day of signing. Our biggest obstacle was splitting the roles currently held by our campus DNS servers. With the new extensions, one server cannot both validate keys for a query and be the authority for those keys. We therefore had to introduce new DNS resolvers for the campus, point all of campus to these new resolvers, and then split the roles of our existing servers. Since this involved some behavioral changes in host name resolution for the LSU community, we had to address the final level of hurdles — the campus level.
DNSSEC was introduced to the campus through a number of communication channels in the months leading up to signing the zone. We sent out broadcast e-mail and published articles in LSU's GROK knowledge base with detailed information on the new extensions and what to expect. Our campus-wide monthly technical e-mail, LSUITWire, advertised the signing of both the root zone and the lsu.edu zone. A "Tech Talk," a public forum for technical contacts across the departments led by our central IT, may occur to further enlighten our users. Until they see some evidence of its effects through their daily consumption of network-based applications, however, DNSSEC will remain a mysterious thing to much of our community.
Most of the development done in regards to DNSSEC has focused on the server side, with not much on the client side: no alerts, no flags, no golden lock. An add-on for Firefox illustrates DNSSEC validation, much like the familiar SSL certificate icon. Now that DNSSEC is gaining momentum and recognition, we assume that new development will quickly begin to close this gap. Until this happens, however, users will simply get a "Page Not Found" error message when browsing to a site that failed DNSSEC validation. Web browsers are only the tip of the iceberg, though. Any Internet protocol that uses DNS resolution needs to get smarter by recognizing why the resolution failed so that the applications depending on them (e-mail, chat, etc.) can make better decisions and create more useful event logs.
Conclusion
So what's next for DNSSEC? Where is it going? From LSU's perspective, we would very much like to see it grow and succeed through a rapid, yet voluntary, sequence of adoption. It's a pretty solid bet that, whether by regulation or incentive, organizations will feel more pressure from governmental, standards, and industry groups attempting to induce adoption of DNSSEC. As more DNSSEC-aware appliances and applications come online, popular demand may combine with the influence of these groups to make DNSSEC nearly ubiquitous and allow it to deliver its maximum benefit.
In adopting DNSSEC at LSU, we have ignored its imperfections. What other solution has a better chance of success? Despite weaknesses, or the many things it will not protect us from, DNSSEC still provides good protection and, more importantly, a basis upon which to build improved security for the Internet.
© 2010 Allie Hopkins and John Borne. The text of this article is licensed under the Creative Commons Attribution-Share Alike 3.0 license.