.Org is the first top-level domain to sign on to DNSSEC. When did the project begin and why was .org the first?
The zone signing occurred on June 2 and that was our first step in implementation. This is the start of a testing period for DNSSEC. .Gov had recently taken steps to deploy DNSSEC. While they are a global top-level domain (GTLD), they are a highly restricted GTLD and .org is the first open GTLD to move forward. With 10.5 million names, it is really a significant milestone for the industry for a GTLD of this magnitude to step forward with this. .Org is the first top-level domain to sign on to DNSSEC. When did the project begin and why was .org the first?
All of .org name servers in 25-plus locations worldwide respond validly to DNSSEC requests coming from any conforming resolver and provide a fluid response back. In addition, .org has also launched a program adding other domain names under .org into the zone one at a time. We're making sure those work properly and we're starting to begin a program that ensures normal transactions in domain names do not get affected. We're making sure things like creating a domain name or transferring a domain name from one registrar to another go through in the same seamless manner as they do today. Has Afilias provided assistance for .gov as well?
We were requested to provide some expert opinions as well as share our own experiences with the U.S. government. We have provided some specific advice based on both the technical

experts we have on board and the technical expertise we have gained working with the public registries to implement .org. There's a lot to learn. For example, we learned that NSEC3 data is very good at a top-level domain basis because you don't want some unknown party to come and extract your entire zone file and use if for malicious purposes. We also learned that it comes with a somewhat higher cost in terms of DNS queries and responses. The packets are much larger. As a result, we recommended when the root is signed it is signed using NSEC instead of NSEC3, simply because everybody knows the root. They know all the top-level domains in the root. NSEC3 adds extra hashing in such a way that you cannot actually guess the next entry in the zone file and use it for any purpose without any legal constraint or agreement. But at the root zone, everybody knows that it consists of just country codes and other top-level domain names. There's no extra value in enhancing what is already a very good encryption standard. Does NSEC and NSEC3 increase bandwidth demand?
They do, but there is a significant difference simply because NSEC3 adds extra hashing on top of the NSEC methodology. NSEC3 is a bit more bandwidth intensive than NSEC. In our own lab tests we found that NSEC adds about 5% more to the query response normal load. But NSEC3 we found can add 15% to the query response normal load. Depending on how you provision, 15% can be a big factor. In our case, when we were getting .org signed and moving we actually saw a significant increase in Transmission Control Protocol (TCP) queries that came as a result of User Datagram Protocol (UDP) packet size being exceeded. That was a configuration flaw in some DNS resolvers. That's commonly expected. What it did for us was we saw a 600-times increase in TCP traffic as compared to UDP traffic. .Org is tremendously over-provisioned and as a result it didn't really make a big difference, but one of the pieces of advice we've given to U.S. government, when assigning the root, be careful. Go with NSEC versus NSEC3. What about testing once DNSSEC is deployed? What do you have to do to conduct a test?
One of the big frustrations is that it is not convenient to deploy DNSSEC if you own your own domain name. It is not easy to understand, the words aren't well defined and network providers haven't implemented programs that make it easy for them to understand it. In our testing and deployment planning what we've done is create both manuals and specific training programs that allow a domain owner to be able to simply click a button and say "DNSSEC enable my domain name." Literally with a click of a button a few scripts run into the background on the registry side and the domains are signed, the keys are loaded up and it's immediately propagated. The big test that we plan to do over the fall is to ensure this kind of single-click DNSSEC deploys seamlessly and scales. That's where the big level of testing is coming up in the fall. It seems like it would be easier for .gov to deploy DNSSEC. Is that the case?

SearchSecurity radio:

I think there are two aspects to that. One is, what do you do at the registry level, and at the registry level .gov is a smaller zone and they have far more control over who gets a .gov and who uses a .gov. But everybody is going to face equal levels of problems when it comes to network service providers and Internet service providers (ISPs). They all have to make sure their DNS resolvers are capable of handling a DNSSEC request and capable of transmitting and forwarding a DNSSEC response in an appropriate manner. Second, those network service providers and ISPs also have to know how to deal with a situation where a key is revoked. Right now the DNS is completely insecure. You can drive a Mac truck through it and we're adding lock and key methodology to DNS, but folks on the DNS resolving side have to learn how to change their own procedures and methods to ensure that if a key is changed, they can have the new key added into their own infrastructure pretty quickly. Right now the issue of key management is still not resolved?
Yes. Key management is well understood at the registry level, but it is a bit of a mystery still at the network-service level. What is it going to take to solve that mystery?
PIR has started a good program in conjunction with the Registry Internet Security Group (RISG). The system administrators and the network engineers already get it. They understand what it takes to make it happen. But if they are running BIND they have to turn on DNSSEC resolution. First, it is understanding and implementing the configuration changes. Secondly, making sure that sufficient education goes out so that you don't have CSOs or directors of IT sweating bullets over whether they have to spend $500,000 for a new set of routers for their entire infrastructure or whether they have to go from a T1 infrastructure to a T3 infrastructure for bandwidth. There's more fear, uncertainty and doubt about it than facts. We're trying to get the facts out to say it's not a lot more bandwidth, it's not a major hardware upgrade -- in fact, in many cases, it's no hardware upgrade at all and in most cases it's a configuration change or a software upgrade. That goes into my next question, which is how often are you going to have to rip and replace equipment?
We've got anecdotal experience here. I've spoke to folks in Sweden. .Se was the first to deploy DNSSEC worldwide. At the registry level there was no upgrade needed. At the registrar level there was no significant upgrade, just the normal cycle of upgrades and capital replacement programs. At the ISP levels as well, there was no upgrade. Where there was a problem and where I anticipate where there may need an upgrade. At-home routers, an old router at home prior to 2003, make assumptions about DNS and DNS request resolution and in many cases those routers have to be replaced. But we haven't seen any major upgrade requirements anywhere beyond the home.