DNSSEC What Is It and Why Is It

Important?
To reach another person on the Internet you have to type an address into your computer
- a name or a number. That address has to be unique so computers know where to find
each other. ICANN coordinates these unique identifiers across the world. Without that
coordination we wouldn't have one global Internet. When typing a name, that name
must be first translated into a number by a system before the connection can be
established. That system is called the Domain Name System (DNS) and it translates
names like www.icann.org into the numbers called Internet Protocol (IP)
addresses. ICANN coordinates the addressing system to ensure all the addresses are
unique.
Recently vulnerabilities in the DNS were discovered that allow an attacker to hijack this
process of looking some one up or looking a site up on the Internet using their name.
The purpose of the attack is to take control of the session to, for example, send the user
to the hijacker's own deceptive web site 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 i 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 byICANN.
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 ii.
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 iii.
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. ICANNreceives 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.
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
authenticatediv 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 DNSSECv, 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
byDNSSEC. 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.