Afilias' specialized technology makes Internet addresses more accessible and useful through a wide range of applications, including Internet domain registry services, Managed DNS and award-winning mobile Web services.
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 DNSSEC queries. 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.