Recently vulnerabilities within the DNS were discovered that allow an attacker to hijack this procedure of looking some body up or looking a niche site up on the world wide web employing their title. The objective of the attack would be to take control of the session to, for instance, deliver the user to your hijacker’s own internet that is misleading for account and password collection.

These vulnerabilities have increased interest in introducing a technology called DNS Security Extensions (DNSSEC) to secure this part of the Internet’s infrastructure.

The questions and answers that follow are an attempt to explain what DNSSEC is and why its implementation is important.

1) First, what is the root zone?

The DNS translates domain names that humans can remember into the numbers used by computers to look up its destination (a little like a phone book is used to look-up a phone number). It does this in stages. The first place it ‘looks’ is the top level of the directory service – or “root zone”. So to use www.google.com as an example, your computer ‘asks’ the root zone directory (or top level) where to find information on “.com”. After it gets a response it then asks the “.com” directory service identified by the root where to find information on .google.com (the second level), and finally asking the google.com directory service identified by “.com” what the address for www.google.com is (the third level). After that process – which is almost instantaneous – the full address is provided to your computer. Different entitiesⁱ manage each one of these directory services: google.com by Google, “.com” by VeriSign Corporation (other top level domains are managed by other organizations), and the root zone by ICANN.

2) Why do we need to “sign the root”?

Recently discovered vulnerabilities in the DNS combined with technological advances have greatly reduced the time it takes an attacker to hijack any step of the DNS lookup process and thereby take over control of a session to, for example, direct users to their own deceptive Web sites for account and password collection. The only long-term solution to this vulnerability
is the end-to-end-deployment of a security protocol called DNS Security Extensions – or DNSSEC.

3) What is DNSSEC?

DNSSEC is a technology that was developed to, among other things, protect against such attacks by digitally ‘signing’ data so you can be assured it is valid. However, in order to eliminate the vulnerability from the Internet, it must be deployed at each step in the lookup from root zone to final domain name (e.g., www.icann.org). Signing the root (deploying DNSSEC on the root zone) is a necessary step in this overall processⁱⁱ. Importantly it does not encrypt data. It just attests to the validity of the address of the site you visit.

4) What’s to stop all the other parts of the addressing chain from employing DNSSEC?

Nothing. But like any chain that relies on another part for its strength, if you leave the root zone unsigned you will have a crucial weakness. Some parts could be trusted and others might not be.

5) How will it improve security for the average user?

Full deployment of DNSSEC will ensure the end user is connecting to the actual web site or other service corresponding to a particular domain name. Although this will not solve all the security problems of the Internet, it does protect a critical piece of it – the directory lookup – complementing other technologies such as SSL (https:) that protect the “conversation”, and provide a platform for yet to be developed security improvements.

6) What actually happens when you sign the root?

“Signing the root” by using DNSSEC adds a few more records per top level domain to the root zone file. What are added are a key and a signature attesting to the validity of that key.

DNSSEC provides a validation path for records. It does not encrypt or change the management of data and is ‘backward compatible’ with the current DNS and applications. That means it doesn’t change the existing protocols upon which the Internet’s addressing system is based. It incorporates a chain of digital signatures into the DNS hierarchy with each level owning its own signature generating keys. This means that for a domain name like www.icann.org each organization along the way must sign the key of the one below it. For example, .org signs icann.org’s key, and the root signs .org’s key. During validation, DNSSEC follows this chain of trust up to the root automatically validating “child” keys with “parent” keys along the way. Since every key can be validated by the one above it, the only key needed to validate the whole domain name would be the top most parent or root key.

This hierarchy does mean however that, even with the root signed, full deployment of DNSSEC across all domain names will be a process that will take time since every domain below must also be signed by their respective operators to complete a particular chain of trust. Signing the root is just a start. But it is crucial. Recently TLD operators have accelerated their efforts to deploy DNSSEC on their zones (.se, .bg, .br, .cz, .pr do now with .gov, .uk, .ca and others coming) and others expect to as wellⁱⁱⁱ.

