oreilly.comSafari Books Online.Conferences.


The Basics of DNSSEC
Pages: 1, 2

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:

  • Sorted the zone in canonical order.
  • Inserted NSEC records between unique domain names.
  • Added the key ID as a comment to each KEY record.
  • Signed the KEY RR set with each key present, the zone signing key in this case.
  • Would sign the other RRs with the all-zone signing keys, if present.

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

Sponsored by: