But what about the root server itself? Who do we go to verify root's keys? There's no parent zone for root. In security, you have to trust someone, and in the perfectly protected world of DNSSEC (we'll talk about the current imperfect state later and ways to work around it), each validating resolver would only have to trust one entity, that is the root name server. The validating resolver would already have the root key on file (and we'll talk about later how we got the root key file). So after answers in #12 are received, validating resolver takes the answer received and compare it to the key it already has on file, and these two should match. If they do, it means we can trust the answer from root, thus we can trust .org, and thus we can trust isc.org. This is known as "chain of trust" in DNSSEC.

The configuration examples given in this document requires BIND version 9.9 or newer. To check the version of named you have installed, use the -v switch as shown below:

# named -v
BIND 9.10.1

All versions of BIND 9 since BIND 9.7 can support DNSSEC as currently deployed in the global DNS. The BIND software you are running most likely already supports DNSSEC as shipped. Run the command named -V to see what flags it was built with. If it was built with OpenSSL (--with-openssl), then it supports DNSSEC. Below is an example screenshot of running named -V:

$ named -V
BIND 9.10.1 <id:fe66c6b1> built by make with '--prefix=/opt/local'
'--mandir=/opt/local/share/man' '--with-openssl=/opt/local'
'--with-libxml2=/opt/local' '--without-libjson' '--enable-threads'
'--enable-ipv6' 'CC=/usr/bin/clang' 'CFLAGS=-pipe -Os -arch x86_64'
'LDFLAGS=-L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64'
'CPPFLAGS=-I/opt/local/include'
compiled by CLANG 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)
using OpenSSL version: OpenSSL 1.0.1i 6 Aug 2014
using libxml2 version: 2.9.1

If the BIND 9 software you have does not support DNSSEC, it may be necessary to rebuild it from source or upgrade to a newer version.

If you plan on deploying DNSSEC to your authoritative server, you will need to generate cryptographic keys (Section 4.3.1, “Generate Keys Explained”). The amount of time it takes to generate the keys depends on the source of randomness, or entropy, on your systems. On some systems (especially virtual machines) with insufficient entropy, it may take much longer than one cares to wait to generate keys.

There are software packages, such as haveged for Linux, that provides additional entropy for your system. Once installed, they will significantly reduce the time needed to generate keys.

The more entropy there is, the better pseudo-random numbers you get, and stronger keys are generated. If you want or need high quality random numbers, take a look at Section 6.3.3, “Hardware Security Modules (HSM)” for some of the hardware-based solutions.

Enabling DNSSEC validation on a recursive server makes it a validating resolver. The job of a validating resolver is to fetch additional information that can be used to computationally verify the answer set. Below are the areas that should be considered for possible hardware enhancement for a validating resolver:

One of the factors to consider is the destinations of your current DNS traffic. If your current users spend a lot of time visiting .gov web sites, then you should expect a bigger jump in all of the above categories when validation is enabled, because .gov is more than 80% signed. This means, more than 80% of the time, your validating resolver will be doing what is described in Section 1.5, “How Does DNSSEC Change DNS Lookup?”. However, if your users only care about resources in the .com domain, which as of this writing, is 0.5% signed, then your recursive name server is unlikely to experience significant load increase after enabling DNSSEC validation.

On the authoritative server side, DNSSEC is enabled on a zone-by-zone basis. When a zone is DNSSEC-enabled, it is also known as "signed". Below are the areas that you should consider for possible hardware enhancements for an authoritative server with signed zones:

One of the factors to consider, but you really have no control over, is how many users who query your domain name have DNSSEC enabled. It was estimated in late 2014, that roughly 10% to 15% of the Internet DNS queries were DNSSEC aware, and since then Google DNS has become DNSSEC enabled and is used by a further 15% of global DNS users. This translates to roughly 25% to 30% of the DNS queries for your domain will take advantage the additional security features, which result in the increased system load and possibly network traffic.

Before starting your DNSSEC deployment, check with your parent zone administrators to make sure they support DNSSEC. This may or may not be the same entity as your registrar. As you will see later in Section 4.4, “Working with Parent Zone”, a crucial step in DNSSEC deployment is to establish the parent-child trust relationship. If your parent zone does not support DNSSEC yet, contact them to voice your concern.

ICANN maintains a list of registrars who support DNSSEC:

https://www.icann.org/resources/pages/deployment-2012-02-25-en

Some organizations may be subject to stricter security requirements than others. Check to see if your organization requires stronger cryptographic keys be generated and stored, or how often keys need to be rotated. The examples presented in this document are not intended for high value zones. We cover some of these security considerations in Chapter 6, Advanced Discussions.

For most people, the simplest way to check if the recursive name server is indeed validating DNS queries, is to use one of the many web-based tools.

Configure your client computer to use the newly reconfigured recursive server for DNS resolution, and then you can use any one of these web-based tests to see if it is in fact validating answers DNS responses.

The web-based tools often employ JavaScript. If you don't trust the JavaScript magic that the web-based tools rely on, you can take matters into your own hands and use a command line DNS tool to check your validating resolver yourself.

While nslookup is popular, partly because it comes pre-installed on most systems, it is not DNSSEC-aware. The Domain Information Groper (dig), on the other hand, fully supports the DNSSEC standard, and comes as a part of BIND. If you do not have dig already installed on your system, install it by downloading it from ISC's web site. ISC provides pre-compiled Windows versions on its web site.

dig is a flexible tool for interrogating DNS name servers. It performs DNS lookups and displays the answers that are returned from the name server(s) that were queried. Most seasoned DNS administrators use dig to troubleshoot DNS problems because of its flexibility, ease of use, and clarity of output.

The example below shows using dig to query the name server 192.168.1.7 for the A record for www.isc.org if DNSSEC is disabled. The address 192.168.1.7 is only used as an example, you should replace this address with the actual address or host name of your recursive name server. Notice although we specifically used the +dnssec command line option, we do not see the DNSSEC OK (do) bit in the response, nor do we see any DNSSEC resource records.

$ dig @192.168.1.7 www.isc.org. A +dnssec +multiline
; <<>> DiG 9.10.0-P2 <<>> @192.168.1.7 www.isc.org. A +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20416
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.isc.org.			IN	A

;; ANSWER SECTION:
www.isc.org.		60	IN	A	149.20.64.69

Below shows what the results look like querying the same server (192.168.1.7) after enabling DNSSEC validation. The exact same command is run, and this time notice three key differences:

The DNSSEC OK (do) flag tells us that the recursive server we are querying (192.168.1.7 in this example) is DNSSEC-aware but not necessarily that it is configured to perform DNSSEC validation. The Authenticated Data (ad) flag tells us that the answer received has passed the validation process as described in Section 3.3.3, “How are Answers Verified?”. We can have confidence in the authenticity and integrity of the answer that www.isc.org really points to the IP address 149.20.64.69, and it was not a spoofed answer from a clever attacker.

$ dig @192.168.1.7 www.isc.org. A +dnssec +multiline

; <<>> DiG 9.10.0-P2 <<>> @192.168.1.7 www.isc.org. A +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32472
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.isc.org.		IN A

;; ANSWER SECTION:
www.isc.org.		4 IN A	149.20.64.69
www.isc.org.		4 IN RRSIG A 5 3 60 (
				20141029233238 20140929233238 4521 isc.org.
				DX5BaGVd4KzU2AIH911Kar/UmdmkARyPhJVLr0oyPZaq
				5zoobGqFI4efvzL0mcpncuUg3BSU5Q48WdBu92xinMdb
				E75zl+adgEBOsFgFQR/zqM3myt/8SngWm4+TQ3XFh9eN
				jqExHZZuZ268Ntlxqgf9OmKRRv8X8YigaPShuyU= )

;; Query time: 3 msec
;; SERVER: 192.168.1.7#53(192.168.1.7)
;; WHEN: Fri Oct 03 16:40:04 CST 2014
;; MSG SIZE  rcvd: 223

If you have BIND 9.10 or later, you can use Domain Entity Lookup & Validation (delv) to validate your setup. This program is similar to dig, but is specifically tailored for DNSSEC.

Without DNSSEC:

$ delv @192.168.1.7 www.isc.org. A
;; no valid RRSIG resolving 'org/DS/IN': 192.168.1.7#53
;; no valid DS resolving 'www.isc.org/A/IN': 192.168.1.7#53
;; resolution failed: no valid DS

delv also comes with a handy +rtrace (trace resolver fetches) switch that shows a little more information on what was fetched:

$  delv @192.168.1.7 www.isc.org. A +rtrace
;; fetch: www.isc.org/A
;; fetch: org/DS
;; no valid RRSIG resolving 'org/DS/IN': 192.168.1.7#53
;; no valid DS resolving 'www.isc.org/A/IN': 192.168.1.7#53
;; resolution failed: no valid DS

After enabling DNSSEC validation, re-running the exact same codes show us the following results:

$ delv @192.168.1.7 www.isc.org. A +multiline
; fully validated
www.isc.org.		60 IN A	149.20.64.69
www.isc.org.		60 IN RRSIG A 5 3 60 (
				20141029233238 20140929233238 4521 isc.org.
				DX5BaGVd4KzU2AIH911Kar/UmdmkARyPhJVLr0oyPZaq
				5zoobGqFI4efvzL0mcpncuUg3BSU5Q48WdBu92xinMdb
				E75zl+adgEBOsFgFQR/zqM3myt/8SngWm4+TQ3XFh9eN
				jqExHZZuZ268Ntlxqgf9OmKRRv8X8YigaPShuyU= )

And +rtrace shows all the glory of what records were fetched to validate this answer:

$ delv @192.168.1.7 www.isc.org +rtrace +multiline
;; fetch: www.isc.org/A
;; fetch: isc.org/DNSKEY
;; fetch: isc.org/DS
;; fetch: org/DNSKEY
;; fetch: org/DS
;; fetch: ./DNSKEY
; fully validated
www.isc.org.		19 IN A	149.20.64.69
www.isc.org.		19 IN RRSIG A 5 3 60 (
				20141029233238 20140929233238 4521 isc.org.
				DX5BaGVd4KzU2AIH911Kar/UmdmkARyPhJVLr0oyPZaq
				5zoobGqFI4efvzL0mcpncuUg3BSU5Q48WdBu92xinMdb
				E75zl+adgEBOsFgFQR/zqM3myt/8SngWm4+TQ3XFh9eN
				jqExHZZuZ268Ntlxqgf9OmKRRv8X8YigaPShuyU= )

It is also important to make sure that DNSSEC is protecting you from domain names that fail to validate; such failures could be caused by attacks on your system, attempting to get it to accept false DNS information. Validation could fail for a number of reasons, maybe the answer doesn't verify because it's a spoofed response; maybe the signature was a replayed network attack that has expired; or maybe the child zone has been compromised along with its keys, and the parent zone's information is telling us that things don't add up. There is a domain name specifically setup to purposely fail DNSSEC validation, www.dnssec-failed.org. Prior to enabling DNSSEC validation, you should have no trouble visiting the URL http://www.dnssec-failed.org/ in your web browser:

And no problem resolving the domain name as shown below using dig:

$ dig @192.168.1.7 www.dnssec-failed.org. A

; <<>> DiG 9.10.1 <<>> @192.168.1.7 www.dnssec-failed.org. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28878
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.dnssec-failed.org.		IN	A

;; ANSWER SECTION:
www.dnssec-failed.org.	7200	IN	A	68.87.109.242
www.dnssec-failed.org.	7200	IN	A	69.252.193.191

;; Query time: 955 msec
;; SERVER: 192.168.1.7#53(192.168.1.7)
;; WHEN: Fri Oct 17 07:42:50 CST 2014
;; MSG SIZE  rcvd: 82

After DNSSEC validation is enabled, any attempt to loading the URL should result in some kind of "Sorry, this page cannot be displayed" error message from your web browser. And looking up this domain name using dig should result in SERVFAIL, as shown below:

$ dig @192.168.1.7 www.dnssec-failed.org. A

; <<>> DiG 9.10.1 <<>> @192.168.1.7 www.dnssec-failed.org. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46592
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.dnssec-failed.org.		IN	A

;; Query time: 2435 msec
;; SERVER: 192.168.1.7#53(192.168.1.7)
;; WHEN: Fri Oct 17 07:44:56 CST 2014
;; MSG SIZE  rcvd: 50

Since all DNSSEC validation failures result in a general SERVFAIL message, how do we know that it was related to validation in the first place? Fortunately, there is a flag in dig, (+cd, checking disabled) which tells the server to disable DNSSEC validation. When you've received a SERVFAIL message, re-run the query one more time, and throw in the +cd flag. If the query succeeds with +cd, but ends in SERVFAIL without it, then you know you are dealing with a validation problem.

$ dig @192.168.1.7 www.isc.org. A +cd

; <<>> DiG 9.10.1 <<>> @192.168.1.7 www.isc.org. A +cd
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33590
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.isc.org.			IN	A

;; ANSWER SECTION:
www.isc.org.		30	IN	A	149.20.64.69

For more information on troubleshooting, please see Chapter 5, Basic Troubleshooting.

options {
    dnssec-validation auto;
};

This “auto” line enables automatic DNSSEC trust anchor configuration using the managed-keys feature. In this case, no manual key configuration is needed. There are three possible choices for the dnssec-validation option:

