DNS Security Extensions, DNSSEC, are a set of improvements to the DNS protocol to secure the transfer of its data. The extensions emerged from a threat analysis performed in the early 1990’s, developed under a US DARPA contract and began to be deployed originally via a US DISA contract that resulted in the release of BIND 9 in 2000. Fostering support for adoption of the extensions has been difficult and there have been several false starts. In the summer of 2008, however, a researcher demonstrated the severity of the threat, DNSSEC interest was renewed.
Although DNS is thought to be a client-server protocol, it really is a client-cache-server protocol, most data transiting at least one third party (a cache) along the way from server to client. The caches are vulnerable to “cache poisoning,” that is, accepting falsified responses. An unsuspecting visitor to the Internet may ask for certain website and land on another, a result of cache poisoning. DNSSEC is designed to address the issue of cache poisoning.
What is DNSSEC?
In a nutshell, DNSSEC makes it all but impossible to forge a reply to a query before the real query arrives. This is achieved by increasing the number of unpredictable bits. Initially it was thought that the message ID (16 bits) would be sufficient, then the source UDP port (16 more bits), and then altering the capitalization in the query name (1 bit per letter in a domain name). However, once the research by Dan Kaminsky was published in 2008, the number of bits that had to be unpredictable grew to the point that only a digital signature was sufficient, hence DNSSEC.
DNSSEC relies on the need for digital signature technology (a key) to create and carry a means to detect poisoning attempts. Key creation and maintaining a database of keys for verification is referred to as key management; key management is one of the most important components of a DNSSEC implementation.
Key management is fairly complex and requires a new set of management expertise as well as ongoing administrative support to keep the digital signatures and keys current.
Does one acronym Solve Internet Security Issues?
It’s important to note that DNSSEC is a solution for one piece of the big Internet security puzzle. DNSSEC is an important component to secure DNS, but it must be employed in conjunction with defenses against denial of service attacks and other cyber attacks intended to take websites, servers and applications away from their intended use. Beyond securing DNS, other tools and practices are needed to defend against application attacks such as phishing.
Challenges with Deploying DNSSEC?
Along with the benefits of DNSSEC, there are some significant challenges.
False sense of security
Deploying DNSSEC doesn’t mean that immediately all of your users or end users will be secure. DNSSEC is like anything else in DNS, it depends upon the entire chain of DNS transactions supporting and delivering the response. A DNS response that has data signed with DNSSEC means only that the response has traveled the Internet intact but does not guarantee the data was entered correctly.
DNSSEC adds bytes to all of the responses that are sent through the Internet. These extra bytes have been observed to cause problems for existing security devices. Firewalls have been an integral part of network security for many years, and many have assumed that DNS messages would never exceed a given size (512 bytes). Other elements of the Internet have also assumed that the underlying protocol (UDP) would be able to hold an entire message in one datagram, never anticipating the need to fragment large responses over a few datagrams. Firewall rules and the failure to handle message fragments are a concern as DNSSEC is deployed, concerns that may not be removed until hardware refreshes are triggered.
There are many estimates of how much increased processing power will be required with DNSSEC. Most estimates come in around the 40% mark, a DNSSEC signed query takes 40% more processing power than a regular DNS query. DNS records are 5-9 times larger when they are signed. That’s another challenge for DNS infrastructures, being able to keep up with the processing power required to support DNSSEC.
With the increase in processing capacity, the DNS infrastructure now needs to be managed and monitored more closely than many organizations have managed it in the past. As organizations roll out DNSSEC it will be critical that they be able to evaluate thresholds to ensure they don’t lose connectivity due to an infrastructure overload.
Infrastructure aside, easily the biggest impact of DNSSEC is the challenge of manually configuring and signing records, generating keys, maintaining and rolling over keys and all related tasks. It will require a highly skilled IT staff and resources to maintain this effort.
The Scariest Part
A misstep in the management of DNSSEC results in Internet users being unable to reach the protected network. DNSSEC is a “safe/unsafe” protector. It is vital to network operations to maintain and manage DNSSEC properly
History of DNSSEC
Development and Deployment
DNSSEC has always been a product of the open standards world. The problem statement came from researchers with a keen eye for vulnerabilities. The work done to develop and then deploy has been public, without a centralized point of organization or authority. This is perhaps the reason it has seemingly taken so long to develop and deploy DNSSEC. This level of security has always been seen as necessary, yet the true pain and threat didn’t materialize until 2008. DNSSEC is complicated to protect the Internet, yet it was designed as closely as possible to the original system.
Stagnation and Breakthrough
It has been said that DNSSEC and DNS security was like “bringing a tank to shoot a fly.” DNSSEC is indeed like a well developed tank, heavy equipment that is very powerful in defense. For many years that was a pretty accurate assessment. As long as cache poisoning was just a fly, instead of tanks, fly-swatter defenses were sufficient. But in 2008, the research by Dan Kaminsky made the fly into something more formidable.
Cache poisoning was enabled by forging a response in a small amount of time. The research showed that a forger could prepare forgeries ahead of time and then provoke the cache to ask questions that would enable the forger to insert a different response. Kaminsky essentially showed that in the race to submit a forgery, if the attacker had the tools and knowledge, a certain number of attempts would produce a forged response.
DNSSEC began to be adopted in some niches a few years ago (Sweden first signed their zone in 2005). The real catalyst for adoption came with the results of Dan Kaminsky’s research, since that time, adoption of the technology has gained momentum.
The earliest proponent of DNSSEC is the US government. After funding the basic research and providing seed money for deployment, the US government actively promoted technology in a number of ways. Once they turned to mandating DNSSEC within government operations as part of FISMA, financial interest grew because now there was demand by agencies to purchase DNSSEC tools, training and operations.
Clearly all organizations that have significant online transactions are at risk for cache poisoning attacks. While we suspect it will take approximately ten years to deploy DNSSEC wide-spread, organizations will adopt it over time. Financial organizations and online retailers are some of the first expected to deploy the technology to minimize risk and are already evaluating infrastructure and capabilities to support DNSSEC. Even if the entire DNS chain to their customers is not signed, if an organization is targeted for cache poisoning, by deploying DNSSEC, they will have taken all steps under their control to combat this problem.
DNSSEC Progress in the DNS tree
There are many different components to DNS, and each needs to support DNSSEC for queries to be secure end-to-end. The components are: end-user physical connectivity to the Internet, recursive services, Root Servers, Top Level Domain (TLD) servers and Authoritative Servers. Each one of these components serves a purpose in the DNS chain and each must support DNSSEC technology for the key to remain intact.
This is probably the biggest wild card in the DNSSEC equation. ISPs that serve the majority of end-users in the world have a large task in front of them, replacing old DSL and other connections that may not support DNSSEC. Some replacements have already been made, but it will take a significant amount of time. Businesses and technologically advanced ISPs are already making strides in this direction.
As of May 5, 2010, all of the root DNS servers for the global public Internet (commonly called “the roots”) have been serving the Deliberately-Unvalidatable Root Zone (DURZ). This is a version of the root zone that contains 2 of the 3 ingredients for validating a digitally signed answer. The data is there, of course, as well as the signature. What is missing is the public key.
The rationale for this unusual configuration is that there are other problems in the “plumbing” of the Internet, namely limits of the number of bytes that DNS is allowed to carry. This set up allows experimentation to find those trouble spots before anyone comes to rely upon the public key of the root zone.
It is anticipated that the signed root zone will be available with the public key in mid-July, 2010. This will make DNSSEC validation more prevalent as users will now be able to track the root key and validate TLDs as they become signed.
Sweden led the way in DNSSEC deployment at the TLD level, beginning in 2005. Today a number of TLDs are signed and many more are on way road to being signed. At least 10 ccTLDs are signed, .us, .gov and .org, as well as the .arpa hierarchy. As DNSSEC is deployed at the top levels of DNS, the benefits for enterprises will continue to increase. Although VeriSign has not signed .com or .net, it is expected to deploy support in 2011. The launch of .com DNSSEC support is critical worldwide, without its support DNSSEC cannot fully function.
Authoritative servers are managed across the Internet in many ways. Organizations manage them internally, some rely on hosting providers and ISPs and registrars, while others outsource this task to specialized DNS service providers. The adoption on authoritative servers has not been pervasive to this point although more and more service providers are adopting and supporting DNSSEC. Many more authoritative servers will launch DNSSEC support around the time when .com (the most critical TLD) plans to launch support.
Neustar UltraDNS Implementation
Neustar is committed to providing the best level of service to its customers. DNSSEC is a critical Internet technology and UltraDNS users will benefit from the deep DNS expertise and years of operational experience at Neustar. One of the early designers of DNSSEC is a Neustar employee, and has played a pivotal role in the timely roll-out of DNSSEC on the entire UltraDNS network.
The .US ccTLD began DNSSEC operations in December of 2009 and announced that on June 7, 2010 it will take registrations of DNSSEC records from customers. The .biz gTLD will be signed shortly after.
Neustar manages a signed .us ccTLD and will soon be managing a signed .biz gTLD with an implementation ready to deploy DNSSEC in other managed zones. Neustar operates a key management function and are able to run large zones (over a million delegations) with a very high rate of change (every few minutes), and serve the results on a global DNS network.
Neustar name servers also serve approximately 30 other TLD zones, to date, two of which are DNSSEC signed by the primary operator. Neustar accepts zone transfers and publishes the zones. Neustar supports DNSSEC all within its standard UltraDNS network without additional fees required.
For enterprise customers, Neustar will offer DNSSEC configuration through its Managed Services Portal (MSP). Neustar will manage DNSSEC operations while the organization retains the control.
Secondary DNS services will launch by the end of 2010. Neustar UltraDNS will accept zone transfers of DNSSEC-signed zone data. The primary DNS server that hosts their zone will sign the zone data then zone transfer it to UltraDNS. Secondary zones are published to our global network of authoritative DNS servers automatically. The end user may use whatever standards-based method to sign their zones and zone transfer them. Of course, if they seek help or recommendations on necessary equipment, Neustar can assist.
Before the end of 2010 Neustar will support full Primar Authoritative DNSSEC features within in the MSP, such as key management, automated zone signing, automated key rotation and an opt-in service. End user will be able to select which zones should be protected. Finally, all features will be integrated within our suite of Managed DNS features such as global load balancing and geographic responses (Traffic Manager and Sitebacker) by the end of Q1 2011.
Secondary Service for TLDs
Neustar has been supporting secondary DNS services for two major ccTLDs since 2009.
Future of DNS with DNSSEC
With the dependence of the world’s communications, economy and information on the Internet, DNS is becoming more critical. With the necessary implementation of initiatives such as DNSSEC, its management becomes more and more complex. The spotlight on security also raises awareness on key components of DNS that have long been overlooked such as recursive services- the services that connect end-users out to the Internet. More and more components of DNS will be scrutinized for effective management.
Managed DNS Service option
Organizations that have critical Internet-based businesses and security concerns have been long-time users of Managed DNS services. With the increasing complexity of DNSSEC and other initiatives such as IPv6, the DNS management time, complexity, tools, and infrastructure build the case for more and more organizations to consider a managed service.
Some key reasons to consider Neustar UltraDNS® service are:
- Experience: DNS is what Neustar does every day. Neustar understands DNSSEC intimately, has been involved in its development and has been working with DNSSEC since its early development.
- Tools: Automated key management, zone signing, and key rotation. These features are automated to simplify management, freeing you from the concerns of maintaining this complicated periodic task.
- Global DNS Infrastructure: multiple nodes worldwide in an anycast environment, supporting DNSSEC globally. The infrastructure nodes are also built with extensive processing capability to handle the stress of DNSSEC. Nodes are also monitored and managed for expansion. When additional processing capacity is required, Neustar builds out the infrastructure.
- Expert Maintenance: DNSSEC features and overall systems are monitored and maintained by our team of experts around the clock.
Given the importance of the Internet, security is definitely a concern. Businesses, governments, literally everyone wants confidence in the Internet. In order to bring the Internet into the next era, security enhancements such as DNSSEC are necessary and inevitable. While the process of deploying and supporting DNSSEC can be daunting, in the end, it will benefit the Internet as a whole.