7) How is the root zone file managed?

Management of the root is shared between four entities:

i) ICANN, an International not-for-profit Corporation under contract from United States Department of Commerce, performs the “IANA” function. IANA stand for Internet Assigned Numbers Authority. ICANN receives and vets information from the top level domain (TLD) operators (e.g. “com”);

ii) National Telecommunications and Information Administration (NTIA) – which is an office within the United States Department of Commerce – authorizes changes to the root;

iii) VeriSign a United States based for profit company is contracted by the US Government to edit the root zone with the changed information supplied and authenticated by ICANN and authorized by the Department of Commerce and distributes the root zone file containing information on where to find info on TLDs (e.g. “com”); and

iv) An international group of root server operators that voluntarily run and own more than 200 servers around the world that distribute root information from the root zone file across the Internet. Designated by letter, the operators of the root servers are:

A) VeriSign Global Registry Services;
B) Information Sciences Institute at USC;
C) Cogent Communications;
D) University of Maryland;
E) NASA Ames Research Center;
F) Internet Systems Consortium Inc.;
G) U.S. DOD Network Information Center;
H) U.S. Army Research Lab;
I) Autonomica/NORDUnet, Sweden;
J) VeriSign Global Registry Services;
K) RIPE NCC, Netherlands;
L) ICANN;
M) WIDE Project, Japan.

Ref: http://www.root-servers.org

8) Why is it important for DNSSEC security that the vetting, the editing and the signing by one organization?

For DNSSEC the strength of each link in the chain of trust is based on the trust the user has in the organization vetting key and other DNS information for that link. In order to guarantee the integrity of this information and preserve this trust once the data has been authenticated^iv it must be immediately protected from errors, whether malicious or accidental, which can be introduced any time key data is exchanged across organizational boundaries. Having a single organization and system directly incorporate the authenticated material into the signed zone maintains that trust through to publication. It is simply more secure.

With the increased confidence in the security of DNS that DNSSEC will bring, it becomes ever more important that the trust achieved from ICANN‘s validation and authentication of TLD trust anchor material be maintained through to a signed root zone file.

9) In DNSSEC, what are the KSK and ZSK?

KSK stands for Key Signing key (a long term key) and ZSK stands for Zone Signing Key (a short term key). Given sufficient time and data, cryptographic keys can eventually be compromised. In the case of the asymmetric or public key cryptography used in DNSSEC^v, this means an attacker determines, through brute force or other methods, the private half of the public-private key pair used to create the signatures attesting to the validity of DNS records. This allows him to defeat the protections afforded by DNSSEC. DNSSEC thwarts these compromise attempts by using a short term key – the zone signing key (ZSK) – to routinely compute signatures for the DNS records and a long term key – the key signing key (KSK) – to compute a signature on the ZSK to allow it to be validated. The ZSK is changed or rolled over frequently to make it difficult for the attacker to “guess” while the longer KSK is changed over a much longer time period (current best practices place this on the order of a year). Since the KSK signs the ZSK and the ZSK signs the DNS records, only the KSK is required to validate a DNS record in the zone. It is a sample of the KSK, in the form of a Delegation Signer (DS) record that is passed up to the “parent” zone. The parent zone (e.g. the root) signs the DS record of the child (e.g., .org) with their own ZSK that is signed by their own KSK.

This means that if DNSSEC is fully adopted the KSK for the root zone would be part of the validation chain for every DNSSEC validated domain name (or yet to be developed application).

10) Who manages the keys?

Under this proposal, ICANN would keep the key infrastructure but the credentials to actually generate the KSK would be held by outside parties. This is an important element to the overall global acceptance of this process. ICANN did not propose a specific solution to which entities should hold the credentials, and believes this, like all of these issues are ones for public consultation and for decision by the United States Department of Commerce.