It was a shocking discovery that had security experts around the world concerned. In 2008, security researcher Dan Kaminsky exposed a serious flaw in the Domain Name System (DNS) that allowed cyber criminals to easily impersonate websites, intercept email, or steal passwords to hack into corporate networks via DNS cache poisoning attacks. In a cache poisoning attack, a miscreant fools an ISPs or enterprise’s resolving or “caching” nameserver into thinking the actual address for a targeted domain is something else and storing it. People and servers using the poisoned DNS server will be misdirected to a different address for web browsing, email sending, messaging, transactions or whatever else they are trying to do.
These new exploits were the tipping point in facing once and for all the security inadequacies of DNS, the address book for the Internet, which had been known for years. Even before Kaminsky publicly announced the flaw, DNS software providers successfully launched a secret effort with him to plug the hole he had found. However, subsequent research showed that even the new fixes were insufficient, so a more permanent solution was needed. As a result, industry leaders and professionals have rallied behind a technology called DNS Security Extensions (or DNSSEC), to fully solve this type of Internet hijacking vulnerability via DNS.
DNSSEC has been around for years – long before Kaminsky’s revelation, but unfortunately its deployment had been languishing due to the lack of an immediate threat. Kaminsky’s discovery changed that. DNSSEC is meant to prevent DNS cache poisoning attacks by allowing domain names and corresponding IP addresses to be verified using digital signatures and public-key encryption. This system extends from the very root of the DNS all the way out to individual hostnames, allowing Internet users to verify the authenticity of DNS responses from their ISPs or enterprise resolving nameservers.
Kaminsky’s finding in 2008 spurred the U.S. government to mandate deployment of DNSSEC in the .gov space, and second-tier domain managers within that space were instructed to begin digitally signing DNS records. ICANN has also kicked into high gear, and is within weeks of fully signing the “root” DNS records, which is required for the entire system to work.
Unfortunately, attackers have been exploiting this flaw in the DNS while DNSSEC implementation work continues. A January 2010 report prepared by the Center for Strategic and International Studies (CSIS) found that 57 percent of 600 IT and security executives, in enterprises that own and/or operate critical infrastructure in 14 countries across the world, experienced DNS poisoning attacks or other critical Internet infrastructure attacks. Most of those attacks were repeated on a monthly basis. Furthermore, according to the IT and security professionals questioned in the report, the cost of downtime incurred from these network infrastructure attacks on their organizations was estimated at more than six million dollars a day.
One prominent DNS cache poisoning attack in April 2009 saw fraudsters impersonate a large Brazilian bank with a fake website. The attackers managed to poison the DNS entries at one of the largest Brazilian ISPs to present the fake website to bank customers and intercept their logins.
Under the Hood of DNS Cache Poisoning
DNS cache poisoning is the key exploit that spurred the call for mass adoption of DNSSEC. So, how does it work? With DNS cache poisoning, an attacker attempts to insert a fake address record for an Internet domain or hostname into a caching DNS server of an ISP or enterprise. They can do this by flooding DNS resolvers with fake requests and concurrently supplying bogus answers. If they hit on the right combination before the real DNS server for a domain answer, their entry will be accepted as being real. If the server accepts the fake record, the cache is poisoned and subsequent requests for the address of the domain are answered with the address of a server controlled by the attacker. For as long as the fake entry is cached by the server (entries typically have a time to live, or TTL, of up to 48 hours) subscribers’ browsers, transaction servers, or email servers will automatically go to the address provided by the compromised DNS server – usually without knowing it.
Is DNSSEC the “Silver Bullet” for DNS attacks? Two years after Kaminsky’s revelation, questions remain as to the effectiveness of DNSSEC as a full solution for DNS security. Will DNSSEC be deployed to a sufficient level to effectively thwart the use of cache poisoning attacks? What can be done about DNS hijacking of the authoritative side of DNS – an area that DNSSEC doesn’t address? Answers to these questions point to a need for further solutions to provide more layers of security around the DNS.
DNSSEC – A Chain That is Only as Strong as its Weakest Link
By the very nature of DNS, the directory assistance that translates human friendly domain and host names (like www.securityweek.com) into IP addresses, DNSSEC must be deployed in a hierarchical fashion. Only in that way can chains of trust for obtaining keys and verifying digital signatures be created for individual users and applications. Use of DNSSEC requires wide-scale deployment throughout the online environment starting with the Internet “root” servers, and extending to the individual top-level domain name registries before individual domain holders can even think about using it. Further, domain name registrars and DNS providers must provide ways to provision DNSSEC records. Finally, application developers like browsers, email servers, and anything that communicates via DNS must be retrofitted to enable checking of DNSSEC records to authenticate DNS entries. In order for end users to benefit from DNSSEC, the standard MUST be supported at every level of the DNS hierarchy.
The root is about to be signed, and most domain registries have announced plans for deploying DNSSEC if they haven’t already done so. However, most of the top domain name registrars have not committed to a firm deadline for deploying DNSSEC for their customers. One reason they are slow to commit to DNSSEC is economics. With domain names selling for a few dollars per year, and the extraordinary variety of uses for domains that don’t include e-commerce or sensitive communications, there’s little incentive for registrars to absorb the costs required to add an extra layer of security and the administrative overhead that DNSSEC support will entail.
Another missing piece to DNSSEC is that there are few end-user applications that make direct use of it – most are relying on resolving servers to simply return errors if validation fails. That strategy may well lead to user confusion, as they won’t know why they can’t get to their favorite website, or where their missing email has gone off to in case of problems.
For instance, no mainstream production web browser checks for DNSSEC signatures and warns end-users of problems, though there is an add-on for Mozilla’s Firefox that does. Therefore, the end user has no way of knowing whether or not a DNS response is authentic – they simply have to operate on trust. If their Internet Service Provider sets up their resolver to error out, then the user won’t be able to access websites or services on an affected domain, but probably won’t know why, and will likely call the company, or their ISP in order to “get the Internet fixed.”
These applications are being worked on, but even when available, adoption time is likely to be lengthy, as with most software deployments. Further, if there are implementation problems along the way, causing user confusion or access problems, some institutions may delay or abandon deployment if it causes more harm than good.
Bottom line: until DNSSEC is end-to-end, it will not work as truly intended. If there’s just one break in the chain, that one missing link is enough for DNSSEC to be essentially useless if not paired with further security layers. Getting everyone on the Internet to agree to one security protocol at the same exact time isn’t realistic. But, there is a way to help ensure this technology is relevant in the Internet security debate.
The Missing Links Beyond DNSSEC
Even if DNSSEC were deployed broadly, it still would not absolutely ensure that DNS for a domain could not be misdirected. That is because DNSSEC does nothing to ensure that the listed authoritative name server for a domain name is one that is legitimately controlled by the owner of the domain name. However, DNSSEC does a great job of ensuring that answers provided by the authoritative name server is accurate, no matter what 
they are. In other words, if DNS for a domain is hijacked at an authoritative server or the sponsoring registrar, the illegitimate DNS entries would still appear to be authenticated with DNSSEC, even though they are fakes. DNSSEC thus can give a false sense of security when things have gone badly wrong.
Take the recent hijacking of CheckFree in December 2008 for example. With CheckFree, the nation’s largest e-bill payment system, hackers were able to hijack the company’s websites, email, and transactions simply by stealing the user name and password needed to make account changes at CheckFree’s domain registrar. Someone then logged in unchallenged using these credentials and changed the address of CheckFree’s authoritative DNS servers and used the new nameservers to point site visitors to an Internet address loaded with malicious software or malware on a server in the Ukraine. Because the hijacking took place at the registrar itself, which controls the authoritative DNS for domains, DNSSEC would not have been able to stop end users from being exposed to malware.
Attacks like this have been on the rise, with high-profile DNS takeovers of Twitter, Baidu.com (the Chinese equivalent to Google), Comcast, Coca-Cola, and even ICANN itself. These attacks are far more devastating than a cache poisoning attack, as the entire Internet is affected rather than just users of a single ISP or enterprise. DNSSEC is simply not designed to prevent or mitigate these kinds of attacks.
DNSSEC and Proactive DNS Monitoring – Better Together
To be assured that a domain’s DNS information has not been tampered with, you need to be certain of two things. First, you need to know that the domain’s authoritative DNS server has not been hijacked. Second, you need to know that the cached DNS data you are relying on has not been tampered with en route to you. DNSSEC will handle the latter when it’s implemented, while a solution that actively verifies a domain’s DNS at all authoritative sources is needed for the first part. This verification solution could be extended to help cover the current gap in protection against cache poisoning that DNSSEC will address, simply by verifying the responses of caching servers at ISPs and enterprises of interest. Regardless of the technology used, implementing this two-layer approach is essential to being able to rely on DNS as a trustworthy data source.
There are many ways to implement a verification solution, from homegrown monitoring scripts to fully outsourced services. The key is making sure there is a response ready to roll immediately if and when an anomaly is detected. Another consideration is the scope of entries you want to protect – just your own primary domain(s), or also your key partners and services you are directly connected to, send sensitive information to, or engage in automated Internet-based transactions with.
In the CheckFree instance introduced above, a solution that was actively monitoring CheckFree would have instantly noticed that CheckFree’s DNS had been moved and its primary hosts all pointed to a server in the Ukraine. If deployed then, DNSSEC would have still identified the DNS as authentic, but the verification system would have alerted CheckFree that someone had redirected their domains maliciously.
CheckFree also has thousands of transaction partners who should have probably been watching the CheckFree DNS system since their own websites were directly tied to it. Most of these partners had their customers exposed to the malware that CheckFree’s DNS directed visitors to, creating all sorts of problems for them. If these partners had an active verification solution, they would have been immediately alerted, and could have instituted countermeasures. By taking three simple steps – instantly detecting, diagnosing and then remediating – DNS attacks like CheckFree’s can be stopped at their root.
Conversely, if the CheckFree DNS had been changed in transit or at ISP caching servers, the bad DNS entries would have spread only to DNS caches at targeted ISPs. If DNSSEC were in use at every level (starting with domain registrars and ISPs), there would be no way to change the DNS in this manner without being noticed immediately, and therefore there would be no effective DNS cache poisoning. However, in today’s world without DNSSEC, a verification and remediation solution is necessary to spot poisoned ISPs and alert them to the problem. While a verify-and-remediate solution can blunt the impact of a cache poisoning attack and is therefore valuable, DNSSEC could render such attacks meaningless.
By using authentication via DNSSEC and continuous verification to ensure valid authoritative DNS entries, you can ensure a highly trustworthy DNS data source. One hundred percent trustworthiness is likely impossible, since a malicious insider or clever hacker can still corrupt information being published by a legitimate authoritative name server. There will always be a window during which that information will be published before even the fastest verification and reaction force can discover and remediate it. However, that’s a far better solution than having to shut down Internet-based services for hours or even days due to a successful DNS infrastructure attack, something that has happened many times, and continues to occur today.
DNSSEC is in the earliest stages of adoption and is not, and may never be, deployed widely enough to fully deliver its promised benefits. To fill this gap, a service that provides detection, diagnosing and remediation of a DNS breakdown is essential. While the upside to DNSSEC far outweighs its downside, there is too much missing to call the technology the “silver bullet” to solving DNS attacks.
Related Column By Rod Rasmussen: Using DNS Across the Extended Enterprise: It’s Risky Business
Rod Rasmussen is the president and chief technology officer for Internet Identity (IID), a provider of technology and services that secure the Internet presence for an organization and its extended enterprise.