Let's discuss the difference between yes and auto. If you set it to yes (the default), the trust anchor will need to be manually defined and maintained using the trusted-keys statement in the configuration file; if you set it to auto (as shown in the example), then no further action should be required as BIND includes a copy^[2] of the root key. When set to auto, BIND will automatically keep the keys (also known as trust anchors, which we will look at in Section 3.4, “Trust Anchors”) up-to-date without intervention from the DNS administrator.

We recommend auto unless you have a good reason for requiring a manual trust anchor. To learn more about trust anchors, please refer to Section 3.4.2, “Trusted Keys and Managed Keys”.

So by now you've enabled validation on your recursive name server, and verified that it works. What exactly changed? In Section 1.5, “How Does DNSSEC Change DNS Lookup?” we looked at the very high level, simplified 12-steps of DNSSEC validation process. Let's revisit that process now and see what your validating resolver is doing in more detail. Again, we are using the example to lookup the A record for the domain name www.isc.org (Figure 1.1, “DNSSEC Validation 12 Steps”):

After step #12, the validating resolver takes the DNSKEY received and compares to the key or keys it has configured, to decide whether or not the received key can be trusted. We will talk about these locally configured keys, or trust anchors, in Section 3.4, “Trust Anchors”.

As you can see here, with DNSSEC, every response includes not just the answer, but a digital signature (RRSIG) as well. This is so the validating resolver can verify the answer received, and that's what we will look at in the next section, Section 3.3.3, “How are Answers Verified?”.

So how exactly are DNSSEC answers verified? Before we can talk about how they are verified, let's first see how verifiable information is generated. On the authoritative server, each DNS record (or message) is run through a hash function, then this hashed value is encrypted by a private key. This encrypted hash value is the digital signature.

Figure 3.1. Signature Generation

When the validating resolver queries for the resource record, it receives both the plain-text message and the digital signature(s). The validating resolver knows the hash function used (listed in the digital signature record itself), so it can take the plain-text message and run it through the same hash function to produce a hashed value, let's call it hash value X. The validating resolver can also obtain the public key (published as DNSKEY records), decrypt the digital signature, and get back the original hashed value produced by the authoritative server, let's call it hash value Y. If hash values X and Y are identical, and the time is correct (more on what this means below), the answer is verified, meaning we know this answer came from the authoritative server (authenticity), and the content remained intact during transit (integrity).

Figure 3.2. Signature Verification

Take the A record www.isc.org for example, the plain text is:

www.isc.org.		4 IN A	149.20.64.69

The digital signature portion is:

www.isc.org.		4 IN RRSIG A 5 3 60 (
				20141029233238 20140929233238 4521 isc.org.
				DX5BaGVd4KzU2AIH911Kar/UmdmkARyPhJVLr0oyPZaq
				5zoobGqFI4efvzL0mcpncuUg3BSU5Q48WdBu92xinMdb
				E75zl+adgEBOsFgFQR/zqM3myt/8SngWm4+TQ3XFh9eN
				jqExHZZuZ268Ntlxqgf9OmKRRv8X8YigaPShuyU= )

When a validating resolver queries for the A record www.isc.org, it receives both the A record and the RRSIG record. It runs the A record through a hash function (in this example, it would be SHA1 as indicated by the number 5, signifying RSA-SHA1) and produces hash value X. The resolver also fetches the appropriate DNSKEY record to decrypt the signature, and the result of the decryption is hash value Y.

But wait! There's more! Just because X equals Y doesn't mean everything is good. We still have to look at the time. Remember we mentioned a little earlier that we need to check if the time is correct? Well, look at the two highlighted timestamps in our example above, the two timestamps are:

This tells us that this signature was generated UTC September 29th, 2014, at 11:32:38PM (20140929233238), and it is good until UTC October 29th, 2014, 11:32:38PM (20141029233238). And the validating resolver's current system time needs to fall between these two timestamps. Otherwise the validation fails, because it could be an attacker replaying an old captured answer set from the past, or feeding us a crafted one with incorrect future timestamps.

If the answer passes both hash value check and timestamp check, it is validated, and the authenticated data (ad) bit is set, and response is sent to the client; if it does not verify, a SERVFAIL is returned to the client.

In the section Section 3.3.2, “How Does DNSSEC Change DNS Lookup (Revisited)?”, we walked through the DNSSEC lookup process (12 steps), and at the end of the 12 steps, a critical comparison happens: the key received from the remote server, and the key we have on file are compared to see if we trust it. The key we have on file is called a trust anchor, sometimes also known as a trust key, trust point, or secure entry point.

The 12-step lookup process describes the DNSSEC lookup in the ideal world where every single domain name is signed and properly delegated, each validating resolver only needs to have one trust anchor, and that is the root's public key. But there is no restriction that the validating resolver must only have one trust anchor. In fact, in the early stages of DNSSEC adoption, it was not unusual for a validating resolver to have more than one trust anchor.

For instance, before the root zone was signed (prior to the year 2010), some validating resolvers that wish to validate domain names in the .gov zone needed to obtain and install the key for .gov. A sample lookup process for www.fbi.gov would thus be only 8 steps rather than 12 steps that look like this:

Figure 3.3. DNSSEC Validation with .gov Trust Anchor

This all looks very similar, except it's shorter than the 12-steps that we saw earlier. Once the validating resolver receives the DNSKEY file in #8, it recognizes that this is the manually configured trusted key (trust anchor), and never goes to the root name servers to ask for the DS record for .gov, or ask the root name servers for its DNSKEY.

In fact, whenever the validating resolver receives a DNSKEY, it checks to see if this is a configured trusted key, to decide whether or not it needs to continue chasing down the validation chain.

So, as the resolver is validating, we must have at least one key (trust anchor) configured. How did it get here, and how do we maintain it?

If you followed the recommendation in Section 3.1, “Easy Start Guide for Recursive Servers”, by setting dnssec-validation to auto, then there is nothing you need to do. BIND already includes a default key (in the file bind.keys), that will automatically update itself. It looks something like this:

managed-keys {
    . initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
    FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
    bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
    X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
    W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
    Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
    QxA+Uk1ihz0=";
};

You could, of course, decide to manage this key on your own by hand. First, you'll need to make sure that your dnssec-validation is set to yes rather than auto:

options {
    dnssec-validation yes;
};

Then, download the root key manually from a trustworthy source, such as https://www.isc.org/bind-keys. Finally, take the root key you manually downloaded, and put it into a trusted-keys statement as shown below:

trusted-keys {
    . 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
    FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
    bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
    X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
    W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
    Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
    QxA+Uk1ihz0=";
};

Looking back at the example in Section 3.4.1, “How Trust Anchors are Used”, if you wanted to explicitly trust .gov and only validate domain names under .gov, your trusted-keys statement would look something like this:

trusted-keys {
    gov. 257 3 8 "AQO8daaz7B+yshOfL60rytKd9aOSujgponEw3fwBMEC3
    /+e9XzHw2k+VKnbJTZ+QaVtpfUd1q9HKZIv/ck83Gl5T
    jYKE5jtUZ2kpEDZfVNGv6yx0smtWAXv1nCJS9ohnyOTd
    397eMojGDHqkEC+uojEScZheEkMxzgCZwDAs+/CSU7mS
    uHtCRZn19xlZUd5Gv7yDQ3mbOUwuy30oSk0z1Q5UUPpo
    ihOugIZHFX6Jk7NLiW2wlqfq9qhV4zj7TiBiJY0mCc4z
    HN8/aq2VKDHp2Na7mWzvKyTy+SYQkBQ/08LbPwj9YMc+
    uCzKL6sU/ObHv17EFhD8aPDftTHZvV9L+OZr";
};

As the name trusted-keys suggests, it is possible to have more than one key configured. You could also leverage Section 6.5.3, “DNSSEC Look-aside Validation (DLV)” as part of your trust-anchor management strategy.

While trusted-keys and managed-keys appear similar, there is an important difference: trusted-keys are always trusted, until they are deleted from named.conf; managed-keys (specifically, initial-key, which is the only supported type currently) are only trusted once: for as long as it takes to load the managed key database and start the key maintenance process.

Traditional DNS responses are typically small in size (less than 512 bytes) and fit nicely into a small UDP packet. Extension mechanism for DNS (EDNS, or EDNS(0)) gives us a mechanism to send DNS data in larger packets over UDP. In order to support EDNS, both the DNS server and the network need to be properly prepared to support the larger packet size and multiple fragments.

This is important for DNSSEC, since the +do bit that signals DNSSEC-awareness is carried within EDNS, and DNSSEC responses are larger than traditional DNS. If DNS servers and network environment cannot support large UDP packets, it will cause retransmission over TCP, or the larger UDP responses will be discarded. Users will likely experience slow DNS resolution or unable to resolve certain names at all.

Note that EDNS applies whether or not you are validating DNSSEC because BIND has DNSSEC enabled by default.

Please see Section 2.3, “Network Requirements” for more information on what DNSSEC expects from the network environment.

BIND has been shipped with EDNS enabled by default for over a decade, and the UDP packet size is set to a maximum of 4096 bytes. So as the DNS administrator, there should not be any re-configuration needed. You can use dig to verify that your server supports EDNS and the UDP packet size it is allowing as follows:

$ dig @192.168.1.7 www.isc.org. A +dnssec +multiline

; <<>> DiG 9.10.0-P2 <<>> @192.168.1.7 www.isc.org. A +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63266
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.isc.org.		IN A

;; ANSWER SECTION:
www.isc.org.		23 IN A	149.20.64.69
www.isc.org.		23 IN RRSIG A 5 3 60 (
				20141029233238 20140929233238 4521 isc.org.
				DX5BaGVd4KzU2AIH911Kar/UmdmkARyPhJVLr0oyPZaq
				5zoobGqFI4efvzL0mcpncuUg3BSU5Q48WdBu92xinMdb
				E75zl+adgEBOsFgFQR/zqM3myt/8SngWm4+TQ3XFh9eN
				jqExHZZuZ268Ntlxqgf9OmKRRv8X8YigaPShuyU= )

;; Query time: 7 msec
;; SERVER: 192.168.1.7#53(192.168.1.7)
;; WHEN: Fri Oct 03 16:31:33 CST 2014
;; MSG SIZE  rcvd: 223

There is a helpful testing tool available (provided by DNS-OARC) that you can use to verify resolver behavior regarding EDNS support: https://www.dns-oarc.net/oarc/services/replysizetest/

So you made sure your name servers have EDNS enabled. That should be the end of the story, right? Unfortunately, EDNS is a hop-by-hop extension to DNS. This means the use of EDNS is negotiated between each pair of hosts in a DNS resolution process, which in turn means if one of your upstream name servers (for instance, your ISP's recursive name server that you forward to) does not support EDNS, you may experience DNS lookup failures or be unable to perform DNSSEC validation.

Okay, so both your recursive name server and your ISP's name servers support EDNS, we are all good here, right? Not so fast. As these large packets have to traverse through the network, the network infrastructure itself must allow them to pass.

When data is physically transmitted over a network, it has to be broken down into chunks. The size of the data chunk is known as Maximum Transmission Units (MTU), and it can be different from network to network. IP fragmentation occurs when a large data packet needs to be broken down into smaller chunks so that each chunk is smaller than the MTU, and these smaller chunks need to be reassembled back into the large data packet. IP fragmentation is not necessarily a bad thing, it most likely occurs on your network today.

Some network equipment, such as firewalls, may make assumptions about DNS traffic. One of these assumptions may be how large each DNS packet is. When a firewall sees a larger DNS packet than it expects, it either rejects the large packet or drops its fragments because the firewall thinks it's an attack. This configuration probably didn't cause problems in the past since traditional DNS packets are usually pretty small in size. However, with DNSSEC, these configurations need to be updated, since DNSSEC traffic regularly exceeds 1500 bytes (a common MTU value). If the configuration is not updated to support larger DNS packet size, it will often result in the larger packets being rejected, and to the end user it looks like the queries go un-answered. Or in the case of fragmentation, only a part of the answer made it to the validating resolver, and your validating resolver may need to re-ask the question again and again, creating the appearance "DNS/network is really slow" for the end users.

And while you're updating configuration on your network equipment, make sure TCP port 53 is also allowed for DNS traffic.

Yes. DNS uses TCP port 53 as a fallback mechanism, when it cannot use UDP to transmit data. This has always been the case even long before DNSSEC arrived at the scene. Traditional DNS relies on TCP 53 for operations such as zone transfer. The use of DNSSEC, or DNS with IPv6 records such as AAAA, increases the chance that DNS data will be transmitted on TCP.

Due to the increased packet size, DNSSEC may fall back to TCP more often then traditional (insecure) DNS. If your network is blocking or filtering TCP port 53 today, you may already experience instability with DNS resolution before deploying DNSSEC.

Everything in DNSSEC centers around keys, and we will begin by generating our own keys. In our example, we are keeping all the keys for example.com in its own directory, /etc/bind/keys/example.com.

# mkdir -p /etc/bind/keys/example.com
# cd /etc/bind/keys/example.com
# dnssec-keygen -a RSASHA256 -b 1024 example.com
Generating key pair...++++++ .............++++++ 
Kexample.com.+008+17694
# dnssec-keygen -a RSASHA256 -b 2048 -f KSK example.com
Generating key pair........................+++ ..................................+++ 
Kexample.com.+008+06817

This generated four key files in /etc/bind/keys/example.com, and the only one we care about for now is the KSK key, Kexample.com.+008+06817.key. Remember this file name: we will need it again shortly. Make sure these files are readable by named.

Refer to Section 2.1.3, “System Entropy” for information on how you might speed up the key generation process if your random number generator has insufficient entropy.

Below is a very simple named.conf, in our example environment, this file is /etc/bind/named.conf. The lines you most likely need to add are in bold.

options {
    directory "/etc/bind";
    recursion no;
    minimal-responses yes;
};

zone "example.com" IN {
    type master;
    file "db/example.com.db";
    key-directory "keys/example.com";
    inline-signing yes;
    auto-dnssec maintain;
};

When you are done updating the configuration file, tell named to reload:

# rndc reload
server reload successful

Your zone is now signed. Before moving on to the next step of coordinating with your parent zone, let's make sure everything looks good using delv. What we want to do is to simulate what a validating resolver would check, by telling delv to use a specific trust anchor.

First of all, we need to make a copy of the key Kexample.com.+008+06817.key for editing:

# cp /etc/bind/keys/example.com/Kexample.com.+008+06817.key /tmp/example.key

The original key file looks like this (actual key shortened for display, and comments omitted):

# cat /etc/bind/keys/example.com/Kexample.com.+008+06817.key
...
example.com. IN DNSKEY 257 3 8 AwEAAcWDps...lM3NRn/G/R

We want to edit the copy to the be the trusted-keys format, so that it looks like this:

# cat /tmp/example.key
trusted-keys {
    example.com. 257 3 8 "AwEAAcWDps...lM3NRn/G/R";
};

Now we can run the delv command and point it to using this trusted-key file to validate the answer it receives from the authoritative name server 192.168.1.13:

$ delv @192.168.1.13 -a /tmp/example.key +root=example.com example.com. SOA +multiline
; fully validated
example.com.		600 IN SOA ns1.example.com. admin.example.com. (
				2014112007 ; serial
				1800       ; refresh (30 minutes)
				900        ; retry (15 minutes)
				2419200    ; expire (4 weeks)
				300        ; minimum (5 minutes)
				)
example.com.		600 IN RRSIG SOA 8 2 600 (
				20150107091559 20141208081559 17694 example.com.
				LwG0rLOm9Q1Lu9bgIz1O+PTCwcCSs1Ev8Eqkqqd3gUJK
				qo0FSVv//axNVJFH2Lz8VLgFypD8xARWj1XQBD/9DIf6
				A3ncnrFymKdKze+2ghvTUxpwqctK4RF66mhu93e33+Ir
				QJVJgdHJVHudQWICA1AbIBYYzLGkKlp7JAJcgBM= )

Everything is done on our name server, now we need to generate some information to be uploaded to the parent zone to complete the chain of trust. The formats and the upload methods are actually dictated by your parent zone's administrator, so contact your registrar or parent zone administrator to find out what the actual format should be, and how to deliver or upload the information to your parent zone.

What about your zone between the time you signed it and the time your parent zone accepts the upload? Well, to the rest of the world, your zone still appears to be insecure. That is because when a validating resolver attempts to validate your domain name, it will eventually come across your parent zone, and your parent zone will indicate that you are not yet signed (as far as it knows). The validating resolver will then give up attempting to validate your domain name, and fall back to the insecure DNS. Basically, before you complete this final step with your parent zone, your zone is still insecure.

Here are some examples of what you may upload to your parent zone, actual keys shortened for display. Note that no matter what formats may be required, the end result will be the parent zone publishing DS record(s) based on the information you upload. Again, contact your parent zone administrator(s) to find out what is the correct format for you.

The DS record format may be generated using the dnssec-dsfromkey tool which is covered in Section 4.4.1, “DS Record Format”. For more details and examples on how to work with your parent zone, please see Section 4.4, “Working with Parent Zone”

Congratulations, your zone is signed, your slave servers have received the new zone data, and the parent zone has accepted your upload and published your DS record. Your zone is now officially DNSSEC-enabled. What happens next? Well, there are a few maintenance tasks you need to do on a regular basis, which you can find in Section 4.6, “Maintenance Tasks”. As for updating your zone file, you can continue to update them the same way you have been prior to signing your zone, the normal work flow of editing zone file and using the rndc command to reload the zone still works the same, and although you are editing the unsigned version of the zone, BIND will generate the signed version automatically.

Curious as to what all these commands did to your zone file? Read on to Section 4.1.6, “Your Zone, Before and After DNSSEC” and find out. If you are interested in how you can roll this out to your existing master and slave name servers, check out Section 7.1, “Inline Signing Recipes” in Chapter 7, Recipes.

In the previous section Section 4.1, “Easy Start Guide for Signing Authoritative Zones”, we provided the minimal amount of information to essentially convert a traditional DNS zone into a DNSSEC-enabled zone. This is what the zone looked like before we started:

$ dig @192.168.1.13 example.com. AXFR +multiline +onesoa

; <<>> DiG 9.10.1 <<>> @192.168.1.13 example.com. AXFR +multiline +onesoa
; (1 server found)
;; global options: +cmd
example.com.		600 IN SOA ns1.example.com. admin.example.com. (
				2014102100 ; serial
				1800       ; refresh (30 minutes)
				900        ; retry (15 minutes)
				2419200    ; expire (4 weeks)
				300        ; minimum (5 minutes)
				)
example.com.		600 IN NS ns1.example.com.
ftp.example.com.	600 IN A 192.168.1.200
ns1.example.com.	600 IN A 192.168.1.1
web.example.com.	600 IN CNAME www.example.com.
www.example.com.	600 IN A 192.168.1.100

Below shows the test zone example.com after we have reloaded the server configuration. As you can see, the zone grew in size, and the number of records multiplied:

# dig @192.168.1.13 example.com. AXFR +multiline +onesoa

; <<>> DiG 9.10.1 <<>> @192.168.1.13 example.com. AXFR +multiline +onesoa
; (1 server found)
;; global options: +cmd
example.com.		600 IN SOA ns1.example.com. admin.example.com. (
				2014102104 ; serial
				1800       ; refresh (30 minutes)
				900        ; retry (15 minutes)
				2419200    ; expire (4 weeks)
				300        ; minimum (5 minutes)
				)
example.com.		300 IN RRSIG NSEC 8 2 300 (
				20141126120153 20141027112239 60798 example.com.
				U1je2BEXY7S/u4An8sKEp2Cb8b90+9mNBoFb9nXgkTvC
				cJkT/4OIUIaO7EbsIASmlzjDwJEKSO/nPDFg3y6tsR0m
				GT7H7AYAouwBhUlIrDrGQpxqRLJXA1kPkxboX4M2JGx4
				rBcBsN/7lG5CGbjtLW3PMnJRELE5fBJBLZM1KLo= )
example.com.		300 IN NSEC ftp.example.com. NS SOA RRSIG NSEC DNSKEY TYPE65534
example.com.		600 IN RRSIG NS 8 2 600 (
				20141126115318 20141027112239 60798 example.com.
				TGC1gAksxHHDoltjJ8ETJ9qdr5MzFjA05vEllSNWBFe7
				O71Payf8o4MISHNeUoZpu7Ys4zBiTRLqUaLeI0oSEnzM
				r2QJkrfUHl1k8D/wCWApEUhMa1GxLIKMsEfgd3D5nK52
				6LAVNihx5BKC1YxuYZXhhBMYQm7bIlUXFvxl3uE= )
example.com.		600 IN RRSIG SOA 8 2 600 (
				20141126122239 20141027112239 60798 example.com.
				0ntLprFpg9bKWs5ArGvpZq8uFa9QPEfl6bOmfIwbNnEp
				9PgBS97icRs27JDgIXGM4dWxXiPVX6sZ8jFulSp2mi2v
				4dhtqMfb4S/rfxSmCphIz5PA+bngKSr5fhRI6tTM8fW1
				l5V3zfKCPFracE0CgdcWIt0xViEs56Axj942f5w= )
example.com.		0 IN RRSIG TYPE65534 8 2 0 (
				20141126120153 20141027112239 60798 example.com.
				Sv+7vfHXz4zlLSEuWs5Bt5boqSDVCK2GcOgAzVXnW9/0
				zgk3v8VwSXRTRnwdsvl3SK6YsM9S/HNXk32AQs2PjXf4
				2/cmv6VCOGSVGin/L5k4KWjpy0ESV2iY0hIIyeXWqUdB
				ZUCu1+2GhHiA5+gKODn/8sg6x04g+lZe6wuhU44= )
example.com.		600 IN RRSIG DNSKEY 8 2 600 (
				20141126122239 20141027112239 45319 example.com.
				F2vrBJqvloP5yNE6X1+b1XJ4gY6DlH1oyJz6pSULmGgQ
				FFztyrCJoV4MI6TeFRXJKLTePewjcTzKlaRKJHZRElcM
				QaClWr6RdZ2Uc1fFOBgYocrDZtGWdTVg7XCiLJ/ubrDH
				7et9rSexmKEwI44T4Vf7w3e+kUQSzMBGfA9Z5Q8WnnBW
				IDn4QFqRx0B02bVLV4giJbVp649ukIApVoHSpJvhrWq8
				eSSdP2ojymzr4gAuQZzmZUJnxp7Q3ktuQgIokhLG4FDH
				/O9qnhnOkUZFsxbBaDYVn5TIl1Kkmn3LH98JQE0z8a7D
				WfqAPAFy0rKHkvyOA8FlimDW09OYeJS00A== )
example.com.		600 IN RRSIG DNSKEY 8 2 600 (
				20141126122239 20141027112239 60798 example.com.
				PoUdallJO0ZF3iFmRoGoKh/iLAJVn52ABVEVku9LK34C
				oh4Y29rgK4jd3DwxU7zDLadVs0Fo3JFHp2jdYCEm03BS
				XE6d0cijZP5aFt8rO/grO/qbkdv+ScEi1kOhCKcvt3Kg
				1mXhiZt4Jx3LeisUpD9mGa+m9ehcPYlAHPKoZMg= )
example.com.		0 IN TYPE65534 \# 5 ( 08B1070001 )
example.com.		0 IN TYPE65534 \# 5 ( 08ED7E0001 )
example.com.		600 IN DNSKEY 256 3 8 (
				AwEAAfbc/0ESumm1mPVkm025PfHKHNYW62yx0wyLN5LE
				4DifN6FzIVSKSGdMOdq+z6vFGxzzjPDz7QZdeC6ttIUA
				Bo4tG7dDrsWK+tG5cm4vuylsEVbnnW5i+gFG/02+RYmZ
				ZT9AobXB5bVjfXl9SDBgpBluB35WUCAnK9WkRRUS08lf
				) ; ZSK; alg = RSASHA256; key id = 60798
example.com.		600 IN DNSKEY 257 3 8 (
				AwEAAb4N53kPbdRTAwvJT8OYVeVhQIldwppMy7KBJ+8k
				Uggx2PU3yP/qlq4Zjl0MMmqRiJhD/S+z9cJLNTZ9tHz1
				7aZQjFyGAyuU3DGW16xfMolcIn+c8TpPCzBOFhxk6jvO
				VLlz+Wgyi1ES+t29FjYYv5cVNRPmxXLRjlHFdO1DzX3N
				dmcUoZ+VVJCvaML9+6UpL/6jitNsoU8JHnxT9B2CGKcw
				N7VaK4l9Ida2BqY3/4UVqWzhj03/M5LK6cn1pEQbQMtY
				R0TNJURBKdK8bH663h98i23tVX0/85IsCVBL4Dd2boa3
				/7HPp7uZN1AjDvcRsOh1mqixwUGmVm1EskDIMy8=
				) ; KSK; alg = RSASHA256; key id = 45319
example.com.		600 IN NS ns1.example.com.
ftp.example.com.	600 IN RRSIG A 8 3 600 (
				20141126115318 20141027112239 60798 example.com.
				PNATas8HPjc6tm7Ldfk7P61IlRVSQW085P9lDw8qwITc
				TghDdAXHJBkCTXaDRWPyQZbGI5fNcxWLkf/HRbKREzQs
				eyztZj2OBnBnnK0t8SWLyM4+OMsGH17z4ZvBmPO/Wgju
				iSm98reH7J87yRlUMQHdPSwAP6q5tZeJbwpSkao= )
ftp.example.com.	300 IN RRSIG NSEC 8 3 300 (
				20141126115318 20141027112239 60798 example.com.
				ohuvpkqlNR+TYOG79JizEV+SFjVbUKSB3hEfHOJszCIr
				bcdPKTS0GgQS62N4ISwfvb735oQzc8pI5R+f+8MMn5c9
				/yRnArTpPJOKDnyIiMaMLBU5sEp5wI+OLsLFMkLef4iK
				gn+j608Qnoo7dXtWWQPv85FyaT9j3C+EV6rglCk= )
ftp.example.com.	300 IN NSEC ns1.example.com. A RRSIG NSEC
ftp.example.com.	600 IN A 192.168.1.200
ns1.example.com.	600 IN RRSIG A 8 3 600 (
				20141126115318 20141027112239 60798 example.com.
				z1rnlU9oVnIhwxQey3Zo6ENYmWXtf97RiZng3u6VkE0n
				yUC5S3sseZgD8Vc+uJsKVAvafM/k7NgS+P3pe5gN01Ln
				+geKEMZ3pCHpzHG4UgJj4Xw/iuWOVAFURD26GNnPppDK
				RNYPWIhA/9FF18vI3V9evNcHGxN+7rOOXF8Qbss= )
ns1.example.com.	300 IN RRSIG NSEC 8 3 300 (
				20141126115318 20141027112239 60798 example.com.
				chH7c6aW6Qk14d4LB866jva9OcH52pJkeHpdslVmUbJ2
				OkJQNhbpOekSjsroxDU4av3/Y49Dtg0lqoISvMMqwE5X
				5sKmn+CMKFfMmi22ui+RsPXyDqjkx+JOsi/7kCx7DFJz
				jF0a6KcsTWNV2QfZjQ50RyrSBBOkw6aqdUC3oF8= )
ns1.example.com.	300 IN NSEC web.example.com. A RRSIG NSEC
ns1.example.com.	600 IN A 192.168.1.1
web.example.com.	600 IN RRSIG CNAME 8 3 600 (
				20141126115318 20141027112239 60798 example.com.
				VgHPC0WllAlHY56xMF3j8FI7MsxDhLJJBDBMSVSQpQkA
				z81kfInYQL4YpAt25WrH7xt4pCmjVl3kUcDGAWWuSiQy
				nh2O4CoY/tSqQ7Sr9UnE5SIvpW5yws8iROOHvJYuKAmu
				8B3gYw1gp9xCMS4iBOIXTTq1KV2OHwo0cPXVyfI= )
web.example.com.	300 IN RRSIG NSEC 8 3 300 (
				20141126115318 20141027112239 60798 example.com.
				zh+9fnIQlfpvc0oFRnNIPJoL/S5RQF4HuGwmLxoCxRVp
				FCQoZbzNB0IVvaA+0XEslcHq3v4+0j9EeKKQw7xORaGu
				TrzcoRGbjuKZlpvnVlxYkjCiEKVbkXd5yEMnbgolFkhH
				NjFlozSyzypY0TY0UVRPXWhZ2shASae/ImqFiug= )
web.example.com.	300 IN NSEC www.example.com. CNAME RRSIG NSEC
web.example.com.	600 IN CNAME www.example.com.
www.example.com.	600 IN RRSIG A 8 3 600 (
				20141126120153 20141027112239 60798 example.com.
				TLkMRs7I3QW8HRS3trNG307Y0/drO4k8uG8Bv8856qPo
				33rbEajV49XBBQ+w8jynfKwxMNDfJhpSG0gxo7+0m75Y
				HRBZ9Xe3EAMNt2/iu0CL6NHyN99qF9TPNbYnD2Zw077L
				GSDOua1KFMxDqFU7rU0+YlKRGbSk1rqAJBqKEH4= )
www.example.com.	300 IN RRSIG NSEC 8 3 300 (
				20141126120153 20141027112239 60798 example.com.
				GSyFVBgMROqDuoSJoDegX3EkdqA90skBTvi9tkPxoQPo
				i8LlaD+wRmcXpYKE3vf/y0WpOOVQXbasyfFk8wGzFsde
				fqpFsscbz3OYgnkwYcTvGXZF9802ytiC5txli9uxUqjc
				lGL+SDl0woYhecwJD63fTDIMszlVR/eptIL9dLc= )
www.example.com.	300 IN NSEC example.com. A RRSIG NSEC
www.example.com.	600 IN A 192.168.1.100

But this is a really messy way to tell if your zone is properly setup with DNSSEC. Fortunately, there are tools to help us with that. Read on to Section 4.2, “How To Test Authoritative Zones (So You Think You Are Signed)” to learn more.

One of the ways to see if your zone is signed, is to check for the presence of DNSKEY record types. In our example, we created two keys, and we expect to see both keys returned when we query for them.

$ dig @192.168.1.13 example.com. DNSKEY +multiline +noall +answer

; <<>> DiG 9.10.1 <<>> @192.168.1.13 example.com. DNSKEY +multiline +noall +answer
; (1 server found)
;; global options: +cmd
example.com.		300 IN DNSKEY 256 3 8 (
				AwEAAclob7q+ccvDwaTVuMM2ddGIynWyMwaZlhFrU6cC
				0qknWoPpkq0gIwTrYf3DJY+eIKPVHxrM+o2AoRIVhubG
				jfv1bT5wTYrawZstS84ejCQ+ehA+8DxKyeWUEzW0ZMBe
				OhyeG0cuQVK/p6Z1E096JLu0DjgbabLspequkw4M+HT7
				) ; ZSK; alg = RSASHA256; key id = 57009
example.com.		300 IN DNSKEY 257 3 8 (
				AwEAAdQ2ctHx8VmryndiOgpchXPdj3NwxMeUvAre6uYI
				5KELlFJUghTHrz+/CzEc8CXG8wwQ4ZvAey0FGV2nJAFC
				ENMxoRiCz0oSiQQxryNhACd3RnE2/D7G+ShwlOM6w53E
				wUJ/lsgu5UevSxFC+eA3fKeL3TWR44PH4iJQp9QmfW5v
				7qG8Sic/HQvBGBdOGfFtHAl0a4jDPBi57imS4YsHcUYD
				9bsWmhYWSHJKZ66+JnTiMS0nQM69YwBF43QfDKurs5R6
				qPUDiBlaMCzSxmlaBU6fsI1Mu/yIU8w1ewy26a42rUTU
				rPBC3Oa/zf9VQ8kpUrMZgJ7LEAA4xmR+qwWDh6U=
				) ; KSK; alg = RSASHA256; key id = 28267

Another way to see if your zone data is signed is to check for the presence of signature. With DNSSEC, every record^[3]now comes with at least one corresponding signature known as RRSIG.

$ dig @192.168.1.13 example.com. SOA +dnssec +multiline

; <<>> DiG 9.10.1 <<>> @192.168.1.13 example.com. SOA +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31466
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;example.com.		IN SOA

;; ANSWER SECTION:
example.com.		300 IN SOA ns1.example.com. dnsadmin.example.com. (
				2014102111 ; serial
				10800      ; refresh (3 hours)
				1080       ; retry (18 minutes)
				2419200    ; expire (4 weeks)
				900        ; minimum (15 minutes)
				)
example.com.		300 IN RRSIG SOA 8 2 300 (
				20141121122105 20141022112105 57009 example.com.
				NqPGNLkUs40Lg/qq7Fv+bgyCwVB4s9PsHQOK6p9ZWWk3
				36z2Qz2WjM+Q19SlVBAPux9jijvcRcjGb6KREuxER9uX
				wdVeiGx9a4X+PaO3qTqdkiXuGS2XkK1kBm1CgwhVHTYV
				/nxVPrckU4/mpeUoFVjMnT49JkVJmgck63esPEU= )

The serial number was automatically incremented from the old, unsigned version. Named keeps track of the serial number of the signed version of the zone independently of the unsigned version. If the unsigned zone is updated with a new serial number that's higher than the one in the signed copy, then the signed copy will be increased to match it, but otherwise the two are kept separate.

Our original zone file example.com.db remains untouched, named has generated 3 additional files automatically for us (shown below). The signed DNS data is stored in example.com.db.signed and in the associated journal file.

# cd /etc/bind/db
# ls
example.com.db	example.com.db.jbk  example.com.db.signed  example.com.db.signed.jnl

A quick description of each of the files:

These files are stored in raw (binary) format for faster loading. You could reveal the human-readable version by using named-compilezone as shown below. In the example below, we are running the command on the raw format zone example.com.db.signed to produce a text version of the zone example.com.text:

# named-compilezone -f raw -F text -o example.com.text example.com example.com.db.signed
zone example.com/IN: loaded serial 2014112008 (DNSSEC signed)
dump zone to example.com.text...done
OK

Although this is not strictly related to whether or not the zone is signed, a critical part of DNSSEC is the trust relationship between the parent and child. Just because we, the child, have all the correctly signed records in our zone doesn't mean it can be fully validated by a validating resolver, unless our parent's data agrees with us. To check if our upload to the parent is successful, ask the parent name server for the DS record of our zone, and we should get back the DS record(s) containing the information we uploaded in Section 4.1.4, “Upload to Parent Zone”:

$ dig example.com. DS

; <<>> DiG 9.10.1 <<>> example.com. DS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49949
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.			IN	DS

;; ANSWER SECTION:
example.com.  61179	IN	DS	28267 8 1 66D47CE4B4F551BE5EDA43AC5F3109E8C98E2FAE
example.com.  61179	IN	DS	28267 8 2 71D9335416B7132519190A95685E18CBF478DCF4CA98867062777938F8FEAB89

The easiest ways to see if your domain name is fully secured is to use one of these excellent online tools.

4.2.5.1. Verisign DNSSEC Debugger

URL: http://dnssec-debugger.verisignlabs.com/

This tool shows a nice summary of checks performed on your domain name, and you can expand to view more details for each of the items checked to get a detailed report.

Figure 4.1. Verisign DNSSEC Debugger

4.2.5.2. DNSViz

URL: http://dnsviz.net/

DNSViz provides a visual analysis of the DNSSEC authentication chain for a domain name and its resolution path in the DNS namespace.

Figure 4.2. DNSViz

In Section 4.1.1, “Generate Keys”, we generated two pairs of keys: a pair of Zone Signing Keys (ZSK) and a pair of Key Signing Keys (KSK). To quickly summarize, ZSKs sign the bulk of the zone, but KSKs only sign the DNSKEYs. This makes ZSKs easier to change (since you can do so without updating the parent). We generated keys by running these commands:

# cd /etc/bind/keys/example.com
# dnssec-keygen -a RSASHA256 -b 1024 example.com
Generating key pair...++++++ .............++++++ 
Kexample.com.+008+17694
# dnssec-keygen -a RSASHA256 -b 2048 -f KSK example.com
Generating key pair........................+++ ..................................+++ 
Kexample.com.+008+06817

With these commands, we generated NSEC3-compatible key pairs (see Section 6.2.2, “NSEC3” to learn more about NSEC3). In the end, four key files were created in /etc/bind/keys/example.com:

The two files ending in .private need to be kept, well, private. These are your private keys, guard them carefully. You should at the very least protect them via file permission settings. Please see Section 6.3, “Key Storage” for more information about how to store your keys.

The two files ending in .key are your public keys. One is the zone-signing key (ZSK), and one is the key-signing Key (KSK). We can tell which is which by looking at the actual file contents (actual keys shortened for display):

# cat Kexample.com.+008+06817.key
; This is a key-signing key, keyid 6817, for example.com.
; Created: 20141120094612 (Thu Nov 20 17:46:12 2014)
; Publish: 20141120094612 (Thu Nov 20 17:46:12 2014)
; Activate: 20141120094612 (Thu Nov 20 17:46:12 2014)
example.com. IN DNSKEY 257 3 8 AwEAAcWDps...lM3NRn/G/R
# cat Kexample.com.+008+17694.key
; This is a zone-signing key, keyid 17694, for example.com.
; Created: 20141120094536 (Thu Nov 20 17:45:36 2014)
; Publish: 20141120094536 (Thu Nov 20 17:45:36 2014)
; Activate: 20141120094536 (Thu Nov 20 17:45:36 2014)
example.com. IN DNSKEY 256 3 8 AwEAAcjGaU...zuu55If5

The first line of each file tell us what type of key it is. Also, by looking at the actual DNSKEY record, we could tell them apart: 256 is ZSK, and 257 is KSK.

So, this is a ZSK:

# cat Kexample.com.+008+17694.key
...
example.com. IN DNSKEY 256 3 8 AwEAAcjGaU...zuu55If5

And this is a KSK:

# cat Kexample.com.+008+06817.key
...
example.com. IN DNSKEY 257 3 8 AwEAAcWDps...lM3NRn/G/R

The parameters we showed in the example, algorithm of RSASHA256, key length of 1024 and 2048, and the use of NSEC3 are just suggestions, you need to evaluate what values work best for your environment. To learn more about key generation, different algorithm choices, and key sizes, see Section 6.1, “Key Generation”.

The table below summarizes the usage and frequency of use for each of the keys.

In Section 4.1.2, “Reconfigure BIND”, we highlighted a few lines, let's explain what each one of them does.

options {
    directory "/etc/bind";
    recursion no;
    minimal-responses yes;
    dnssec-enable yes;
};

zone "example.com" IN {
    type master;
    file "db/example.com.db";
    key-directory "keys/example.com";
    inline-signing yes;
    auto-dnssec maintain;
};

zone "example.com" IN {
    key-directory "keys/example.com";
};

zone "example.com" IN {
    inline-signing yes;
};

zone "example.com" IN {
    auto-dnssec maintain;
};

Below is an example of generating DS record formats from the KSK we created earlier (Kexample.com.+008+28267.key) using two different secure hashing algorithms (SHA-1 and SHA-256, respectively):

# cd /etc/bind/keys/example.com
# dnssec-dsfromkey -a SHA-1 Kexample.com.+008+06817.key
example.com. IN DS 6817 8 1 59194A835ACD78D25D538D5F35CA043A8F3F4446
# dnssec-dsfromkey -a SHA-256 Kexample.com.+008+06817.key
example.com. IN DS 6817 8 2 2A5F1DF55D5E64CBD7BCFE1EFA6E9586AF335FA56A2473296E975B89AFD31E11

Some registrars many ask you to manually specify the types of algorithm and digest used. In the first example, 8 represents the algorithm used, and 1 represents the digest type (SHA-1); in the second example, 8 is the algorithm, and 2 is the digest type (SHA-256). The key tag or key ID is 28267.

Alternatively, you could generate it from the DNSKEY records like this:

$ dig @192.168.1.13 example.com. DNSKEY | dnssec-dsfromkey -f - example.com
example.com. IN DS 6817 8 1 59194A835ACD78D25D538D5F35CA043A8F3F4446
example.com. IN DS 6817 8 2 2A5F1DF55D5E64CBD7BCFE1EFA6E9586AF335FA56A2473296E975B89AFD31E11

Below is an example of a different key ID (16027) using DNSKEY format (actual key shortened for display):

example.com. 172800 IN DNSKEY 257 3 8 (AwEAAbGOPf...AX2QHMY8=) ; key id = 16027

The key itself is easy to find (it's kind of hard to miss that big long base64 string) in the file. Remember, we want the KSK, so look for the presence of 257.

# cd /etc/bind/keys/example.com
# cat Kexample.com.+008+06817.key
; This is a key-signing key, keyid 6817, for example.com.
; Created: 20141120094612 (Thu Nov 20 17:46:12 2014)
; Publish: 20141120094612 (Thu Nov 20 17:46:12 2014)
; Activate: 20141120094612 (Thu Nov 20 17:46:12 2014)
example.com. IN DNSKEY 257 3 8 AwEAAcWDps...lM3NRn/G/R

Some registrars may ask you to manually specify the type of algorithm used and the key tag number. In our example above, the chosen algorithm is 8, and the key ID is 6817.

This format is very similar to the DNSKEY format, the differences are mostly cosmetic. Below is an example of trusted-keys format (again, actual key shortened for display):

"example.com." 257 3 8 "AwEAAbGOPf...9AX2QHMY8=";

Assuming you are rolling your ZSK every year on January 1st, below is the timeline of what should happen:

This may look like a lot of work, but with inline-signing and auto-dnssec, most of these are automated. The only things that need to be done manually are just the first two items:

For an example of how to execute a ZSK rollover, please see Section 7.2.1, “ZSK Rollover Recipe”.

KSK rollover is very similar to ZSK, with the addition of interacting with the parent zone. In fact, as you can see below, the timeline looks nearly identical to the ZSK rollover, with the addition of interaction with parent zone:

Unfortunately, as of this writing, KSK rollover involves a lot of manual steps. As described above, the only automated tasks are the ones that occur on the day of the rollover (January 1st), everything else needs to be done manually. To see an example of how to perform a KSK rollover, please see Section 7.2.2, “KSK Rollover Recipe”.

A word of caution: before you enable debug logging, be aware that this may dramatically increase the load on your name servers.

With that said, sometimes it may become necessary to temporarily enable BIND debug logging to see more details of how DNSSEC is validating (or not). DNSSEC-related messages are not recorded in syslog by default, even if query log is enabled, only DNSSEC errors will show up in syslog. Enabling debug logging is not recommended for production servers, as it increases load on the server.

The example below shows how to enable debug level 3 (to see full DNSSEC validation messages) in BIND 9 and have it sent to syslog:

logging {
   channel dnssec_log {
        syslog daemon;
        severity debug 3;
        print-category yes;
    };
    category dnssec { dnssec_log; };
};

The example below shows how to log DNSSEC messages to their own file:

logging {
    channel dnssec_log {
        file "/var/log/dnssec.log";
        severity debug 3;
    };
    category dnssec { dnssec_log; };
};

After restarting BIND, a large number of log messages will appear in syslog. The example below shows the log messages as a result of successfully looking up and validating the domain name www.isc.org.

validating @0xb8012d88: . NS: starting
validating @0xb8012d88: . NS: attempting positive response validation
validating @0xb805a9b0: . DNSKEY: starting
validating @0xb805a9b0: . DNSKEY: attempting positive response validation
validating @0xb805a9b0: . DNSKEY: verify rdataset (keyid=19036): success
validating @0xb805a9b0: . DNSKEY: signed by trusted key; marking as secure
validator @0xb805a9b0: dns_validator_destroy
validating @0xb8012d88: . NS: in fetch_callback_validator
validating @0xb8012d88: . NS: keyset with trust 8
validating @0xb8012d88: . NS: resuming validate
validating @0xb8012d88: . NS: verify rdataset (keyid=8230): success
validating @0xb8012d88: . NS: marking as secure, noqname proof not needed
validator @0xb8012d88: dns_validator_destroy
validating @0xb8012d88: www.isc.org A: starting
validating @0xb8012d88: www.isc.org A: attempting positive response validation
validating @0xb805a9b0: isc.org DNSKEY: starting
validating @0xb805a9b0: isc.org DNSKEY: attempting positive response validation
validating @0xb827e298: isc.org DS: starting
validating @0xb827e298: isc.org DS: attempting positive response validation 
validating @0xb827fd18: org DNSKEY: starting
validating @0xb827fd18: org DNSKEY: attempting positive response validation 
validating @0xb8281798: . NS: starting
validating @0xb8281798: . NS: attempting positive response validation 
validating @0xb8281798: . NS: keyset with trust 8
validating @0xb8280790: org DS: starting
validating @0xb8280790: org DS: attempting positive response validation 
validating @0xb8280790: org DS: keyset with trust 8
validating @0xb8280790: org DS: verify rdataset (keyid=8230): success
validating @0xb8280790: org DS: marking as secure, noqname proof not needed
validator @0xb8280790: dns_validator_destroy
validating @0xb827fd18: org DNSKEY: in dsfetched
validating @0xb827fd18: org DNSKEY: dsset with trust 8
validating @0xb827fd18: org DNSKEY: verify rdataset (keyid=21366): success
validating @0xb827fd18: org DNSKEY: marking as secure (DS)
validator @0xb827fd18: dns_validator_destroy
validating @0xb827e298: isc.org DS: in fetch_callback_validator
validating @0xb827e298: isc.org DS: keyset with trust 8
validating @0xb827e298: isc.org DS: resuming validate
validating @0xb827e298: isc.org DS: verify rdataset (keyid=33287): success
validating @0xb827e298: isc.org DS: marking as secure, noqname proof not needed
validator @0xb827e298: dns_validator_destroy
validating @0xb805a9b0: isc.org DNSKEY: in dsfetched 
validating @0xb805a9b0: isc.org DNSKEY: dsset with trust 8
validating @0xb805a9b0: isc.org DNSKEY: verify rdataset (keyid=12892): success
validating @0xb805a9b0: isc.org DNSKEY: marking as secure (DS)
validator @0xb805a9b0: dns_validator_destroy
validating @0xb8012d88: www.isc.org A: in fetch_callback_validator

Similar to Lame Delegation in traditional DNS, this refers to the symptom when the parent zone holds a set of DS records that point to something that does not exist in the child zone. The resulting symptom is that the entire child zone may "disappear", being marked as bogus by validating resolvers.

Below is an example attempting to resolve the A record for a test domain name www.example.com. From the user's perspective, as described in Section 3.2.5, “How Do I know I Have a Validation Problem?”, only SERVFAIL message is returned. On the validating resolver, we could see the following messages in syslog:

named[6703]: error (no valid RRSIG) resolving 'example.com/DNSKEY/IN': 149.20.61.151#53
named[6703]: error (broken trust chain) resolving 'www.example.com/DS/IN': 149.20.61.151#53
named[6703]: error (broken trust chain) resolving 'www.example.com/A/IN': 149.20.61.151#53

This gives us a hint that it is a broken trust chain issue. Let's take a look at the DS records that are published by querying one of the public DNS resolvers that supports DNSSEC. We have highlighted in the key tag ID returned, and shortened some keys for display:

$ dig @8.8.8.8 example.com. DS

; <<>> DiG 9.10.1 <<>> @8.8.8.8 example.com. DS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9640
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;example.com.		IN	DS

;; ANSWER SECTION:
example.com.	21599	IN	DS	53476 8 2 1544D......7DDA7
example.com.	21599	IN	DS	53476 8 1 CD2AF...0B47B

;; Query time: 212 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Nov 27 17:23:42 CST 2014
;; MSG SIZE  rcvd: 133

Next, we query for the DNSKEY and RRSIG of example.com, to see if there's anything wrong. Since we are having trouble validating, we flipped on the +cd option to disable checking for now to get the results back, even though they do not pass the validation tests. The +multiline option tells dig to print the type, algorithm type, and key id for DNSKEY records. Again, key tag ID's are highlighted, and some long strings are shortened for display:

$ dig @8.8.8.8 example.com. DNSKEY +dnssec +cd +multiline

; <<>> DiG 9.10.1 <<>> @8.8.8.8 example.com. DNSKEY +dnssec +cd +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20329
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;example.com.	IN DNSKEY

;; ANSWER SECTION:
example.com.	299 IN DNSKEY 257 3 8 (
				AwEAAePggU...0VPPEX+DE=
				) ; KSK; alg = RSASHA256; key id = 48580
example.com.	299 IN DNSKEY 256 3 8 (
				AwEAAbMZp6...NRJnwyC/uX
				) ; ZSK; alg = RSASHA256; key id = 60426
example.com.	299 IN RRSIG DNSKEY 8 2 300 (
				20141227074820 20141127064820 48580 example.com.
				ph3eBXsBQy...fQTRTlpg== )
example.com.	299 IN RRSIG DNSKEY 8 2 300 (
				20141227074820 20141127064820 60426 example.com.
				VaQ0INIa3a...nj3YTPv5A= )

;; Query time: 368 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Nov 28 11:33:00 CST 2014
;; MSG SIZE  rcvd: 961

Here is our problem: the parent zone is telling the world that example.com is using the key 53476, but the authoritative servers are saying: no no no, I am using keys 48580 and 60426. There might be several causes for this mismatch, one possibility is that a malicious attacker has compromised one side and change the data. The more likely scenario is that the DNS administrator for the child zone did not upload the correct key information to the parent zone.

In DNSSEC, every record will come with at least one RRSIG, and RRSIG contains two timestamps indicating when it starts becoming valid, and when it expires. If the validating resolver's current system time does not fall within the RRSIG two timestamps, the following error messages occur in BIND debug log.

First, the example below shows the log messages when the RRSIG has expired. This could mean the validating resolver system time is incorrectly set too far in the future, or the zone administrator has not kept up with RRSIG maintenance.

validating @0xb7b839b0: . DNSKEY: verify failed due to bad signature (keyid=19036): RRSIG has expired

The logs below show RRSIG validity period has not begun. This could mean validation resolver system is incorrectly set too far in the past, or the zone administrator has incorrectly generated signatures for this domain name.

validating @0xb7c1bd88: www.isc.org A: verify failed due to bad signature (keyid=4521): RRSIG validity period has not begun

As we have seen in the section Section 3.4, “Trust Anchors”, whenever a DNSKEY is received by the validating resolver, it is actually compared to the list of keys the resolver has explicitly trusted to see if further action is needed. If the two keys match, the validating resolver stops performing further verification and returns the answer(s) as validated.

But what if the key file on the validating resolver is misconfigured or missing? Below we show some examples of log messages when things are not working properly.

First of all, if the key you copied is malformed, BIND will not even start up and you will likely find this error message in syslog:

named[18235]: /etc/bind/named.conf.options:29: bad base64 encoding
named[18235]: loading configuration: failure

If the key is a valid base64 string, but the key algorithm is incorrect, or if the wrong key is installed, the first thing you will notice is that pretty much all of your DNS lookups result in SERVFAIL, even when you are looking up domain names that have not been DNSSEC-enabled. Below shows an example of querying a recursive server 192.168.1.7:

$ dig @192.168.1.7 www.example.com. A

; <<>> DiG 9.10.1 <<>> @192.168.1.7 www.example.com. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 8093
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.example.com.			IN	A

delv shows similar result:

$ delv @192.168.1.7 www.example.com. +rtrace
;; fetch: www.example.com/A
;; resolution failed: failure

The next symptom you will see is in the DNSSEC log messages:

validating @0xb8b18a38: . DNSKEY: starting
validating @0xb8b18a38: . DNSKEY: attempting positive response validation
validating @0xb8b18a38: . DNSKEY: unable to find a DNSKEY which verifies the DNSKEY RRset and also matches a trusted key for '.'
validating @0xb8b18a38: . DNSKEY: please check the 'trusted-keys' for '.' in named.conf.

This is a simple yet common issue. If the keys files were present but not readable by named, the syslog messages are clear, as shown below:

named[32447]: zone example.com/IN (signed): reconfiguring zone keys
named[32447]: dns_dnssec_findmatchingkeys: error reading key file Kexample.com.+008+06817.private: permission denied
named[32447]: dns_dnssec_findmatchingkeys: error reading key file Kexample.com.+008+17694.private: permission denied
named[32447]: zone example.com/IN (signed): next key event: 27-Nov-2014 20:04:36.521

However, if no keys are found, the error is not as obvious. Below shows the syslog messages after executing rndc reload, with the key files missing from the key directory:

named[32516]: received control channel command 'reload'
named[32516]: loading configuration from '/etc/bind/named.conf'
named[32516]: reading built-in trusted keys from file '/etc/bind/bind.keys'
named[32516]: using default UDP/IPv4 port range: [1024, 65535]
named[32516]: using default UDP/IPv6 port range: [1024, 65535]
named[32516]: sizing zone task pool based on 6 zones
named[32516]: the working directory is not writable
named[32516]: reloading configuration succeeded
named[32516]: reloading zones succeeded
named[32516]: all zones loaded
named[32516]: running
named[32516]: zone example.com/IN (signed): reconfiguring zone keys
named[32516]: zone example.com/IN (signed): next key event: 27-Nov-2014 20:07:09.292

This happens to look exactly the same as if the keys were present and readable, and named loaded the keys and signed the zone. It will even generate the internal (raw) files:

# cd /etc/bind/db
# ls
example.com.db	example.com.db.jbk  example.com.db.signed

If named really loaded the keys and signed the zone, you should see the following files:

# cd /etc/bind/db
# ls
example.com.db	example.com.db.jbk  example.com.db.signed  example.com.db.signed.jnl

So, unless you see the *.signed.jnl file, your zone has not been signed.

Yes and no. Good security practice suggests that you should use unique key pairs for each zone, just like how you should have different passwords for your email account, social media login, and online banking credentials. On a technical level, this is completely feasible, but then multiple zones are at risk when one key pair is compromised. If you have hundreds or thousands (or even hundreds of thousands) of zones to administer, a single key pair for all might be less error-prone to manage. You may choose to use the same approach to password management: use unique passwords for your bank accounts and shopping sites, but use a standard password for your not-very-important logins. So categorize your zones, high valued zones (or zones that have specific key rollover requirements) get their own key pairs, while other more "generic" zones can use a single key pair for easier management.

No, it is not required that you create two separate sets of keys, but you should, for operational ease. The DNSSEC protocol itself does not require two classes of keys, but for operational practicality, having two classes of keys make the life of a typical DNS(SEC) administrator's life easier. One of the advantages of having separate ZSKs and KSKs is a better balance between security and ease of use: the KSK can be stored in a secure and less accessible area, while the ZSK is easily accessible for routine use. For more details and considerations on this topic, please refer to RFC 6781 Section 3 .

Please refer to Table 4.1, “ZSK KSK Comparison” for a comparison of how each of the keys are used.

There are at least three algorithm choices for DNSSEC as of this writing (late 2016):

While all three are supported by BIND, RSA is the only one that is mandated to be implemented with DNSSEC and, at the time of writing, is the most widely supported algorithm by both name servers and clients. For the time being, RSA/SHA-256 is the algorithm of choice.

However, RSA is a little long in the tooth, and ECDSA is emerging as the next new cryptographic standard. In fact, the US federal government recommended to stop using RSA altogether by September 2015, and migrate to using ECDSA or similar algorithms.

So for now, use RSA, but keep your eyes on emerging new standards or requirements. For details about rolling over DNSKEYs to a new algorithm, see Section 6.4.5, “DNSKEY Algorithm Rollovers”.

The choice of key sizes is a classic issue of finding the balance between performance and security. The larger the key size, the longer it takes for an attacker to crack the key; but larger keys also means more resources are needed both when generating signatures (authoritative servers) and verifying signatures (recursive servers).

Of the two sets of keys, ZSK is used much more frequently. Whenever zone data changes, or when signatures expire, ZSK is used, so performance certainly is of a bigger concern. As for KSK, it is used less frequently, so performance is less of a factor, but its impact is bigger because of its role in signing other keys.

In this guide, the following key length were chosen for each set, with the recommendation that they be rotated more frequently for better security:

These should be the minimum key sizes one should choose. At the time of writing (late 2016) the root zone and many TLDs are already using 2048 bit ZSKs.

If you choose to implement larger key sizes, keep in mind that larger key size results in larger DNS responses, and this may mean more load on network resources. Depending on network configuration, end users may even experience resolution failures due to the increased response sizes, as we have discussed in Section 3.5, “What's EDNS All About (And Why Should I Care)?”.

The NSEC record is used to prove that something really does not exist, by providing the name before it, and the name after it. Using our tiny company example, this would be analogous to someone calling for Bob over the phone, and our nameless intern answered the phone with: "I'm sorry, that person doesn't work here. The name before that is Alice, and the name after that is Edward". Let's say someone called in again for a non-existent person, Oliver, the answer would be: "I'm sorry, that person doesn't work here. The name before that is Edward, and the name after that is Susan". Another caller asked for Todd, and the answer would be: "I'm sorry, that person doesn't work here. The name before that is Susan, and there's no other name after that".

So we end up with four NSEC records:

example.com.        300	IN	NSEC	alice.example.com.  A RRSIG NSEC
alice.example.com.  300	IN	NSEC	edward.example.com. A RRSIG NSEC
edward.example.com. 300	IN	NSEC	susan.example.com.  A RRSIG NSEC
susan.example.com.  300	IN	NSEC	example.com.        A RRSIG NSEC

What if the attacker tried to use the same replay method described earlier? If someone called for Edward, none of the four answers would fit. If attacker played message #2, "I'm sorry, that person doesn't work here. The name before it is Alice, and the name after it is Edward", it is obviously false, since "Edward" is in the response; same for #3, Edward and Susan. As for #1 and #4, Edward does not fall in range before Alice or after Susan, so the caller can logically deduce that it was an incorrect answer.

In BIND inline signing, your zone data will be automatically sorted on the fly before generating NSEC records, much like how a phone directory is sorted.

The NSEC record allows for a proof of non-existence for record types. If you ask a signed zone for a name that exists but for a record type that doesn't (for that name), the signed NSEC record returned lists all of the record types that do exist for the requested domain name.

NSEC records can also be used to show whether a record was generated as the result of a wildcard expansion or not. The details of this are out of scope for this document, but are described well in RFC 7129.

Unfortunately, the NSEC solution has a few drawbacks, one of which is trivial "zone walking". A curious person can keep calling back, and our nameless, gullible intern will keep divulging information about our employees. Imagine if the caller first asked: "Is Bob there?" and received back the names Alice and Edward. The caller can then call back again: "Is Edward A. there?", and will get back Edward and Susan. Repeat the process enough times, the caller will eventually learn every name in our company phone directory. For many of you, this may not be a problem, since the very idea of DNS is similar to a public phone book: if you don't want a name to be known publicly, don't put it in DNS! Consider using DNS views (split DNS) and only display your sensitive names to a selective audience.

The second drawback of NSEC is a actually increased operational overhead: no opt-out mechanism for insecure child zones, this generally is a problem for parent zone operators dealing with a lot of insecure child zones, such as .com. To learn more about opt-out, please see Section 6.2.2.2, “NSEC3 Opt-Out”.

NSEC3 adds two additional features that NSEC does not have:

Recall, in Section 6.2.1, “NSEC”, we provided a range of names to prove that something really does not exist. But as it turns out, even disclosing these ranges of names becomes a problem: this made it very easy for the curious minded to look at your entire zone. Not only that, unlike a zone transfer, this "zone walking" is more resource intensive. So how do we disclose something, without actually disclosing it?

The answer is actually quite simple, hashing functions, or one-way hashes. Without going into many details, think of it like a magical meat grinder. A juicy piece of ribeye steak goes in one end, and out comes a predictable shape and size of ground meat (hash) with a somewhat unique pattern. No matter how hard you try, you cannot turn the ground meat back into the juicy ribeye steak, that's what we call a one-way hash.

NSEC3 basically runs the names through a one-way hash, before giving it out, so the recipients can verify the non-existence, without any knowledge of the actual names.

So let's tell our little phone receptionist story for the third time, this time with NSEC3. This time, our intern is not given a list of actual names, he is given a list of "hashed" names. So instead of Alice, Edward, and Susan, the list he is given reads like this (hashes shortened for easier reading):

FSK5....  (produced from Edward)
JKMA.... (produced from Susan)
NTQ0.... (produced from Alice)

Then, the phone rings, someone's asking for Bob again. Our intern takes the name Bob through a hash function, and the result is L8J2..., so he tells them on the phone: "I'm sorry, that person doesn't work here. The name before that is JKMA..., and the name after that is NTQ0...". There, we proved Bob doesn't exist, without giving away any names! To put that into proper NSEC3 resource records, they would look like this (again, hashes shortened for display):

FSK5....example.com. 300 IN NSEC3 1 0 10 1234567890ABCDEF  JKMA... A RRSIG
JKMA....example.com. 300 IN NSEC3 1 0 10 1234567890ABCDEF  NTQ0... A RRSIG
NTQ0....example.com. 300 IN NSEC3 1 0 10 1234567890ABCDEF  FSK5... A RRSIG

# rndc signing -nsec3param 1 0 10 1234567890abcdef example.com

# rndc signing -nsec3param 1 0 10 FFFF example.com

# rndc signing -nsec3param 1 1 15 - example.com

So which one should you choose? NSEC or NSEC3? There is not really a single right answer here that fits everyone. It all comes down to your needs or requirements.

If you prefer not to make your zone easily enumerable, implementing NSEC3 paired with a periodically changed salt will provide a certain level of privacy protection. However, someone could still randomly guess the names in your zone (such as "ftp" or "www"), as in the traditional insecure DNS.

If you have many many delegations, and have a need for opt-out to save resources, NSEC3 is for you.

Other than that, using NSEC is typically a good choice for most zone administrators, as it relieves the authoritative servers from the additional cryptographic operations that NSEC3 requires, and NSEC is comparatively easier to troubleshoot than NSEC3.

The beauty of a public key cryptography system is that the public key portion can and should be distributed to as many people as possible. As the administrator, you may want to keep the public keys on an easily accessible file system for operational ease, but there is no need to securely store them, since both ZSK and KSK public keys are published in the zone data as DNSKEY resource records.

Additionally, a hash of the KSK public key is also uploaded to the parent zone (see Section 4.4, “Working with Parent Zone” for more details), and is published by the parent zone as DS records.

Ideally, private keys should be stored offline, in secure devices such as a smart card. Operationally, however, this creates certain challenges, since we need the private key to create RRSIG resource records, and it would be a hassle to bring the private key out of storage every time the zone file changes or when signatures expire.

A common approach to strike the balance between security and practicality is to have two sets of keys, a ZSK set, and a KSK set. ZSK private key is used to sign zone data, and can be kept online for ease of use; KSK private key is used to sign just the DNSKEY (the ZSK), it is used less frequently, and can be stored in a much more secure and restricted fashion.

For example, a KSK private key stored on a USB flash drive that is kept in a fireproof safe, only brought online once a year to sign a new pair of ZSK, combined with a ZSK private key stored on the network file-system available for routine use, maybe be a good balance between operational flexibility and security.

And if you need to change your keys, please see Section 6.4.1, “Key Rollovers”.

A Hardware Security Module (HSM) comes in different shapes and sizes, but as the name indicates, it's a physical device or devices, usually with some or all of the following features:

Most organizations do not incorporate HSMs into their security practices due to cost and the added operational complexity.

BIND supports PKCS #11 (Public Key Cryptography Standard #11) for communication with HSMs and other cryptographic support devices. For more information on how to configure BIND to work with HSMs, please refer to the BIND 9 Administrator Reference Manual.

Generally speaking, ZSKs should be rolled more frequently than KSKs. In Section 4.6, “Maintenance Tasks”, we described at a very high level how to roll the ZSK every year using key pre-publication (described below), and how to roll the KSK every five years using double DS (also described below). Here, we show some other methods of rolling keys. To see examples of key rolling, please refer to Section 7.2, “Rollover Recipes”. For (far) deeper discussions and considerations on the topic of key rolling, check out RFC 7583 .

In Section 4.3.2.4, “auto-dnssec”, we alluded that auto-dnssec is doing a lot of automation for us so we don't have to, and we've also alluded to something called the key timing metadata. In fact, if you looked at your key file, it likely already has a section near the top that looks like this:

; Publish: 20141120094612 (Thu Nov 20 17:46:12 2014)
; Activate: 20141120094612 (Thu Nov 20 17:46:12 2014)

These are only two of the five metadata fields of a key. Below is a complete list of each of the metadata fields, and how it affects your key's behavior:

You can set these metadata fields on a key pair as you've seen in Section 4.6.1, “ZSK Rollover” using commands such as dnssec-keygen or dnssec-settime.

# cd /etc/bind/keys/example.com/
# dnssec-signzone -A -t -N INCREMENT -o example.com -f /etc/bind/db/example.com.signed.db \
> /etc/bind/db/example.com.db Kexample.com.+008+17694.key Kexample.com.+008+06817.key
Verifying the zone using the following algorithms: RSASHA256.
Zone fully signed:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
                      ZSKs: 1 active, 0 stand-by, 0 revoked
/etc/bind/db/example.com.signed.db
Signatures generated:                       17
Signatures retained:                         0
Signatures dropped:                          0
Signatures successfully verified:            0
Signatures unsuccessfully verified:          0
Signing time in seconds:                 0.046
Signatures per second:                 364.634
Runtime in seconds:                      0.055

zone "example.com" IN {
    type master;
    file "db/example.com.signed.db";
};

If you have followed the examples described in Section 4.1, “Easy Start Guide for Signing Authoritative Zones” and Section 4.6, “Maintenance Tasks”, old keys and old signatures are automatically removed from the zone.

However, it is still good to discuss why bother waiting a period of time before removing any old data, be it DNSKEY or RRSIG. The goal here is to not "orphan" anyone out there who may be getting a cached answer, and the information to verify that cached answer doesn't exist anymore. For example, if you chose to pre-publish your ZSK, but did not wait long enough before removing the old ZSK, you're running with the risk that there may be users out there receiving the old RRSIG out of cache, but they are unable to verify the cached old RRSIG because the old ZSK has already been removed. To these users, the domain names would fail validation, until the cached RRSIG entries expire, and their validating resolver retrieves the new RRSIG signed by the new ZSK.

In Section 4.6, “Maintenance Tasks”, we recommended using a very generic and easy to remember 30 days as the amount of time to wait, partly because 30 days is also the default validity time for RRSIG. If you decide to manage your own zone signing and record removing, you should wait at least the duration of your old record's TTL before attempting to removing it from the zone. It is probably better to err on the safe side and leave the old data in the zone a little longer.

Keys are generally rolled at a regular schedule (that is, if you choose to roll them at all). But sometimes, you may have to rollover keys out-of-schedule due to a security incident. The aim of an emergency rollover is re-sign the zone with a new key as soon as possible, because when a key is suspected of being compromised, the malicious attacker (or anyone who has access to the key) could impersonate you, and trick other validating resolvers into believing that they are receiving authentic, validated answers.

During an emergency rollover, you would follow the same operational procedures as described in Section 7.2, “Rollover Recipes”, with the added task of reducing the TTL of current active (possibly compromised) DNSKEY RRset, in attempt to phase out the compromised key faster before the new key takes effect. The time frame should be significantly reduced from the 30-days-apart example, since you probably don't want to wait up to 60 days for the compromised key to be removed from your zone.

Another method is to always carry a spare key with you at all times. You could always have a second key (pre)published (and hopefully this one was not compromised the same time as the first key), so if the active key is compromised, you could save yourself some time to immediately activate the spare key, and all the validating resolvers should already have this spare key cached, thus saving you some time.

With KSK emergency rollover, you would have to also consider factors related to your parent zone, such as how quickly they can remove the old DS record and published the new ones.

As usual, there is a lot more to consider when it comes to emergency key rollovers. For more in-depth considerations, please check out RFC 7583 .

From time to time new digital signature algorithms with improved security are introduced, and it may be desirable for administrators to roll over DNSKEYs to a new algorithm, e.g. from RSASHA1 (algorithm 5 or 7) to RSASHA256 (algorithm 8). The algorithm rollover must be done with care in a stepwise fashion to avoid breaking DNSSEC validation.

As with other DNSKEY rollovers, when the zone is of type master, an algorithm rollover can be accomplished using dynamic updates or automatic key rollovers. For zones of type slave, only automatic key rollovers are possible, but the dnssec-settime utility can be used to control the timing of such.

In any case the first step is to put DNSKEYs using the new algorithm in place. You must generate the K* files for the new algorithm and put them in the zone's key directory where named can access them. Take care to set appropriate ownership and permissions on the keys. If the auto-dnssec zone option is set to maintain, named will automatically sign the zone with the new keys based on their timing metadata when the dnssec-loadkeys-interval elapses or you issue the rndc loadkeys command. Otherwise for zones of type master, you can use nsupdate to add the new DNSKEYs to the zone. This will cause named to use them to sign the zone. For zones of type slave, e.g. on a bump-in-the-wire inline signing server, nsupdate cannot be used.

Once the zone has been signed by the new DNSKEYs, you must inform the parent zone and any trust anchor repositories of the new KSKs, e.g. you might place DS records in the parent zone through your DNS registrar's website.

Before starting to remove the old algorithm from a zone, you must allow the maximum TTL on its DS records in the parent zone to expire. This will assure that any subsequent queries will retrieve the new DS records for the new algorithm. After the TTL has expired, you can remove the DS records for the old algorithm from the parent zone and any trust anchor repositories. You must then allow another maximum TTL interval to elapse so that the old DS records disappear from all resolver caches.

The next step is to remove the DNSKEYs using the old algorithm from your zone. Again this can be accomplished using nsupdate to delete the old DNSKEYs (master zones only) or by automatic key rollover when auto-dnssec is set to maintain. You can cause the automatic key rollover to take place immediately by using the dnssec-settime utility to set the Delete date on all keys to any time in the past. (See dnssec-settime -D <date/offset> option.)

After adjusting the timing metadata, the rndc loadkeys command will cause named to remove the DNSKEYs and RRSIGs for the old algorithm from the zone. Note also that with the nsupdate method, removing the DNSKEYs also causes named to remove the associated RRSIGs automatically.

Once you have verified that the old DNSKEYs and RRSIGs have been removed from the zone, the final (optional) step is to remove the key files for the old algorithm from the key directory.

Dynamic DNS (DDNS) actually is independent of DNSSEC. DDNS provides a mechanism other than editing the zone file or zone database, to edit DNS data. Most clients and DNS servers have the capability to handle dynamic updates, and DDNS can also be integrated as part of your DHCP environment.

When you have both DNSSEC and dynamic updates in your environment, updating zone data works the same way as with traditional (insecure) DNS: you can use rndc freeze before editing the zone file, and rndc thaw when you have finished editing, or you could use the command nsupdate to add, edit, or remove records like this:

$ nsupdate
> server 192.168.1.13
> update add xyz.example.com. 300 IN A 1.1.1.1
> send
> quit

The examples provided in this guide will make named automatically re-sign the zone whenever its content has changed. If you decide to sign your own zone file manually, you will need to remember to executed the dnssec-signzone whenever your zone file has been updated.

As far as system resources and performance is concerned, be mindful that when you have a DNSSEC zone that changes frequently, every time the zone changes, your system is executing a series of cryptographic operations to (re)generate signatures and NSEC or NSEC3 records.

ISC introduces the "inline-signing" option with the release of BIND 9.9, which allows named to sign zones completely transparently. named does this by automatically creating an internal version of the zone that is signed on the fly, and only the signed version of the zone is presented to queries. The unsigned version of the zone file is untouched on the file system, but not served.

This features simplifies DNSSEC deployment, below are two common scenarios of how this feature can be used:

For more details and configuration examples on Inline Signing, please see Section 7.1, “Inline Signing Recipes”.

DNSSEC Look-aside Validation (DLV) is an extension to the DNSSEC protocol. It was designed to assist in early DNSSEC adoption by simplifying the configuration of recursive servers and lessen the burden of key management for the administrators. Without DLV, in the absence of a fully signed path from root to a zone, administrators wishing to enable DNSSEC validation would have to configure and maintain multiple trust anchors or managed keys in their configuration.

DLV removes the need for manual key management by identifying a trusted repository through which those keys can be securely retrieved by the validating resolver when it needs them. Basically, someone else (in this case, ISC) is performing the tedious task of trust anchor management, and your validating resolver just needs to trust that that someone else is doing a good job maintaining these trust anchors for you.

To enable DLV on your validating resolver, place this line in your configuration file and reload named:

dnssec-lookaside auto;

Before we discuss DNSSEC on private networks, let's clarify what we mean by private networks. In this section, private networks really refers to a private or internal DNS view. Most DNS products offer the ability to have different version of DNS answers, depending on the origin of the query. This feature is often called DNS views or split DNS, and is most commonly implemented as an "internal" versus an "external" setup.

For instance, your organization may have a version of example.com that is offered to the world, and its names most likely resolves to publicly reachable IP addresses. You may also have an internal version of example.com that is only accessible when you are on the company's private networks or via a VPN connection. These private networks typical fall under 10.0.0.0/8, 172.16.0.0.0/12, or 192.168.0.0.0/16 for IPv4.

So what if you want to offer DNSSEC for your internal version of example.com? This is actually a more involving question, and we can only cover this topic briefly in this document.

Deploying DNSSEC in this context is possible. Because private networks are usually trusted, there may be less need to worry about someone hijacking your DNS traffic. This is commonly known as the "last mile" in DNS delivery. If you wish to deploy DNSSEC on your private networks, here are some scenarios to consider:

In addition, early efforts have concentrated on getting DNSSEC deployed between authoritative servers and recursive servers as that is a prerequisite for working DNSSEC between the recursive server and the application. These efforts also provide a degree of protection for applications that are not DNSSEC-aware.

With your DNS infrastructure now secured with DNSSEC, information can now be stored in DNS and its integrity and authenticity can be proved. One of the new features that takes advantage of this is the DNS-Based Authentication of Named Entities, or DANE. Below is a list of features currently being developed and tested by the DANE community:

DANE is an exciting area for DNS administrators. If you would like to learn more about the standards being proposed or new features being discussed, check out the DANE working group: https://datatracker.ietf.org/wg/dane/charter/. You can also check out Section 7.5, “Self-signed Certificate Recipe”.

In this recipe, our servers are illustrated as shown in Figure 7.1, “Inline Signing Recipe #1”: we have a master server 192.168.1.1 and three slave servers (192.168.1.2, 192.168.1.3, and 192.168.1.4) that receive zone transfers. In order to get the zone signed, we need to reconfigure the master server, as described in Section 4.1, “Easy Start Guide for Signing Authoritative Zones”. Once reconfigured, a signed version of the zone is generated on the fly by inline-signing, and zone transfers will take care of synchronizing the signed zone data to all slave name servers, without configuration or software changes on the slave servers.

Figure 7.1. Inline Signing Recipe #1

Below is what the named.conf looks like on the master server, 192.168.1.1:

zone "example.com" IN {
    type master;
    file "db/example.com.db";
    key-directory "keys/example.com";
    inline-signing yes;
    auto-dnssec maintain;
    allow-transfer { 192.168.1.2; 192.168.1.3; 192.168.1.4; };
};

On the slave servers, named.conf does not need to be updated, and it looks like this:

zone "example.com" IN {
    type slave;
    file "db/example.com.db";
    masters { 192.168.1.1; };
};

In fact, the slave servers do not even need to be running BIND, it could be running any other DNS product that has DNSSEC support.

In this recipe, we are taking advantage of the power of inline signing by placing an additional name server 192.168.1.5 between the hidden master (192.168.1.1) and the DNS slaves (192.168.1.2, 192.168.1.3, and 192.168.1.4). The additional name server 192.168.1.5 acts as a "bump in the wire", taking unsigned zone from the hidden master on one end, and sending out signed data on the other end to the slave name servers. The steps described in this recipe may be used as part of the DNSSEC deployment strategy, since it requires minimal changes made to the existing hidden DNS master and DNS slaves.

Figure 7.2. Inline Signing Scenario #2

It is important to remember that 192.168.1.1 in this case is a hidden master not exposed to the world, it must not be listed in the NS RRset. Otherwise the world will get conflicting answers, unsigned answers from the hidden master, and signed answers from the other name servers.

The only configuration change needed on the hidden master 192.168.1.1 is to make sure it allows our middle box to perform a zone transfer:

zone "example.com" IN {
    ...
    allow-transfer { 192.168.1.5; };
    ...
};

On the middle box 192.168.1.5, all the tasks described in Section 4.1, “Easy Start Guide for Signing Authoritative Zones” still need to be performed, such as generating key pairs and uploading information to parent zone. This server is configured as slave to the hidden master 192.168.1.1, receiving the unsigned data, and then using keys accessible to this middle box, sign data on the fly, and send out the signed data via zone transfer to the other three DNS slaves. Its named.conf looks like this:

zone example.com {
    type slave;
    masters { 192.168.1.1; };
    file "db/example.com.db";
    key-directory "keys/example.com";
    inline-signing yes;
    auto-dnssec maintain;
    allow-transfer { 192.168.1.2; 192.168.1.3; 192.168.1.4; };
};

Finally, on the three slave servers, configuration should be updated to receive zone transfer from 192.168.1.5 (middle box) instead of 192.168.1.1 (hidden master). If using BIND, the named.conf looks like this:

zone "example.com" IN {
    type slave;
    file "db/example.com.db";
    masters { 192.168.1.5; };   # this was 192.168.1.1 before!
};

This recipe covers how to perform a ZSK rollover using what is known as the Pre-Publication method. For other ZSK rolling methods, please see Section 6.4.1.1, “ZSK Rollover Methods” in Chapter 6, Advanced Discussions.

Below is the timeline for a ZSK rollover to occur on January 1st, 2017:

The current active ZSK has the ID 17694 in this example. For more information on key management (such as what inactive date is, and why 30 days for example), please see Section 6.4, “Key Management”.

# cd /etc/bind/keys/example.com/
# dnssec-settime -I 20170101 -D 20170201 Kexample.com.+008+17694
./Kexample.com.+008+17694.key
./Kexample.com.+008+17694.private
# dnssec-keygen -S Kexample.com.+008+17694
Generating key pair..++++++ ...........++++++ 
Kexample.com.+008+51623

zone example.com/IN (signed): next key event: 01-Dec-2016 00:13:05.385

# cd /etc/bind/keys/example.com
# cat Kexample.com.+008+51623.key 
; This is a zone-signing key, keyid 11623, for example.com.
; Created: 20161130160024 (Mon Dec  1 00:00:24 2016)
; Publish: 20161202000000 (Fri Dec  2 08:00:00 2016)
; Activate: 20170101000000 (Sun Jan  1 08:00:00 2017)
...

$ dig @192.168.1.13 example.com. DNSKEY +dnssec +multiline

...
;; ANSWER SECTION:
example.com.		600 IN DNSKEY 257 3 8 (
				AwEAAcWDps...lM3NRn/G/R
				) ; KSK; alg = RSASHA256; key id = 6817
example.com.		600 IN DNSKEY 256 3 8 (
				AwEAAbi6Vo...qBW5+iAqNz
				) ; ZSK; alg = RSASHA256; key id = 51623
example.com.		600 IN DNSKEY 256 3 8 (
				AwEAAcjGaU...0rzuu55If5
				) ; ZSK; alg = RSASHA256; key id = 17694
example.com.		600 IN RRSIG DNSKEY 8 2 600 (
				20170101000000 20161201230000 6817 example.com.
				LAiaJM26T7...FU9syh/TQ= )
example.com.		600 IN RRSIG DNSKEY 8 2 600 (
				20170101000000 20161201230000 17694 example.com.
				HK4EBbbOpj...n5V6nvAkI= )
...

$ dig @192.168.1.13 example.com. SOA +dnssec +multiline

...
;; ANSWER SECTION:
example.com.		600 IN SOA ns1.example.com. admin.example.com. (
				2016120102 ; serial
				1800       ; refresh (30 minutes)
				900        ; retry (15 minutes)
				2419200    ; expire (4 weeks)
				300        ; minimum (5 minutes)
				)
example.com.		600 IN RRSIG SOA 8 2 600 (
				20161230160109 20161130150109 17694 example.com.
				YUTC8rFULaWbW+nAHzbfGwNqzARHevpryzRIJMvZBYPo
				NAeejNk9saNAoCYKWxGJ0YBc2k+r5fYq1Mg4ll2JkBF5
				buAsAYLw8vEOIxVpXwlArY+oSp9T1w2wfTZ0vhVIxaYX
				6dkcz4I3wbDx2xmG0yngtA6A8lAchERx2EGy0RM= )

$ dig @192.168.1.13 example.com. SOA +dnssec +multiline

...
;; ANSWER SECTION:
example.com.		600 IN SOA ns1.example.com. admin.example.com. (
				2016112011 ; serial
				1800       ; refresh (30 minutes)
				900        ; retry (15 minutes)
				2419200    ; expire (4 weeks)
				300        ; minimum (5 minutes)
				)
example.com.		600 IN RRSIG SOA 8 2 600 (
				20170131000000 20161231230000 51623 example.com.
				J4RMNpJPOmMidElyBugJp0RLqXoNqfvo/2AT6yAAvx9X
				zZRL1cuhkRcyCSLZ9Z+zZ2y4u2lvQGrNiondaKdQCor7
				uTqH5WCPoqalOCBjqU7c7vlAM27O9RD11nzPNpVQ7xPs
				y5nkGqf83OXTK26IfnjU1jqiUKSzg6QR7+XpLk0= )
...

$ dig @192.168.1.13 example.com. DNSKEY +multiline +dnssec

...
;; ANSWER SECTION:
example.com.		600 IN DNSKEY 257 3 8 (
				AwEAAcWDps...lM3NRn/G/R
				) ; KSK; alg = RSASHA256; key id = 6817
example.com.		600 IN DNSKEY 256 3 8 (
				AwEAAdeCGr...1DnEfX+Xzn
				) ; ZSK; alg = RSASHA256; key id = 51623
example.com.		600 IN RRSIG DNSKEY 8 2 600 (
				20170203000000 20170102230000 6817 example.com.
				KHY8P0zE21...Y3szrmjAM= )
example.com.		600 IN RRSIG DNSKEY 8 2 600 (
				20170203000000 20170102230000 51623 example.com.
				G2g3crN17h...Oe4gw6gH8= )
...

This recipe describes how to perform KSK rollover using the Double-DS method. For other KSK rolling methods, please see Section 6.4.1.2, “KSK Rollover Methods” in Chapter 6, Advanced Discussions. The registrar used in this recipe is GoDaddy . Also for this recipe, we are keeping the number of DS records down to just one per active set using just SHA-1, for the sake of better clarity, although in practice most zone operators choose to upload 2 DS records as we have shown in Section 4.4, “Working with Parent Zone”. For more information on key management (such as what inactive date is, and why 30 days for example), please see Section 6.4, “Key Management”.

Below is the timeline for a KSK rollover to occur on January 1st, 2017:

The current active KSK has the ID 24828, and this is the DS record that has already been published by the parent zone:

# dnssec-dsfromkey -a SHA-1 Kexample.com.+007+24828.key
example.com. IN DS 24828 7 1 D4A33E8DD550A9567B4C4971A34AD6C4B80A6AD3

# cd /etc/bind/keys/example.com/
# dnssec-settime -I 20170101 -D 20170201 Kexample.com.+007+24828
./Kexample.com.+007+24848.key
./Kexample.com.+007+24848.private
# dnssec-keygen -S Kexample.com.+007+24848
Generating key pair.......................................................................................++ ...................................++ 
Kexample.com.+007+23550
# dnssec-dsfromkey -a SHA-1 Kexample.com.+007+23550.key
example.com. IN DS 23550 7 1 54FCF030AA1C79C0088FDEC1BD1C37DAA2E70DFB

zone example.com/IN (signed): next key event: 01-Dec-2016 00:13:05.385

# cd /etc/bind/keys/example.com
# cat Kexample.com.+007+23550.key
; This is a key-signing key, keyid 23550, for example.com.
; Created: 20161130160024 (Thu Dec  1 00:00:24 2016)
; Publish: 20161202000000 (Fri Dec  2 08:00:00 2016)
; Activate: 20170101000000 (Sun Jan  1 08:00:00 2017)
...

$ dig @192.168.1.13 example.com. DNSKEY +dnssec +multiline

...
;; ANSWER SECTION:
example.com.   300 IN DNSKEY 256 3 7 (
                AwEAAdYqAc...TiSlrma6Ef
                ) ; ZSK; alg = NSEC3RSASHA1; key id = 29747
example.com.   300 IN DNSKEY 257 3 7 (
                AwEAAeTJ+w...O+Zy9j0m63
                ) ; KSK; alg = NSEC3RSASHA1; key id = 24828
example.com.   300 IN DNSKEY 257 3 7 (
                AwEAAc1BQN...Wdc0qoH21H
                ) ; KSK; alg = NSEC3RSASHA1; key id = 23550
example.com.   300 IN RRSIG DNSKEY 7 2 300 (
                20161206125617 20161107115617 24828 example.com.
                4y1iPVJOrK...aC3iF9vgc= )
example.com.   300 IN RRSIG DNSKEY 7 2 300 (
                20161206125617 20161107115617 29747 example.com.
                g/gfmPjr+y...rt/S/xjPo= )

...

$ dig @8.8.8.8 example.com. DS

...
;; ANSWER SECTION:
example.com.	21552	IN	DS	24828 7 1 D4A33E8DD550A9567B4C4971A34AD6C4B80A6AD3
example.com.	21552	IN	DS	23550 7 1 54FCF030AA1C79C0088FDEC1BD1C37DAA2E70DFB

$ dig @192.168.1.13 example.com. DNSKEY +dnssec +multiline

...
;; ANSWER SECTION:
example.com.   300 IN DNSKEY 256 3 7 (
                AwEAAdYqAc...TiSlrma6Ef
                ) ; ZSK; alg = NSEC3RSASHA1; key id = 29747
example.com.   300 IN DNSKEY 257 3 7 (
                AwEAAeTJ+w...O+Zy9j0m63
                ) ; KSK; alg = NSEC3RSASHA1; key id = 24828
example.com.   300 IN DNSKEY 257 3 7 (
                AwEAAc1BQN...Wdc0qoH21H
                ) ; KSK; alg = NSEC3RSASHA1; key id = 23550
example.com.	300 IN RRSIG DNSKEY 7 2 300 (
				20170201074900 20170101064900 23550 mydnssecgood.org.
				S6zTbBTfvU...Ib5eXkbtE= )
example.com.	300 IN RRSIG DNSKEY 7 2 300 (
				20170105074900 20161206064900 29747 mydnssecgood.org.
				VY5URQA2/d...OVKr1+KX8= )
...

$ dig @192.168.1.13 example.com. DNSKEY +dnssec +multiline

...
;; ANSWER SECTION:
example.com.	300 IN DNSKEY 256 3 7 (
				AwEAAdYqAc...TiSlrma6Ef
				) ; ZSK; alg = NSEC3RSASHA1; key id = 29747
example.com.	300 IN DNSKEY 257 3 7 (
				AwEAAc1BQN...Wdc0qoH21H
				) ; KSK; alg = NSEC3RSASHA1; key id = 23550
example.com.	300 IN RRSIG DNSKEY 7 2 300 (
				20170208000000 20170105230000 23550 mydnssecgood.org.
				Qw9Em3dDok...bNCS7KISw= )
example.com.	300 IN RRSIG DNSKEY 7 2 300 (
				20170208000000 20170105230000 29747 mydnssecgood.org.
				OuelpIlpY9...XfsKupQgc= )
...

This recipe describes how to go from using NSEC to NSEC3, as described in both Section 4.5, “Using NSEC3” and Section 6.2, “Proof of Non-Existence (NSEC and NSEC3) ”. This recipe assumes that the zones are already signed, and named is configured according to the steps described in Section 4.1, “Easy Start Guide for Signing Authoritative Zones”.

This command below enables NSEC3 for the zone example.com, using a pseudo-random string 1234567890abcdef for its salt:

# rndc signing -nsec3param 1 0 10 1234567890abcdef example.com

You'll know it worked if you see the following log messages:

Oct 21 13:47:21 received control channel command 'signing -nsec3param 1 0 10 1234567890abcdef example.com'
Oct 21 13:47:21 zone example.com/IN (signed): zone_addnsec3chain(1,CREATE,10,1234567890ABCDEF)

You can also verify that this worked by querying for a name you know that does not exist, and check for the presence of the NSEC3 record, such as this:

$ dig @192.168.1.13 thereisnowaythisexists.example.com. A +dnssec +multiline

...
TOM10UQBL336NFAQB3P6MOO53LSVG8UI.example.com. 300 IN NSEC3 1 0 10 1234567890ABCDEF (
				TQ9QBEGA6CROHEOC8KIH1A2C06IVQ5ER
				NS SOA RRSIG DNSKEY NSEC3PARAM )
...

Our example used four parameters: 1, 0, 10, and 1234567890ABCDEF, in the order they appeared. 1 represents the algorithm, 0 represents the opt-out flag, 10 represents the number of iterations, and 1234567890abcedf is the salt. To learn more about each of these parameters, please see Section 6.2.2.1, “NSEC3PARAM”.

For example, to create an NSEC3 chain using the SHA-1 hash algorithm, no opt-out flag, 10 iterations, and a salt value of "FFFF", use:

# rndc signing -nsec3param 1 0 10 FFFF example.com

To set the opt-out flag, 15 iterations, and no salt, use:

# rndc signing -nsec3param 1 1 15 - example.com

This recipe describes how to migrate from NSEC3 to NSEC.

Migrating from NSEC3 back to NSEC is easy, just use the rndc command like this:

$ rndc signing -nsec3param none example.com

You know that it worked if you see these messages in log:

named[14093]: received control channel command 'signing -nsec3param none example.com'
named[14093]: zone example.com/IN: zone_addnsec3chain(1,REMOVE,10,1234567890ABCDEF)

Of course, you can query for a name that you know that does not exist, and you should no longer see any traces of NSEC3 records.

$ dig @192.168.1.13 reieiergiuhewhiouwe.example.com. A +dnssec +multiline

...
example.com.		300 IN NSEC aaa.example.com. NS SOA RRSIG NSEC DNSKEY
...
ns1.example.com.	300 IN NSEC web.example.com. A RRSIG NSEC
...

In Section 6.2.2.3, “NSEC3 Salt”, we've discussed the reasons why you may want to change your salt once in a while for better privacy. In this recipe, we will look at what command to execute to actually change the salt, and how to verify that it has been changed.

To change your NSEC3 salt to "fedcba0987654321", you may run the rndc signing command like this:

# rndc signing -nsec3param 1 1 10 fedcba0987654321 example.com

You should see the following messages in log, assuming your old salt was "1234567890abcdef":

named[15848]: zone example.com/IN: zone_addnsec3chain(1,REMOVE,10,1234567890ABCDEF)
named[15848]: zone example.com/IN: zone_addnsec3chain(1,CREATE|OPTOUT,10,FEDCBA0987654321)

You can of course, try to query the name server (192.168.1.13 in our example) for a name that does not exist, and check the NSEC3 record returned:

$ dig @192.168.1.13 thereisnowaythisexists.example.com. A +dnssec +multiline

...
TOM10UQBL336NFAQB3P6MOO53LSVG8UI.example.com. 300 IN NSEC3 1 0 10 FEDCBA0987654321 (
				TQ9QBEGA6CROHEOC8KIH1A2C06IVQ5ER
				NS SOA RRSIG DNSKEY NSEC3PARAM )
...

# rndc signing -nsec3param 1 0 10 $(head -c 300 /dev/random | sha1sum | cut -b 1-16) example.com

BIND 9.10 and newer provides the keyword “auto” which may be used in place of the salt field for named to generate a random salt.

This recipe discusses how to enable and disable NSEC3 opt-out, and show the results of each action. As discussed in Section 6.2.2.2, “NSEC3 Opt-Out”, NSEC3 opt-out is a feature that can help conserve resources on parent zones that have many delegations that have yet been signed.

Before starting, for this recipe we will assume the zone example.com has the following 4 entries (for this example, it is not relevant what record types these entries are):

And the zone example.com has 5 delegations to 5 sub domains, only one of which is signed and has a valid DS RRset:

Before enabling NSEC3 opt-out, the zone example.com contains ten NSEC3 records, below is the list with plain text name before the actual NSEC3 record:

We can enable NSEC3 opt-out with this command, changing the opt-out bit (the second parameter of the 4) from 0 to 1 (see Section 6.2.2.1, “NSEC3PARAM” to review what each parameter is):

# rndc signing -nsec3param 1 1 10 1234567890abcdef example.com

After NSEC3 opt-out is enabled, the number of NSEC3 records is reduced. Notice that the unsigned delegations aaa, ccc, ddd, and eee now don't have corresponding NSEC3 records.

To undo NSEC3 opt-out, run the same rndc command with the opt-out bit set to 0:

# rndc signing -nsec3param 1 0 10 1234567890abcdef example.com

# nsec3hash 1234567890ABCDEF 1 10 www.example.com.
NTQ0CQEJHM0S17POMCUSLG5IOQQEDTBJ (salt=1234567890ABCDEF, hash=1, iterations=10)