VeriSign, who runs the .tv Registry, is an active member in the ICANN and Internet community. DNSSEC is another example of that.

When DNS was designed over 25 years ago, there wasn’t much thought given to security. Many people have worked to change that over the past few years, and the result is the DNS security extensions, or DNSSEC for short.  Recently there have been some important milestones in the rollout of DNSSEC and a really important one is imminent: the DNS root zone will soon be fully DNSSEC-enabled.

The root zone is the most important zone in the entire DNS name space. At the lowest level, DNS is a big distributed database and the name space is the tree structure that makes up that distributed database. A zone is an “administrative region” of the name space controlled by a single entity. Zones contain data, such as IP addresses corresponding to computer names, and sometimes they also contain delegations. 

A delegation is a pointer from one zone to another zone below it in the tree-structured name space. This delegation process starts at the root, which is what makes the root zone so important. For example, the root zone delegates the .tv zone, and the .tv zone delegates the watch.tv zone, and the watch.tv zone has an entry for the IP address of blog.watch.tv, which is for the web server, where your web browser retrieved this blog posting.

Devices called recursive name servers look up names in DNS on behalf of clients, such as Macs, PCs, iPhones, refrigerators (eventually!), etc. There are a bunch of clients that use the Internet, so there has to be a recursive name server to perform DNS lookups for them. This means you find recursive name servers at ISPs, commercial enterprises and other large organizations.

Because the DNS database is distributed over the entire world, a lookup can take a long time. Recursive name servers cache the results of lookups to speed up future searches, and that’s where DNS’s lack of security can be a real problem. Without DNSSEC, a recursive name server has to believe the responses it receives. But there are various ways to spoof a recursive name server and feed it bad information, also known as “poisoning its cache”. For example, if a bad guy can poison a recursive name server’s cache to believe that the IP address of www.bigbank.com points to the bad guy’s web server, then any client that uses that recursive name server to look up www.bigbank.com is going to be sent to the bad guy’s bogus web site.

DNSSEC makes cache poisoning much harder by adding digital signatures to DNS data. In a DNSSEC-enabled world, DNS administrators sign the data they put into their zones with a “private key”, and when recursive name servers perform a DNS lookup, the answer they receive includes not only the data they asked for but also a digital signature of that data. 

The recursive name server can validate the digital signature with the zone’s “public key” to ensure that the data is legitimate. The bad guy can’t poison the recursive name server’s cache anymore because he doesn’t have the zone’s private key. Without that private key, he can’t generate the proper digital signature that would make his poison data appear legitimate.

VeriSign and ICANN manage the root zone under agreements with the U.S. Department of Commerce. VeriSign and ICANN have also cooperated to bring DNSSEC to the root zone. The root zone’s key-signing key will be managed by ICANN. This key doesn’t exist yet, but it will be created in a “key ceremony” on June 16, with several representatives from the Internet community present as participants and witnesses.

VeriSign has an important role in DNSSEC for the root zone, too. For years, VeriSign has maintained the definitive database of entries in the root zone and produced the updated file with all the root zone information twice a day, every day. Recently we’ve also started to digitally sign this information, but this data isn’t usable quite yet – those details can be the subject of another entire blog post.  One of the dependencies for making the signed root zone usable is the creation of the key-signing key at the key ceremony on June 16.  After the key is created, it will then be used to sign information that VeriSign needs to include in each signed root zone.

But the biggest day of all is July 15. That’s when the DNSSEC-signed root zone is scheduled to become usable. ICANN will publish the key-signing key and VeriSign will “take the wraps off” the signed root zone. Administrators of recursive name servers all over the Internet will be able to configure the root zone’s key and DNSSEC validation can begin. 

It’s a small step, but it’s also a big step. With DNSSEC enabled in the most important zone on the Internet, rolling out DNSSEC can really begin. For more information, go to www.verisign.com/dnssec.