Welcome:
Login
|
Sign Up
|
About CircleID
Follow:
|
|
|
|
||
|
||
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 DNSSEC Trial 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 see http://www.dnssec.comcast.net or http://dns.comcast.net.
Sponsored byVerisign
Sponsored byRadix
Sponsored byCSC
Sponsored byIPv4.Global
Sponsored byWhoisXML API
Sponsored byDNIB.com
Sponsored byVerisign
A World-Renowned Source for Internet Developments. Serving Since 2002.
What nobody has ever told me is how, as a domain name owner, I get my key signed and entered into the .com registry.
I have been asking this question for five years now. I have asked ICANN people in public and private. I gave a talk at RSA this year explaining why DNSSEC is incomplete and nobody in the audience could answer the question either.
Telling me to ask my registrar is not an answer as they do not have any idea. There are a lot of people complaining about how unprepared the registrars are, but nobody has told them what they are expected to do, how they are expected to do it or what the business incentive would be for them to put their business on the line by accepting the liability of acting as a Certificate Authority for DNSSEC.
The issue of liability is not a trivial one, it is the reason that VeriSign had to be split from RSA Labs in the first place. The SSL world hangs together because they use a very clever set of legal tools developed by Michael Baum that allow them to limit their liability exposure.
Don’t let the fact that we have not had any lawsuits to date fool you. We hadn’t had a major spill in the gulf for 20 years until Deepwater Horizon went. The liabilities of SSL are largely controlled by the fact that credit card purchases all carry insurance and the certificate formats have liability control tools (CPS, CP, Relying Party Agreement) built in.
There is some understanding of liability in the DNSSEC world. ICANN is very clear that it does not want the liability. And the registry operations of what was Network Solutions now trading as VeriSign are certain to avoid taking liability. So that means that either the liability fairy has visited and poofed the liability away or it has been dumped on the registrars.
Up till now the expectation has been that VeriSign knows about being a CA and how to work in that business. But now that what was really VeriSign is going to be called Symantec, the DNSSEC operations are going to be run by Former NetSol trading as VeriSign, a totally different proposition.
It is rather unlikely that the registrars will fail to notice that they are the ones being asked to hold the bag here. So as I see it, DNSSEC is not going to happen unless the model is changed. There may be some registrars that are prepared to risk participation, but no registrar with deep pockets should unless they are prepared to risk them being emptied.
Lauren:
Interesting to get Comcast’s take, but IMHO you can’t just focus on the technical issues. Exactly how does DNSSEC benefit anyone until the authority chain is complete, and how can the chain be complete without the registrars participating?
And therein lies the business model problem—they’ve no incentive to do so. How can they pass along the additional cost to consumers when the margins are so thin now? Never mind the liability question, which I’m not up on and sounds like Phillip has down cold.
For years it was conventional wisdom inside the Internet community that DNSSEC would never happen, because there was no business model to make it happen. Then Kaminsky publicizes a fundamental flaw in DNS, and everyone starts singing from the same song sheet. I think that’s great, and I think we need to make DNSSEC happen. But to just focus on the technical hurdles ignores the elephant in the room and raises false hopes that DNSSEC is right around the corner.
I’m not as technical as some in this community. But to my understanding there are things ISPs can do today to make their DNS secure, they don’t have to wait until DNSSEC. I’d be really interested to hear how Comcast and other ISPs plan to protect customer DNS now, while waiting for DNSSEC to eventually happen.
I think Vint Cerf answered your question in the key signing ceremony PR video: people are going to find something more interesting for DNSSEC to do. Sometimes you have to do the wrong thing before you can do the right thing. Signing the ICANN root was essential if DNSSEC was going to go to the next level. These people can only see one problem ahead. they are not going to take any notice of people like you or me who point out that the business model is broken until that is the next problem they have to face. Lots of business in Congress works the same way, they passed the Medicare part D bill knowing that the donut hole and corporate welfare would be unacceptable, then they came in and fixed them. Where Cerf was wrong is claiming that the signing of the root was as important as the invention of the Web. That is bunk, signing the root is just technology. The Internet was just technology. It was the Web (and email before it) that gave them a purpose. Some important changes have already occurred that are going to make development of a business model possible. The most important of these being the breakup of VeriSign but not for the reason some might think. DNSSEC was conceived as an alternative Internet PKI before deployment of SSL took place. Some people still think that can happen, just like some people still think X.500 can win. The window for deployment of an alternative PKI is shut. Instead of trying to replace SSL and the existing business model for PKI, DNSSEC has to find a role that is complimentary. The role that DNS can play but no other system is distribution of authenticated domain security policy. Statements of the form 'This Web site always offers SSL', 'This email server always accepts STARTTLS'. That is the missing link in the Internet security infrastructure and that is what DNSSEC should be used to provide.