DNSSEC HOWTO

Contents

About This Document

This document was developed as part of the RIPE NCC project on the deployment of DNSSEC. The document started as being an addendum to the RIPE NCC DNSSEC course. It was found to be more useful as a stand alone ”HOWTO” for setting up DNSSEC in ones own environment.

In the cause of time the document has been updated during workshops and based on feedback by folk using the document. It has grown beyond the size of your typical HOWTO.

In this HOWTO, which, because of its bulky nature is more of a tutorial in disguise, we touch upon the following topics:

Part I,

about the aspects of DNSSEC that deal with data security.

• Creating an island of security (Chapter 1, “Configuring a recursive name server to validate answers” and Chapter 2, “Securing a DNS zone”) by configuring a recursive name server to validate the signed zones served by your organisations authoritative name servers. When you have learnt and implemented this, you can be sure that DNS data in your organisation is protected from change. Once you have created an island of security it is a small step to become part of a chain of trust.
• Delegating signing authority; building a chain of trust (Chapter 3, “Delegating of signing authority; becoming globally secure”). You will learn how to exchange keys with your parent and with your children.
• Chapter 4, “Rolling keys” covers maintaining keys and ensuring that during the rollover process clients will be able to maintain a consistent view of your DNS data.

Part II,

covering aspects that deal with server to server security and transaction security.

• Chapter 5, “Securing zone transfers” is on the use of transaction security (TSIG) to provide authorisation and integrity for zone transfers.

Part III,

describes a few tools that may turn out handy while figuring out what might have gone wrong.

The documentation is based on the so called DNSSEC-bis specifications that where finalised by the IETF DNSEXT working group in July 2004 and published in March 2005 as [3, 5, 4].

As of November 2006 the author is aware of the following open-source and or freeware implementations of the DNSSEC-bis specifications: BIND 9.3.2 and NSD 3.0.3. All our examples are based on BIND 9.4.1-P1.

This document is not intended as an introduction to DNS. Basic knowledge of DNS and acronyms used is assumed. We have tried not to use jargon but when unavoidable we have tried to explain the meaning. If you want to know more about the topic of DNS in general then Paul Albitz and Cricket Lui’s[2] or Ron Aitchinson’s [1] text books provide an excelent introduction.

This document will be subject to change. Please regularly check for new versions. <http://www.nlnetlabs.nl/dnssec_howto/>. Your corrections and additions are appreciated.

Part I
Securing DNS data

1 Configuring a recursive name server to validate answers

1.1 Introduction

We plan to configure a recursive name server to validate the data it receives. Users that use this recursive name server as their resolver will, then, only receive data that is either secure and validated or not secured in any way. As a result, secured data that fails validation will not find its way to the users¹. Having a validating recursive name server protects all those that use it as a forwarder against receiving spoofed DNS data.

Figure 1 illustrates how to configure the recursive DNS servers with a trusted key for ”example.com” so that all the data served by the authoritative servers for ”example.com” is validated before it is handed to the protected infrastructure that have the recursive servers configured as their forwarder (the name servers that usually are assigned through DHCP or configured in /etc/resolv.conf).

By configuring a public key for a specific zone, we tell the caching forwarder that all data coming from that zone should be signed with the corresponding private key. The zone acts as a secure entry point into the DNS tree and the key configured in the recursive name server acts as the start for a chain of trust. In an ideal situation you have only one key configured as a secure entry point: the key of the root zone.

We assume you have configured your name server to be recursive only.

We also assume that that name server in your organisation has been configured to run as an authoritative server for a secured zone called example.net. Notes on how to set up a secured zone can be found below in Chapter 2, “Securing a DNS zone”

1.2 Warning

Your recursive name server will treat the zones for which you configured trust anchors as being secured. If the zones for which you have configured trust anchors change their keys you will also have to reconfigure your trust anchors. Failure to do so will result in the data in these zones, or any child, being marked as bogus and therefore becoming invisible to users.

1.3 Configuring the caching forwarder

See AppendixA for information on compiling BIND with the correct switches to allow for DNSSEC. Do not forget enter the dnssec-enable yes; and dnssec-validation yes; statements in the options directive of your named.conf.²

1.3.1 Configuring a trust anchor

A trust anchor is a public key that is configured as the entry point for a chain of authority. In the ideal case —where the root is signed and chains of trusts can be constructed through top-level domains to end-nodes — validating name servers would only need one of these trust anchors to be configured. During early deployment you will probably want to configure multiple trust anchors.

In Figure 2 we show a zone tree. In this tree, the domains ripe.net, 194.in-addr.arpa, 193.in-addr.arpa and 0.0.193.in-addr.arpa are assumed to be signed. It is also assumed that there is a secure delegation between 193.in-addr.arpa and 0.0.193.in-addr.arpa. In order to validate all these domains, the validating DNS client would have to configure trust anchors for ripe.net, 194.in-addr.arpa and 193.in-addr.arpa.³

To configure a trust-anchor you have to obtain the public key of the zone that you want to use as the start of the chain of authority that is to be followed when the data is validated. It is possible to get these straight from from the DNS, but there are two reasons why this may not be advisable.

Firstly, you have to establish the authenticity of the key you are about to configure as your trust anchor. How you do this depends on on what method the zone owner has made available for out of band validation of the key.

• You could do this by visiting the zone owners secure website and validate the key information. For instance, the RIPE NCC signs a number of reverse zones. They publish their public keys on through <https://www.ripe.net/projects/disi/keys/>
• You could give the zone owner a call if you personally know them.
• You could trust the key that is published on the bill you just received from the zone owner.
• You could just believe that your OS vendor did the validation on your behalf.

Secondly, you may have a choice of public keys, in which case you need to select the the proper ”Secure Entry Point” key.

In DNSSEC a difference is made between key- and zone-signing keys. Key-signing keys exclusively sign the DNSKEY RR set at the apex, while zone-signing keys sign all RR sets in a zone. ⁴. Key-signing keys are often used as Secure Entry Points (SEP) keys. These SEP keys are the keys intended to be first used when building a chain of authority from a trust anchor to signed data. We advise a one-to-one mapping between SEP keys and key-signing keys. In practise key-signing keys have a lower rollover frequency than zone-signing keys so you should configure the SEP i.e. key-signing keys.

In addition to having the proper public key you should either be aware of the rollover policy of the zone owner, or that you have a tool that takes care of automated rollover. Failure to modify the trust anchor before the corresponding SEP key is rolled will result in validation failures.

Assume you have obtained the key-signing keys of nlnetlabs.nl., 193.in-addr.arpa., and 195.in-addr.arpa.. To configure those key as a trust anchor you will have to include those keys using the trusted-keys directive in the named.conf of the recursive name server. See figure 3.

The format is similar to the DNSKEY RR except that the ”DNSKEY” label, the CLASS and the TTL, are omitted and quotes are placed around the name and the public key material.

1.3.2 Testing

As soon as a trusted-key has been configured, data from that zone or its sub zones will be validated by the caching forwarder. You can test this by querying your server⁵. If data is validated by the caching forwarder the ad-bit will be set by the name server (see the ’flags’ in the following example).

It is important that you check that the validation is working correctly. This can be done by using the BIND log facilities on the machine that is configured as the validating recursive name server.

In BIND messages of a certain category can be logged to separate channels. The channels determine where the messages go and to what severity level they will need to be reported. The relevant category for DNSSEC validation is dnssec. In the example below the errors of the dnssec category are directed to the dnssec_log channel. In order to follow the validation process the channel has to log at least severity debug 3.

The output in the log file will look similar to the output below. The attempt for positive response validation shows how the validator tries to prove that the RR set is trusted by following the chain of trust to the appropriate secure entry point, your trusted-key statement. Chains of trust (see figure 4) start by the validation of a signature over a DNSKEY RRset, then these keys are used to validate the DS RRset that point to DNSKEY RRs in a child zone – which validates the DNSKEY RRs in the child zone –, or the DNSKEYs can be used to validate the data you have queried for. The log reflects the activity of the validator following the chain of trust.

1.4 Finding trust-anchors

It is not trivial to find and maintain trust anchors. If you want to get started with validation of DNSSEC here are a few places where you can find more information.

• RIPE NCC maintains a set of keys on their secured website under https://www.ripe.net/projects/disi/keys/index.html (Note that this is a secured website, check the certificate).
• The Swedish TLD is signed. Its key can be found at https://dnssec.nic.se/key.html. (Also check the certificate of this site).
• The DNSSEC spider tries to locate secured zones and checks their status. You could use this site to find secured zones. See http://secspider.cs.ucla.edu/islands.html.

Since maintaining trust anchors is a pain you may also want to read the section 1.5 on lookaside validation.

1.5 Lookaside Validation

Remember figure 2. If you would like to validate all these islands you will have to configure many trust-anchors, as in the example in figure 3.

In order to deal with this problem in absence of secure delegation from a small set of trust-anchors (ideally only 1, the root), BIND supports, as of version 9.3.2, a ⁶ mechanism called lookaside validation [14, 13].

In the lookaside validation a DLV registry will maintain all the trust-anchors you trust them to do the “Good Thing”. The maintainers of zones that are secure register their trust-anchors with the DLV registry and (non-standard extensions) in BIND (as of 9.3.2) will allow you, operator of a validating nameserver, to make use of all trust anchors that are present in the DLV tree.

In the DLV scheme the trust anchors are published in a dedicated domain (dlv.isc.org in the figure 5). Whenever a validating resolver recognises that a zone is signed it will first try to validate it by assessing if it is within the island of trust configured by its local trust anchors. When the validated domain is not in a trusted island the resolver will lookup perform a lookup in the DLV domain and use the trust anchor from that zone if and when available.

1.5.1 Configuring lookaside validation

What follows is a generic description if you want to configure ISC’s DLV as your authoritative lookaside domain you may want to read http://www.isc.org/ops/dlv/.

In the example below we assume that dlv-registry.org is the registry of our choice.

You have to perform two (additional) steps in order to turn on lookaside validation.

Configure a trust anchor for the DLV registry. You do this by defining a trust anchor for the island of trust defined by dlv-registry.org in named.conf. Obviously, this trust-anchor is not exclusive, any trust-anchor configured in your trusted-keys statement will have preference over the data in the DLV registry.

Configuring how the DNS name space anchors in the DLV name space. By using the dnssec-lookaside statement in the options section of named.conf. The statement takes two arguments the first one is the domain in the DNS for which lookaside validation is to be applied. Usually this will be the full name space so the "." (root) is configured. The second argument is the name of the trust-anchor where a lookup should be performed for a DLV record.

It is best to configure only one DLV trust-anchor.

testing When you have your logging configured as described in section 1.3.2 i.e. you log errors of the dnssec category are directed to a channel that logs at least at severity debug 3, then your log output when querying for example.net SOA will be similar to what is shown below.

First, the amount of log-ouput to validate one query covers more than one page of fine print. On a production server this data for several validation sequences will be print mixed. It will be very hard to debug from logfiles on production servers if you have not first looked at what happens for a single query.

Second, the structure is that the validator first finds DNSSEC RRs, notices that those records are not secure according ’plain DNSSEC’ and then moves to DLV validation.

Third, small chains of trust are build, from the DLV trust-anchor, via DNSKEY RRs to the signatures over the data. Trie to follow these trust anchors in the example output so it will be easier to identify them in production logs.

When using lookaside validation assessing the log output in case of corrupted zone data is a challenge. Below is the output of the validator when it tries to figure out if a query that returns a corrupted result is valid or not. The conclusion is reached in the last few lines.

1.6 Some Troubleshooting Tips

Suppose that you have configured a trust anchor and you are experiencing problems. For instance, your nameserver returns “SERVFAIL” for particular queries. Well, “SERVFAIL” is the default return code that a validating nameserver returns when it flags data as being bogus. Bogus data can be caused by two things. Either you are under attack or you experiencing a configuration error either by the operator of one of the zones in the chain of trust or by the operator of the validating recursive nameserver.

In addition to looking at the logs there are a number of tools at your disposal (see III). To assess if problems occur because of misconfiguration, or bugs, in you validating nameserver, or because of problems with the signed zones you will need a troubleshooting strategy.

One of the approaches you could take is to first use drill (see 6) or dig (see 7) to perform a ’sigchase’ or a ’trace’ with a key copied to your local file system, circumventing you validating recursive nameserver. In that way you will be able to check if the chain of trust can actually be built from the data. Make sure you use the correct trust-anchor when tracing data.

When you have verified that the chain of trust can be build from the data in the DNS it is time to troubleshoot the validating nameserver. This is easy when you have access to the log files but may be more troublesome if you don’t. You could use dig to query the validating nameservers with and without the +cd flag. That flag sets a bit in the query that instructs the nameserver not to perform validation. When the individual pieces in the chain of trust (drill returned those when using the trace option) you may be able to find inconsistencies that indicate that an expired trust anchor has been configured. You start by querying the DNSKEY RRset for which you assume there is a trust-anchor considered and work your way down. Or, alternatively, you query for the data you were looking for, use the data in the RRSIG RR to find for which DNSKEY RR to query, then query for a DS RR at the same name and work your way up (similar to the ’sigchase’ in drill).

While troubleshooting there are a number of failures that are easily introduced. Take the following example.

In his ISP column [8, 7, 6], Geoff Huston documented his experiences as an early deployer. He blindly configured a trust-anchor for the “nlnetlabs.nl” zone. While this zone was signed it was done in an experimental setup whereby not all servers for the zone were configured with the same version of the protocol. In this case one of the servers would not provide RRSIGs with the answer, something which may give rise to re-occurring but hard to predict failures.

There are two things to learn from this: Never blindly configure trust anchors in validating resolvers and make sure that when you serve zones all your servers conform to the DNSSEC protocol specification.

Another failure is that one of the RRsets in the chain of trust has expired signatures. Check this by looking at the date fields in the RRSIG RRs.

More problematic to find may be a rollover, where DNSKEY RRs or RRSIG RRs have been removed to early so that there is an inconsistency between data in cache and data that needs to be validated (also see section 4). Using the +cd to with dig and looking at the TTLs might help to distinguish if you are trying to validate RRSIGs for which there are no DNSKEYs available (or vice versa).

2 Securing a DNS zone

2.1 Introduction

If a zone has been signed and its key has been configured in a validating recursive name server we usually refer to it as being an ”island of security”. It apparently does not have a secured parent and stands alone in the sea of other unsecured domains. Usually creating an ”island of security” is the first step to becoming part of the secure DNS. The ”island of security” will remain ”insecure” for resolvers that have no trust anchor configured for the domain.

If a zone owner decides to create ”an island of security” she will sign her zones and distribute the ”secure entry points” to the system administrators that want to validate her zone data. Once the island of security has been set up the island can become part of the secure tree by exchanging the ”secure entry point” with the parent.

After creation of the key-pairs used for signing and validation we want to sign the zone data for our own organisation (e.g. example.net.) and configure the caching forwarders on our organisations network to validate data against the public key of our organisation.

In the text below, we assume that your organisation’s domain names are maintained in one zone. If domain name administration is delegated to sub-zones, see section Chapter 3, “Delegating of signing authority; becoming globally secure”.

Signing the zone data is the task of the zone administrator, configuring the caching forwarder is a task of system administrators.

The examples are based on the example zone in section Figure 7.

2.2 Configuring authoritative servers

All the authoritative servers will need to be configured to deal with the DNSSEC protocol. How this is done for BIND is explained in AppendixA. The essential steps are compiling bind with openssl and enabling dnssec through the use of the dnssec-enable yes; directive in the options section of named.conf.

That is all there is to it.

2.3 Creating key pairs

2.3.1 Key Maintenance Policy

Before generating keys, you will need to think about your key maintenance policy. Such policy should address

• What will be the sizes of your keys?
• Will you separate the key- and zone-signing keys functionality?
• How often will you roll the keys?
• How will system administrators that intend to use your zone as a trust anchor get hold of the appropriate public key and what mechanism will you provide to enable them to validate the authenticity of your public key?
• How will you signal a key rollover or how can you make sure that all interested parties are aware of a rollover?

Some of these issues may be easy to address. For example, your organisation may have established mechanisms to distribute the public keys, there may be obvious ways to publish an upcoming rollover such as the possibility of publishing the event in a corporate newspaper. Alternatively, it may be possible to notify all relevant parties by mail when a corporate X.509 hierarchy is available for e-mail validation.

Key- and zone-signing keys. The author thinks it is good practise to use zone-signing keys and key-signing keys (also see Chapter 4, “Rolling keys”). The key-signing keys are usually the first keys from your zone that are used to build a chain of authority to the data that needs to be validated. Therefore, these keys are often called a secure entry point key (or SEP key). These SEP keys are the ones that you should exchange with your parents or that validating resolvers configure as their trust anchors.

Throughout this document we assume that you use separate key- and zone-signing keys and that the key-signing keys are exclusively used as secure entry point keys and can be identified by the SEP[10] bit in the flag field; the flag field is odd.

2.3.2 Creating the keys

dnssec-keygen is the tool that we use to generate key pairs. The arguments that we have to provide dnssec-keygen are shown in Figure 6.

The output can be found in two files. The name of the files contain relevant information:

Kdomain_name+algorithm_id+key_id.extension

The domain_name is the name specified on the command line. It is used by other BIND DNSSEC tools, if you use a different name from the domain name, you might confuse those tools. The algorithm_id identifies the algorithm used: 1 for RSAMD5, 3 for DSA, 5 for RSASHA1 and 54 for HMAC-MD5 (TSIG only). The key_id is an identifier for the key material. This key_id is used by the RRSIG Resource Record. The extension is either key or private, the first is the public key, the second is the private key.

We create an RSASHA1 zone-signing key pair for example.net:

Because of the considerations in Section 2.3.1 you will also need to create SEP keys. Create keys with the SEP bit set by specifying the -f KSK flag with dnssec-keygen.

Lets have a look at the content of these files⁷

The public key (.key extension) is exactly as it appears in your zone file. Note, that the TTL value is not specified. This key has a ”flag” value of 256. Since this value is an even number, the key is not marked as a SEP key and should be used for zone-signing.

The private key (.private extension) contains all the parameters that make an RSASHA1 private key. The private key of a RSA key contains different parameters to DSA. Here is the private key (with base64 material truncated):

This private key should be kept secure⁸ i.e. the file permissions should be set so that the zone administrator will be able to access them when a zone needs to be signed. The BIND tools will, by default,⁹ look for the keys in the directory where signing is performed (see Section 2.4), that might not be the most secure place on your OS.

2.4 Zone-signing

When you create key pairs, you should include them in your zone file. Refer to the example in Figure7, where we use the $include directive to include the keys. We increase the serial number in the SOA record before signing.

In the example below we will use the RSASHA1 type keys for zone and key-signing keys.

Once the key is included in the zone file we are ready to sign the zone using the dnssec-signzone tool (see Figure 8 for all the arguments). We use the -o flag to specify the origin of the zone; by default the origin is deduced from the zone file name.

With the ’-k key_name’ we specify which key is to be used as the key-signing key. That key will only sign the DNSKEY RR set in the apex of the zone. The keys that come as arguments at the end of the command are used to sign all the RR data for which the zone is authoritative. If you do not specify the keys, BIND will use the ones for which the public keys are included in the zone and use the SEP flag to distinguish between key- and zone-signing keys.

In practise you would not want to rely on the default, since in key rollover scenarios you will have a public key in your zone file but you would not want to use that for zone-signing (in order to avoid double signatures and therefore longer signature generation times and more resource consumption on your name server). Below is the command issued to sign a zone with the 49656 key as key-signing key and the 17000 key as zone-signing key.

The signed zone file is reproduced in figure 2.4 . Note that the apex DNSKEY RRset is the only RRset with two signatures, made with the zone- and key-signing keys. The other RRsets are only signed with the zone-signing keys.

The signing process completed the following:

• Sorted the zone in ’canonical’ order¹⁰.
• Inserted NSEC records for every label.
• Added the key-id as a comment to each DNSKEY-record.
• Signed the DNSKEY RR set with two keys; the key-signing key and the zone-signing key.
• Signed the other RRs with the zone-signing key.
• It created two files, dsset-example.net and keyset-example.net. These two files are relevant when building a chain of trust. Per default the files are created in the ’current directory’ i.e. the directory in which you ran thednssec-signzone command, but when specifying the -d, with its directory, then the files end up there.

The signatures were created with a default life time of 30 days from the moment of signing. Once signatures have expired data can not be validated and your zone will marked ’bogus’. Therefore you will have to re-sign your zone within 30 days. Zone re-signing is discussed below.

The signed zone is stored in db.example.net.signed, make sure you have configured named to use this file to serve the zones from.