oreilly.comSafari Books Online.Conferences.


The Basics of DNSSEC

by Ibrahim Haddad and David Gordon

The Domain Name System (DNS) is one of the Internet's fundamental building blocks. It is responsible of locating and translating Internet domain names into Internet Protocol (IP) addresses. A domain name is a meaningful and easy-to-remember "handle" for an Internet address.

Securing DNS is important in order to deal with the various threats originating from the Internet, threats that the original DNS design did not anticipate. One technique for securing DNS is through DNS Security Extensions (DNSSEC), a set of extensions to DNS that provide authenticity and integrity. In this article, we will provide an overview of DNS and DNSSEC and a step-by-step tutorial that gives you the needed instructions to secure your own DNS servers with DNSSEC.

Overview of DNS

DNS is a hierarchical database, with data stored in a tree, much like the directory structure of a standard operating file system. The root domain is at the top and various sub-domains branch out from the root. On the Internet, the first branches coming out of the root are the top-level domains such as .com, .net, and .org.

the DNS hierarchy
Figure 1. The DNS hierarchy

Figure 1 illustrates the DNS hierarchy, which works from an inverted tree structure. Branching downward from the single entity at the top of the DNS structure are several top-level domains that divide the hierarchy into various categories. Commercial organizations use the .com domain; educational organizations use the .edu domain; governmental agencies use the .gov domain, and so on. These domains have further divisions into sub-domains, representing individual organizations or divisions within the domain.

DNS name resolution uses the principle of delegation. Because DNS is distributed across domains, when a name server receives a request for name resolution for a host outside of its domain, it may not have address information for that host. Because DNS is hierarchical, it does not need that information; the name server only needs to know how to access the root name server. It forwards the name resolution request to the root name server, which then delegates the request to the appropriate domain beneath it. This process continues until it reaches a name server that has address information for the host reached, from which it retrieves the information.

Each name server stores information about its domain in the form of several different kinds of resource records, each of which stores a different kind of information about the domain its hosts. Resource records are traditionally text entries stored in different files on the domain name server. DNS resource record types include NS for name server, A for address, and TXT for text information.

Related Reading

Network Security Hacks
100 Industrial-Strength Tips & Tools
By Andrew Lockhart

DNS Security Vulnerabilities

DNS was designed long before anyone knew of the Internet security issues that have developed since its creation. As the Internet grew and more people became connected, threats and the need for security awareness have increased.

Because DNS is a UDP-based network service, it has several major inherent security vulnerabilities. Most are instances of more general problems, but a few are inherent to peculiarities of the DNS protocol itself. Unlike TCP, UDP does not have a mechanism for verifying a packet source, which makes it very vulnerable to source-packet spoofing and inception attacks. There are four major points of attack: cache spoofing, traffic diversion, distributed denial-of-service (DDoS) attacks on the top-level domain servers themselves, and buffer overruns. These security problems needed solutions to ensure a more secure service and network environment.

Problems Solved with DNSSEC

The Internet and security engineering communities have responded to these threats by developing DNSSEC, a new secure DNS protocol, which addresses the data integrity and source-spoofing issues by means of a public key distribution. Interestingly, the extensions do not protect against buffer overruns or DDoS types of attack, nor do they provide confidentiality--another major issue.

DNSSEC solves many of the worst DNS security problems. It uses generally known technology and is backwards-compatible with the existing DNS infrastructure. It is completely transparent to the user population and downstream administrators if they choose not to implement the extensions. While it does require installation of BIND 9 or later, you should upgrade to BIND 9 for many other beneficial reasons.

DNSSEC Background

The reason for the existence of DNSSEC is to ensure the authenticity and integrity of DNS. DNS security is possible in different ways. For example, using Transaction Signatures (TSIG) authenticates communication between DNS servers by signing each transaction to ensure authenticity.

DNSSEC relies on cryptography to ensure authenticity and integrity. There are two types of encryption schemes: symmetric and asymmetric cryptography. Currently, DNS servers supporting DNSSEC support only asymmetric cryptography, using the RSA and DSA algorithms.

For the purpose of this article, we installed and experimented with the latest Bind DNS server version 9.3, which the Internet Software Consortium's web site makes available for download. At the time of writing, Bind 9 supports shared secrets, or symmetric cryptography, with the HMAC-MD5 algorithm. This algorithm is one of many hashing algorithms. Instead of signing the entire message, the server hashes the message with a shared secret key. The advantage of this model is that a hash will be much smaller than the message. A shared secret is common to both sender and receiver. This implies that a server must have as many shared secrets as the number of DNS servers with which it communicates to implement TSIG, whereas with public key cryptography, each server only needs a pair of public/secret keys.

Configuring TSIG to Secure Each Transaction

Transaction Signatures (TSIG) are useful for securing communications between DNS servers. The default behavior for a DNS server is to permit any host to receive a full listing of its entries. This is similar to calling the automated receptionist and receiving a full listing of the company's phone numbers and addresses. With the allow-transfer directive and a TSIG key, it is possible to limit those allowed to access data in the server.

The TSIG key consists of a secret (a string) and a hashing algorithm. By having the same key on two different DNS servers, they can communicate securely to the extent that both servers trust each other.

two servers communicating
Figure 2. Two servers communicating

In our example, illustrated in Figure 2, we will configure TSIG between and

The first step is to generate the DNS TSIG key for the server pair. dnssec-keygen generates keys for DNSSEC, as defined in RFC 2535. It can also generate keys for use with TSIG, as defined in RFC 2845. We will use dnssec-keygen to generate a base64-encoded random number to use as the secret string in TSIG, or key.

The command dnssec-keygen produces two files as output:

# dnssec-keygen -r /dev/urandom -a HMAC-MD5 -b 128 -n HOST \

# ls*

The extension of the resulting files is either .key or .private. The first file is the public key and the second file is the private key. Because we are using symmetric cryptography, both and will have the same key. The format of these files differs a bit but they contain exactly the same information: a base64-encoded random number that we will use as a shared secret.

# cat
IN KEY 512 3 157 gQOqMJA/LGHwJa8vtD7u6w==

The base64-encoded random number is gQOqMJA/LGHwJa8vtD7u6w==. Insert it as the secret of the key definition in named.conf in both primary and secondary DNS servers, as illustrated below:

    algorithm hmac-md5;

    secret "gQOqMJA/LGHwJa8vtD7u6w==";

For security reasons, we recommend that you maintain the list of secret keys in a file other than named.conf and make it readable by root only. Then, include it in the named.conf file with the include "/etc/bind/shared.keys" directive.

To configure to use TSIG with, follow this sample named.conf:

include "/etc/bind/shared.keys"
// contains key directives
// for communicating with

server {
   keys {; };

zone "my.dom" {
     type master;

     // allow transfer only from secondary server that has
     // key
     allow-transfer { key ; };

You'll need to add the DNS TSIG key to the secondary server. Below is a sample named.conf:

include /etc/bind/shared.keys
// contains key directives
// for communicating with

server {
   keys {; };

zone "my.dom" {
     type slave;
     master { };
     file my.dom.cache;
     // don't need to allow transfer to any subservers
     allow-transfer { none; };

The DNS TSIG key is now in place between the two DNS servers. Communications between primary and secondary are now verifiable through their signatures. The benefit of this setup is the restriction of communication to hosts with valid TSIG keys. DNS requests and answers can be verified for valid TSIG keys.

Pages: 1, 2

Next Pagearrow

Sponsored by: