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 primary.my.dom.
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:

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.

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 db.my.dom:

# dnssec-signzone -o my.dom db.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
db.my.dom.signed:

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 primary.my.dom 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.

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.

Conclusion

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.