DNSSEC Deployment Among ISPs- The Why, How, and What

It's no secret that Comcast has been leading the charge of DNSSEC deployment among ISPs.  For the past couple years, Comcast has been testing and pushing for the widespread adoption of DNSSEC.  In the spirit of increasing adoption, I thought I would interview the DNS gurus at Comcast to see what they’ve learned and what advice they would give other ISPs considering DNSSEC deployment.

1. What is the benefit to an end user when an ISP supports DNSSEC?

When an ISP supports DNSSEC it enables that ISP to provide their end users with an enhanced level of Internet security by providing DNS servers with the ability to validate domain names and make sure that the DNS has not been altered.   This is why we started our <a href=http://www.dnssec.comcast.net> DNSSEC Trial</a> and have committed to signing all of our domain names by the first quarter of next year or earlier.  We will also enable validation on all customer facing caching DNS servers by the end of 2011.

2. What does an ISP need to do to implement DNSSEC?

Almost all recent DNS application servers – both open source and commercial implementations – have added support for signing in their authoritative server and validation and key roll over support in their caching resolver code.  Three implementations that Comcast has evaluated over the last few years are ISC BIND, NlNet Labs Unbound and NSD, and Nominum Vantio and ANS.  Each implementation takes a slightly different approach to signing and key rollover, and all of them have attempted to automate this very time and resource consuming process.  There are also third party solutions like OpenDNSSEC that integrate with DNS server code to help take on the complex nature of signing DNS data.   There is a very good chance that your current DNS vendor supports DNSSEC signing and validation already, and there is no time like the present to start planning.

3. What advice would you give other ISPs?

Start your planning and testing as soon as possible if you have not already done so.  While tools and resources are available to make DNSSEC implementation much easier than it used to be, there is still operational planning that is needed in order to incorporate DNSSEC into a production environment.  Take the time to evaluate with your DNS and hardware vendors what types of traffic you are currently seeing, and plan for additional growth as needed. Build a small lab environment and plan for how you will sign your DNS data if you manage authoritative DNS zones.   If you are only running recursive resolvers for your customers, then you should plan on testing out DNSSEC validation in your lab and plan to support EDNS0 and TCP traffic for your DNS platform. You should also take a look at your Network Time Protocol configuration (NTP for short) for your DNS platform.   This is the protocol stack that most modern operating systems use to synchronize their system time.  This becomes important when you want to make sure that a signed key or zone is active at the right time and helps to ensure all of your systems are in sync from a time perspective.

4. In your opinion, what will help widespread adoption of DNSSEC in the ISP community?

I think once we move to a signed root and other ISPs realize that running a DNSSEC validating resolver or authoritative server is not as complex as they might think, there should be a tipping point where ISPs will want to secure their DNS data and responses to protect their customers.  Like most security technologies, its important to test and trial before integrating into your existing operations model.
 

5. Any notable lessons learned you want to share from your testing?

There are a few key items we have found along the way that might help others with their testing.  The first being EDNS0 UDP payload sizing issues.  When we began our trial, some of the upstream routing gear that our DNS servers were connected to had issues with DNS responses above 1400 bytes using UDP.  Working with our vendor we identified this issue and worked toward increasing this to 4000 bytes to support very large UDP DNS packets without having to failover to TCP.  Because we were able to trial our solutions ahead of a larger scale launch, we were able to find and correct this type of connectivity issue fairly easily with a patch and still provide a meaningful test environment to our customers.  This also gave us the ability to test out TCP DNS packet sizing and responses by removing EDNS0 and make sure TCP worked just as well in our trial environment.  The other notable item we found was making sure our DNS systems had a very good and secure Network Time Protocol or NTP source.   Because DNSSEC uses encryption, time of day becomes critical due to when keys and signed records and zones become active.   By ensuring we have accurate time across all of our servers, we can make sure our keys and signed zones become active when they are supposed.  This is important for all DNS servers that intend to run a server configured for DNSSEC.

For further information about what Comcast is doing on DNSSEC or DNS please see http://www.dnssec.comcast.net or http://dns.comcast.net.