ONLamp.com
oreilly.comSafari Books Online.Conferences.

advertisement


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 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:

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

Kmy.dom.+003+08987

Let's look at the content of these files:

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

my.dom. IN KEY 256 3 3

BM8d6185SU4ba815a6T2s4f8jNK14EOplnQ4K7jEc5UAs3UT+yiIvps0
HC2gyoRvpwVf798r161zZBdGtoQ3rRqjoJLbHCI+tDKxtk7GbLFV2bIR
Bhau7lXbLBf+5ci8id6wvun8nxJjZLaY8KPFBPD1ocQh3NqZLqefGPoS
8XXHcBypHE/cr7ZFjaUqgn8BMzBN4COV6PkbM+bvZFogfsOLVt6ToU89
fnDztYpMvx5qdDDYG/aLC8kYz95iGNnc8v76qNrAb1GCccYArZ9TtAwf
11mZaqQL07r5oCbByzdQuo+YY3t+maOWL0DcG2P4snPZ2rlP2Mf2/AR9
qpjUTeNU5SYbIuVaso2wtmFtr1Y9xlYZqdq6nXcr1+8uknVpJRjWlIXC
WoJZktBk38Af6Bp2GX9V

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

Private-key-format: v1.2

Algorithm: 3 (DSA)

Prime(p):
4EOplnQ4K7jEc5UAs3UT+yiIvps0HC2gyoRvpwVf798r161zZBdGtoQ3rRqj
oJLbHCI+tDKxtk7GbLFV2bIRBhau7lXbLBf+5ci8id6wvun8nxJjZLaY8KPFBPD1ocQh

Subprime(q):
zx3rXzlJThtrzXlrpPazh/yM0rU=

Base(g):
3NqZLqefGPoS8XXHcBypHE/cr7ZFjaUqgn8BMzBN4COV6PkbM+bvZFogfsOL
Vt6ToU89fnDztYpMvx5qdDDYG/aLC8kYz95iGNnc8v76qNrAb1GCccYArZ9TtAwf11mZ

Private_value(x):
nVisc+b5n2oXbDF5zpGWSHocgAo=

Public_value(y):
aqQL07r5oCbByzdQuo+YY3t+maOWL0DcG2P4snPZ2rlP2Mf2/AR9qpjUTeNU
5SYbIuVaso2wtmFtr1Y9xlYZqdq6nXcr1+8uknVpJRjWlIXCWoJZktBk38Af6Bp2GX9V

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)

my.dom.             
IN NS   ns.my.dom.

secondary.my.dom     IN A    192.168.1.1

$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 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:

my.dom.                
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.
                             BIXpbP5zrJxniT/E6gM4kliupdLQqLFJm+VK
                             DpLbcm1JOjz3nq21cjM= )
                 100   NS    ns.my.dom.
                 100   SIG   NS 3 2 100 20040902093054 (
                             20040803093054 8987 my.dom.
                             BIjE6ogFfsY0V8qYoCF+p17ksrnKagiKHIk7
                             GkL2eA13Gowf7zAh6io= )
                 100   KEY   256 3 3 (
                             BM8d6185SU4ba815a6T2s4f8jNK14EOplnQ4
                             K7jEc5UAs3UT+yiIvps0HC2gyoRvpwVf798r
                             161zZBdGtoQ3rRqjoJLbHCI+tDKxtk7GbLFV
                             2bIRBhau7lXbLBf+5ci8id6wvun8nxJjZLaY
                             8KPFBPD1ocQh3NqZLqefGPoS8XXHcBypHE/c
                             r7ZFjaUqgn8BMzBN4COV6PkbM+bvZFogfsOL
                             Vt6ToU89fnDztYpMvx5qdDDYG/aLC8kYz95i
                             GNnc8v76qNrAb1GCccYArZ9TtAwf11mZaqQL
                             07r5oCbByzdQuo+YY3t+maOWL0DcG2P4snPZ
                             2rlP2Mf2/AR9qpjUTeNU5SYbIuVaso2wtmFt
                             r1Y9xlYZqdq6nXcr1+8uknVpJRjWlIXCWoJZ
                             ktBk38Af6Bp2GX9V
                             ) ; key id = 8987
                 100   NXT   secondary.my.dom NS SOA SIG KEY NXT
                 100   SIG  NXT 3 2 100 20040902093054 (
                             20040803093054 8987 my.dom.
                             BEckizFAreqKu8sgrKYSVkMdVJCQKMyF6eY9
                             4ZIVb5ohuFXIdj8M/Kk= )
secondary.my.dom.
                 100   IN A  192.168.1.1
                 100   SIG  A 3 5 100 20040902093054 (
                             20040803093054 8987 my.dom.
                             BBh+ePXrvgfOoz71V4bmN5cJyCoxOI3mbT3R
                             9VIqtYWGNYvHbd2kaAE= )
                 100   NXT   my.dom. A SIG NXT
                 100   SIG   NXT 3 5 100 20040902093054 (
                             20040803093054 8987 my.dom.
                             BDDwUk/0INxaFlmwbceHDldT4GGhfYUUGIv+
                             hH7lnPI+5chIS024f+w= )

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

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

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.

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.

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.

Happy and secure hacking!

References

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 ONLamp.com



Sponsored by: