Comcast has been a leader in the testing of and advocating for the wide adoption of DNSSEC. Our leadership continues today with the announcement of a plan to implement DNSSEC validation in the DNS servers that our customers use, as well as for the signing of authoritative domains such as comcast.com and xfinity.com. In addition, we're pleased to tell you that we have something you can do to get involved today (so keep reading!).
First, we plan to sign the domain names we manage, such as comcast.com and comcast.net, by the end of the first quarter of 2011, if not sooner. While we are already signing several domains today on a trial basis, such as comcast.org, this is our goal for signing the full range of domains that we own (there are thousands).
Second, by the end of 2011, if not sooner, we plan to implement DNSSEC validation in all of the recursive DNS servers (a.k.a. caching servers) that our customers use every day. Customers will not need to make any changes to their configurations in order to take advantage of that; this will automatically occur via DHCP lease updates at that time.
Third, and of particular interest to people here, customers who would like to start using a DNSSEC-validating DNS server today, can immediately do so on an opt-in basis as the next step in our DNSSEC technical trials. You can do so now by changing your DNS server IP addresses to 18.104.22.168 and 22.214.171.124. The servers supporting this are operating in our production network, not a trial network, and are deployed nationally in the same locations as our other DNS servers that customers use everyday.
We hope that by announcing our DNSSEC plans, and immediately making available our Anycast-based DNSSEC-validating servers, we will catalyze other stakeholders to really focus on DNSSEC, and do their share to ensure we collectively have a secure foundation for the Internet. Just as with IPv6, it's time for organizations to get serious about DNSSEC and today we take another step in doing our share to move the Internet community ahead.
Finally, I'd like to anticipate one question some of you might ask, which is how we reconcile the use of DNS redirect as used in Comcast Domain Helper, and as described in this IETF draft, with our plan to implement DNSSEC. The answer is that we believe that DNSSEC is basically incompatible with current DNS redirect technology. We have always known this and we expect that one result of turning on DNSSEC validation will be that Domain Helper's DNS redirect functionality will need to be disabled, absent any additional IETF standards work or other technology advances (and we're not aware of any work on either of these fronts). We anticipate updating our IETF draft on this subject to reflect this in the upcoming -01 version, which we are working on now and hope to publish shortly after IETF 77, which takes place in late March. We also look forward to any feedback users may have about their experiences using our trial DNSSEC-validating resolvers, as such feedback is important to preparing our infrastructure and processes for full DNSSEC support. For more information on the DNSSEC deployment at Comcast, please check out http://www.dnssec.comcast.net.
Found an issue that seems to be related to the DNSSEC servers. While trying to look at http://www.broadband.gov (mentioned in another post), I found I could not get to it, and by that I mean I couldn't resolve the IP address through DNS. My Win7 box is pointing at my Apple Time Capsule for DNS proxy, the Time Capsule is pointing at the 75.75.*.* DNSSEC servers.
After some playing on my Linux system, I got dig to cough this up:
1. /etc/resolv.conf pointing at 126.96.36.199 and 188.8.131.52, I get this:
;; Query time: 3051 msec ;; SERVER: 184.108.40.206#53(220.127.116.11) ;; WHEN: Sun Mar 14 18:08:56 2010 ;; MSG SIZE rcvd: 38
Too many problems, the DNSSEC servers are clearly not ready for prime time yet. I'm converting back to the DNS servers delivered with my IP address.
We are looking into the signed domains under .gov which seem to be having issues with larger UDP packets. That is why we are performing a trial and hopefully you give it a try again and provide feedback.
Both the NASA Astronomy Picture of the Day site and www.broadband.gov are still not resolving. It's not all .gov sites, for example, irs.gov seems to resolve OK. But the three examples I know of with issues are all .gov sites, which is interesting.
We are pushing out a code update to the DNSSEC trial servers shortly that should resolve this. We were testing on one of the nodes in Florida and its now working from there. I will update once we make that change.
Since Sunday or Monday, usage of the DNSSEC servers prevents the Cafe World Facebook app from working. Switching to a non-DNSSEC server and it loads fine. Other Facebook apps (FarmTown, Farmville) seem to work either way. Appears the culprit is that the DNSSEC servers are returning SERVFAIL for facebook.cafe.static.zynga.com: