Published on (
 See this if you're having trouble printing code examples

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.

Signing a DNS Zone

DNS hosting is a service that provides a location to store DNS records for your domain name, or zone. Resource records (RRs) describe the specific available network resources, including mail exchangers, name servers, and web servers. The DNS host answers queries about your domain name to other hosts on the Internet. This process is known as resolving a domain name.

The importance of signing a DNS zone is to ensure its integrity and authenticity. Each RR has two additional resource records associated with the existing resource record sets, RRSIG and DNSKEY. The RRSIG record holds the signature of the RR, signed with the server's secret key (asymmetric cryptography). The DNSKEY record contains the public key of the zone that the receiver will use to verify the signature.

Referring back to Figure 2, we will sign the zone of The first step to signing a DNS zone is to create a zone key. The zone key will mainly sign all the records in the zone. Currently, BIND 9 supports both DSA and RSA. The following will create a DSA key for the my.dom zone:

# dnssec-keygen -a DSA -b 768 -n ZONE my.dom


Let's look at the content of these files:

# cat Kmy.dom.+003+08987.key

my.dom. IN KEY 256 3 3


#cat Kmy.dom.+003+08987.private

Private-key-format: v1.2

Algorithm: 3 (DSA)






The key file names contain the key name (my.dom.), algorithm (3 is DSA), and the key tag (08987, in this case). The private key (in the .private file) helps to generate signatures, and the public key (in the .key file) helps to verify signatures.

Include the public key (with the .key extension) in the zone file. You should also you increase the value of the serial number in the Start Of Authority (SOA) record. When the serial number of a master DNS server increases, the secondary DNS servers automatically do a zone transfer to update their information.

Here is a sample zone file:

$TTL 100

$ORIGIN my.dom.

@ 100 IN SOA localhost.root.localhost. (
	2002050501    ; serial number
	100           ; refresh period
	200           ; retry refresh this often
	604800        ; expiration period
	100 )         ; minimum Time To Live (TTL)

IN NS     IN A

$include Kmy.dom.+003+08987.key

With the key included in the zone file, we are ready to sign the zone using the dnssec-signzone tool. Any signed keys for secure sub-zones should also be present in the zone file prior to signing. We are signing the zone contained in

# dnssec-signzone -o my.dom

The signing process did the following:

Next, we present the output of a signed zone file. This usually takes the name of the zone file with .signed appended. In our case, it is

100   IN SOA      localhost.root.localhost. (
                             2002050501; serial
                             10        ; refresh (1 minute 40 seconds)
                             200       ; retry  (3 minutes 20 seconds)
                             604800    ; expire  (1 week)
                             100       ; minimum (1 minute 40 seconds)
                 100   SIG   SOA 3 2 100 20040902093054 (
                             20040803093054 8987 my.dom.
                             DpLbcm1JOjz3nq21cjM= )
                 100   NS
                 100   SIG   NS 3 2 100 20040902093054 (
                             20040803093054 8987 my.dom.
                             GkL2eA13Gowf7zAh6io= )
                 100   KEY   256 3 3 (
                             ) ; key id = 8987
                 100   NXT NS SOA SIG KEY NXT
                 100   SIG  NXT 3 2 100 20040902093054 (
                             20040803093054 8987 my.dom.
                             4ZIVb5ohuFXIdj8M/Kk= )
                 100   IN A
                 100   SIG  A 3 5 100 20040902093054 (
                             20040803093054 8987 my.dom.
                             9VIqtYWGNYvHbd2kaAE= )
                 100   NXT   my.dom. A SIG NXT
                 100   SIG   NXT 3 5 100 20040902093054 (
                             20040803093054 8987 my.dom.
                             hH7lnPI+5chIS024f+w= )

The signed zone,, is the new zone file that should be present in named.conf:

zone "my.dom" {
     type master;
     file;  // we are using the signed zone file
     // allow transfer only from secondary server that has
     // key
     allow-transfer { key ; };

Now, even if a malicious user modifies the entries, he cannot recreate the SIG entries without the secret key. The modified DNS entries will be discovered and will not be trusted.

Becoming Globally Secure

We have briefly covered how to deploy DNSSEC in a single zone and TSIG between two trusted DNS servers. However, recall that in a signed zone the KEY field of a RR contains the public key of the zone. How can we trust this public key?

We would want to build a chain of trust. In other words, our DNS server would possess the public keys of certain DNS servers higher in the hierarchy that we trust. The parent server signs the key of the child server, and the process repeats itself until we reach the DNS server that is sending us information. This is called building a chain of trust.

To be able to delegate authority, the parent has to sign data that securely indicates which child key to use as the next step in the chain of trust. A zone is globally secure based on the parental signature of the child's key signing key. For example, the DNS server would create a keyset of its keys with dnssec-makekeyset for the parent to sign. Then, the parent would sign the child's key signing key with dnssec-signkey.

From a global perspective, an isolated DNS server with DNSSEC and TSIG has no impact on the security of the DNS protocol. In order to secure DNS, many hosts must work together to establish a web of trust. A good example of this is the first top-level secure DNS in the Netherlands.

Opportunistic Encryption (OE)

Now that we have covered DNSSEC and have set up our own DNSSEC server, new possibilities are open to us, such as opportunistic encryption (OE). IPsec previously suffered from a scaling problem; network administrators from any pair of systems or networks that wanted to have encryption between them had to exchange public keys manually.

With OE, each network administrator puts the key(s) needed to create IPsec tunnels with their networks into the DNS. When another OE-enabled IPsec gateway wants to send packets to a host on the Internet, it first performs a check to see if there are any keys in the DNS for that host. If there are, it fetches the keys and sets up an encrypted tunnel.

OE permits secure (encrypted, authenticated) communication via IPsec without connection-by-connection pre-arrangement, either explicitly between hosts (when the hosts are capable of it) or transparently, via packet-intercepting security gateways. It uses DNS records (authenticated with DNSSEC) to provide the necessary information for gateway discovery and gateway authentication.

opportunistic encryption
Figure 3. Opportunistic encryption

Figure 3 presents a simplified OE scenario. Host A attempts to communicate with host B. In the process of establishing a connection, it obtains the public key for host B, allowing host A to establish a secure communication channel. However, this is a simplified scenario to explain the concept.


In this article, we have covered how to configure TSIG to secure each transaction and securing zone transfers. We demonstrated how to sign a zone with DNSSEC. DNSSEC can be the tool for becoming globally secure in everyday communications by providing opportunistic encryption. It is important to consider using DNSSEC, because only a coordinated effort between many DNS servers will allow an effective improvement in secure communications and personal privacy. There are other secure forms of communication, such as SSH or secure sockets.

Yet, DNSSEC involves more than one simple session. It is the source of the vision that eventually all traffic will be encrypted on public networks.

Happy and secure hacking!


Ibrahim Haddad is the Director of Technology for the Software Operations Group (Home & Network Mobility Business Unit) at Motorola Inc.

David Gordon is a computer science undergrad student at Sherbrooke University.

Return to

Copyright © 2009 O'Reilly Media, Inc.