Security Experts:

The Need For A DNS Emergency Alert System

Several of the world’s largest ISPs, along with major enterprises, realize the need for a centralized clearing-house capable of alerting the world about major DNS problems

In today’s fast-paced world, alerts are key to avoiding disasters, saving lives and ensuring business continuity. For example, there’s an emergency alert system that broadcasts urgent information like severe weather across the United States. There are Amber Alerts that are disseminated across regions in the U.S. when a child has been abducted using the highway traffic signage systems, radio broadcasts, and tickers on local TV screens. There is a Health Alert Network run by the Centers for Disease Control and Prevention to inform the American public of possible emerging health risks. Many of these alert systems take advantage of widely available infrastructure with a high likelihood of delivery to recipients, where other more “standard” communications channels may fail to deliver timely information to their intended audiences. Such a situation exists with the Domain Name System (DNS) today – a widely distributed system with no central control or direct communications mechanism to all operators for critical events.

DNS Alert System

So why not create an emergency alert system for the DNS that takes advantage of a better, more timely communications infrastructure? The goal would be to provide a system where alerts go out to Internet Service Providers worldwide that provide DNS resolution services to their users whenever a critical domain name or DNS server has been hijacked. You might think this sounds a little over-the-top, but actually, DNS attacks can be devastating. Worse yet, with DNS caching, even long after an incident has been mitigated, ISPs around the world will still report the wrong DNS information to their users, continuing their exposures.

Devastating DNS Attacks

When cyber criminals hijack various organizations’ DNS, commercial and government operations run the risk of coming to a screeching halt, and millions of Internet users could have their personal information stolen. That’s because the DNS acts as the address book for the Internet and when a DNS configuration is hijacked, the perpetrators have the keys to an organization’s information and/or direct access to the people and transaction systems that do business with the hijacked organization.

For instance if attackers re-route the DNS that points to the servers that keep time on the ‘Net, it could severely derail billions of financial transactions that rely on accurate time stamps. When electronic bill pay company CheckFree (a subsidiary of Fiserv) had its domains hijacked in December 2008, millions of users were exposed to malicious software via their banks' online bill-pay systems. Large numbers of banks, utilities and credit unions around the country had to shut down their on-line bill-pay services for days to protect customers. In this instance, cyber criminals redirected the DNS to a server in the Ukraine that attempted to download malware onto visitors’ PCs. The hackers could have used the installed malware not just to access CheckFree users’ vital data, but also to swindle information from hundreds of CheckFree’s transaction partners.

CheckFree isn’t the only organization to recently have its DNS hijacked – similar attacks also happened to China’s largest search engine Baidu, Internet Service Provider and cable giant Comcast, large social networking site Twitter, the international oversight body for domain names ICANN, and the list goes on and on. These hijackings potentially cost the companies and their partners millions of dollars, and eroded the trust their customers and users have in them.

Mechanics of a DNS Attack

When a DNS hijacking occurs, cyber criminals redirect a domain to a fraudulent Internet host that they control. All traffic, e-mail, website visits, transactions, etc., that were supposed to be sent to the original server are collected by the criminals. By hijacking an enterprise’s DNS, hackers can potentially gain access to data and communications shared between an organization and its partners or customers: vital data like financial and customer information, passwords, emails and instant messages, proprietary documents and more. And, these attacks affect more than just domains on the Web – they can impact all traffic and transactions throughout an entire extended enterprise, like those of transaction providers, Internet Service Providers, email hosts and more. 

If a DNS server is hacked or domain taken over, the distributed nature of the DNS system helps the false entries spread like a virus. The very nature of Time To Live (or TTL) caching settings – meant to make the Internet more stable – mean that corrections can often take more than 48 hours to resolve. Unfortunately, there is no standard method or “kill switch” to have all ISPs and enterprises “flush” this poisoned data from their DNS server caches. So it typically lives on for hours or days.

For example, although CheckFree was able to regain control of its domains within about eight hours, the nature of DNS meant that the malicious server was still having traffic directed to it for up to 48 hours after CheckFree regained control of its domains. That meant CheckFree’s falsely redirected domain entry lived within some ISPs for up to 56 hours!

Conversely, quickly alerting ISPs worldwide of issues and errors, and remediating them, can chop the propagation off at the root (before bad data can spread to long lived caches) or quickly resolve them.

The Buck Stops at the ISPs

With time of the essence and the stakes extremely high, there is a need for a centralized system that would alert organizations, their extended enterprise partners, and most importantly ISPs, about these types of issues and threats.

Several of the world’s largest ISPs, along with major enterprises, realize this need for a centralized clearing-house capable of alerting the world about major DNS problems – more specifically a DNS Emergency Alert System. By stopping the spread of a bad DNS entry, and enabling the timely flushing away of bad entries, a DNS Emergency Alert System could stop these crimes by getting to the root of a problem and preventing or stripping the caching of that bad information.

A DNS Emergency Alert System could use a variety of alerting mechanisms to get the word out in the most efficient, expeditious and widespread fashion possible. Since ISPs are the first line of defense, and those that could immediately stop the spread of bad DNS information, they would be among the first ones alerted. Therefore, all key ISPs must have a list of primary contacts and/or an internal system that would receive an instant alert. This could be accomplished in a variety of ways – via email, RSS feed, posted to an alert website, text message, etc. One proposal is to use a DNS-based system in itself as the dissemination mechanism, with special servers set up to provide resolution of affected hosts/domains/etc. Members of the alert system could simply check the broadcast network servers for any entries and use them as keys to flush their caches or even as overlays of their own cached entries.

By immediately alerting an ISP to clear out its cache for an affected DNS entry, bad data would stop being sent out to its customers quickly. The ISP would then resolve to the old or corrected DNS and the bad DNS would cease to exist for that segment of the Internet. Enterprises, governments, and other organizations that provide DNS resolution services to their users can take similar steps to update their own cached DNS data.

Trust is the Key

Creating an alert system in and of itself is relatively straightforward, but will anyone use it? They will if they can trust the data provided is timely, accurate, and vetted. Without these trust factors, system adoption will not get off the ground, as the very nature of the system is tied to properly resolving DNS for targeted organizations, and those are likely to be high-value targets. Looking at other alert systems in the real world, we see that the infrastructure used to provide them is typically closely controlled or regulated, and that governments or vetted organizations are the only parties that can create new alerts. This creates a highly trusted alerting system.

What can we take from these real-world examples? First, the delivery mechanism needs to be trusted. In the online world, that translates into something that can be authenticated, and not easily intercepted by outsiders. The second big factor is the knowledge that the people creating entries in the alert system are trusted, vetted, and ultimately made responsible for the content of their alerts. It wouldn’t be acceptable if the system was wide-open, allowing a hijacker to put out fake alerts in conjunction with his take-over attempts, and thus accelerating the damage done.

There are many ways to secure the alert system to ensure authenticity and integrity of the messages from sender to receiver. However, this has often proven to be problematic in the messaging space, as e-mail, for instance, is trivially spoofed. So signed/authenticated communications, or a two-step process may be needed. For example, an e-mail alert could go out that there’s a new DNS incident, and subscribers to the system would know to check the secure messaging platform (say a password-protected, SSL-based website) for the alert details. If a messaging platform like RSS or DNS were to be used, then signed messaging would be a must. Whatever the chosen methodology though, there are existing solutions to the problems with secured messages, they just have to be built into the system from the outset.

If the platform is secure, how do we handle who gets to access and use it? This is especially challenging given that the actual victims of DNS hijackings are usually enterprises like banks or e-commerce sites, and not ISPs or DNS providers themselves. The good news is that such companies have ISPs, DNS providers, and security companies that they work with on a regular basis. These are exactly the kind of companies that can be vetted in a manageable system, plus be trusted to know what they’re doing when crafting alerts. Organizations like DNS-OARC, ICANN, MAAWG, and others could be enlisted to help in crafting the vetting process, as their members represent these types of organizations.

One final consideration here is open access. The Internet was built largely on open standards and interoperability for all players. This is especially true for the DNS system. Any emergency alert system needs to provide open access to both victims of hijackings (alert senders) and organizations that run DNS resolvers (alert receivers). A closed or proprietary system that effectively locks out major victims or ISPs and enterprises running resolvers is not likely to win wide adoption. Indeed, there have been some attempts by some in the DNS services space to set-up some of the aspects of the alert system I’ve described, yet adoption remains low, likely due to “closed club” aspects of these efforts. Vetting and a sustainable funding model are of course important considerations for building any such alerting system, but there needs to be a way for nearly anyone whose DNS is attacked or that runs DNS resolvers for a community of users, large or small, to participate in order for this kind of proposal to work.

Making it all Come Together

With a system in place, the process is fairly simple. When an organization or their monitoring service spots a hijacking, they can verify it and issue an alert via their vetted submitter. This can be their ISP, DNS provider, security vendor, government organization, etc. That alert would contain the affected DNS entry plus any correction information. During the hijacking, that information would consist of the real IP address, for instance, of a host or the proper nameservers for a domain. Once the hijacking was overcome, the message sent out would be a simple cache-flush request for the previously affected entity. This request would tell the organizations running DNS resolvers simply to flush their values for the affected entries, and reload them from the authoritative source.

The Time is Now

With so many corporations and organizations being targeted with attacks on their DNS, action must be taken before these attacks become more regular, more widespread and wreak more havoc across the Internet. Consider recent DNS attacks directed at the likes of Twitter, Comcast and more as shots across our industry’s bow by cyber pirates wanting to exploit the Internet’s very infrastructure to commit crimes. Attacks like this could well destroy many users’ confidence in the Internet. An emergency alert system should be implemented now before this trust continues to erode and we see reversals in adoption of e-commerce, on-line banking, government service delivery, and the social interactions the Internet has uniquely created for us within the last few years.

< Be Informed. Subscribe to the SecurityWeek Email Briefing Here >

view counter
Rod Rasmussen co-founded Internet Identity and serves as its lead technology development executive. He is widely recognized as a leading expert on the abuse of the domain name system. Rasmussen is co-chair of the Anti-Phishing Working Group’s Internet Policy Committee and serves as the APWG’s Industry Liaison, representing and speaking on behalf of the organization at events around the world and works closely with ICANN. He also is a member of the Online Trust Alliance’s (OTA) Steering Committee and an active member of the Digital PhishNet and is an active participant in the Messaging Anti-Abuse Working Group. Rasmussen earned an MBA from the Haas School of Business at UC-Berkeley and holds two bachelor’s degrees, in Economics and Computer Science, from the University of Rochester.