Home / Blogs

Preventing DNS Strain When You Deploy DNSSEC

The barriers to DNSSEC adoption are quickly disappearing. There are nearly 20 top-level domains that have already deployed DNSSEC including generic TLDs like .org and .gov. This July, the DNS root will also be signed, and will begin validating. At this point, the decision for remaining TLDs to deploy DNSSEC is really no longer a question. In fact, as it stands today, all new TLDs approved by ICANN will be required to have DNSSEC deployed at launch.

Afilias already supports .ORG’s deployment of DNSSEC and provides secondary DNSSEC service for other ccTLDs. Our experience in deploying DNSSEC demonstrates that you need to plan for an increase in strain on your DNS network if your ccTLD or gTLD plans to deploy DNSSEC.

Deploying DNSSEC will have three main effects on your DNS operations:

Larger Zone File Size

For every signed domain, your zone file will now have to store and provide not only the original DNS information such as Start of Authority (SOA) and other Resource Records, but also a digital signer record (DS) to point to the Public Key as well as the actual signature record (RRsig) for each RRset in your zone file for which you are authoritative.

On average, you should expect your zone file to increase 4-6 times its current size.

More than 50% of the DNS traffic Afilias serves today already requests DNSSEC information. When you sign your zone, you will be serving signature information immediately.

Delivering a larger zone file that is serving more records for every DNS query will increase the daily strain on your DNS servers, and could result in increased response times.

Greater Bandwidth Requirements

DNSSEC-enabled responses contain more information because they are now carrying an additional set of information (signatures and keys) that go along with every DNS query. On average, a DNSSEC response is about twice the size of a non-DNSSEC response.

You will need to factor in more bandwidth and processing power to handle larger responses for each DNSSEC query that you need to serve. Some of this is dependent on the DNSSEC configuration choices you make.

While our experience shows that the bandwidth increase associated with a signed zone is not orders of magnitude higher than an unsigned zone, we recommend that you plan for at least a 2-4 times increase in bandwidth required to respond to normal DNS query volume.

Increased DNS Traffic

There are a few reasons why you may see an overall bump in DNS traffic just because you enable DNSSEC.

DNS uses UDP, a lightweight protocol, to return responses for most DNS queries. BIND 9.4.x and earlier versions limit UDP responses to 512 bytes. Since DNSSEC information is larger, responses can be truncated, thereby forcing validating resolvers to ask for the DNSSEC information again using TCP. Most signed TLDs to date report a 1-2% TCP traffic increase overall.

Solving for these three significant operational impacts could cost you time, money and pull your resources away from other critical projects. And, it may even deter you from implementing DNSSEC even though it has become an essential part of TLD management. We would like to suggest a simple solution that will lighten your load: back-up your DNS with a Secondary provider.

Why? It will reduce your overall risk by offloading part of your traffic onto someone else’s network that has already planned for higher peak capacities. It provides a more economical solution by minimizing the overall expense and capital requirements to expand your existing DNS network. And more importantly it provides a virtual insurance plan against unexpected traffic spikes not just for DNSSEC, but any DNS traffic spike or malfunction whether caused by network failure, DDoS, or a natural disaster affecting the geographic location of your existing nodes.

It’s easy, it’s economical and it makes your infrastructure more resilient.

A free Web Seminar, “Lessons from the Trenches: Deploying DNSSEC”, will be held on June 9, 2010, featuring leaders from the .SE registry, .ORG The Public Interest Registry, Shinkuro , and Afilias. To register visit http://www.afilias.info/webex

By John Kane, Vice President of Corporate Services, Afilias

Filed Under

Comments

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

VINTON CERF
Co-designer of the TCP/IP Protocols & the Architecture of the Internet

Related

Topics

New TLDs

Sponsored byRadix

IPv4 Markets

Sponsored byIPv4.Global

Threat Intelligence

Sponsored byWhoisXML API

Domain Names

Sponsored byVerisign

DNS

Sponsored byDNIB.com

Cybersecurity

Sponsored byVerisign

Brand Protection

Sponsored byCSC