Today ICANN and VeriSign have deployed a signed DNS root zone in a historic milestone for the Internet. Comcast is pleased to announce the deployment of the DNS root key to all of our DNSSEC servers across the country. If you are a Comcast customer, you can start using our trial servers immediately by changing your DNS server IP addresses to 18.104.22.168 and 22.214.171.124. We are pleased to see global DNSSEC deployment continue to move forward and congratulate ICANN, VeriSign, and the Internet community in taking the next step in securing the DNS.
Today in Brussels, the Public Interest Registry, operator of the .ORG Top Level Domain (TLD), announced that they have signed the .ORG TLD, enabling support for DNSSEC in that TLD. Coinciding with that announcement and joint testing we have performed with PIR, Comcast is pleased to sign all of our over 650 .ORG domains. This is an important milestone in our continuing work to deploy DNSSEC. In addition, you can find slides we will be presenting at two ICANN DNSSEC workshops tomorrow here and here.
DNSSEC validation can be a very difficult to test, in order to validate that it is working. However, with good tools, this becomes a lot easier. We want to highlight one such tool from dnsviz.net. This tool allows an end user as well as a DNS admin to verify the chain of trust in DNSSEC signing of domains. It's especially useful as it validates from the root of the DNS down to a specific domain, showing all security chaining between the layers of the DNS. As an example, you can try one of our signed zones like comcast.org and see what a signed zone should look like (though since the root zone is not yet signed so you will only see the chain of trust from the ORG zone down).
It's been two months since we launched our DNSSEC trial and we have been busy. We're happy to see that some of our customers are giving it a try and reporting issues. One problem we've been working to correct is how the DNS servers handle the amount of data that a signed response creates. This is known as UDP payload size and normal DNS responses are usually limited to 512 bytes. This changes with DNSSEC, where this size can increase to 4000, causing issues with network elements like firewalls and routers.
Use of this larger UDP size is also known as EDNS0. We encountered this issue with some signed zones in the .GOV and .ORG top level domains (TLDs). These TLDs are signed and have allowed some secondary zones to sign and become DNSSEC-aware. When our validating resolvers were trying to cache these DNSSEC-aware zones, the DNS servers attempted to validate the signatures, but due to a limitation on one of our upstream systems that limited the UDP payload size, the response never reached our DNS servers (which can handle the prescribed 4000 payload size). As an interim fix, we have lowered the max UDP payload size, which tells the DNS servers to fall back to TCP as a transport for the DNSSEC responses while we work with the affected vendor to fix this limitation in UDP payload sizing. We are glad to report that the fix is currently in our labs being tested and should be rolled out to our production systems soon. These kind of operational issues are best found in a trial, and this is why we are testing out DNSSEC now, before going live with millions of subscribers.
Comcast has been a leader in 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 by the end of 2011, as well as for signing of our authoritative domains, such as comcast.com, by the end of the first quarter of 2011. In addition, today we are making available DNSSEC-validating DNS servers for customers to use on a trial basis now. You can learn more about this in our DNSSEC trial FAQs.
We have deployed the IANA ITAR anchors to the Nominum Vantio and NLnet Labs Unbound resolvers. We are still working on the configuration for ISC BIND 9.6. We have also signed mycomcast.org and comcastbusiness.org and are working to have the DS records inserted in the ORG registry for additional testing. Once this has been completed, we will be able to validate these zones using the ITAR repository and DLV registry without having to have a trust anchor key on our resolvers for these zones.
It has been awhile since we updated this page and there are some major updates on the DNSSEC front and regarding our testbed that we wanted to update you on. IANA has launched the Interim Trust Anchor Repository (ITAR) and we are in process of upgrading our test resolvers to use this system to load the keys in their repository. We will post when this process is completed, and which resolvers are using ITAR will be posted below.
This trial is being conducted by the Internet Services team, in National Engineering & Technical Operations. Given the move by the .GOV Top Level Domain (TLD), as well as the coordinated activities of the public sector, private sector, industry groups, and other non-governmental organizations regarding other TLDs implementing DNSSEC, we have started a production trial to evaluate a move to DNSSEC by large ISPs. As of October 1, 2008, we have made available a DNSSEC resolver for anyone in the Internet community to test against. In addition, as we perform testing, decide how to deploy DNSSEC resolvers widely, and how to sign our own zones, we will be building documentation about our experiences, and intend to share this with the Internet community at large.