DNSSEC Guide¶
Preface¶
Organization¶
This document provides introductory information on how DNSSEC works, how to configure BIND 9 to support some common DNSSEC features, and some basic troubleshooting tips. The chapters are organized as follows:
Introduction covers the intended audience for this document, assumed background knowledge, and a basic introduction to the topic of DNSSEC.
Getting Started covers various requirements before implementing DNSSEC, such as software versions, hardware capacity, network requirements, and security changes.
Validation walks through setting up a validating resolver, and gives both more information on the validation process and some examples of tools to verify that the resolver is properly validating answers.
Signing explains how to set up a basic signed authoritative zone, details the relationship between a child and a parent zone, and discusses ongoing maintenance tasks.
Basic DNSSEC Troubleshooting provides some tips on how to analyze and diagnose DNSSEC-related problems.
Advanced Discussions covers several topics, including key generation, key storage, key management, NSEC and NSEC3, and some disadvantages of DNSSEC.
Recipes provides several working examples of common DNSSEC solutions, with step-by-step details.
Commonly Asked Questions lists some commonly asked questions and answers about DNSSEC.
Acknowledgements¶
This document was originally authored by Josh Kuo of DeepDive Networking. He can be reached at josh@deepdivenetworking.com.
Thanks to the following individuals (in no particular order) who have helped in completing this document: Jeremy C. Reed, Heidi Schempf, Stephen Morris, Jeff Osborn, Vicky Risk, Jim Martin, Evan Hunt, Mark Andrews, Michael McNally, Kelli Blucher, Chuck Aurora, Francis Dupont, Rob Nagy, Ray Bellis, Matthijs Mekking, and Suzanne Goldlust.
Special thanks goes to Cricket Liu and Matt Larson for their selflessness in knowledge sharing.
Thanks to all the reviewers and contributors, including John Allen, Jim Young, Tony Finch, Timothe Litt, and Dr. Jeffry A. Spain.
The sections on key rollover and key timing metadata borrowed heavily from the Internet Engineering Task Force draft titled “DNSSEC Key Timing Considerations” by S. Morris, J. Ihren, J. Dickinson, and W. Mekking, subsequently published as RFC 7583.
Icons made by Freepik and SimpleIcon from Flaticon, licensed under Creative Commons BY 3.0.
Introduction¶
Who Should Read this Guide?¶
This guide is intended as an introduction to DNSSEC for the DNS administrator who is already comfortable working with the existing BIND and DNS infrastructure. He or she might be curious about DNSSEC, but may not have had the time to investigate DNSSEC, to learn whether DNSSEC should be a part of his or her environment, and understand what it means to deploy it in the field.
This guide provides basic information on how to configure DNSSEC using BIND 9.16.0 or later. Most of the information and examples in this guide also apply to versions of BIND later than 9.9.0, but some of the key features described here were only introduced in version 9.16.0. Readers are assumed to have basic working knowledge of the Domain Name System (DNS) and related network infrastructure, such as concepts of TCP/IP. In-depth knowledge of DNS and TCP/IP is not required. The guide assumes no prior knowledge of DNSSEC or related technology such as public key cryptography.
Who May Not Want to Read this Guide?¶
If you are already operating a DNSSEC-signed zone, you may not learn much from the first half of this document, and you may want to start with Advanced Discussions. If you want to learn about details of the protocol extension, such as data fields and flags, or the new record types, this document can help you get started but it does not include all the technical details.
If you are experienced in DNSSEC, you may find some of the concepts in this document to be overly simplified for your taste, and some details are intentionally omitted at times for ease of illustration.
If you administer a large or complex BIND environment, this guide may not provide enough information for you, as it is intended to provide only basic, generic working examples.
If you are a top-level domain (TLD) operator, or administer zones under signed TLDs, this guide can help you get started, but it does not provide enough details to serve all of your needs.
If your DNS environment uses DNS products other than (or in addition to) BIND, this document may provide some background or overlapping information, but you should check each product’s vendor documentation for specifics.
Finally, deploying DNSSEC on internal or private networks is not covered in this document, with the exception of a brief discussion in DNSSEC on Private Networks.
What is DNSSEC?¶
The Domain Name System (DNS) was designed in a day and age when the Internet was a friendly and trusting place. The protocol itself provides little protection against malicious or forged answers. DNS Security Extensions (DNSSEC) addresses this need, by adding digital signatures into DNS data so that each DNS response can be verified for integrity (the answer did not change during transit) and authenticity (the data came from the true source, not an impostor). In the ideal world, when DNSSEC is fully deployed, every single DNS answer can be validated and trusted.
DNSSEC does not provide a secure tunnel; it does not encrypt or hide DNS data. It operates independently of an existing Public Key Infrastructure (PKI). It does not need SSL certificates or shared secrets. It was designed with backwards compatibility in mind, and can be deployed without impacting “old” unsecured domain names.
DNSSEC is deployed on the three major components of the DNS infrastructure:
Recursive Servers: People use recursive servers to lookup external domain names such as
www.example.com. Operators of recursive servers need to enable DNSSEC validation. With validation enabled, recursive servers carry out additional tasks on each DNS response they receive to ensure its authenticity.Authoritative Servers: People who publish DNS data on their name servers need to sign that data. This entails creating additional resource records, and publishing them to parent domains where necessary. With DNSSEC enabled, authoritative servers respond to queries with additional DNS data, such as digital signatures and keys, in addition to the standard answers.
Applications: This component lives on every client machine, from web servers to smart phones. This includes resolver libraries on different operating systems, and applications such as web browsers.
In this guide, we focus on the first two components, Recursive Servers and Authoritative Servers, and only lightly touch on the third component. We look at how DNSSEC works, how to configure a validating resolver, how to sign DNS zone data, and other operational tasks and considerations.
What Does DNSSEC Add to DNS?¶
Note
Public Key Cryptography works on the concept of a pair of keys: one made available to the world publicly, and one kept in secrecy privately. Not surprisingly, they are known as a public key and a private key. If you are not familiar with the concept, think of it as a cleverly designed lock, where one key locks and one key unlocks. In DNSSEC, we give out the unlocking public key to the rest of the world, while keeping the locking key private. To learn how this is used to secure DNS messages, see How Are Answers Verified?.
DNSSEC introduces eight new resource record types:
RRSIG (digital resource record signature)
DNSKEY (public key)
DS (parent-child)
NSEC (proof of nonexistence)
NSEC3 (proof of nonexistence)
NSEC3PARAM (proof of nonexistence)
CDS (child-parent signaling)
CDNSKEY (child-parent signaling)
This guide does not go deep into the anatomy of each resource record type; the details are left for the reader to research and explore. Below is a short introduction on each of the new record types:
RRSIG: With DNSSEC enabled, just about every DNS answer (A, PTR, MX, SOA, DNSKEY, etc.) comes with at least one resource record signature, or RRSIG. These signatures are used by recursive name servers, also known as validating resolvers, to verify the answers received. To learn how digital signatures are generated and used, see How Are Answers Verified?.
DNSKEY: DNSSEC relies on public-key cryptography for data authenticity and integrity. There are several keys used in DNSSEC, some private, some public. The public keys are published to the world as part of the zone data, and they are stored in the DNSKEY record type.
In general, keys in DNSSEC are used for one or both of the following roles: as a Zone Signing Key (ZSK), used to protect all zone data; or as a Key Signing Key (KSK), used to protect the zone’s keys. A key that is used for both roles is referred to as a Combined Signing Key (CSK). We talk about keys in more detail in DNSSEC Keys.
DS: One of the critical components of DNSSEC is that the parent zone can “vouch” for its child zone. The DS record is verifiable information (generated from one of the child’s public keys) that a parent zone publishes about its child as part of the chain of trust. To learn more about the Chain of Trust, see Chain of Trust.
NSEC, NSEC3, NSEC3PARAM: These resource records all deal with a very interesting problem: proving that something does not exist. We look at these record types in more detail in Proof of Non-Existence (NSEC and NSEC3).
CDS, CDNSKEY: The CDS and CDNSKEY resource records apply to operational matters and are a way to signal to the parent zone that the DS records it holds for the child zone should be updated. This is covered in more detail in The CDS and CDNSKEY Resource Records.
How Does DNSSEC Change DNS Lookup?¶
Traditional (insecure) DNS lookup is simple: a recursive name server
receives a query from a client to lookup a name like www.isc.org. The
recursive name server tracks down the authoritative name server(s)
responsible, sends the query to one of the authoritative name servers,
and waits for it to respond with the answer.
With DNSSEC validation enabled, a validating recursive name server (a.k.a. a validating resolver) asks for additional resource records in its query, hoping the remote authoritative name servers respond with more than just the answer to the query, but some proof to go along with the answer as well. If DNSSEC responses are received, the validating resolver performs cryptographic computation to verify the authenticity (the origin of the data) and integrity (that the data was not altered during transit) of the answers, and even asks the parent zone as part of the verification. It repeats this process of get-key, validate, ask-parent, and its parent, and its parent, all the way until the validating resolver reaches a key that it trusts. In the ideal, fully deployed world of DNSSEC, all validating resolvers only need to trust one key: the root key.
The 12-Step DNSSEC Validation Process (Simplified)¶
The following example shows the 12 steps of the DNSSEC validating process
at a very high level, looking up the name www.isc.org :
Upon receiving a DNS query from a client to resolve
www.isc.org, the validating resolver follows standard DNS protocol to track down the name server forisc.org, and sends it a DNS query to ask for the A record ofwww.isc.org. But since this is a DNSSEC-enabled resolver, the outgoing query has a bit set indicating it wants DNSSEC answers, hoping the name server that receives it is DNSSEC-enabled and can honor this secure request.The
isc.orgname server is DNSSEC-enabled, so it responds with both the answer (in this case, an A record) and a digital signature for verification purposes.The validating resolver requires cryptographic keys to be able to verify the digital signature, so it asks the
isc.orgname server for those keys.The
isc.orgname server responds with the cryptographic keys (and digital signatures of the keys) used to generate the digital signature that was sent in #2. At this point, the validating resolver can use this information to verify the answers received in #2.Let’s take a quick break here and look at what we’ve got so far… how can our server trust this answer? If a clever attacker had taken over the
isc.orgname server(s), or course she would send matching keys and signatures. We need to ask someone else to have confidence that we are really talking to the realisc.orgname server. This is a critical part of DNSSEC: at some point, the DNS administrators atisc.orguploaded some cryptographic information to its parent,.org, maybe through a secure web form, maybe through an email exchange, or perhaps in person. In any event, at some point some verifiable information about the child (isc.org) was sent to the parent (.org) for safekeeping.The validating resolver asks the parent (
.org) for the verifiable information it keeps on its child,isc.org.Verifiable information is sent from the
.orgserver. At this point, the validating resolver compares this to the answer it received in #4; if the two of them match, it proves the authenticity ofisc.org.Let’s examine this process. You might be thinking to yourself, what if the clever attacker that took over
isc.orgalso compromised the.orgservers? Of course all this information would match! That’s why we turn our attention now to the.orgserver, interrogate it for its cryptographic keys, and move one level up to.org’s parent, root.The validating resolver asks the
.orgauthoritative name server for its cryptographic keys, to verify the answers received in #6.The
.orgname server responds with the answer (in this case, keys and signatures). At this point, the validating resolver can verify the answers received in #6.The validating resolver asks root (
.org’s parent) for the verifiable information it keeps on its child,.org.The root name server sends back the verifiable information it keeps on
.org. The validating resolver uses this information to verify the answers received in #8.So at this point, both
isc.organd.orgcheck out. But what about root? What if this attacker is really clever and somehow tricked us into thinking she’s the root name server? Of course she would send us all matching information! So we repeat the interrogation process and ask for the keys from the root name server.The validating resolver asks the root name server for its cryptographic keys to verify the answer(s) received in #10.
The root name server sends its keys; at this point, the validating resolver can verify the answer(s) received in #10.
Chain of Trust¶
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 talk later
about the current imperfect state 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 already has the root key
on file (we discuss later how we got the root key file). So
after the answer in #12 is received, the validating resolver compares it
to the key it already has on file. Providing one of the keys in the
answer matches the one on file, we can trust the answer from root. Thus
we can trust .org, and thus we can trust isc.org. This is known
as the “chain of trust” in DNSSEC.
We revisit this 12-step process again later in How Does DNSSEC Change DNS Lookup (Revisited)? with more technical details.
Why is DNSSEC Important? (Why Should I Care?)¶
You might be thinking to yourself: all this DNSSEC stuff sounds wonderful, but why should I care? Below are some reasons why you may want to consider deploying DNSSEC:
Being a good netizen: By enabling DNSSEC validation (as described in Validation) on your DNS servers, you’re protecting your users and yourself a little more by checking answers returned to you; by signing your zones (as described in Signing), you are making it possible for other people to verify your zone data. As more people adopt DNSSEC, the Internet as a whole becomes more secure for everyone.
Compliance: You may not even get a say in implementing DNSSEC, if your organization is subject to compliance standards that mandate it. For example, the US government set a deadline in 2008 to have all
.govsubdomains signed by December 2009 1. So if you operate a subdomain in.gov, you must implement DNSSEC to be compliant. ICANN also requires that all new top-level domains support DNSSEC.Enhanced Security: Okay, so the big lofty goal of “let’s be good” doesn’t appeal to you, and you don’t have any compliance standards to worry about. Here is a more practical reason why you should consider DNSSEC: in the event of a DNS-based security breach, such as cache poisoning or domain hijacking, after all the financial and brand damage done to your domain name, you might be placed under scrutiny for any preventive measure that could have been put in place. Think of this like having your website only available via HTTP but not HTTPS.
New Features: DNSSEC brings not only enhanced security, but also a whole new suite of features. Once DNS can be trusted completely, it becomes possible to publish SSL certificates in DNS, or PGP keys for fully automatic cross-platform email encryption, or SSH fingerprints…. New features are still being developed, but they all rely on a trustworthy DNS infrastructure. To take a peek at these next-generation DNS features, check out Introduction to DANE.
- 1
The Office of Management and Budget (OMB) for the US government published a memo in 2008, requesting all
.govsubdomains to be DNSSEC-signed by December 2009. This explains why.govis the most-deployed DNSSEC domain currently, with around 90% of subdomains signed.
How Does DNSSEC Change My Job as a DNS Administrator?¶
With this protocol extension, some of the things you were used to in DNS have changed. As the DNS administrator, you have new maintenance tasks to perform on a regular basis (as described in Maintenance Tasks); when there is a DNS resolution problem, you have new troubleshooting techniques and tools to use (as described in Basic DNSSEC Troubleshooting). BIND 9 tries its best to make these things as transparent and seamless as possible. In this guide, we try to use configuration examples that result in the least amount of work for BIND 9 DNS administrators.
Getting Started¶
Software Requirements¶
BIND Version¶
Most configuration examples given in this document require BIND version
9.16.0 or newer (although many do work with all versions of BIND
later than 9.9). To check the version of named you have installed,
use the -v switch as shown below:
# named -v
BIND 9.16.0 (Stable Release) <id:6270e602ea>
Some configuration examples are added in BIND version 9.17 and backported to 9.16. For example, NSEC3 configuration requires BIND version 9.16.9.
We recommend you run the latest stable version to get the most complete DNSSEC configuration, as well as the latest security fixes.
DNSSEC Support in BIND¶
All versions of BIND 9 since BIND 9.7 can support DNSSEC, as currently
deployed in the global DNS, so the BIND software you are running most
likely already supports DNSSEC. 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
of the output from running named -V:
$ named -V
BIND 9.16.0 (Stable Release) <id:6270e602ea>
running on Linux x86_64 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u4 (2019-07-19)
built by make with defaults
compiled by GCC 6.3.0 20170516
compiled with OpenSSL version: OpenSSL 1.1.0l 10 Sep 2019
linked to OpenSSL version: OpenSSL 1.1.0l 10 Sep 2019
compiled with libxml2 version: 2.9.4
linked to libxml2 version: 20904
compiled with json-c version: 0.12.1
linked to json-c version: 0.12.1
compiled with zlib version: 1.2.8
linked to zlib version: 1.2.8
threads support is enabled
default paths:
named configuration: /usr/local/etc/named.conf
rndc configuration: /usr/local/etc/rndc.conf
DNSSEC root key: /usr/local/etc/bind.keys
nsupdate session key: /usr/local/var/run/named/session.key
named PID file: /usr/local/var/run/named/named.pid
named lock file: /usr/local/var/run/named/named.lock
If the BIND 9 software you have does not support DNSSEC, you should upgrade it. (It has not been possible to build BIND without DNSSEC support since BIND 9.13, released in 2018.) As well as missing out on DNSSEC support, you are also missing a number of security fixes made to the software in recent years.
System Entropy¶
To deploy DNSSEC to your authoritative server, you need to generate cryptographic keys. 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
provide additional entropy for a system. Once installed, they
significantly reduce the time needed to generate keys.
The more entropy there is, the better pseudo-random numbers you get, and the stronger the keys that are generated. If you want or need high-quality random numbers, take a look at Hardware Security Modules (HSMs) for some of the hardware-based solutions.
Hardware Requirements¶
Recursive Server Hardware¶
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:
CPU: a validating resolver executes cryptographic functions on many of the answers returned, which usually leads to increased CPU usage, unless your recursive server has built-in hardware to perform cryptographic computations.
System memory: DNSSEC leads to larger answer sets and occupies more memory space.
Network interfaces: although DNSSEC does increase the amount of DNS traffic overall, it is unlikely that you need to upgrade your network interface card (NIC) on the name server unless you have some truly outdated hardware.
One factor to consider is the destinations of your current DNS
traffic. If your current users spend a lot of time visiting .gov
websites, you should expect a jump in all of the above
categories when validation is enabled, because .gov is more than 90%
signed. This means that more than 90% of the time, your validating resolver
will be doing what is described in
How Does DNSSEC Change DNS Lookup?. However, if your users
only care about resources in the .com domain, which, as of mid-2020,
is under 1.5% signed 2, your recursive name server is unlikely
to experience a significant load increase after enabling DNSSEC
validation.
Authoritative Server Hardware¶
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 to consider for possible hardware enhancements for an authoritative server with signed zones:
CPU: a DNSSEC-signed zone requires periodic re-signing, which is a cryptographic function that is CPU-intensive. If your DNS zone is dynamic or changes frequently, that also adds to higher CPU loads.
System storage: A signed zone is definitely larger than an unsigned zone. How much larger? See Your Zone, Before and After DNSSEC for a comparison example. Roughly speaking, you should expect your zone file to grow by at least three times, and frequently more.
System memory: Larger DNS zone files take up not only more storage space on the file system, but also more space when they are loaded into system memory.
Network interfaces: While your authoritative name servers will begin sending back larger responses, it is unlikely that you need to upgrade your network interface card (NIC) on the name server unless you have some truly outdated hardware.
One factor to consider, but over which you really have no control, is the number of users who query your domain name who themselves have DNSSEC enabled. It was estimated in late 2014 that roughly 10% to 15% of the Internet DNS queries were DNSSEC-aware. Estimates by APNIC suggest that in 2020 about one-third of all queries are validating queries, although the percentage varies widely on a per-country basis. This means that more DNS queries for your domain will take advantage of the additional security features, which will result in increased system load and possibly network traffic.
Network Requirements¶
From a network perspective, DNS and DNSSEC packets are very similar; DNSSEC packets are just bigger, which means DNS is more likely to use TCP. You should test for the following two items to make sure your network is ready for DNSSEC:
DNS over TCP: Verify network connectivity over TCP port 53, which may mean updating firewall policies or Access Control Lists (ACL) on routers. See Wait… DNS Uses TCP? for more details.
Large UDP packets: Some network equipment, such as firewalls, may make assumptions about the size of DNS UDP packets and incorrectly reject DNS traffic that appears “too big.” Verify that the responses your name server generates are being seen by the rest of the world: see What’s EDNS All About (And Why Should I Care)? for more details.
Operational Requirements¶
Parent Zone¶
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 Working With the Parent Zone, a crucial step in DNSSEC deployment is establishing the parent-child trust relationship. If your parent zone does not yet support DNSSEC, contact that administrator to voice your concerns.
Security Requirements¶
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, and 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 Advanced Discussions.
Validation¶
Easy-Start Guide for Recursive Servers¶
This section provides the basic information needed to set up a working DNSSEC-aware recursive server, also known as a validating resolver. A validating resolver performs validation for each remote response received, following the chain of trust to verify that the answers it receives are legitimate, through the use of public key cryptography and hashing functions.
Enabling DNSSEC Validation¶
So how do we turn on DNSSEC validation? It turns out that you may not need to reconfigure your name server at all, since the most recent versions of BIND 9 - including packages and distributions - have shipped with DNSSEC validation enabled by default. Before making any configuration changes, check whether you already have DNSSEC validation enabled by following the steps described in So You Think You Are Validating (How To Test A Recursive Server).
In earlier versions of BIND, including 9.11-ESV, DNSSEC
validation must be explicitly enabled. To do this, you only need to
add one line to the options section of your configuration file:
options {
...
dnssec-validation auto;
...
};
Restart named or run rndc reconfig, and your recursive server is
now happily validating each DNS response. If this does not work for you,
and you have already verified DNSSEC support as described in
DNSSEC Support in BIND, you may have some other
network-related configurations that need to be adjusted. Take a look at
Network Requirements to make sure your network is ready for
DNSSEC.
Effects of Enabling DNSSEC Validation¶
Once DNSSEC validation is enabled, any DNS response that does not pass the validation checks results in a failure to resolve the domain name (often a SERVFAIL status seen by the client). If everything has been configured properly, this is the correct result; it means that an end user has been protected against a malicious attack.
However, if there is a DNSSEC configuration issue (sometimes outside of
the administrator’s control), a specific name or sometimes entire
domains may “disappear” from the DNS, and become unreachable
through that resolver. For the end user, the issue may manifest itself
as name resolution being slow or failing altogether; some parts of a URL
not loading; or the web browser returning an error message indicating
that the page cannot be displayed. For example, if root name
servers were misconfigured with the wrong information about .org, it
could cause all validation for .org domains to fail. To end
users, it would appear that all .org web
sites were out of service 3. Should you encounter DNSSEC-related problems, don’t be
tempted to disable validation; there is almost certainly a solution that
leaves validation enabled. A basic troubleshooting guide can be found in
Basic DNSSEC Troubleshooting.
- 3
Of course, something like this could happen for reasons other than DNSSEC: for example, the root publishing the wrong addresses for the
.orgnameservers.
So You Think You Are Validating (How To Test A Recursive Server)¶
Now that you have reconfigured your recursive server and restarted it, how do you know that your recursive name server is actually verifying each DNS query? There are several ways to check, and we’ve listed a few of them below.
Using Web-Based Tools to Verify¶
For most people, the simplest way to check if a recursive name server is indeed validating DNS queries is to use one of the many web-based tools available.
Configure your client computer to use the newly reconfigured recursive server for DNS resolution; then use one of these web-based tests to confirm that it is in fact validating DNS responses.
Using dig to Verify¶
Web-based DNSSEC-verification 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. 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 website. ISC provides pre-compiled
Windows versions on its website.
dig is a flexible tool for interrogating DNS name servers. It
performs DNS lookups and displays the answers that are returned from the
name servers 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 how to use dig to query the name server 10.53.0.1
for the A record for ftp.isc.org when DNSSEC validation is enabled
(i.e. the default). The address 10.53.0.1 is only used as an example;
replace it with the actual address or host name of your
recursive name server.
$ dig @10.53.0.1 ftp.isc.org. A +dnssec +multiline
; <<>> DiG 9.16.0 <<>> @10.53.0.1 ftp.isc.org a +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48742
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 29a9705c2160b08c010000005e67a4a102b9ae079c1b24c8 (good)
;; QUESTION SECTION:
;ftp.isc.org. IN A
;; ANSWER SECTION:
ftp.isc.org. 300 IN A 149.20.1.49
ftp.isc.org. 300 IN RRSIG A 13 3 300 (
20200401191851 20200302184340 27566 isc.org.
e9Vkb6/6aHMQk/t23Im71ioiDUhB06sncsduoW9+Asl4
L3TZtpLvZ5+zudTJC2coI4D/D9AXte1cD6FV6iS6PQ== )
;; Query time: 452 msec
;; SERVER: 10.53.0.1#53(10.53.0.1)
;; WHEN: Tue Mar 10 14:30:57 GMT 2020
;; MSG SIZE rcvd: 187
The important detail in this output is the presence of the ad flag
in the header. This signifies that BIND has retrieved all related DNSSEC
information related to the target of the query (ftp.isc.org) and that
the answer received has passed the validation process described in
How Are Answers Verified?. We can have confidence in the
authenticity and integrity of the answer, that ftp.isc.org really
points to the IP address 149.20.1.49, and that it was not a spoofed answer
from a clever attacker.
Unlike earlier versions of BIND, the current versions of BIND always
request DNSSEC records (by setting the do bit in the query they make
to upstream servers), regardless of DNSSEC settings. However, with
validation disabled, the returned signature is not checked. This can be
seen by explicitly disabling DNSSEC validation. To do this, add the line
dnssec-validation no; to the “options” section of the configuration
file, i.e.:
options {
...
dnssec-validation no;
...
};
If the server is restarted (to ensure a clean cache) and the same
dig command executed, the result is very similar:
$ dig @10.53.0.1 ftp.isc.org. A +dnssec +multiline
; <<>> DiG 9.16.0 <<>> @10.53.0.1 ftp.isc.org a +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39050
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: a8dc9d1b9ec45e75010000005e67a8a69399741fdbe126f2 (good)
;; QUESTION SECTION:
;ftp.isc.org. IN A
;; ANSWER SECTION:
ftp.isc.org. 300 IN A 149.20.1.49
ftp.isc.org. 300 IN RRSIG A 13 3 300 (
20200401191851 20200302184340 27566 isc.org.
e9Vkb6/6aHMQk/t23Im71ioiDUhB06sncsduoW9+Asl4
L3TZtpLvZ5+zudTJC2coI4D/D9AXte1cD6FV6iS6PQ== )
;; Query time: 261 msec
;; SERVER: 10.53.0.1#53(10.53.0.1)
;; WHEN: Tue Mar 10 14:48:06 GMT 2020
;; MSG SIZE rcvd: 187
However, this time there is no ad flag in the header. Although
dig is still returning the DNSSEC-related resource records, it is
not checking them, and thus cannot vouch for the authenticity of the answer.
If you do carry out this test, remember to re-enable DNSSEC validation
(by removing the dnssec-validation no; line from the configuration
file) before continuing.
Verifying Protection From Bad Domain Names¶
It is also important to make sure that DNSSEC is protecting your network 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 tells us that things don’t add up. There is a
domain name specifically set up to fail DNSSEC validation,
www.dnssec-failed.org.
With DNSSEC validation enabled (the default), an attempt to look up that name fails:
$ dig @10.53.0.1 www.dnssec-failed.org. A
; <<>> DiG 9.16.0 <<>> @10.53.0.1 www.dnssec-failed.org. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 22667
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 69c3083144854587010000005e67bb57f5f90ff2688e455d (good)
;; QUESTION SECTION:
;www.dnssec-failed.org. IN A
;; Query time: 2763 msec
;; SERVER: 10.53.0.1#53(10.53.0.1)
;; WHEN: Tue Mar 10 16:07:51 GMT 2020
;; MSG SIZE rcvd: 78
On the other hand, if DNSSEC validation is disabled (by adding the
statement dnssec-validation no; to the options clause in the
configuration file), the lookup succeeds:
$ dig @10.53.0.1 www.dnssec-failed.org. A
; <<>> DiG 9.16.0 <<>> @10.53.0.1 www.dnssec-failed.org. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54704
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 251eee58208917f9010000005e67bb6829f6dabc5ae6b7b9 (good)
;; 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: 439 msec
;; SERVER: 10.53.0.1#53(10.53.0.1)
;; WHEN: Tue Mar 10 16:08:08 GMT 2020
;; MSG SIZE rcvd: 110
Do not be tempted to disable DNSSEC validation just because some names are failing to resolve. Remember, DNSSEC protects your DNS lookup from hacking. The next section describes how to quickly check whether the failure to successfully look up a name is due to a validation failure.
How Do I Know I Have a Validation Problem?¶
Since all DNSSEC validation failures result in a general SERVFAIL
message, how do we know if it was really a validation error?
Fortunately, there is a flag in dig, (+cd, for “checking
disabled”) which tells the server to disable DNSSEC validation. If
you receive a SERVFAIL message, re-run the query a second time
and set the +cd flag. If the query succeeds with +cd, but
ends in SERVFAIL without it, you know you are dealing with a
validation problem. So using the previous example of
www.dnssec-failed.org and with DNSSEC validation enabled in the
resolver:
$ dig @10.53.0.1 www.dnssec-failed.org A +cd
; <<>> DiG 9.16.0 <<>> @10.53.0.1 www.dnssec-failed.org. A +cd
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62313
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 73ca1be3a74dd2cf010000005e67c8c8e6df64b519cd87fd (good)
;; QUESTION SECTION:
;www.dnssec-failed.org. IN A
;; ANSWER SECTION:
www.dnssec-failed.org. 7197 IN A 68.87.109.242
www.dnssec-failed.org. 7197 IN A 69.252.193.191
;; Query time: 0 msec
;; SERVER: 10.53.0.1#53(10.53.0.1)
;; WHEN: Tue Mar 10 17:05:12 GMT 2020
;; MSG SIZE rcvd: 110
For more information on troubleshooting, please see Basic DNSSEC Troubleshooting.
Validation Easy Start Explained¶
In Easy-Start Guide for Recursive Servers, we used one line of configuration to turn on DNSSEC validation: the act of chasing down signatures and keys, making sure they are authentic. Now we are going to take a closer look at what DNSSEC validation actually does, and some other options.
dnssec-validation¶
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:
yes: DNSSEC validation is enabled, but a trust anchor must be manually configured. No validation actually takes place until at least one trusted key has been manually configured.
no: DNSSEC validation is disabled, and the recursive server behaves in the “old-fashioned” way of performing insecure DNS lookups.
auto: DNSSEC validation is enabled, and a default trust anchor (included as part of BIND 9) for the DNS root zone is used. This is the default; BIND automatically does this if there is no
dnssec-validationline in the configuration file.
Let’s discuss the difference between yes and auto. If set to
yes, the trust anchor must be manually defined and maintained
using the trust-anchors statement (with either the static-key or
static-ds modifier) in the configuration file; if set to
auto (the default, and as shown in the example), then no further
action should be required as BIND includes a copy 4 of the root key.
When set to auto, BIND automatically keeps the keys (also known as
trust anchors, discussed in Trust Anchors)
up-to-date without intervention from the DNS administrator.
We recommend using the default auto unless there is a good reason to require a manual trust anchor. To learn more about trust anchors, please refer to Trusted Keys and Managed Keys.
How Does DNSSEC Change DNS Lookup (Revisited)?¶
Now you’ve enabled validation on your recursive name server and
verified that it works. What exactly changed? In
How Does DNSSEC Change DNS Lookup? we looked at a very
high-level, simplified version of the 12 steps of the DNSSEC validation process. Let’s revisit
that process now and see what your validating resolver is doing in more
detail. Again, as an example we are looking up the A record for the
domain name www.isc.org (see The 12-Step DNSSEC Validation Process (Simplified)):
The validating resolver queries the
isc.orgname servers for the A record ofwww.isc.org. This query has theDNSSEC OK(do) bit set to 1, notifying the remote authoritative server that DNSSEC answers are desired.Since the zone
isc.orgis signed, and its name servers are DNSSEC-aware, it responds with the answer to the A record query plus the RRSIG for the A record.The validating resolver queries for the DNSKEY for
isc.org.The
isc.orgname server responds with the DNSKEY and RRSIG records. The DNSKEY is used to verify the answers received in #2.The validating resolver queries the parent (
.org) for the DS record forisc.org.The
.orgname server is also DNSSEC-aware, so it responds with the DS and RRSIG records. The DS record is used to verify the answers received in #4.The validating resolver queries for the DNSKEY for
.org.The
.orgname server responds with its DNSKEY and RRSIG. The DNSKEY is used to verify the answers received in #6.The validating resolver queries the parent (root) for the DS record for
.org.The root name server, being DNSSEC-aware, responds with DS and RRSIG records. The DS record is used to verify the answers received in #8.
The validating resolver queries for the DNSKEY for root.
The root name server responds with its DNSKEY and RRSIG. The DNSKEY is used to verify the answers received in #10.
After step #12, the validating resolver takes the DNSKEY received and compares it to the key or keys it has configured, to decide whether the received key can be trusted. We talk about these locally configured keys, or trust anchors, in Trust Anchors.
With DNSSEC, every response includes not just the answer, but a digital signature (RRSIG) as well, so the validating resolver can verify the answer received. That is what we look at in the next section, How Are Answers Verified?.
How Are Answers Verified?¶
Note
Keep in mind, as you read this section, that although words like “encryption” and “decryption” are used here from time to time, DNSSEC does not provide privacy. Public key cryptography is used to verify data authenticity (who sent it) and data integrity (it did not change during transit), but any eavesdropper can still see DNS requests and responses in clear text, even when DNSSEC is enabled.
So how exactly are DNSSEC answers 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, and this hashed value is then encrypted by a private key. This encrypted hash value is the digital signature.
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 (it is 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, which we’ll call 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, which we’ll call 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 this answer came from the authoritative server (authenticity), and the content remained intact during transit (integrity).
Signature Verification¶
Take the A record ftp.isc.org, for example. The plain text is:
ftp.isc.org. 4 IN A 149.20.1.49
The digital signature portion is:
ftp.isc.org. 300 IN RRSIG A 13 3 300 (
20200401191851 20200302184340 27566 isc.org.
e9Vkb6/6aHMQk/t23Im71ioiDUhB06sncsduoW9+Asl4
L3TZtpLvZ5+zudTJC2coI4D/D9AXte1cD6FV6iS6PQ== )
When a validating resolver queries for the A record ftp.isc.org, it
receives both the A record and the RRSIG record. It runs the A record
through a hash function (in this example, SHA256 as
indicated by the number 13, signifying ECDSAP256SHA256) 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? Look at the two timestamps in our example above:
Signature Expiration: 20200401191851
Signature Inception: 20200302184340
This tells us that this signature was generated UTC March 2nd, 2020, at 6:43:40 PM (20200302184340), and it is good until UTC April 1st, 2020, 7:18:51 PM (20200401191851). The validating resolver’s current system time needs to fall between these two timestamps. If it does not, 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 the hash value check and the timestamp check, it is
validated and the authenticated data (ad) bit is set, and the response
is sent to the client; if it does not verify, a SERVFAIL is returned to
the client.
- 4
BIND technically includes two copies of the root key: one is in
bind.keys.hand is built into the executable, and one is inbind.keysas atrust-anchorsstatement. The two copies of the key are identical.
Trust Anchors¶
A trust anchor is a key that is placed into a validating resolver, so that the validator can verify the results of a given request with a known or trusted public key (the trust anchor). A validating resolver must have at least one trust anchor installed to perform DNSSEC validation.
How Trust Anchors are Used¶
In the section How Does DNSSEC Change DNS Lookup (Revisited)?, we walked through the 12 steps of the DNSSEC lookup process. 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, and where each validating resolver only needs to have one trust anchor - 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 (in July 2010), some
validating resolvers that wished 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 at that time would have been eight steps rather
than 12:
The validating resolver queried
fbi.govname server for the A record ofwww.fbi.gov.The FBI’s name server responded with the answer and its RRSIG.
The validating resolver queried the FBI’s name server for its DNSKEY.
The FBI’s name server responded with the DNSKEY and its RRSIG.
The validating resolver queried a
.govname server for the DS record offbi.gov.The
.govname server responded with the DS record and the associated RRSIG forfbi.gov.The validating resolver queried the
.govname server for its DNSKEY.The
.govname server responded with its DNSKEY and the associated RRSIG.
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 their DNSKEY.
In fact, whenever the validating resolver receives a DNSKEY, it checks to see if this is a configured trusted key to decide whether it needs to continue chasing down the validation chain.
Trusted Keys and Managed Keys¶
Since 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
Easy-Start Guide for Recursive Servers, by setting
dnssec-validation to auto, there is nothing left to do.
BIND already includes a copy of the root key (in the file
bind.keys), and automatically updates it when the root key
changes. 5 It looks something like this:
trust-anchors {
# This key (20326) was published in the root zone in 2017.
. initial-key 257 3 8 "AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
R1AkUTV74bU=";
};
You can, of course, decide to manage this key manually yourself.
First, you need to make sure that 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 trust-anchors statement as
shown below:
trust-anchors {
# This key (20326) was published in the root zone in 2017.
. static-key 257 3 8 "AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
R1AkUTV74bU=";
};
While this trust-anchors statement and the one in the bind.keys
file appear similar, the definition of the key in bind.keys has the
initial-key modifier, whereas in the statement in the configuration
file, that is replaced by static-key. There is an important
difference between the two: a key defined with static-key is always
trusted until it is deleted from the configuration file. With the
initial-key modified, keys are only trusted once: for as long as it
takes to load the managed key database and start the key maintenance
process. Thereafter, BIND uses the managed keys database
(managed-keys.bind.jnl) as the source of key information.
Warning
Remember, if you choose to manage the keys on your own, whenever the
key changes (which, for most zones, happens on a periodic basis),
the configuration needs to be updated manually. Failure to do so will
result in breaking nearly all DNS queries for the subdomain of the
key. So if you are manually managing .gov, all domain names in
the .gov space may become unresolvable; if you are manually
managing the root key, you could break all DNS requests made to your
recursive name server.
Explicit management of keys was common in the early days of DNSSEC, when neither the root zone nor many top-level domains were signed. Since then, over 90% of the top-level domains have been signed, including all the largest ones. Unless you have a particular need to manage keys yourself, it is best to use the BIND defaults and let the software manage the root key.
- 5
The root zone was signed in July 2010 and, as at the time of this writing (mid-2020), the key has been changed once, in October 2018. The intention going forward is to roll the key once every five years.
What’s EDNS All About (And Why Should I Care)?¶
EDNS Overview¶
Traditional DNS responses are typically small in size (less than 512 bytes) and fit nicely into a small UDP packet. The Extension mechanism for DNS (EDNS, or EDNS(0)) offers a mechanism to send DNS data in larger packets over UDP. To support EDNS, both the DNS server and the network need to be properly prepared to support the larger packet sizes 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 ones. If DNS servers and the 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 be unable to resolve certain names at all.
Note that EDNS applies regardless of whether you are validating DNSSEC, because BIND has DNSSEC enabled by default.
Please see Network Requirements for more information on what DNSSEC expects from the network environment.
EDNS on DNS Servers¶
For many years, BIND has had EDNS enabled by default,
and the UDP packet size is set to a maximum of 4096 bytes. The DNS
administrator should not need to perform any reconfiguration. You can
use dig to verify that your server supports EDNS and see the UDP packet
size it allows with this dig command:
$ dig @10.53.0.1 www.isc.org. A +dnssec +multiline
; <<>> DiG 9.16.0 <<>> @10.53.0.1 ftp.isc.org a +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48742
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 29a9705c2160b08c010000005e67a4a102b9ae079c1b24c8 (good)
;; QUESTION SECTION:
;ftp.isc.org. IN A
;; ANSWER SECTION:
ftp.isc.org. 300 IN A 149.20.1.49
ftp.isc.org. 300 IN RRSIG A 13 3 300 (
20200401191851 20200302184340 27566 isc.org.
e9Vkb6/6aHMQk/t23Im71ioiDUhB06sncsduoW9+Asl4
L3TZtpLvZ5+zudTJC2coI4D/D9AXte1cD6FV6iS6PQ== )
;; Query time: 452 msec
;; SERVER: 10.53.0.1#53(10.53.0.1)
;; WHEN: Tue Mar 10 14:30:57 GMT 2020
;; MSG SIZE rcvd: 187
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/ .
Once you’ve verified that 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 your name server forwards to) does not support EDNS, you may experience DNS lookup failures or be unable to perform DNSSEC validation.
Support for Large Packets on Network Equipment¶
If both your recursive name server and your ISP’s name servers support EDNS, we are all good here, right? Not so fast. Since these large packets have to traverse 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 the Maximum Transmission Unit (MTU), and it can differ from network to network. IP fragmentation occurs when a large data packet needs to be broken down into chunks smaller than the MTU; these smaller chunks then need to be reassembled back into the large data packet at their destination. IP fragmentation is not necessarily a bad thing, and it most likely occurs on your network today.
Some network equipment, such as a firewall, 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 may either reject the large packet or drop 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 a larger DNS packet size, it often results in the larger packets being rejected, and to the end user it looks like the queries go unanswered. Or in the case of fragmentation, only a part of the answer makes it to the validating resolver, and your validating resolver may need to re-ask the question again and again, creating the appearance for end users that the DNS/network is slow.
While you are updating the configuration on your network equipment, make sure TCP port 53 is also allowed for DNS traffic.
Wait… DNS Uses TCP?¶
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 the arrival of DNSSEC. Traditional DNS relies on TCP port 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 via TCP.
Due to the increased packet size, DNSSEC may fall back to TCP more often than traditional (insecure) DNS. If your network blocks or filters TCP port 53 today, you may already experience instability with DNS resolution, before even deploying DNSSEC.
Signing¶
Easy-Start Guide for Signing Authoritative Zones¶
This section provides the basic information needed to set up a DNSSEC-enabled authoritative name server. A DNSSEC-enabled (or “signed”) zone contains additional resource records that are used to verify the authenticity of its zone information.
To convert a traditional (insecure) DNS zone to a secure one, we need to create some additional records (DNSKEY, RRSIG, and NSEC or NSEC3), and upload verifiable information (such as a DS record) to the parent zone to complete the chain of trust. For more information about DNSSEC resource records, please see What Does DNSSEC Add to DNS?.
Note
In this chapter, we assume all configuration files, key files, and
zone files are stored in /etc/bind, and most examples show
commands run as the root user. This may not be ideal, but the point is
not to distract from what is important here: learning how to sign
a zone. There are many best practices for deploying a more secure
BIND installation, with techniques such as jailed process and
restricted user privileges, but those are not covered
in this document. We trust you, a responsible DNS
administrator, to take the necessary precautions to secure your
system.
For the examples below, we work with the assumption that
there is an existing insecure zone example.com that we are
converting to a secure zone.
Enabling Automated DNSSEC Zone Maintenance and Key Generation¶
To sign a zone, add the following statement to its
zone clause in the BIND 9 configuration file:
options {
directory "/etc/bind";
recursion no;
...
};
zone "example.com" in {
...
dnssec-policy default;
...
};
The dnssec-policy statement causes the zone to be signed and turns
on automatic maintenance for the zone. This includes re-signing the zone
as signatures expire and replacing keys on a periodic basis. The value
default selects the default policy, which contains values suitable
for most situations. We cover the creation of a custom policy in
Creating a Custom DNSSEC Policy, but for the moment we are accepting the
default values.
When the configuration file is updated, tell named to
reload the configuration file by running rndc reconfig:
# rndc reconfig
And that’s it - BIND signs your zone.
At this point, before you go away and merrily add dnssec-policy
statements to all your zones, we should mention that, like a number of
other BIND configuration options, its scope depends on where it is placed. In
the example above, we placed it in a zone clause, so it applied only
to the zone in question. If we had placed it in a view clause, it
would have applied to all zones in the view; and if we had placed it in
the options clause, it would have applied to all zones served by
this instance of BIND.
Verification¶
The BIND 9 reconfiguration starts the process of signing the zone. First, it generates a key for the zone and includes it in the published zone. The log file shows messages such as these:
07-Apr-2020 16:02:55.045 zone example.com/IN (signed): reconfiguring zone keys
07-Apr-2020 16:02:55.045 reloading configuration succeeded
07-Apr-2020 16:02:55.046 keymgr: DNSKEY example.com/ECDSAP256SHA256/10376 (CSK) created for policy default
07-Apr-2020 16:02:55.046 Fetching example.com/ECDSAP256SHA256/10376 (CSK) from key repository.
07-Apr-2020 16:02:55.046 DNSKEY example.com/ECDSAP256SHA256/10376 (CSK) is now published
07-Apr-2020 16:02:55.046 DNSKEY example.com/ECDSAP256SHA256/10376 (CSK) is now active
07-Apr-2020 16:02:55.048 zone example.com/IN (signed): next key event: 07-Apr-2020 18:07:55.045
It then starts signing the zone. How long this process takes depends on the
size of the zone, the speed of the server, and how much activity is
taking place. We can check what is happening by using rndc,
entering the command:
# rndc signing -list example.com
While the signing is in progress, the output is something like:
Signing with key 10376/ECDSAP256SHA256
and when it is finished:
Done signing with key 10376/ECDSAP256SHA256
When the second message appears, the zone is signed.
Before moving on to the next step of coordinating with the parent zone,
let’s make sure everything looks good using delv. We want to
simulate what a validating resolver will check, by telling
delv to use a specific trust anchor.
First, we need to make a copy of the key created by BIND. This
is in the directory you set with the directory statement in
your configuration file’s options clause, and is named something
like Kexample.com.+013.10376.key:
# cp /etc/bind/Kexample.com.+013+10376.key /tmp/example.key
The original key file looks like this (with the actual key shortened for ease of display, and comments omitted):
# cat /etc/bind/Kexample.com.+013+10376.key
...
example.com. 3600 IN DNSKEY 257 3 13 6saiq99qDB...dqp+o0dw==
We want to edit the copy to be in the trust-anchors format, so that
it looks like this:
# cat /tmp/example.key
trust-anchors {
example.com. static-key 257 3 13 "6saiq99qDB...dqp+o0dw==";
};
Now we can run the delv command and instruct it to use 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. (
2020040703 ; serial
1800 ; refresh (30 minutes)
900 ; retry (15 minutes)
2419200 ; expire (4 weeks)
300 ; minimum (5 minutes)
)
example.com. 600 IN RRSIG SOA 13 2 600 (
20200421150255 20200407140255 10376 example.com.
jBsz92zwAcGMNV/yu167aKQZvFyC7BiQe1WEnlogdLTF
oq4yBQumOhO5WX61LjA17l1DuLWcd/ASwlUZWFGCYQ== )
Uploading Information to the Parent Zone¶
Once everything is complete on our name server, we need to generate some information to be uploaded to the parent zone to complete the chain of trust. The format 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 the parent zone.
What about your zone between the time you signed it and the time your parent zone accepts the upload? To the rest of the world, your zone still appears to be insecure, because if a validating resolver attempts to validate your domain name via your parent zone, 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 will fall back to the insecure DNS. Until you complete this final step with your parent zone, your zone remains insecure.
Note
Before uploading to your parent zone, verify that your newly signed zone has propagated to all of your name servers (usually via zone transfers). If some of your name servers still have unsigned zone data while the parent tells the world it should be signed, validating resolvers around the world cannot resolve your domain name.
Here are some examples of what you may upload to your parent zone, with the DNSKEY/DS data shortened for display. Note that no matter what format may be required, the end result is the parent zone publishing DS record(s) based on the information you upload. Again, contact your parent zone administrator(s) to find out the correct format for their system.
DS record format:
example.com. 3600 IN DS 10376 13 2 B92E22CAE0...33B8312EF0
DNSKEY format:
example.com. 3600 IN DNSKEY 257 3 13 6saiq99qDB...dqp+o0dw==
The DS record format may be generated from the DNSKEY using the
dnssec-dsfromkey tool, which is covered in
DS Record Format. For more details and examples on how
to work with your parent zone, please see
Working With the Parent Zone.
So… What Now?¶
Congratulations! Your zone is signed, your secondary 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? That is basically it - BIND
takes care of everything else. As for updating your zone file, you can
continue to update it the same way as prior to signing your
zone; the normal work flow of editing a zone file and using the rndc
command to reload the zone still works as usual, and although you are
editing the unsigned version of the zone, BIND generates the signed
version automatically.
Curious as to what all these commands did to your zone file? Read on to Your Zone, Before and After DNSSEC and find out. If you are interested in how to roll this out to your existing primary and secondary name servers, check out DNSSEC Signing in the Recipes chapter.
Your Zone, Before and After DNSSEC¶
When we assigned the default DNSSEC policy to the zone, we provided the minimal amount of information to 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.16.0 <<>> @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. (
2020040700 ; 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 reloading the
server configuration. Clearly, the zone grew in size, and the
number of records multiplied:
# dig @192.168.1.13 example.com. AXFR +multiline +onesoa
; <<>> DiG 9.16.0 <<>> @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. (
2020040703 ; serial
1800 ; refresh (30 minutes)
900 ; retry (15 minutes)
2419200 ; expire (4 weeks)
300 ; minimum (5 minutes)
)
example.com. 300 IN RRSIG NSEC 13 2 300 (
20200413050536 20200407140255 10376 example.com.
drtV1rJbo5OMi65OJtu7Jmg/thgpdTWrzr6O3Pzt12+B
oCxMAv3orWWYjfP2n9w5wj0rx2Mt2ev7MOOG8IOUCA== )
example.com. 300 IN NSEC ftp.example.com. NS SOA RRSIG NSEC DNSKEY TYPE65534
example.com. 600 IN RRSIG NS 13 2 600 (
20200413130638 20200407140255 10376 example.com.
2ipmzm1Ei6vfE9OLowPMsxLBCbjrCpWPgWJ0ekwZBbux
MLffZOXn8clt0Ql2U9iCPdyoQryuJCiojHSE2d6nrw== )
example.com. 600 IN RRSIG SOA 13 2 600 (
20200421150255 20200407140255 10376 example.com.
jBsz92zwAcGMNV/yu167aKQZvFyC7BiQe1WEnlogdLTF
oq4yBQumOhO5WX61LjA17l1DuLWcd/ASwlUZWFGCYQ== )
example.com. 0 IN RRSIG TYPE65534 13 2 0 (
20200413050536 20200407140255 10376 example.com.
Xjkom24N6qeCJjg9BMUfuWf+euLeZB169DHvLYZPZNlm
GgM2czUDPio6VpQbUw6JE5DSNjuGjgpgXC5SipC42g== )
example.com. 3600 IN RRSIG DNSKEY 13 2 3600 (
20200421150255 20200407140255 10376 example.com.
maK75+28oUyDtci3V7wjTsuhgkLUZW+Q++q46Lea6bKn
Xj77kXcLNogNdUOr5am/6O6cnPeJKJWsnmTLISm62g== )
example.com. 0 IN TYPE65534 \# 5 ( 0D28880001 )
example.com. 3600 IN DNSKEY 257 3 13 (
6saiq99qDBb5b4G4cx13cPjFTrIvUs3NW44SvbbHorHb
kXwOzeGAWyPORN+pwEV/LP9+FHAF/JzAJYdqp+o0dw==
) ; KSK; alg = ECDSAP256SHA256 ; key id = 10376
example.com. 600 IN NS ns1.example.com.
ftp.example.com. 600 IN RRSIG A 13 3 600 (
20200413130638 20200407140255 10376 example.com.
UYo1njeUA49VhKnPSS3JO4G+/Xd2PD4m3Vaacnd191yz
BIoouEBAGPcrEM2BNrgR0op1EWSus9tG86SM1ZHGuQ== )
ftp.example.com. 300 IN RRSIG NSEC 13 3 300 (
20200413130638 20200407140255 10376 example.com.
rPADrAMAPIPSF3S45OSY8kXBTYMS3nrZg4Awj7qRL+/b
sOKy6044MbIbjg+YWL69dBjKoTSeEGSCSt73uIxrYA== )
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 13 3 600 (
20200413130638 20200407140255 10376 example.com.
Yeojg7qrJmxL6uLTnALwKU5byNldZ9Ggj5XjcbpPvujQ
ocG/ovGBg6pdugXC9UxE39bCDl8dua1frjDcRCCZAA== )
ns1.example.com. 300 IN RRSIG NSEC 13 3 300 (
20200413130638 20200407140255 10376 example.com.
vukgQme6k7JwCf/mJOOzHXbE3fKtSro+Kc10T6dHMdsc
oM1/oXioZvgBZ9cKrQhIAUt7r1KUnrUwM6Je36wWFA== )
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 13 3 600 (
20200413130638 20200407140255 10376 example.com.
JXi4WYypofD5geUowVqlqJyHzvcRnsvU/ONhTBaUCw5Y
XtifKAXRHWrUL1HIwt37JYPLf5uYu90RfkWLj0GqTQ== )
web.example.com. 300 IN RRSIG NSEC 13 3 300 (
20200413130638 20200407140255 10376 example.com.
XF4Hsd58dalL+s6Qu99bG80PQyMf7ZrHEzDiEflRuykP
DfBRuf34z27vj70LO1lp2ZiX4BB1ahcEK2ae9ASAmA== )
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 13 3 600 (
20200413050536 20200407140255 10376 example.com.
mACKXrDOF5JMWqncSiQ3pYWA6abyGDJ4wgGCumjLXhPy
0cMzJmKv2s7G6+tW3TsA6BK3UoMfv30oblY2Mnl4/A== )
www.example.com. 300 IN RRSIG NSEC 13 3 300 (
20200413050536 20200407140255 10376 example.com.
1YQ22odVt0TeP5gbNJwkvS684ipDmx6sEOsF0eCizhCv
x8osuOATdlPjIEztt+rveaErZ2nsoLor5k1nQAHsbQ== )
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 the zone is set up properly with DNSSEC. Fortunately, there are tools to help us with that. Read on to How To Test Authoritative Zones to learn more.
How To Test Authoritative Zones¶
So we’ve activated DNSSEC and uploaded some data to our parent zone. How do we know our zone is signed correctly? Here are a few ways to check.
Look for Key Data in Your Zone¶
One way to see if your zone is signed is to check for the presence of DNSKEY record types. In our example, we created a single key, and we expect to see it returned when we query for it.
$ dig @192.168.1.13 example.com. DNSKEY +multiline
; <<>> DiG 9.16.0 <<>> @10.53.0.6 example.com DNSKEY +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18637
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: efe186423313fb66010000005e8c997e99864f7d69ed7c11 (good)
;; QUESTION SECTION:
;example.com. IN DNSKEY
;; ANSWER SECTION:
example.com. 3600 IN DNSKEY 257 3 13 (
6saiq99qDBb5b4G4cx13cPjFTrIvUs3NW44SvbbHorHb
kXwOzeGAWyPORN+pwEV/LP9+FHAF/JzAJYdqp+o0dw==
) ; KSK; alg = ECDSAP256SHA256 ; key id = 10376
Look for Signatures in Your Zone¶
Another way to see if your zone data is signed is to check for the presence of a signature. With DNSSEC, every record 6 now comes with at least one corresponding signature, known as an RRSIG.
$ dig @192.168.1.13 example.com. SOA +dnssec +multiline
; <<>> DiG 9.16.0 <<>> @10.53.0.6 example.com SOA +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45219
;; 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
; COOKIE: 75adff4f4ce916b2010000005e8c99c0de47eabb7951b2f5 (good)
;; QUESTION SECTION:
;example.com. IN SOA
;; ANSWER SECTION:
example.com. 600 IN SOA ns1.example.com. admin.example.com. (
2020040703 ; serial
1800 ; refresh (30 minutes)
900 ; retry (15 minutes)
2419200 ; expire (4 weeks)
300 ; minimum (5 minutes)
)
example.com. 600 IN RRSIG SOA 13 2 600 (
20200421150255 20200407140255 10376 example.com.
jBsz92zwAcGMNV/yu167aKQZvFyC7BiQe1WEnlogdLTF
oq4yBQumOhO5WX61LjA17l1DuLWcd/ASwlUZWFGCYQ== )
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 is higher than the one in the
signed copy, then the signed copy is increased to match it;
otherwise, the two are kept separate.
Examine the Zone File¶
Our original zone file example.com.db remains untouched, and named has
generated three 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
# 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:
.jbk: a transient file used bynamed.signed: the signed version of the zone in raw format.signed.jnl: a journal file for the signed version of the zone
These files are stored in raw (binary) format for faster loading. To
reveal the human-readable version, use named-compilezone
as shown below. In the example below, we run 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
Check the Parent¶
Although this is not strictly related to whether the zone is signed, a critical part of DNSSEC is the trust relationship between the parent and the child. Just because we, the child, have all the correctly signed records in our zone does not mean it can be fully validated by a validating resolver, unless our parent’s data agrees with ours. To check if our upload to the parent was successful, ask the parent name server for the DS record of our child zone; we should get back the DS record(s) containing the information we uploaded in Uploading Information to the Parent Zone:
$ dig example.com. DS
; <<>> DiG 9.16.0 <<>> example.com DS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16954
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: db280d5b52576780010000005e8c9bf5b0d8de103d934e5d (good)
;; QUESTION SECTION:
;example.com. IN DS
;; ANSWER SECTION:
example.com. 61179 IN DS 10376 13 2 B92E22CAE0B41430EC38D3F7EDF1183C3A94F4D4748569250C15EE33B8312EF0
- 6
Well, almost every record: NS records and glue records for delegations do not have RRSIG records. If there are no delegations, then every record in your zone is signed and comes with its own RRSIG.
External Testing Tools¶
We recommend two tools, below: Verisign DNSSEC Debugger and DNSViz. Others can be found via a simple online search. These excellent online tools are an easy way to verify that your domain name is fully secured.
Verisign DNSSEC Debugger¶
URL: https://dnssec-debugger.verisignlabs.com/
This tool shows a nice summary of checks performed on your domain name. You can expand it to view more details for each of the items checked, to get a detailed report.
Verisign DNSSEC Debugger¶
DNSViz¶
URL: https://dnsviz.net/
DNSViz provides a visual analysis of the DNSSEC authentication chain for a domain name and its resolution path in the DNS namespace.
DNSViz¶
Signing Easy Start Explained¶
Enable Automatic DNSSEC Maintenance Explained¶
Signing a zone requires a number of separate steps:
Generation of the keys to sign the zone.
Inclusion of the keys into the zone.
Signing of the records in the file (including the generation of the NSEC or NSEC3 records).
Maintaining a signed zone comprises a set of ongoing tasks:
Re-signing the zone as signatures approach expiration.
Generation of new keys as the time approaches for a key roll.
Inclusion of new keys into the zone when the rollover starts.
Transition from signing the zone with the old set of keys to signing the zone with the new set of keys.
Waiting the appropriate interval before removing the old keys from the zone.
Deleting the old keys.
That is quite complex, and it is all handled in BIND 9 with the single
dnssec-policy default statement. We will see later on (in the
Creating a Custom DNSSEC Policy section) how these actions can be tuned, by
setting up our own DNSSEC policy with customized parameters. However, in many
cases the defaults are adequate.
At the time of this writing (mid-2020), dnssec-policy is still a
relatively new feature in BIND. Although it is the preferred
way to run DNSSEC in a zone, it is not yet able to automatically implement
all the features that are available
with a more “hands-on” approach to signing and key maintenance. For this
reason, we cover alternative signing techniques in
Alternate Ways of Signing a Zone.
Working With the Parent Zone¶
As mentioned in Uploading Information to the Parent Zone, the format of the information uploaded to your parent zone is dictated by your parent zone administrator. The two main formats are:
DS record format
DNSKEY format
Check with your parent zone to see which format they require.
But how can you get each of the formats from your existing data?
When named turned on automatic
DNSSEC maintenance, essentially the first thing it did was to create
the DNSSEC keys and put them in the directory you specified in the
configuration file. If you look in that directory, you will see three
files with names like Kexample.com.+013+10376.key,
Kexample.com.+013+10376.private, and
Kexample.com.+013+10376.state. The one we are interested in is the
one with the .key suffix, which contains the zone’s public key. (The
other files contain the zone’s private key and the DNSSEC state
associated with the key.) This public key is used to generate the information we
need to pass to the parent.
DS Record Format¶
Below is an example of a DS record format generated from the KSK we
created earlier (Kexample.com.+013+10376.key):
# cd /etc/bind
dnssec-dsfromkey Kexample.com.+013+10376.key
example.com. IN DS 10376 13 2 B92E22CAE0B41430EC38D3F7EDF1183C3A94F4D4748569250C15EE33B8312EF0
Some registrars ask their customers to manually specify the types of algorithm and digest used. In this example, 13 represents the algorithm used, and 2 represents the digest type (SHA-256). The key tag or key ID is 10376.
DNSKEY Format¶
Below is an example of the same key ID (10376) using DNSKEY format (with the actual key shortened for ease of display):
example.com. 3600 IN DNSKEY 257 3 13 (6saiq99qDB...dqp+o0dw==) ; key id = 10376
The key itself is easy to find (it’s difficult to miss that long base64 string) in the file.
# cd /etc/bind
# cat Kexample.com.+013+10376.key
; This is a key-signing key, keyid 10376, for example.com.
; Created: 20200407150255 (Tue Apr 7 16:02:55 2020)
; Publish: 20200407150255 (Tue Apr 7 16:02:55 2020)
; Activate: 20200407150255 (Tue Apr 7 16:02:55 2020)
example.com. 3600 IN DNSKEY 257 3 13 6saiq99qDB...dqp+o0dw==
Creating a Custom DNSSEC Policy¶
The remainder of this section describes the contents of a custom DNSSEC policy. Advanced Discussions describes the concepts involved here and the pros and cons of choosing particular values. If you are not already familiar with DNSSEC, it may be worth reading that chapter first.
Setting up your own DNSSEC policy means that you must include a
dnssec-policy clause in the zone file. This sets values for the
various parameters that affect the signing of zones and the rolling of
keys. The following is an example of such a clause:
dnssec-policy standard {
dnskey-ttl 600;
keys {
ksk lifetime 365d algorithm ecdsap256sha256;
zsk lifetime 60d algorithm ecdsap256sha256;
};
max-zone-ttl 600;
parent-ds-ttl 600;
parent-propagation-delay 2h;
publish-safety 7d;
retire-safety 7d;
signatures-refresh 5d;
signatures-validity 15d;
signatures-validity-dnskey 15d;
zone-propagation-delay 2h;
};
The policy has multiple parts:
The name must be specified. As each zone can use a different policy,
namedneeds to be able to distinguish between policies. This is done by giving each policy a name, such asstandardin the above example.The
keysclause lists all keys that should be in the zone, along with their associated parameters. In this example, we are using the conventional KSK/ZSK split, with the KSK changed every year and the ZSK changed every two months. We have used one of the two mandatory algorithms for the keys. (ThedefaultDNSSEC policy sets a CSK that is never changed.)The parameters ending in
-ttlare, as expected, the TTLs of the associated records. Remember that during a key rollover, we have to wait for records to expire from caches? The values here tell BIND 9 the maximum amount of time it has to wait for this to happen. Values can be set for the DNSKEY records in your zone, the non-DNSKEY records in your zone, and the DS records in the parent zone.Another set of time-related parameters are those ending in
-propagation-delay. These tell BIND how long it takes for a change in zone contents to become available on all secondary servers. (This may be non-negligible: for example, if a large zone is transferred over a slow link.)The policy also sets values for the various signature parameters: how long the signatures on the DNSKEY and non-DNSKEY records are valid, and how often BIND should re-sign the zone.
The parameters ending in
-safetyare there to give you a bit of leeway in case a key roll doesn’t go to plan. When introduced into the zone, thepublish-safetytime is the amount of additional time, over and above that calculated from the other parameters, during which the new key is in the zone but before BIND starts to sign records with it. Similarly, theretire-safetyis the amount of additional time, over and above that calculated from the other parameters, during which the old key is retained in the zone before being removed.Finally, the
purge-keysoption allows you to clean up key files automatically after a period of time. If a key has been removed from the zone, this option will determine how long its key files will be retained on disk.
(You do not have to specify all the items listed above in your policy definition. Any that are not set simply take the default value.)
Usually, the exact timing of a key roll, or how long a signature remains valid, is not critical. For this reason, err on the side of caution when setting values for the parameters. It is better to have an operation like a key roll take a few days longer than absolutely required, than it is to have a quick key roll but have users get validation failures during the process.
Having defined a new policy called “standard”, we now need to tell
named to use it. We do this by adding a dnssec-policy standard;
statement to the configuration file. Like many other configuration
statements, it can be placed in the options statement (thus applying
to all zones on the server), a view statement (applying to all zones
in the view), or a zone statement (applying only to that zone). In
this example, we’ll add it to the zone statement:
zone "example.net" in {
...
dnssec-policy standard;
...
};
Finally, tell named to use the new policy:
# rndc reconfig
… and that’s it. named now applies the “standard” policy to
your zone.
Maintenance Tasks¶
Zone data is signed and the parent zone has published your DS records: at this point your zone is officially secure. When other validating resolvers look up information in your zone, they are able to follow the 12-step process as described in How Does DNSSEC Change DNS Lookup (Revisited)? and verify the authenticity and integrity of the answers.
There is not that much left for you, as the DNS administrator, to do on an ongoing basis. Whenever you update your zone, BIND automatically re-signs your zone with new RRSIG and NSEC/NSEC3 records, and even increments the serial number for you. If you choose to split your keys into a KSK and ZSK, the rolling of the ZSK is completely automatic. Rolling of a KSK or CSK may require some manual intervention, though, so let’s examine two more DNSSEC-related resource records, CDS and CDNSKEY.
The CDS and CDNSKEY Resource Records¶
Passing the DS record to the organization running the parent zone has always been recognized as a bottleneck in the key rollover process. To automate the process, the CDS and CDNSKEY resource records were introduced.
The CDS and CDNSKEY records are identical to the DS and DNSKEY records, except in the type code and the name. When such a record appears in the child zone, it is a signal to the parent that it should update the DS it has for that zone. In essence, when the parent notices the presence of the CDS and/or CDNSKEY record(s) in the child zone, it checks these records to verify that they are signed by a valid key for the zone. If the record(s) successfully validate, the parent zone’s DS RRset for the child zone is changed to correspond to the CDS (or CDNSKEY) records. (For more information on how the signaling works and the issues surrounding it, please refer to RFC 7344 and RFC 8078.)
Working with the Parent Zone (2)¶
Once the zone is signed, the only required manual tasks are to monitor KSK or CSK key rolls and pass the new DS record to the parent zone. However, if the parent can process CDS or CDNSKEY records, you may not even have to do that 7.
When the time approaches for the roll of a KSK or CSK, BIND adds a CDS and a CDNSKEY record for the key in question to the apex of the zone. If your parent zone supports polling for CDS/CDNSKEY records, they are uploaded and the DS record published in the parent - at least ideally.
If BIND is configured with parental-agents, it will check for the DS
presence. Let’s look at the following configuration excerpt:
parental-agents "net" {
10.53.0.11, 10.53.0.12;
};
zone "example.net" in {
...
dnssec-policy standard;
parental-agents { "net"; };
...
};
BIND will check for the presence of the DS record in the parent zone by querying its parental agents (defined in RFC 7344 to be the entities that the child zone has a relationship with to change its delegation information). In the example above, The zone example.net is configured with two parental agents, at the addresses 10.53.0.11 and 10.53.0.12. These addresses are used as an example only. Both addresses will have to respond with a DS RRset that includes the DS record identifying the key that is being rolled. If one or both don’t have the DS included yet the rollover is paused, and the check for DS presence is retried after an hour. The same applies for DS withdrawal.
Alternatively, you can use the rndc tool to tell named that the DS
record has been published or withdrawn. For example:
# rndc dnssec -checkds published example.net
If your parent zone doesn’t support CDS/CDNSKEY, you will have to supply
the DNSKEY or DS record to the parent zone manually when a new KSK appears in
your zone, presumably using the same mechanism you used to upload the
records for the first time. Again, you need to use the rndc tool
to tell named that the DS record has been published.
- 7
For security reasons, a parent zone that supports CDS/CDNSKEY may require the DS record to be manually uploaded when we first sign the zone. Until our zone is signed, the parent cannot be sure that a CDS or CDNSKEY record it finds by querying our zone really comes from our zone; thus, it needs to use some other form of secure transfer to obtain the information.
Alternate Ways of Signing a Zone¶
Although use of the automatic dnssec-policy is the preferred way to sign zones in
BIND, there are occasions where a more manual approach may be
needed, such as when external hardware is used to
generate and sign the zone. dnssec-policy does not currently support
the use of external hardware, so if your security policy requires it, you
need to use one of the methods described here.
The idea of DNSSEC was first discussed in the 1990s and has been extensively developed over the intervening years. BIND has tracked the development of this technology, often being the first name server implementation to introduce new features. However, for compatibility reasons, BIND retained older ways of doing things even when new ways were added. This particularly applies to signing and maintaining zones, where different levels of automation are available.
The following is a list of the available methods of signing in BIND, in the order that they were introduced - and in order of decreasing complexity.
- Manual
“Manual” signing was the first method to be introduced into BIND and its name describes it perfectly: the user needs to do everything. In the more-automated methods, you load an unsigned zone file into
named, which takes care of signing it. With manual signing, you have to provide a signed zone fornamedto serve.In practice, this means creating an unsigned zone file as usual, then using the BIND-provided tools
dnssec-keygento create the keys anddnssec-signzoneto sign the zone. The signed zone is stored in another file and is the one you tell BIND to load. To update the zone (for example, to add a resource record), you update the unsigned zone, re-sign it, and tellnamedto load the updated signed copy. The same goes for refreshing signatures or rolling keys; the user is responsible for providing the signed zone served bynamed. (In the case of rolling keys, you are also responsible for ensuring that the keys are added and removed at the correct times.)Why would you want to sign your zone this way? You probably wouldn’t in the normal course of events, but as there may be circumstances in which it is required, the scripts have been left in the BIND distribution.
- Semi-Automatic
The first step in DNSSEC automation came with BIND 9.7, when the
auto-dnssecoption was added. This causesnamedto periodically search the directory holding the key files (see Generate Keys for a description) and to use the information in them to both add and remove keys and sign the zone.Use of
auto-dnssecalone requires that the zone be dynamic, something not suitable for a number of situations, so BIND 9.9 added theinline-signingoption. With this,namedessentially keeps the signed and unsigned copies of the zone separate. The signed zone is created from the unsigned one using the key information; when the unsigned zone is updated and the zone reloaded,nameddetects the changes and updates the signed copy of the zone.This mode of signing has been termed “semi-automatic” in this document because keys still have to be manually created (and deleted when appropriate). Although not an onerous task, it is still additional work.
Why would anyone want to use this method when fully automated ones are available? At the time of this writing (mid-2020), the fully automatic methods cannot handle all scenarios, particularly that of having a single key shared among multiple zones. They also do not handle keys stored in Hardware Security Modules (HSMs), which are briefly covered in Hardware Security Modules (HSMs).
- Fully Automatic with
dnssec-keymgr The next step in the automation of DNSSEC operations came with BIND 9.11, which introduced the
dnssec-keymgrutility. This is a separate program and is expected to be run on a regular basis (probably viacron). It reads a DNSSEC policy from its configuration file and reads timing information from the DNSSEC key files. With this information it creates new key files with timing information in them consistent with the policy.namedis run as usual, picking up the timing information in the key files to determine when to add and remove keys, and when to sign with them.In BIND 9.17.0 and later, this method of handling DNSSEC policies has been replaced by the
dnssec-policystatement in the configuration file.- Fully Automatic with
dnssec-policy Introduced a BIND 9.16,
dnssec-policyreplacesdnssec-keymgrfrom BIND 9.17 onwards and avoids the need to run a separate program. It also handles the creation of keys if a zone is added (dnssec-keymgrrequires an initial key) and deletes old key files as they are removed from the zone. This is the method described in Easy-Start Guide for Signing Authoritative Zones.
We now look at some of these methods in more detail. We cover
semi-automatic signing first, as that contains a lot of useful
information about keys and key timings. We then describe what
dnssec-keymgr adds to semi-automatic signing. After that, we
touch on fully automatic signing with dnssec-policy. Since this has
already been described in
Easy-Start Guide for Signing Authoritative Zones, we will just
mention a few additional points. Finally, we briefly describe manual signing.
Semi-Automatic Signing¶
As noted above, the term semi-automatic signing has been used in this
document to indicate the mode of signing enabled by the auto-dnssec
and inline-signing keywords. named signs the zone without any
manual intervention, based purely on the timing information in the
DNSSEC key files. The files, however, must be created manually.
By appropriately setting the key parameters and the timing information
in the key files, you can implement any DNSSEC policy you want for your
zones. But why manipulate the key information yourself rather than rely
on dnssec-keymgr or dnssec-policy to do it for you? The answer
is that semi-automatic signing allows you to do things that, at the time of this writing
(mid-2020), are currently not possible with one of the key managers: for
example, the ability to use an HSM to store keys, or the ability to use
the same key for multiple zones.
To convert a traditional (insecure) DNS zone to a secure one, we need to create various additional records (DNSKEY, RRSIG, NSEC/NSEC3) and, as with fully automatic signing, to upload verifiable information (such as a DS record) to the parent zone to complete the chain of trust.
Note
Again, we assume all configuration files, key
files, and zone files are stored in /etc/bind, and most examples
show commands run
as the root user. This may not be ideal, but the point is not
to distract from what is important here: learning how to sign
a zone. There are many best practices for deploying a more secure
BIND installation, with techniques such as jailed process and
restricted user privileges, but those are not covered
in this document. We trust you, a responsible DNS
administrator, to take the necessary precautions to secure your
system.
For our examples below, we work with the assumption that
there is an existing insecure zone example.com that we are
converting to a secure version. The secure version uses both a KSK
and a ZSK.
Generate Keys¶
Everything in DNSSEC centers around keys, so we begin by generating our own keys.
# cd /etc/bind
# dnssec-keygen -a RSASHA256 -b 1024 example.com
Generating key pair...........................+++++ ......................+++++
Kexample.com.+008+34371
# dnssec-keygen -a RSASHA256 -b 2048 -f KSK example.com
Generating key pair........................+++ ..................................+++
Kexample.com.+008+00472
This command generates four key files in /etc/bind/keys:
Kexample.com.+008+34371.key
Kexample.com.+008+34371.private
Kexample.com.+008+00472.key
Kexample.com.+008+00472.private
The two files ending in .key are the public keys. These contain the
DNSKEY resource records that appear in the zone. The two files
ending in .private are the private keys, and contain the information
that named actually uses to sign the zone.
Of the two pairs, 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 file contents (the actual keys are shortened here for ease of display):
# cat Kexample.com.+008+34371.key
; This is a zone-signing key, keyid 34371, for example.com.
; Created: 20200616104249 (Tue Jun 16 11:42:49 2020)
; Publish: 20200616104249 (Tue Jun 16 11:42:49 2020)
; Activate: 20200616104249 (Tue Jun 16 11:42:49 2020)
example.com. IN DNSKEY 256 3 8 AwEAAfel66...LqkA7cvn8=
# cat Kexample.com.+008+00472.key
; This is a key-signing key, keyid 472, for example.com.
; Created: 20200616104254 (Tue Jun 16 11:42:54 2020)
; Publish: 20200616104254 (Tue Jun 16 11:42:54 2020)
; Activate: 20200616104254 (Tue Jun 16 11:42:54 2020)
example.com. IN DNSKEY 257 3 8 AwEAAbCR6U...l8xPjokVU=
The first line of each file tells us what type of key it is. Also, by looking at the actual DNSKEY record, we can tell them apart: 256 is ZSK, and 257 is KSK.
The name of the file also tells us something about the contents. The file names are of the form:
K<zone-name>+<algorithm-id>+<keyid>
The “zone name” is self-explanatory. The “algorithm ID” is a number assigned to the algorithm used to construct the key: the number appears in the DNSKEY resource record. In our example, 8 means the algorithm RSASHA256. Finally, the “keyid” is essentially a hash of the key itself.
Make sure these files are readable by named and make sure that the
.private files are not readable by anyone else.
Refer to System Entropy for information on how to speed up the key generation process if your random number generator has insufficient entropy.
Setting Key Timing Information¶
You may remember that in the above description of this method, we said
that time information related to rolling keys is stored in the key
files. This is placed there by dnssec-keygen when the file is
created, and it can be modified using dnssec-settime. By default,
only a limited amount of timing information is included in the file, as
illustrated in the examples in the previous section.
All the dates are the same, and are the date and time that
dnssec-keygen created the key. We can use dnssec-settime to
modify the dates 8. For example, to publish this key in
the zone on 1 July 2020, use it to sign records for a year starting on
15 July 2020, and remove it from the zone at the end of July 2021, we
can use the following command:
# dnssec-settime -P 20200701 -A 20200715 -I 20210715 -D 20210731 Kexample.com.+008+34371.key
./Kexample.com.+008+34371.key
./Kexample.com.+008+34371.private
which would set the contents of the key file to:
; This is a zone-signing key, keyid 34371, for example.com.
; Created: 20200616104249 (Tue Jun 16 11:42:49 2020)
; Publish: 20200701000000 (Wed Jul 1 01:00:00 2020)
; Activate: 20200715000000 (Wed Jul 15 01:00:00 2020)
; Inactive: 20210715000000 (Thu Jul 15 01:00:00 2021)
; Delete: 20210731000000 (Sat Jul 31 01:00:00 2021)
example.com. IN DNSKEY 256 3 8 AwEAAfel66...LqkA7cvn8=
(The actual key is truncated here to improve readability.)
Below is a complete list of each of the metadata fields, and how each one affects the signing of your zone:
Created: This records the date on which the key was created. It is not used in calculations; it is useful simply for documentation purposes.
Publish: This sets the date on which a key is to be published to the zone. After that date, the key is included in the zone but is not used to sign it. This allows validating resolvers to get a copy of the new key in their cache before there are any resource records signed with it. By default, if not specified at creation time, this is set to the current time, meaning the key is published as soon as
namedpicks it up.Activate: This sets the date on which the key is to be activated. After that date, resource records are signed with the key. By default, if not specified during creation time, this is set to the current time, meaning the key is used to sign data as soon as
namedpicks it up.Revoke: This sets the date on which the key is to be revoked. After that date, the key is flagged as revoked, although it is still included in the zone and used to sign it. This is used to notify validating resolvers that this key is about to be removed or retired from the zone. (This state is not used in normal day-to-day operations. See RFC 5011 to understand the circumstances where it may be used.)
Inactive: This sets the date on which the key is to become inactive. After that date, the key is still included in the zone, but it is no longer used to sign it. This sets the “expiration” or “retire” date for a key.
Delete: This sets the date on which the key is to be deleted. After that date, the key is no longer included in the zone, but it continues to exist on the file system or key repository.
This can be summarized as follows:
Metadata |
Included in Zone File? |
Used to Sign Data? |
Purpose |
|---|---|---|---|
Created |
No |
No |
Recording of key creation |
Publish |
Yes |
No |
Introduction of a key soon to be active |
Activate |
Yes |
Yes |
Activation date for new key |
Revoke |
Yes |
Yes |
Notification of a key soon to be retired |
Inactive |
Yes |
No |
Inactivation or retirement of a key |
Delete |
No |
No |
Deletion or removal of a key from a zone |
The publication date is the date the key is introduced into the zone. Sometime later it is activated and is used to sign resource records. After a specified period, BIND stops using it to sign records, and at some other specified later time it is removed from the zone.
Finally, we should note that the dnssec-keygen command supports the
same set of switches so we could have set the dates
when we created the key.
Reconfiguring BIND¶
Having created the keys with the appropriate timing information, the
next step is to turn on DNSSEC signing. Below is a very simple
named.conf; in our example environment, this file is
/etc/bind/named.conf.
options {
directory "/etc/bind";
recursion no;
minimal-responses yes;
};
zone "example.com" IN {
type primary;
file "example.com.db";
auto-dnssec maintain;
inline-signing yes;
};
Once the configuration file is updated, tell named to
reload:
# rndc reload
server reload successful
Verifying That the Zone Is Signed Correctly¶
You should now check that the zone is signed. Follow the steps in Verification.
Uploading the DS Record to the Parent¶
As described in Uploading Information to the Parent Zone, we must now upload the new information to the parent zone. The format of the information and how to generate it is described in Working With the Parent Zone, although it is important to remember that you must use the contents of the KSK file that you generated above as part of the process.
When the DS record is published in the parent zone, your zone is fully signed.
Checking That Your Zone Can Be Validated¶
Finally, follow the steps in How To Test Authoritative Zones to confirm that a query recognizes the zone as properly signed and vouched for by the parent zone.
So… What Now?¶
Once the zone is signed, it must be monitored as described in Maintenance Tasks. However, as the time approaches for a key roll, you must create the new key. Of course, it is possible to create keys for the next fifty years all at once and set the key times appropriately. Whether the increased risk in having the private key files for future keys available on disk offsets the overhead of having to remember to create a new key before a rollover depends on your organization’s security policy.
Fully Automatic Signing With dnssec-keymgr¶
dnssec-keymgr is a program supplied with BIND (versions 9.11 to
9.16) to help with key rollovers. When run, it compares the timing
information for existing keys with the defined policy, and adjusts it if
necessary. It also creates additional keys as required.
dnssec-keymgr is completely separate from named. As we will see,
the policy states a coverage period; dnssec-keymgr generates
enough key files to handle all rollovers in that period. However, it is
a good idea to schedule it to run on a regular basis; that way there is
no chance of forgetting to run it when the coverage period ends.
BIND should be set up exactly the same way as described in
Semi-Automatic Signing, i.e.,
with auto-dnssec set to maintain and inline-signing set to
true. Then a policy file must be created. The following is an
example of such a file:
# cat policy.conf
policy standard {
coverage 1y;
algorithm RSASHA256;
directory "/etc/bind";
keyttl 2h;
key-size ksk 4096;
roll-period ksk 1y;
pre-publish ksk 30d;
post-publish ksk 30d;
key-size zsk 2048;
roll-period zsk 90d;
pre-publish zsk 30d;
post-publish zsk 30d;
};
zone example.com {
policy standard;
};
zone example.net {
policy standard;
keyttl 300;
};
As can be seen, the syntax is similar to that of the named
configuration file.
In the example above, we define a DNSSEC policy called “standard”. Keys
are created using the RSASHA256 algorithm, assigned a TTL of two hours,
and placed in the directory /etc/bind. KSKs have a key size of
4096 bits and are expected to roll once a year; the new key is added to the
zone 30 days before it becomes active, and is retained in the zone for
30 days after it is rolled. ZSKs have a key size of 2048 bits and roll
every 90 days; like the KSKs, the are added to the zone 30 days before
they are used for signing, and retained for 30 days after named
ceases signing with them.
The policy is applied to two zones, example.com and example.net.
The policy is applied unaltered to the former, but for the latter the
setting for the DNSKEY TTL has been overridden and set to 300 seconds.
To apply the policy, we need to run dnssec-keymgr. Since this does
not read the named configuration file, it relies on the presence of
at least one key file for a zone to tell it that the zone is
DNSSEC-enabled. If a key file does not already exist, we first need to create
one for each zone. We can do that either by running
dnssec-keygen to create a key file for each zone 9, or by
specifying the zones in question on the command line. Here, we do the
latter:
# dnssec-keymgr -c policy.conf example.com example.net
# /usr/local/sbin/dnssec-keygen -q -K /etc/bind -L 7200 -a RSASHA256 -b 2048 example.net
# /usr/local/sbin/dnssec-keygen -q -K /etc/bind -L 7200 -fk -a RSASHA256 -b 4096 example.net
# /usr/local/sbin/dnssec-settime -K /etc/bind -I 20200915110318 -D 20201015110318 Kexample.net.+008+31339
# /usr/local/sbin/dnssec-keygen -q -K /etc/bind -S Kexample.net.+008+31339 -L 7200 -i 2592000
# /usr/local/sbin/dnssec-settime -K /etc/bind -I 20201214110318 -D 20210113110318 Kexample.net.+008+14526
# /usr/local/sbin/dnssec-keygen -q -K /etc/bind -S Kexample.net.+008+14526 -L 7200 -i 2592000
# /usr/local/sbin/dnssec-settime -K /etc/bind -I 20210314110318 -D 20210413110318 Kexample.net.+008+46069
# /usr/local/sbin/dnssec-keygen -q -K /etc/bind -S Kexample.net.+008+46069 -L 7200 -i 2592000
# /usr/local/sbin/dnssec-settime -K /etc/bind -I 20210612110318 -D 20210712110318 Kexample.net.+008+13018
# /usr/local/sbin/dnssec-keygen -q -K /etc/bind -S Kexample.net.+008+13018 -L 7200 -i 2592000
# /usr/local/sbin/dnssec-settime -K /etc/bind -I 20210617110318 -D 20210717110318 Kexample.net.+008+55237
# /usr/local/sbin/dnssec-keygen -q -K /etc/bind -S Kexample.net.+008+55237 -L 7200 -i 2592000
# /usr/local/sbin/dnssec-keygen -q -K /etc/bind -L 7200 -a RSASHA256 -b 2048 example.com
# /usr/local/sbin/dnssec-keygen -q -K /etc/bind -L 7200 -fk -a RSASHA256 -b 4096 example.com
# /usr/local/sbin/dnssec-settime -K /etc/bind -P 20200617110318 -A 20200617110318 -I 20200915110318 -D 20201015110318 Kexample.com.+008+31168
# /usr/local/sbin/dnssec-keygen -q -K /etc/bind -S Kexample.com.+008+31168 -L 7200 -i 2592000
# /usr/local/sbin/dnssec-settime -K /etc/bind -I 20201214110318 -D 20210113110318 Kexample.com.+008+24199
# /usr/local/sbin/dnssec-keygen -q -K /etc/bind -S Kexample.com.+008+24199 -L 7200 -i 2592000
# /usr/local/sbin/dnssec-settime -K /etc/bind -I 20210314110318 -D 20210413110318 Kexample.com.+008+08728
# /usr/local/sbin/dnssec-keygen -q -K /etc/bind -S Kexample.com.+008+08728 -L 7200 -i 2592000
# /usr/local/sbin/dnssec-settime -K /etc/bind -I 20210612110318 -D 20210712110318 Kexample.com.+008+12874
# /usr/local/sbin/dnssec-keygen -q -K /etc/bind -S Kexample.com.+008+12874 -L 7200 -i 2592000
# /usr/local/sbin/dnssec-settime -K /etc/bind -P 20200617110318 -A 20200617110318 Kexample.com.+008+26186
This creates enough key files to last for the coverage period, set in
the policy file to be one year. The script should be run on a regular
basis (probably via cron) to keep the reserve of key files topped
up. With the shortest roll period set to 90 days, every 30 days is
more than adequate.
At any time, you can check what key changes are coming up and whether
the keys and timings are correct by using dnssec-coverage. For
example, to check coverage for the next 60 days:
# dnssec-coverage -d 2h -m 1d -l 60d -K /etc/bind/keys
PHASE 1--Loading keys to check for internal timing problems
PHASE 2--Scanning future key events for coverage failures
Checking scheduled KSK events for zone example.net, algorithm RSASHA256...
Wed Jun 17 11:03:18 UTC 2020:
Publish: example.net/RSASHA256/55237 (KSK)
Activate: example.net/RSASHA256/55237 (KSK)
Ignoring events after Sun Aug 16 11:47:24 UTC 2020
No errors found
Checking scheduled ZSK events for zone example.net, algorithm RSASHA256...
Wed Jun 17 11:03:18 UTC 2020:
Publish: example.net/RSASHA256/31339 (ZSK)
Activate: example.net/RSASHA256/31339 (ZSK)
Sun Aug 16 11:03:18 UTC 2020:
Publish: example.net/RSASHA256/14526 (ZSK)
Ignoring events after Sun Aug 16 11:47:24 UTC 2020
No errors found
Checking scheduled KSK events for zone example.com, algorithm RSASHA256...
Wed Jun 17 11:03:18 UTC 2020:
Publish: example.com/RSASHA256/26186 (KSK)
Activate: example.com/RSASHA256/26186 (KSK)
No errors found
Checking scheduled ZSK events for zone example.com, algorithm RSASHA256...
Wed Jun 17 11:03:18 UTC 2020:
Publish: example.com/RSASHA256/31168 (ZSK)
Activate: example.com/RSASHA256/31168 (ZSK)
Sun Aug 16 11:03:18 UTC 2020:
Publish: example.com/RSASHA256/24199 (ZSK)
Ignoring events after Sun Aug 16 11:47:24 UTC 2020
No errors found
The -d 2h and -m 1d on the command line specify the maximum TTL
for the DNSKEYs and other resource records in the zone: in this example
two hours and one day, respectively. dnssec-coverage needs this
information when it checks that the zones will remain secure through key
rolls.
Fully Automatic Signing With dnssec-policy¶
The latest development in DNSSEC key management appeared with BIND 9.16,
and is the full integration of key management into named. Managing
the signing process and rolling of these keys has been described in
Easy-Start Guide for Signing Authoritative Zones and is not
repeated here. A few points are worth noting, though:
The
dnssec-policystatement in thenamedconfiguration file describes all aspects of the DNSSEC policy, including the signing. Withdnssec-keymgr, this is split between two configuration files and two programs.When using
dnssec-policy, there is no need to set theauto-dnssecandinline-signingoptions for a zone. The zone’spolicystatement implicitly does this.It is possible to manage some zones served by an instance of BIND through
dnssec-policyand others throughdnssec-keymgr, but this is not recommended. Although it should work, if you modify the configuration files and inadvertently specify a zone to be managed by both systems, BIND will not operate properly.
Manual Signing¶
Manual signing of a zone was the first method of signing introduced into BIND and offers, as the name suggests, no automation. The user must handle everything: create the keys, sign the zone file with them, load the signed zone, periodically re-sign the zone, and manage key rolls, including interaction with the parent. A user certainly can do all this, but why not use one of the automated methods? Nevertheless, it may be useful for test purposes, so we cover it briefly here.
The first step is to create the keys as described in Generate Keys.
Then, edit the zone file to make sure
the proper DNSKEY entries are included in your zone file. Finally, use the
command dnssec-signzone:
# 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
The -o switch explicitly defines the domain name (example.com in
this case), while the -f switch specifies the output file name. The second line
has three parameters: the unsigned zone name
(/etc/bind/db/example.com.db), the ZSK file name, and the KSK file name. This
also generates a plain text file /etc/bind/db/example.com.signed.db,
which you can verify for correctness.
Finally, you’ll need to update named.conf to load the signed version
of the zone, which looks something like this:
zone "example.com" IN {
type primary;
file "db/example.com.signed.db";
};
Once the rndc reconfig command is issued, BIND serves a signed
zone. The file dsset-example.com (created by dnssec-signzone
when it signed the example.com zone) contains the DS record for the
zone’s KSK. You will need to pass that to the administrator of the parent
zone, to be placed in the zone.
Since this is a manual process, you will need to re-sign periodically, as well as every time the zone data changes. You will also need to manually roll the keys by adding and removing DNSKEY records (and interacting with the parent) at the appropriate times.
Basic DNSSEC Troubleshooting¶
In this chapter, we cover some basic troubleshooting techniques, some common DNSSEC symptoms, and their causes and solutions. This is not a comprehensive “how to troubleshoot any DNS or DNSSEC problem” guide, because that could easily be an entire book by itself.
Query Path¶
The first step in troubleshooting DNS or DNSSEC should be to determine the query path. Whenever you are working with a DNS-related issue, it is always a good idea to determine the exact query path to identify the origin of the problem.
End clients, such as laptop computers or mobile phones, are configured
to talk to a recursive name server, and the recursive name server may in
turn forward requests on to other recursive name servers before arriving at the
authoritative name server. The giveaway is the presence of the
Authoritative Answer (aa) flag in a query response: when present, we know we are talking
to the authoritative server; when missing, we are talking to a recursive
server. The example below shows an answer to a query for
www.example.com without the Authoritative Answer flag:
$ dig @10.53.0.3 www.example.com A
; <<>> DiG 9.16.0 <<>> @10.53.0.3 www.example.com a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62714
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: c823fe302625db5b010000005e722b504d81bb01c2227259 (good)
;; QUESTION SECTION:
;www.example.com. IN A
;; ANSWER SECTION:
www.example.com. 60 IN A 10.1.0.1
;; Query time: 3 msec
;; SERVER: 10.53.0.3#53(10.53.0.3)
;; WHEN: Wed Mar 18 14:08:16 GMT 2020
;; MSG SIZE rcvd: 88
Not only do we not see the aa flag, we see an ra
flag, which indicates Recursion Available. This indicates that the
server we are talking to (10.53.0.3 in this example) is a recursive name
server: although we were able to get an answer for
www.example.com, we know that the answer came from somewhere else.
If we query the authoritative server directly, we get:
$ dig @10.53.0.2 www.example.com A
; <<>> DiG 9.16.0 <<>> @10.53.0.2 www.example.com a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39542
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
...
The aa flag tells us that we are now talking to the
authoritative name server for www.example.com, and that this is not a
cached answer it obtained from some other name server; it served this
answer to us right from its own database. In fact,
the Recursion Available (ra) flag is not present, which means this
name server is not configured to perform recursion (at least not for
this client), so it could not have queried another name server to get
cached results.
Visible DNSSEC Validation Symptoms¶
After determining the query path, it is necessary to
determine whether the problem is actually related to DNSSEC
validation. You can use the +cd flag in dig to disable
validation, as described in
How Do I Know I Have a Validation Problem?.
When there is indeed a DNSSEC validation problem, the visible symptoms, unfortunately, are very limited. With DNSSEC validation enabled, if a DNS response is not fully validated, it results in a generic SERVFAIL message, as shown below when querying against a recursive name server at 192.168.1.7:
$ dig @10.53.0.3 www.example.org. A
; <<>> DiG 9.16.0 <<>> @10.53.0.3 www.example.org A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 28947
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: d1301968aca086ad010000005e723a7113603c01916d136b (good)
;; QUESTION SECTION:
;www.example.org. IN A
;; Query time: 3 msec
;; SERVER: 10.53.0.3#53(10.53.0.3)
;; WHEN: Wed Mar 18 15:12:49 GMT 2020
;; MSG SIZE rcvd: 72
With delv, a “resolution failed” message is output instead:
$ delv @10.53.0.3 www.example.org. A +rtrace
;; fetch: www.example.org/A
;; resolution failed: SERVFAIL
BIND 9 logging features may be useful when trying to identify DNSSEC errors.
Basic Logging¶
DNSSEC validation error messages show up in syslog as a
query error by default. Here is an example of what it may look like:
validating www.example.org/A: no valid signature found
RRSIG failed to verify resolving 'www.example.org/A/IN': 10.53.0.2#53
Usually, this level of error logging is sufficient. Debug logging, described in BIND DNSSEC Debug Logging, gives information on how to get more details about why DNSSEC validation may have failed.
BIND DNSSEC Debug Logging¶
A word of caution: before you enable debug logging, be aware that this may dramatically increase the load on your name servers. Enabling debug logging is thus not recommended for production servers.
With that said, sometimes it may become necessary to temporarily enable
BIND debug logging to see more details of how and whether DNSSEC is
validating. DNSSEC-related messages are not recorded in syslog by default,
even if query log is enabled; only DNSSEC errors show up in syslog.
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
(here, /var/log/dnssec.log):
logging {
channel dnssec_log {
file "/var/log/dnssec.log";
severity debug 3;
};
category dnssec { dnssec_log; };
};
After turning on debug logging and restarting BIND, a large
number of log messages appear in
syslog. The example below shows the log messages as a result of
successfully looking up and validating the domain name ftp.isc.org.
validating ./NS: starting
validating ./NS: attempting positive response validation
validating ./DNSKEY: starting
validating ./DNSKEY: attempting positive response validation
validating ./DNSKEY: verify rdataset (keyid=20326): success
validating ./DNSKEY: marking as secure (DS)
validating ./NS: in validator_callback_dnskey
validating ./NS: keyset with trust secure
validating ./NS: resuming validate
validating ./NS: verify rdataset (keyid=33853): success
validating ./NS: marking as secure, noqname proof not needed
validating ftp.isc.org/A: starting
validating ftp.isc.org/A: attempting positive response validation
validating isc.org/DNSKEY: starting
validating isc.org/DNSKEY: attempting positive response validation
validating isc.org/DS: starting
validating isc.org/DS: attempting positive response validation
validating org/DNSKEY: starting
validating org/DNSKEY: attempting positive response validation
validating org/DS: starting
validating org/DS: attempting positive response validation
validating org/DS: keyset with trust secure
validating org/DS: verify rdataset (keyid=33853): success
validating org/DS: marking as secure, noqname proof not needed
validating org/DNSKEY: in validator_callback_ds
validating org/DNSKEY: dsset with trust secure
validating org/DNSKEY: verify rdataset (keyid=9795): success
validating org/DNSKEY: marking as secure (DS)
validating isc.org/DS: in fetch_callback_dnskey
validating isc.org/DS: keyset with trust secure
validating isc.org/DS: resuming validate
validating isc.org/DS: verify rdataset (keyid=33209): success
validating isc.org/DS: marking as secure, noqname proof not needed
validating isc.org/DNSKEY: in validator_callback_ds
validating isc.org/DNSKEY: dsset with trust secure
validating isc.org/DNSKEY: verify rdataset (keyid=7250): success
validating isc.org/DNSKEY: marking as secure (DS)
validating ftp.isc.org/A: in fetch_callback_dnskey
validating ftp.isc.org/A: keyset with trust secure
validating ftp.isc.org/A: resuming validate
validating ftp.isc.org/A: verify rdataset (keyid=27566): success
validating ftp.isc.org/A: marking as secure, noqname proof not needed
Note that these log messages indicate that the chain of trust has been
established and ftp.isc.org has been successfully validated.
If validation had failed, you would see log messages indicating errors. We cover some of the most validation problems in the next section.
Common Problems¶
Security Lameness¶
Similar to lame delegation in traditional DNS, security lameness refers to the condition when the parent zone holds a set of DS records that point to something that does not exist in the child zone. As a result, the entire child zone may “disappear,” having been marked as bogus by validating resolvers.
Below is an example attempting to resolve the A record for a test domain
name www.example.net. From the user’s perspective, as described in
How Do I Know I Have a Validation Problem?, only a SERVFAIL
message is returned. On the validating resolver, we see the
following messages in syslog:
named[126063]: validating example.net/DNSKEY: no valid signature found (DS)
named[126063]: no valid RRSIG resolving 'example.net/DNSKEY/IN': 10.53.0.2#53
named[126063]: broken trust chain resolving 'www.example.net/A/IN': 10.53.0.2#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 for the zone (with the keys shortened for ease of display):
$ dig @10.53.0.3 example.net. DS
; <<>> DiG 9.16.0 <<>> @10.53.0.3 example.net DS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59602
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 7026d8f7c6e77e2a010000005e735d7c9d038d061b2d24da (good)
;; QUESTION SECTION:
;example.net. IN DS
;; ANSWER SECTION:
example.net. 256 IN DS 14956 8 2 9F3CACD...D3E3A396
;; Query time: 0 msec
;; SERVER: 10.53.0.3#53(10.53.0.3)
;; WHEN: Thu Mar 19 11:54:36 GMT 2020
;; MSG SIZE rcvd: 116
Next, we query for the DNSKEY and RRSIG of example.net to see if
there’s anything wrong. Since we are having trouble validating, we
can use the +cd option to temporarily disable checking and return
results, 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,
some long strings are shortened for ease of display:
$ dig @10.53.0.3 example.net. DNSKEY +dnssec +cd +multiline
; <<>> DiG 9.16.0 <<>> @10.53.0.3 example.net DNSKEY +cd +multiline +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42980
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 4b5e7c88b3680c35010000005e73722057551f9f8be1990e (good)
;; QUESTION SECTION:
;example.net. IN DNSKEY
;; ANSWER SECTION:
example.net. 287 IN DNSKEY 256 3 8 (
AwEAAbu3NX...ADU/D7xjFFDu+8WRIn
) ; ZSK; alg = RSASHA256 ; key id = 35328
example.net. 287 IN DNSKEY 257 3 8 (
AwEAAbKtU1...PPP4aQZTybk75ZW+uL
6OJMAF63NO0s1nAZM2EWAVasbnn/X+J4N2rLuhk=
) ; KSK; alg = RSASHA256 ; key id = 27247
example.net. 287 IN RRSIG DNSKEY 8 2 300 (
20811123173143 20180101000000 27247 example.net.
Fz1sjClIoF...YEjzpAWuAj9peQ== )
example.net. 287 IN RRSIG DNSKEY 8 2 300 (
20811123173143 20180101000000 35328 example.net.
seKtUeJ4/l...YtDc1rcXTVlWIOw= )
;; Query time: 0 msec
;; SERVER: 10.53.0.3#53(10.53.0.3)
;; WHEN: Thu Mar 19 13:22:40 GMT 2020
;; MSG SIZE rcvd: 962
Here is the problem: the parent zone is telling the world that
example.net is using the key 14956, but the authoritative server
indicates that it is using keys 27247 and 35328. There are several
potential causes for this mismatch: one possibility is that a malicious
attacker has compromised one side and changed the data. A more likely
scenario is that the DNS administrator for the child zone did not upload
the correct key information to the parent zone.
Incorrect Time¶
In DNSSEC, every record comes with at least one RRSIG, and each RRSIG contains two timestamps: one indicating when it becomes valid, and one when it expires. If the validating resolver’s current system time does not fall within the two RRSIG timestamps, error messages appear in the BIND debug log.
The example below shows a log message when the RRSIG appears to have 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 example.com/DNSKEY: verify failed due to bad signature (keyid=19036): RRSIG has expired
The log below shows that the RRSIG validity period has not yet begun. This could mean the validation resolver’s system time is incorrectly set too far in the past, or the zone administrator has incorrectly generated signatures for this domain name.
validating example.com/DNSKEY: verify failed due to bad signature (keyid=4521): RRSIG validity period has not begun
Unable to Load Keys¶
This is a simple yet common issue. If the key files are present but
unreadable by named for some reason, the syslog returns clear error
messages, 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 appears to indicate that named loaded the keys and signed the zone. It
even generates 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.
Invalid Trust Anchors¶
In most cases, you never need to explicitly configure trust
anchors. named supplies the current root trust anchor and,
with the default setting of dnssec-validation, updates it on the
infrequent occasions when it is changed.
However, in some circumstances you may need to explicitly configure your own trust anchor. As we saw in the Trust Anchors section, whenever a DNSKEY is received by the validating resolver, it is compared to the list of keys the resolver explicitly trusts 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 does not even start 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 virtually 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 10.53.0.3:
$ dig @10.53.0.3 www.example.com. A
; <<>> DiG 9.16.0 <<>> @10.53.0.3 www.example.org A +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29586
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: ee078fc321fa1367010000005e73a58bf5f205ca47e04bed (good)
;; QUESTION SECTION:
;www.example.org. IN A
delv shows a similar result:
$ delv @192.168.1.7 www.example.com. +rtrace
;; fetch: www.example.com/A
;; resolution failed: SERVFAIL
The next symptom you see is in the DNSSEC log messages:
managed-keys-zone: DNSKEY set for zone '.' could not be verified with current keys
validating ./DNSKEY: starting
validating ./DNSKEY: attempting positive response validation
validating ./DNSKEY: no DNSKEY matching DS
validating ./DNSKEY: no DNSKEY matching DS
validating ./DNSKEY: no valid signature found (DS)
These errors are indications that there are problems with the trust anchor.
Negative Trust Anchors¶
BIND 9.11 introduced Negative Trust Anchors (NTAs) as a means to temporarily disable DNSSEC validation for a zone when you know that the zone’s DNSSEC is misconfigured.
NTAs are added using the rndc command, e.g.:
$ rndc nta example.com
Negative trust anchor added: example.com/_default, expires 19-Mar-2020 19:57:42.000
The list of currently configured NTAs can also be examined using
rndc, e.g.:
$ rndc nta -dump
example.com/_default: expiry 19-Mar-2020 19:57:42.000
The default lifetime of an NTA is one hour, although by default, BIND
polls the zone every five minutes to see if the zone correctly
validates, at which point the NTA automatically expires. Both the
default lifetime and the polling interval may be configured via
named.conf, and the lifetime can be overridden on a per-zone basis
using the -lifetime duration parameter to rndc nta. Both timer
values have a permitted maximum value of one week.
NSEC3 Troubleshooting¶
BIND includes a tool called nsec3hash that runs through the same
steps as a validating resolver, to generate the correct hashed name
based on NSEC3PARAM parameters. The command takes the following
parameters in order: salt, algorithm, iterations, and domain. For
example, if the salt is 1234567890ABCDEF, hash algorithm is 1, and
iteration is 10, to get the NSEC3-hashed name for www.example.com we
would execute a command like this:
$ nsec3hash 1234567890ABCEDF 1 10 www.example.com
RN7I9ME6E1I6BDKIP91B9TCE4FHJ7LKF (salt=1234567890ABCEDF, hash=1, iterations=10)
While it is unlikely you would construct a rainbow table of your own zone data, this tool may be useful when troubleshooting NSEC3 problems.
Advanced Discussions¶
Signature Validity Periods and Zone Re-Signing Intervals¶
In How Are Answers Verified?, we saw that record signatures have a validity period outside of which they are not valid. This means that at some point, a signature will no longer be valid and a query for the associated record will fail DNSSEC validation. But how long should a signature be valid for?
The maximum value for the validity period should be determined by the impact of a replay attack: if this is low, the period can be long; if high, the period should be shorter. There is no “right” value, but periods of between a few days to a month are common.
Deciding a minimum value is probably an easier task. Should something fail (e.g., a hidden primary distributing to secondary servers that actually answer queries), how long will it take before the failure is noticed, and how long before it is fixed? If you are a large 24x7 operation with operators always on-site, the answer might be less than an hour. In smaller companies, if the failure occurs just after everyone has gone home for a long weekend, the answer might be several days.
Again, there are no “right” values - they depend on your circumstances. The signature validity period you decide to use should be a value between the two bounds. At the time of this writing (mid-2020), the default policy used by BIND sets a value of 14 days.
To keep the zone valid, the signatures must be periodically refreshed since they expire - i.e., the zone must be periodically re-signed. The frequency of the re-signing depends on your network’s individual needs. For example, signing puts a load on your server, so if the server is very highly loaded, a lower re-signing frequency is better. Another consideration is the signature lifetime: obviously the intervals between signings must not be longer than the signature validity period. But if you have set a signature lifetime close to the minimum (see above), the signing interval must be much shorter. What would happen if the system failed just before the zone was re-signed?
Again, there is no single “right” answer; it depends on your circumstances. The BIND 9 default policy sets the signature refresh interval to 5 days.
Proof of Non-Existence (NSEC and NSEC3)¶
How do you prove that something does not exist? This zen-like question is an interesting one, and in this section we provide an overview of how DNSSEC solves the problem.
Why is it even important to have authenticated denial of existence in DNS? Couldn’t we just send back “hey, what you asked for does not exist,” and somehow generate a digital signature to go with it, proving it really is from the correct authoritative source? Aside from the technical challenge of signing something that doesn’t exist, this solution has flaws, one of which is it gives an attacker a way to create the appearance of denial of service by replaying this message on the network.
Let’s use a little story, told three different ways, to illustrate how proof of nonexistence works. In our story, we run a small company with three employees: Alice, Edward, and Susan. For reasons that are far too complicated to go into, they don’t have email accounts; instead, email for them is sent to a single account and a nameless intern passes the message to them. The intern has access to our private DNSSEC key to create signatures for their responses.
If we followed the approach of giving back the same answer no matter what was asked, when people emailed and asked for the message to be passed to “Bob,” our intern would simply answer “Sorry, that person doesn’t work here” and sign this message. This answer could be validated because our intern signed the response with our private DNSSEC key. However, since the signature doesn’t change, an attacker could record this message. If the attacker were able to intercept our email, when the next person emailed asking for the message to be passed to Susan, the attacker could return the exact same message: “Sorry, that person doesn’t work here,” with the same signature. Now the attacker has successfully fooled the sender into thinking that Susan doesn’t work at our company, and might even be able to convince all senders that no one works at this company.
To solve this problem, two different solutions were created. We will look at the first one, NSEC, next.
NSEC¶
The NSEC record is used to prove that something 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 sending an email for Bob and our nameless intern responding with with: “I’m sorry, that person doesn’t work here. The name before the location where ‘Bob’ would be is Alice, and the name after that is Edward.” Let’s say another email was received for a non-existent person, this time Oliver; our intern would respond “I’m sorry, that person doesn’t work here. The name before the location where ‘Oliver’ would be is Edward, and the name after that is Susan.” If another sender asked for Todd, the answer would be: “I’m sorry, that person doesn’t work here. The name before the location where ‘Todd’ would be is Susan, and there are no other names 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 sent an email for Edward, none of the four answers would fit. If attacker replied with 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; and the same goes for #3, Edward and Susan. As for #1 and #4, Edward does not fall in the alphabetical range before Alice or after Susan, so the sender can logically deduce that it was an incorrect answer.
When BIND signs your zone, the zone data is 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. The details of this are not within the scope of this document, but are described well in RFC 7129.
Unfortunately, the NSEC solution has a few drawbacks, one of which is trivial “zone walking.” In our story, a curious person can keep sending emails, and our nameless, gullible intern keeps divulging information about our employees. Imagine if the sender first asked: “Is Bob there?” and received back the names Alice and Edward. Our sender could then email again: “Is Edwarda there?”, and will get back Edward and Susan. (No, “Edwarda” is not a real name. However, it is the first name alphabetically after “Edward” and that is enough to get the intern to reply with a message telling us the next valid name after Edward.) Repeat the process enough times and the person sending the emails eventually learns 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 select audience.
The second drawback of NSEC is actually increased operational
overhead: there is 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
NSEC3 Opt-Out.
NSEC3¶
NSEC3 adds two additional features that NSEC does not have:
It offers no easy zone enumeration.
It provides a mechanism for the parent zone to exclude insecure delegations (i.e., delegations to zones that are not signed) from the proof of non-existence.
Recall that in NSEC we provided a range of names to prove that something 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 our 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 ribeye steak: that’s what we call a one-way hash.
NSEC3 basically runs the names through a one-way hash before giving them out, so the recipients can verify the non-existence without any knowledge of the actual names.
So let’s tell our little story for the third time, this time with NSEC3. In this version, 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, an email is received for Bob again. Our intern takes the name Bob through a hash function, and the result is L8J2…, so he replies: “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 ease of 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
Note
Just because we employed one-way hash functions does not mean there is no way for a determined individual to figure out our zone data. Someone could still gather all of our NSEC3 records and hashed names and perform an offline brute-force attack by trying all possible combinations to figure out what the original name is. In our meat-grinder analogy, this would be like someone buying all available cuts of meat and grinding them up at home using the same model of meat grinder, and comparing the output with the meat you gave him. It is expensive and time-consuming (especially with real meat), but like everything else in cryptography, if someone has enough resources and time, nothing is truly private forever. If you are concerned about someone performing this type of attack on your zone data, read more about adding salt as described in NSEC3 Salt.
NSEC3PARAM¶
The above NSEC3 examples used four parameters: 1, 0, 10, and 1234567890ABCDEF. 1 represents the algorithm, 0 represents the opt-out flag, 10 represents the number of iterations, and 1234567890ABCDEF is the salt. Let’s look at how each one can be configured:
Algorithm: The only currently defined value is 1 for SHA-1, so there is no configuration field for it.
Opt-out: Set this to 1 for NSEC3 opt-out, which we discuss in NSEC3 Opt-Out.
Iterations: Iterations defines the number of additional times to apply the algorithm when generating an NSEC3 hash. More iterations yield more secure results, but consume more resources for both authoritative servers and validating resolvers. The considerations here are similar to those seen in Key Sizes, of security versus resources.
Salt: The salt cannot be configured explicitly, but you can provide a salt length and
namedgenerates a random salt of the given length. We learn more about salt in NSEC3 Salt.
If you want to use these NSEC3 parameters for a zone, you can add the
following configuration to your dnssec-policy. For example, to create an
NSEC3 chain using the SHA-1 hash algorithm, with no opt-out flag,
5 iterations, and a salt that is 8 characters long, use:
dnssec-policy "nsec3" {
...
nsec3param iterations 5 optout no salt-length 8;
};
To set the opt-out flag, 15 iterations, and no salt, use:
dnssec-policy "nsec3" {
...
nsec3param iterations 15 optout yes salt-length 0;
};
NSEC3 Opt-Out¶
One of the advantages of NSEC3 over NSEC is the ability for a parent zone to publish less information about its child or delegated zones. Why would you ever want to do that? If a significant number of your delegations are not yet DNSSEC-aware, meaning they are still insecure or unsigned, generating DNSSEC-records for their NS and glue records is not a good use of your precious name server resources.
The resources may not seem like a lot, but imagine that you are the
operator of busy top-level domains such as .com or .net, with
millions of insecure delegated domain names: it quickly
adds up. As of mid-2020, less than 1.5% of all .com zones are
signed. Basically, without opt-out, with 1,000,000 delegations,
only 5 of which are secure, you still have to generate NSEC RRsets for
the other 999,995 delegations; with NSEC3 opt-out, you will have saved
yourself 999,995 sets of records.
For most DNS administrators who do not manage a large number of delegations, the decision whether to use NSEC3 opt-out is probably not relevant.
To learn more about how to configure NSEC3 opt-out, please see NSEC3 Opt-Out.
NSEC3 Salt¶
As described in NSEC3, while NSEC3 does not put your zone data in plain public display, it is still not difficult for an attacker to collect all the hashed names and perform an offline attack. All that is required is running through all the combinations to construct a database of plaintext names to hashed names, also known as a “rainbow table.”
There is one more feature NSEC3 gives us to provide additional protection: salt. Basically, salt gives us the ability to introduce further randomness into the hashed results. Whenever the salt is changed, any pre-computed rainbow table is rendered useless, and a new rainbow table must be re-computed. If the salt is changed periodically, it becomes difficult to construct a useful rainbow table, and thus difficult to walk the DNS zone data programmatically. How often you want to change your NSEC3 salt is up to you.
To learn more about the steps to take to change NSEC3, please see Changing the NSEC3 Salt.
NSEC or NSEC3?¶
So which one should you choose: NSEC or NSEC3? There is not a single right answer here that fits everyone; it comes down to your network’s needs or requirements.
If you prefer not to make your zone easily enumerable, implementing NSEC3 paired with a periodically changed salt provides 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 delegations and need to be able to opt-out to save resources, NSEC3 is for you.
In other situations, NSEC is typically a good choice for most zone administrators, as it relieves the authoritative servers of the additional cryptographic operations that NSEC3 requires, and NSEC is comparatively easier to troubleshoot than NSEC3.
NSEC3 in conjunction with dnssec-policy is supported in BIND
as of version 9.16.9.
DNSSEC Keys¶
Types of Keys¶
Although DNSSEC documentation talks about three types of keys, they are all the same thing - but they have different roles. The roles are:
- Zone-Signing Key (ZSK)
This is the key used to sign the zone. It signs all records in the zone apart from the DNSSEC key-related RRsets: DNSKEY, CDS, and CDNSKEY.
- Key-Signing Key (KSK)
This is the key used to sign the DNSSEC key-related RRsets and is the key used to link the parent and child zones. The parent zone stores a digest of the KSK. When a resolver verifies the chain of trust it checks to see that the DS record in the parent (which holds the digest of a key) matches a key in the DNSKEY RRset, and that it is able to use that key to verify the DNSKEY RRset. If it can do that, the resolver knows that it can trust the DNSKEY resource records, and so can use one of them to validate the other records in the zone.
- Combined Signing Key (CSK)
A CSK combines the functionality of a ZSK and a KSK. Instead of having one key for signing the zone and one for linking the parent and child zones, a CSK is a single key that serves both roles.
It is important to realize the terms ZSK, KSK, and CSK describe how the keys are used - all these keys are represented by DNSKEY records. The following examples are the DNSKEY records from a zone signed with a KSK and ZSK:
$ dig @192.168.1.12 example.com DNSKEY
; <<>> DiG 9.16.0 <<>> @192.168.1.12 example.com dnskey +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54989
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 5258d7ed09db0d76010000005ea1cc8c672d8db27a464e37 (good)
;; QUESTION SECTION:
;example.com. IN DNSKEY
;; ANSWER SECTION:
example.com. 60 IN DNSKEY 256 3 13 (
tAeXLtIQ3aVDqqS/1UVRt9AE6/nzfoAuaT1Vy4dYl2CK
pLNcUJxME1Z//pnGXY+HqDU7Gr5HkJY8V0W3r5fzlw==
) ; ZSK; alg = ECDSAP256SHA256 ; key id = 63722
example.com. 60 IN DNSKEY 257 3 13 (
cxkNegsgubBPXSra5ug2P8rWy63B8jTnS4n0IYSsD9eW
VhiyQDmdgevKUhfG3SE1wbLChjJc2FAbvSZ1qk03Nw==
) ; KSK; alg = ECDSAP256SHA256 ; key id = 42933
… and a zone signed with just a CSK:
$ dig @192.168.1.13 example.com DNSKEY
; <<>> DiG 9.16.0 <<>> @192.168.1.13 example.com dnskey +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22628
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: bf19ee914b5df46e010000005ea1cd02b66c06885d274647 (good)
;; QUESTION SECTION:
;example.com. IN DNSKEY
;; ANSWER SECTION:
example.com. 60 IN DNSKEY 257 3 13 (
p0XM6AJ68qid2vtOdyGaeH1jnrdk2GhZeVvGzXfP/PNa
71wGtzR6jdUrTbXo5Z1W5QeeJF4dls4lh4z7DByF5Q==
) ; KSK; alg = ECDSAP256SHA256 ; key id = 1231
The only visible difference between the records (apart from the key data itself) is the value of the flags fields; this is 256 for a ZSK and 257 for a KSK or CSK. Even then, the flags field is only a hint to the software using it as to the role of the key: zones can be signed by any key. The fact that a CSK and KSK both have the same flags emphasizes this. A KSK usually only signs the DNSSEC key-related RRsets in a zone, whereas a CSK is used to sign all records in the zone.
The original idea of separating the function of the key into a KSK and ZSK was operational. With a single key, changing it for any reason is “expensive,” as it requires interaction with the parent zone (e.g., uploading the key to the parent may require manual interaction with the organization running that zone). By splitting it, interaction with the parent is required only if the KSK is changed; the ZSK can be changed as often as required without involving the parent.
The split also allows the keys to be of different lengths. So the ZSK, which is used to sign the record in the zone, can be of a (relatively) short length, lowering the load on the server. The KSK, which is used only infrequently, can be of a much longer length. The relatively infrequent use also allows the private part of the key to be stored in a way that is more secure but that may require more overhead to access, e.g., on an HSM (see Hardware Security Modules (HSMs)).
In the early days of DNSSEC, the idea of splitting the key went more or less unchallenged. However, with the advent of more powerful computers and the introduction of signaling methods between the parent and child zones (see The CDS and CDNSKEY Resource Records), the advantages of a ZSK/KSK split are less clear and, for many zones, a single key is all that is required.
As with many questions related to the choice of DNSSEC policy, the decision on which is “best” is not clear and depends on your circumstances.
Which Algorithm?¶
There are three algorithm choices for DNSSEC as of this writing (mid-2020):
RSA
Elliptic Curve DSA (ECDSA)
Edwards Curve Digital Security Algorithm (EdDSA)
All are supported in BIND 9, but only RSA and ECDSA (specifically RSASHA256 and ECDSAP256SHA256) are mandatory to implement in DNSSEC. However, RSA is a little long in the tooth, and ECDSA/EdDSA are emerging as the next new cryptographic standards. In fact, the US federal government recommended discontinuing RSA use altogether by September 2015 and migrating to using ECDSA or similar algorithms.
For now, use ECDSAP256SHA256 but keep abreast of developments in this area. For details about rolling over DNSKEYs to a new algorithm, see Algorithm Rollovers.
Key Sizes¶
If using RSA keys, 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 mean 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. ZSK is used whenever zone data changes or when signatures expire, 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 earlier versions of this guide, the following key lengths were chosen for each set, with the recommendation that they be rotated more frequently for better security:
ZSK: RSA 1024 bits, rollover every year
KSK: RSA 2048 bits, rollover every five years
These should be considered minimum RSA key sizes. At the time of this writing (mid-2020), 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 sizes result in larger DNS responses, which this may mean more load on network resources. Depending on your network configuration, end users may even experience resolution failures due to the increased response sizes, as discussed in What’s EDNS All About (And Why Should I Care)?.
ECDSA key sizes can be much smaller for the same level of security, e.g., an ECDSA key length of 224 bits provides the same level of security as a 2048-bit RSA key. Currently BIND 9 sets a key size of 256 for all ECDSA keys.
Key Storage¶
Public Key Storage¶
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 Working With the Parent Zone for more details), and is published by the parent zone as DS records.
Private Key Storage¶
Ideally, private keys should be stored offline, in secure devices such as a smart card. Operationally, however, this creates certain challenges, since the private key is needed to create RRSIG resource records, and it is a hassle to bring the private key out of storage every time the zone file changes or 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. A ZSK private key is used to sign zone data, and can be kept online for ease of use, while a 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 ZSKs, combined with a ZSK private key stored on the network file system and available for routine use, may be a good balance between operational flexibility and security.
For more information on changing keys, please see Key Rollovers.
Hardware Security Modules (HSMs)¶
A Hardware Security Module (HSM) may come in different shapes and sizes, but as the name indicates, it is a physical device or devices, usually with some or all of the following features:
Tamper-resistant key storage
Strong random-number generation
Hardware for faster cryptographic operations
Most organizations do not incorporate HSMs into their security practices due to cost and the added operational complexity.
BIND supports Public Key Cryptography Standard #11 (PKCS #11) for communication with HSMs and other cryptographic support devices. For more information on how to configure BIND to work with an HSM, please refer to the BIND 9 Administrator Reference Manual.
Rollovers¶
Key Rollovers¶
A key rollover is where one key in a zone is replaced by a new one. There are arguments for and against regularly rolling keys. In essence these are:
Pros:
Regularly changing the key hinders attempts at determination of the private part of the key by cryptanalysis of signatures.
It gives administrators practice at changing a key; should a key ever need to be changed in an emergency, they would not be doing it for the first time.
Cons:
A lot of effort is required to hack a key, and there are probably easier ways of obtaining it, e.g., by breaking into the systems on which it is stored.
Rolling the key adds complexity to the system and introduces the possibility of error. We are more likely to have an interruption to our service than if we had not rolled it.
Whether and when to roll the key is up to you. How serious would the damage be if a key were compromised without you knowing about it? How serious would a key roll failure be?
Before going any further, it is worth noting that if you sign your zone with either of the fully automatic methods (described in ref:signing_alternative_ways), you don’t really need to concern yourself with the details of a key rollover: BIND 9 takes care of it all for you. If you are doing a manual key roll or are setting up the keys for a semi-automatic key rollover, you do need to familiarize yourself with the various steps involved and the timing details.
Rolling a key is not as simple as replacing the DNSKEY statement in the
zone. That is an essential part of it, but timing is everything. For
example, suppose that we run the example.com zone and that a friend
queries for the AAAA record of www.example.com. As part of the
resolution process (described in
How Does DNSSEC Change DNS Lookup?), their recursive server
looks up the keys for the example.com zone and uses them to verify
the signature associated with the AAAA record. We’ll assume that the
records validated successfully, so they can use the
address to visit example.com’s website.
Let’s also assume that immediately after the lookup, we want to roll the ZSK
for example.com. Our first attempt at this is to remove the old
DNSKEY record and signatures, add a new DNSKEY record, and re-sign the
zone with it. So one minute our server is serving the old DNSKEY and
records signed with the old key, and the next minute it is serving the
new key and records signed with it. We’ve achieved our goal - we are
serving a zone signed with the new keys; to check this is really the
case, we booted up our laptop and looked up the AAAA record
ftp.example.com. The lookup succeeded so all must be well. Or is it?
Just to be sure, we called our friend and asked them to check. They
tried to lookup ftp.example.com but got a SERVFAIL response from
their recursive server. What’s going on?
The answer, in a word, is “caching.” When our friend looked up
www.example.com, their recursive server retrieved and cached
not only the AAAA record, but also a lot of other records. It cached
the NS records for com and example.com, as well as
the AAAA (and A) records for those name servers (and this action may, in turn, have
caused the lookup and caching of other NS and AAAA/A records). Most
importantly for this example, it also looked up and cached the DNSKEY
records for the root, com, and example.com zones. When a query
was made for ftp.example.com, the recursive server believed it
already had most of the information
we needed. It knew what nameservers served example.com and their
addresses, so it went directly to one of those to get the AAAA record for
ftp.example.com and its associated signature. But when it tried to
validate the signature, it used the cached copy of the DNSKEY, and that
is when our friend had the problem. Their recursive server had a copy of
the old DNSKEY in its cache, but the AAAA record for ftp.example.com
was signed with the new key. So, not surprisingly, the signature could not
validate.
How should we roll the keys for example.com? A clue to the
answer is to note that the problem came about because the DNSKEY records
were cached by the recursive server. What would have happened had our
friend flushed the DNSKEY records from the recursive server’s cache before
making the query? That would have worked; those records would have been
retrieved from example.com’s nameservers at the same time that we
retrieved the AAAA record for ftp.example.com. Our friend’s server would have
obtained the new key along with the AAAA record and associated signature
created with the new key, and all would have been well.
As it is obviously impossible for us to notify all recursive server operators to flush our DNSKEY records every time we roll a key, we must use another solution. That solution is to wait for the recursive servers to remove old records from caches when they reach their TTL. How exactly we do this depends on whether we are trying to roll a ZSK, a KSK, or a CSK.
ZSK Rollover Methods¶
The ZSK can be rolled in one of the following two ways:
Pre-Publication: Publish the new ZSK into zone data before it is actually used. Wait at least one TTL interval, so the world’s recursive servers know about both keys, then stop using the old key and generate a new RRSIG using the new key. Wait at least another TTL, so the cached old key data is expunged from the world’s recursive servers, and then remove the old key.
The benefit of the pre-publication approach is it does not dramatically increase the zone size; however, the duration of the rollover is longer. If insufficient time has passed after the new ZSK is published, some resolvers may only have the old ZSK cached when the new RRSIG records are published, and validation may fail. This is the method described in ZSK Rollover.
Double-Signature: Publish the new ZSK and new RRSIG, essentially doubling the size of the zone. Wait at least one TTL interval, and then remove the old ZSK and old RRSIG.
The benefit of the double-signature approach is that it is easier to understand and execute, but it causes a significantly increased zone size during a rollover event.
KSK Rollover Methods¶
Rolling the KSK requires interaction with the parent zone, so operationally this may be more complex than rolling ZSKs. There are three methods of rolling the KSK:
Double-KSK: Add the new KSK to the DNSKEY RRset, which is then signed with both the old and new keys. After waiting for the old RRset to expire from caches, change the DS record in the parent zone. After waiting a further TTL interval for this change to be reflected in caches, remove the old key from the RRset.
Basically, the new KSK is added first at the child zone and used to sign the DNSKEY; then the DS record is changed, followed by the removal of the old KSK. Double-KSK keeps the interaction with the parent zone to a minimum, but for the duration of the rollover, the size of the DNSKEY RRset is increased.
Double-DS: Publish the new DS record. After waiting for this change to propagate into caches, change the KSK. After a further TTL interval during which the old DNSKEY RRset expires from caches, remove the old DS record.
Double-DS is the reverse of Double-KSK: the new DS is published at the parent first, then the KSK at the child is updated, then the old DS at the parent is removed. The benefit is that the size of the DNSKEY RRset is kept to a minimum, but interactions with the parent zone are increased to two events. This is the method described in KSK Rollover.
Double-RRset: Add the new KSK to the DNSKEY RRset, which is then signed with both the old and new key, and add the new DS record to the parent zone. After waiting a suitable interval for the old DS and DNSKEY RRsets to expire from caches, remove the old DNSKEY and old DS record.
Double-RRset is the fastest way to roll the KSK (i.e., it has the shortest rollover time), but has the drawbacks of both of the other methods: a larger DNSKEY RRset and two interactions with the parent.
CSK Rollover Methods¶
Rolling the CSK is more complex than rolling either the ZSK or KSK, as the timing constraints relating to both the parent zone and the caching of records by downstream recursive servers must be taken into account. There are numerous possible methods that are a combination of ZSK rollover and KSK rollover methods. BIND 9 automatic signing uses a combination of ZSK Pre-Publication and Double-KSK rollover.
Emergency Key Rollovers¶
Keys are generally rolled on a regular schedule - 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 to re-sign the zone with a new key as soon as possible, because when a key is suspected of being compromised, a malicious attacker (or anyone who has access to the key) could impersonate your server and trick other validating resolvers into believing that they are receiving authentic, validated answers.
During an emergency rollover, follow the same operational procedures described in Rollovers, with the added task of reducing the TTL of the current active (potentially compromised) DNSKEY RRset, in an 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 do not want to wait up to 60 days for the compromised key to be removed from your zone.
Another method is to carry a spare key with you at all times. If you have a second key pre-published and that one is not compromised at the same time as the first key, you could save yourself some time by immediately activating the spare key if the active key is compromised. With pre-publication, all validating resolvers should already have this spare key cached, thus saving you some time.
With a KSK emergency rollover, you also need to consider factors related to your parent zone, such as how quickly they can remove the old DS records and publish the new ones.
As with many other facets of DNSSEC, there are multiple aspects to take into account when it comes to emergency key rollovers. For more in-depth considerations, please check out RFC 7583.
Algorithm Rollovers¶
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 steps must be followed with care to avoid breaking DNSSEC validation.
If you are managing DNSSEC by using the dnssec-policy configuration,
named handles the rollover for you. Simply change the algorithm
for the relevant keys, and named uses the new algorithm when the
key is next rolled. It performs a smooth transition to the new
algorithm, ensuring that the zone remains valid throughout rollover.
If you are using other methods to sign the zone, the administrator needs to do more work. As
with other key rollovers, when the zone is a primary zone, an algorithm
rollover can be accomplished using dynamic updates or automatic key
rollovers. For secondary zones, only automatic key rollovers are
possible, but the dnssec-settime utility can be used to control the
timing.
In any case, the first step is to put DNSKEYs in place using the new algorithm.
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
automatically signs the zone with the new keys, based on their timing
metadata when the dnssec-loadkeys-interval elapses or when you issue the
rndc loadkeys command. Otherwise, for primary zones, you can use
nsupdate to add the new DNSKEYs to the zone; this causes named
to use them to sign the zone. For secondary zones, e.g., on a
“bump in the wire” signing server, nsupdate cannot be used.
Once the zone has been signed by the new DNSKEYs (and you have waited for at least one TTL period), 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 assures that any subsequent queries 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 (for primary 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 the dnssec-settime -D <date/offset> option.)
After adjusting the timing metadata, the rndc loadkeys command
causes 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.
Other Topics¶
DNSSEC and Dynamic Updates¶
Dynamic DNS (DDNS) is actually independent of DNSSEC. DDNS provides a mechanism, separate from editing the zone file or zone database, to edit DNS data. Most DNS clients and servers are able 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 can 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 make named automatically
re-sign the zone whenever its content has changed. If you decide to sign
your own zone file manually, you need to remember to execute the
dnssec-signzone command whenever your zone file has been updated.
As far as system resources and performance are concerned, be mindful that with 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.
DNSSEC on Private Networks¶
Let’s clarify what we mean: in this section, “private networks” really refers to a private or internal DNS view. Most DNS products offer the ability to have different versions 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 resolve 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 typically
fall under 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16 for IPv4.
So what if you want to offer DNSSEC for your internal version of
example.com? This can be done: the golden rule is to use the same
key for both the internal and external versions of the zones. This
avoids problems that can occur when machines (e.g., laptops) move
between accessing the internal and external zones, when it is possible
that they may have cached records from the wrong zone.
Introduction to DANE¶
With your DNS infrastructure 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. This improves security in a number of ways, including:
Disadvantages of DNSSEC¶
DNSSEC, like many things in this world, is not without its problems. Below are a few challenges and disadvantages that DNSSEC faces.
Increased, well, everything: With DNSSEC, signed zones are larger, thus taking up more disk space; for DNSSEC-aware servers, the additional cryptographic computation usually results in increased system load; and the network packets are bigger, possibly putting more strains on the network infrastructure.
Different security considerations: DNSSEC addresses many security concerns, most notably cache poisoning. But at the same time, it may introduce a set of different security considerations, such as amplification attack and zone enumeration through NSEC. These concerns are still being identified and addressed by the Internet community.
More complexity: If you have read this far, you have probably already concluded this yourself. With additional resource records, keys, signatures, and rotations, DNSSEC adds many more moving pieces on top of the existing DNS machine. The job of the DNS administrator changes, as DNS becomes the new secure repository of everything from spam avoidance to encryption keys, and the amount of work involved to troubleshoot a DNS-related issue becomes more challenging.
Increased fragility: The increased complexity means more opportunities for things to go wrong. Before DNSSEC, DNS was essentially “add something to the zone and forget it.” With DNSSEC, each new component - re-signing, key rollover, interaction with parent zone, key management - adds more opportunity for error. It is entirely possible that a failure to validate a name may come down to errors on the part of one or more zone operators rather than the result of a deliberate attack on the DNS.
New maintenance tasks: Even if your new secure DNS infrastructure runs without any hiccups or security breaches, it still requires regular attention, from re-signing to key rollovers. While most of these can be automated, some of the tasks, such as KSK rollover, remain manual for the time being.
Not enough people are using it today: While it’s estimated (as of mid-2020) that roughly 30% of the global Internet DNS traffic is validating 10 , that doesn’t mean that many of the DNS zones are actually signed. What this means is, even if your company’s zone is signed today, fewer than 30% of the Internet’s servers are taking advantage of this extra security. It gets worse: with less than 1.5% of the
.comdomains signed, even if your DNSSEC validation is enabled today, it’s not likely to buy you or your users a whole lot more protection until these popular domain names decide to sign their zones.
The last point may have more impact than you realize. Consider this:
HTTP and HTTPS make up the majority of traffic on the Internet. While you may have
secured your DNS infrastructure through DNSSEC, if your web hosting is
outsourced to a third party that does not yet support DNSSEC in its
own domain, or if your web page loads contents and components from
insecure domains, end users may experience validation problems when
trying to access your web page. For example, although you may have signed
the zone company.com, the web address www.company.com may actually be a
CNAME to foo.random-cloud-provider.com. As long as
random-cloud-provider.com remains an insecure DNS zone, users cannot
fully validate everything when they visit your web page and could be
redirected elsewhere by a cache poisoning attack.
- 10
Based on APNIC statistics at https://stats.labs.apnic.net/dnssec/XA
Recipes¶
This chapter provides step-by-step “recipes” for some common DNSSEC configurations.
DNSSEC Signing¶
There are two recipes here: the first shows an example using DNSSEC signing on the primary server, which has been covered in this guide; the second shows how to setup a “bump in the wire” between a hidden primary and the secondary servers to seamlessly sign the zone “on the fly.”
Primary Server DNSSEC Signing¶
In this recipe, our servers are illustrated as shown in DNSSEC Signing Recipe #1: we have a primary server (192.168.1.1) and three secondary servers (192.168.1.2, 192.168.1.3, and 192.168.1.4) that receive zone transfers. To get the zone signed, we need to reconfigure the primary server. Once reconfigured, a signed version of the zone is generated on the fly; zone transfers take care of synchronizing the signed zone data to all secondary name servers, without configuration or software changes on them.
DNSSEC Signing Recipe #1¶
Using the method described in
Easy-Start Guide for Signing Authoritative Zones, we just need to
add a dnssec-policy statement to the relevant zone clause. This is
what the named.conf zone statement looks like on the primary server, 192.168.1.1:
zone "example.com" IN {
type primary;
file "db/example.com.db";
key-directory "keys/example.com";
dnssec-policy default;
allow-transfer { 192.168.1.2; 192.168.1.3; 192.168.1.4; };
};
We have chosen to use the default policy, storing the keys generated for
the zone in the directory keys/example.com. To use a
custom policy, define the policy in the configuration
file and select it in the zone statement (as described in
Creating a Custom DNSSEC Policy).
On the secondary servers, named.conf does not need to be updated,
and it looks like this:
zone "example.com" IN {
type secondary;
file "db/example.com.db";
primaries { 192.168.1.1; };
};
In fact, the secondary servers do not even need to be running BIND; they can run any DNS product that supports DNSSEC.
“Bump in the Wire” Signing¶
In this recipe, we take advantage of the power of automated signing by placing an additional name server (192.168.1.5) between the hidden primary (192.168.1.1) and the DNS secondaries (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 an unsigned zone from the hidden primary, and sending out signed data on the other end to the secondary name servers. The steps described in this recipe may be used as part of a DNSSEC deployment strategy, since it requires only minimal changes made to the existing hidden DNS primary and DNS secondaries.
DNSSEC Signing Recipe #2¶
It is important to remember that 192.168.1.1 in this case is a hidden primary not exposed to the world, and it must not be listed in the NS RRset. Otherwise the world will get conflicting answers: unsigned answers from the hidden primary and signed answers from the other name servers.
The only configuration change needed on the hidden primary, 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
Easy-Start Guide for Signing Authoritative Zones still need to be
performed, such as generating key pairs and uploading information to
the parent zone. This server is configured as secondary to the hidden
primary 192.168.1.1 to receive the unsigned data; then, using keys
accessible to this middle box, to sign data on the fly; and finally, to send out the
signed data via zone transfer to the other three DNS secondaries. Its
named.conf zone statement looks like this:
zone example.com {
type secondary;
primaries { 192.168.1.1; };
file "db/example.com.db";
key-directory "keys/example.com";
dnssec-policy default;
allow-transfer { 192.168.1.2; 192.168.1.3; 192.168.1.4; };
};
(As before, the default policy has been selected here. See Creating a Custom DNSSEC Policy for instructions on how to define and use a custom policy.)
Finally, on the three secondary servers, the configuration should be updated
to receive a zone transfer from 192.168.1.5 (the middle box) instead of
from 192.168.1.1 (the hidden primary). If using BIND, the named.conf file looks
like this:
zone "example.com" IN {
type secondary;
file "db/example.com.db";
primaries { 192.168.1.5; }; # this was 192.168.1.1 before!
};
Rollovers¶
If you are signing your zone using a dnssec-policy statement, this
section is not really relevant to you. In the policy statement, you set how long
you want your keys to be valid for, the time
taken for information to propagate through your zone, the time it takes
for your parent zone to register a new DS record, etc., and that’s more
or less it. named implements everything for you automatically, apart from
uploading the new DS records to your parent zone - which is covered in
Uploading Information to the Parent Zone. (Some
screenshots from a session where a KSK is uploaded to the parent zone
are presented here for convenience.) However, these recipes may be useful
in describing what happens
through the rollover process and what you should be monitoring.
ZSK Rollover¶
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 ZSK Rollover Methods in Advanced Discussions.
Below is a sample timeline for a ZSK rollover to occur on January 1, 2021:
December 1, 2020 (one month before rollover)
Generate new ZSK
Add DNSKEY for new ZSK to zone
January 1, 2021 (day of rollover)
New ZSK used to replace RRSIGs for the bulk of the zone
February 1, 2021 (one month after rollover)
Remove old ZSK DNSKEY RRset from zone
DNSKEY signatures made with KSK are changed
The current active ZSK has the ID 17694 in the example below. For more information on key management and rollovers, please see Rollovers.
One Month Before ZSK Rollover¶
On December 1, 2020, a month before the example rollover, you (as administrator) should change the parameters on the current key (17694). Set it to become inactive on January 1, 2021 and be deleted from the zone on February 1, 2021; also, generate a successor key (51623):
# cd /etc/bind/keys/example.com/
# dnssec-settime -I 20210101 -D 20210201 Kexample.com.+008+17694
./Kexample.com.+008+17694.key/GoDaddy
./Kexample.com.+008+17694.private
# dnssec-keygen -S Kexample.com.+008+17694
Generating key pair..++++++ ...........++++++
Kexample.com.+008+51623
The first command gets us into the key directory
/etc/bind/keys/example.com/, where keys for example.com are
stored.
The second, dnssec-settime, sets an inactive (-I) date of January 1,
2021, and a deletion (-D) date of February 1, 2021, for the current ZSK
(Kexample.com.+008+17694).
The third command, dnssec-keygen, creates a successor key, using
the exact same parameters (algorithms, key sizes, etc.) as the current
ZSK. The new ZSK created in our example is Kexample.com.+008+51623.
Make sure the successor keys are readable by named.
named’s logging messages indicate when the next
key checking event is scheduled to occur, the frequency of which can be
controlled by dnssec-loadkeys-interval. The log message looks like
this:
zone example.com/IN (signed): next key event: 01-Dec-2020 00:13:05.385
And you can check the publish date of the key by looking at the key file:
# cd /etc/bind/keys/example.com
# cat Kexample.com.+008+51623.key
; This is a zone-signing key, keyid 11623, for example.com.
; Created: 20201130160024 (Mon Dec 1 00:00:24 2020)
; Publish: 20201202000000 (Fri Dec 2 08:00:00 2020)
; Activate: 20210101000000 (Sun Jan 1 08:00:00 2021)
...
Since the publish date is set to the morning of December 2, and our example scenario takes place on December 1, the next morning you will notice that your zone has gained a new DNSKEY record, but the new ZSK is not yet being used to generate signatures. Below is the abbreviated output - with shortened DNSKEY and RRSIG - when querying the authoritative name server, 192.168.1.13:
$ 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 (
20210101000000 20201201230000 6817 example.com.
LAiaJM26T7...FU9syh/TQ= )
example.com. 600 IN RRSIG DNSKEY 8 2 600 (
20210101000000 20201201230000 17694 example.com.
HK4EBbbOpj...n5V6nvAkI= )
...
For good measure, let’s take a look at the SOA record and its signature for this zone. Notice the RRSIG is signed by the current ZSK, 17694. This will come in handy later when you want to verify whether the new ZSK is in effect:
$ dig @192.168.1.13 example.com. SOA +dnssec +multiline
...
;; ANSWER SECTION:
example.com. 600 IN SOA ns1.example.com. admin.example.com. (
2020120102 ; 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 (
20201230160109 20201130150109 17694 example.com.
YUTC8rFULaWbW+nAHzbfGwNqzARHevpryzRIJMvZBYPo
NAeejNk9saNAoCYKWxGJ0YBc2k+r5fYq1Mg4ll2JkBF5
buAsAYLw8vEOIxVpXwlArY+oSp9T1w2wfTZ0vhVIxaYX
6dkcz4I3wbDx2xmG0yngtA6A8lAchERx2EGy0RM= )
These are all the manual tasks you need to perform for a ZSK rollover.
If you have followed the configuration examples in this guide of using
inline-signing and auto-dnssec, everything else is automated for
you by BIND.
Day of ZSK Rollover¶
On the actual day of the rollover, although there is technically nothing for you to do, you should still keep an eye on the zone to make sure new signatures are being generated by the new ZSK (51623 in this example). The easiest way is to query the authoritative name server 192.168.1.13 for the SOA record as you did a month ago:
$ dig @192.168.1.13 example.com. SOA +dnssec +multiline
...
;; ANSWER SECTION:
example.com. 600 IN SOA ns1.example.com. admin.example.com. (
2020112011 ; 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 (
20210131000000 20201231230000 51623 example.com.
J4RMNpJPOmMidElyBugJp0RLqXoNqfvo/2AT6yAAvx9X
zZRL1cuhkRcyCSLZ9Z+zZ2y4u2lvQGrNiondaKdQCor7
uTqH5WCPoqalOCBjqU7c7vlAM27O9RD11nzPNpVQ7xPs
y5nkGqf83OXTK26IfnjU1jqiUKSzg6QR7+XpLk0= )
...
As you can see, the signature generated by the old ZSK (17694) has disappeared, replaced by a new signature generated from the new ZSK (51623).
Note
Not all signatures will disappear magically on the same day; it depends on when each one was generated. In the worst-case scenario, a new signature could have been signed by the old ZSK (17694) moments before it was deactivated, meaning that the signature could live for almost 30 more days, until just before February 1.
This is why it is important to keep the old ZSK in the zone and not delete it right away.
One Month After ZSK Rollover¶
Again, technically there is nothing you need to do on this day,
but it doesn’t hurt to verify that the old ZSK (17694) is now completely
gone from your zone. named will not touch
Kexample.com.+008+17694.private and Kexample.com.+008+17694.key
on your file system. Running the same dig command for DNSKEY should
suffice:
$ 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= )
...
Congratulations, the ZSK rollover is complete! As for the actual key
files (the files ending in .key and .private), they may be deleted at this
point, but they do not have to be.
KSK Rollover¶
This recipe describes how to perform KSK rollover using the Double-DS method. For other KSK rolling methods, please see KSK Rollover Methods in 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 two DS records as shown in Working With the Parent Zone. For more information on key management and rollovers, please see Rollovers.
Below is a sample timeline for a KSK rollover to occur on January 1, 2021:
December 1, 2020 (one month before rollover)
Change timer on the current KSK
Generate new KSK and DS records
Add DNSKEY for the new KSK to zone
Upload new DS records to parent zone
January 1, 2021 (day of rollover)
Use the new KSK to sign all DNSKEY RRsets, which generates new RRSIGs
Add new RRSIGs to the zone
Remove RRSIG for the old ZSK from zone
Start using the new KSK to sign DNSKEY
February 1, 2021 (one month after rollover)
Remove the old KSK DNSKEY from zone
Remove old DS records from parent zone
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
One Month Before KSK Rollover¶
On December 1, 2020, a month before the planned rollover, you (as administrator) should change the parameters on the current key. Set it to become inactive on January 1, 2021, and be deleted from the zone on February 1st, 2021; also generate a successor key (23550). Finally, generate a new DS record based on the new key, 23550:
# cd /etc/bind/keys/example.com/
# dnssec-settime -I 20210101 -D 20210201 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
The first command gets us into the key directory
/etc/bind/keys/example.com/, where keys for example.com are
stored.
The second, dnssec-settime, sets an inactive (-I) date of January 1,
2021, and a deletion (-D) date of February 1, 2021 for the current KSK
(Kexample.com.+007+24848).
The third command, dnssec-keygen, creates a successor key, using
the exact same parameters (algorithms, key sizes, etc.) as the current
KSK. The new key pair created in our example is Kexample.com.+007+23550.
The fourth and final command, dnssec-dsfromkey, creates a DS record
from the new KSK (23550), using SHA-1 as the digest type. Again, in
practice most people generate two DS records for both supported digest
types (SHA-1 and SHA-256), but for our example here we are only using
one to keep the output small and hopefully clearer.
Make sure the successor keys are readable by named.
The syslog message indicates when the next key
checking event is. The log message looks like this:
zone example.com/IN (signed): next key event: 01-Dec-2020 00:13:05.385
You can check the publish date of the key by looking at the key file:
# cd /etc/bind/keys/example.com
# cat Kexample.com.+007+23550.key
; This is a key-signing key, keyid 23550, for example.com.
; Created: 20201130160024 (Thu Dec 1 00:00:24 2020)
; Publish: 20201202000000 (Fri Dec 2 08:00:00 2020)
; Activate: 20210101000000 (Sun Jan 1 08:00:00 2021)
...
Since the publish date is set to the morning of December 2, and our example scenario takes place on December 1, the next morning you will notice that your zone has gained a new DNSKEY record based on your new KSK, but with no corresponding RRSIG yet. Below is the abbreviated output - with shortened DNSKEY and RRSIG - when querying the authoritative name server, 192.168.1.13:
$ 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 (
20201206125617 20201107115617 24828 example.com.
4y1iPVJOrK...aC3iF9vgc= )
example.com. 300 IN RRSIG DNSKEY 7 2 300 (
20201206125617 20201107115617 29747 example.com.
g/gfmPjr+y...rt/S/xjPo= )
...
Anytime after generating the DS record, you can upload it; it is not necessary to wait for the DNSKEY to be published in your zone, since this new KSK is not active yet. You can do it immediately after the new DS record has been generated on December 1, or you can wait until the next day after you have verified that the new DNSKEY record is added to the zone. Below are some screenshots from GoDaddy’s web-based interface, used to add a new DS record 11.
After logging in, click the green “Launch” button next to the domain name you want to manage.
Upload DS Record Step #1¶
Scroll down to the “DS Records” section and click “Manage.”
Upload DS Record Step #2¶
A dialog appears, displaying the current key (24828). Click “Add DS Record.”
Upload DS Record Step #3¶
Enter the Key ID, algorithm, digest type, and the digest, then click “Next.”
Upload DS Record Step #4¶
Address any errors and click “Finish.”
Upload DS Record Step #5¶
Both DS records are shown. Click “Save.”
Upload DS Record Step #6¶
Finally, let’s verify that the registrar has published the new DS record. This may take anywhere from a few minutes to a few days, depending on your parent zone. You can verify whether your parent zone has published the new DS record by querying for the DS record of your zone. In the example below, the Google public DNS server 8.8.8.8 is used:
$ 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
You can also query your parent zone’s authoritative name servers
directly to see if these records have been published. DS records will
not show up on your own authoritative zone, so you cannot query your own
name servers for them. In this recipe, the parent zone is .com, so
querying a few of the .com name servers is another appropriate
verification.
Day of KSK Rollover¶
If you have followed the examples in this document, as described in Easy-Start Guide for Signing Authoritative Zones, there is technically nothing you need to do manually on the actual day of the rollover. However, you should still keep an eye on the zone to make sure new signature(s) are being generated by the new KSK (23550 in this example). The easiest way is to query the authoritative name server 192.168.1.13 for the same DNSKEY and signatures, as you did a month ago:
$ 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 (
20210201074900 20210101064900 23550 mydnssecgood.org.
S6zTbBTfvU...Ib5eXkbtE= )
example.com. 300 IN RRSIG DNSKEY 7 2 300 (
20210105074900 20201206064900 29747 mydnssecgood.org.
VY5URQA2/d...OVKr1+KX8= )
...
As you can see, the signature generated by the old KSK (24828) has disappeared, replaced by a new signature generated from the new KSK (23550).
One Month After KSK Rollover¶
While the removal of the old DNSKEY from the zone should be automated by
named, the removal of the DS record is manual. You should make sure
the old DNSKEY record is gone from your zone first, by querying for the
DNSKEY records of the zone; this time we expect not to see
the key with an ID of 24828:
$ 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 (
20210208000000 20210105230000 23550 mydnssecgood.org.
Qw9Em3dDok...bNCS7KISw= )
example.com. 300 IN RRSIG DNSKEY 7 2 300 (
20210208000000 20210105230000 29747 mydnssecgood.org.
OuelpIlpY9...XfsKupQgc= )
...
Since the key with the ID 24828 is gone, you can now remove the old DS record for that key from our parent zone. Be careful to remove the correct DS record. If you accidentally remove the new DS record(s) with key ID 23550, it could lead to a problem called “security lameness,” as discussed in Security Lameness, and may cause users to be unable to resolve any names in the zone.
After logging in (again, GoDaddy.com in our example) and launching the domain, scroll down to the “DS Records” section and click Manage.
Remove DS Record Step #1¶
A dialog appears, displaying both keys (24828 and 23550). Use the far right-hand X button to remove key 24828.
Remove DS Record Step #2¶
Key 24828 now appears crossed out; click “Save” to complete the removal.
Remove DS Record Step #3¶
Congratulations, the KSK rollover is complete! As for the actual key
files (ending in .key and .private), they may be deleted at this
point, but they do not have to be.
- 11
The screenshots were taken from GoDaddy’s interface at the time the original version of this guide was published (2015). It may have changed since then.
NSEC and NSEC3¶
Migrating from NSEC to NSEC3¶
This recipe describes how to transition from using NSEC to NSEC3, as described
in Proof of Non-Existence (NSEC and NSEC3). This recipe
assumes that the zones are already signed, and that named is configured
according to the steps described in
Easy-Start Guide for Signing Authoritative Zones.
Warning
If your zone is signed with RSASHA1 (algorithm 5), you cannot migrate to NSEC3 without also performing an algorithm rollover to RSASHA1-NSEC3-SHA1 (algorithm 7), as described in Algorithm Rollovers. This ensures that older validating resolvers that do not understand NSEC3 will fall back to treating the zone as unsecured (rather than “bogus”), as described in Section 2 of RFC 5155.
To enable NSEC3, update your dnssec-policy and add the desired NSEC3
parameters. The example below enables NSEC3 for zones with the standard
DNSSEC policy, using 10 iterations, no opt-out, and a random string that is
16 characters long:
dnssec-policy "standard" {
nsec3param iterations 10 optout no salt-length 16;
};
Then reconfigure the server with rndc. You can tell that it worked if you
see the following debug log messages:
Oct 21 13:47:21 received control channel command 'reconfig'
Oct 21 13:47:21 zone example.com/IN (signed): zone_addnsec3chain(1,CREATE,10,1234567890ABCDEF)
You can also verify that it worked by querying for a name that you know does not exist, and checking for the presence of the NSEC3 record. For example:
$ 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 order. 1 represents the algorithm, 0 represents the opt-out flag, 10 represents the number of iterations, and 1234567890ABCDEF is the salt. To learn more about each of these parameters, please see NSEC3PARAM.
Migrating from NSEC3 to NSEC¶
Migrating from NSEC3 back to NSEC is easy; just remove the nsec3param
configuration option from your dnssec-policy and reconfigure the name
server. You can tell that it worked if you see these messages in the log:
named[14093]: received control channel command 'reconfig'
named[14093]: zone example.com/IN: zone_addnsec3chain(1,REMOVE,10,1234567890ABCDEF)
You can also query for a name that you know 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
...
Changing the NSEC3 Salt¶
In NSEC3 Salt, we discuss the reasons why you may want to change your salt periodically for better privacy. In this recipe, we look at what command to execute to actually change the salt, and how to verify that it has been changed.
The dnssec-policy currently has no easy way to re-salt using the
same salt length, so to change your NSEC3 salt you need to change the
salt-length value and reconfigure your server. You should see
the following messages in the log, assuming your old salt was
“1234567890ABCDEF” and named created “FEDCBA09” (salt length 8)
as the new salt:
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)
To verify that it worked, you can query the name server (192.168.1.13 in our example) for a name that you know 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 FEDCBA09 (
TQ9QBEGA6CROHEOC8KIH1A2C06IVQ5ER
NS SOA RRSIG DNSKEY NSEC3PARAM )
...
If you want to use the same salt length, you can repeat the above steps and go back to your original length value.
NSEC3 Opt-Out¶
This recipe discusses how to enable and disable NSEC3 opt-out, and how to show the results of each action. As discussed in NSEC3 Opt-Out, NSEC3 opt-out is a feature that can help conserve resources on parent zones with many delegations that have not yet been signed.
Because the NSEC3PARAM record does not keep track of whether opt-out is used,
it is hard to check whether changes need to be made to the NSEC3 chain if the flag
is changed. Similar to changing the NSEC3 salt, your best option is to change
the value of optout together with another NSEC3 parameter, like
iterations, and in a following step restore the iterations value.
For this recipe we assume the zone example.com
has the following four entries (for this example, it is not relevant what
record types these entries are):
ns1.example.comftp.example.comwww.example.comweb.example.com
And the zone example.com has five delegations to five subdomains, only one of
which is signed and has a valid DS RRset:
aaa.example.com, not signedbbb.example.com, signedccc.example.com, not signedddd.example.com, not signedeee.example.com, not signed
Before enabling NSEC3 opt-out, the zone example.com contains ten
NSEC3 records; below is the list with the plain text name before the actual
NSEC3 record:
aaa.example.com: 9NE0VJGTRTMJOS171EC3EDL6I6GT4P1Q.example.com.
bbb.example.com: AESO0NT3N44OOSDQS3PSL0HACHUE1O0U.example.com.
ccc.example.com: SF3J3VR29LDDO3ONT1PM6HAPHV372F37.example.com.
ddd.example.com: TQ9QBEGA6CROHEOC8KIH1A2C06IVQ5ER.example.com.
eee.example.com: L16L08NEH48IFQIEIPS1HNRMQ523MJ8G.example.com.
ftp.example.com: JKMAVHL8V7EMCL8JHIEN8KBOAB0MGUK2.example.com.
ns1.example.com: FSK5TK9964BNE7BPHN0QMMD68IUDKT8I.example.com.
web.example.com: D65CIIG0GTRKQ26Q774DVMRCNHQO6F81.example.com.
www.example.com: NTQ0CQEJHM0S17POMCUSLG5IOQQEDTBJ.example.com.
example.com: TOM10UQBL336NFAQB3P6MOO53LSVG8UI.example.com.
We can enable NSEC3 opt-out with the following configuration, changing
the optout configuration value from no to yes:
dnssec-policy "standard" {
nsec3param iterations 10 optout yes salt-length 16;
};
After NSEC3 opt-out is enabled, the number of NSEC3 records is reduced.
Notice that the unsigned delegations aaa, ccc, ddd, and
eee no longer have corresponding NSEC3 records.
bbb.example.com: AESO0NT3N44OOSDQS3PSL0HACHUE1O0U.example.com.
ftp.example.com: JKMAVHL8V7EMCL8JHIEN8KBOAB0MGUK2.example.com.
ns1.example.com: FSK5TK9964BNE7BPHN0QMMD68IUDKT8I.example.com.
web.example.com: D65CIIG0GTRKQ26Q774DVMRCNHQO6F81.example.com.
www.example.com: NTQ0CQEJHM0S17POMCUSLG5IOQQEDTBJ.example.com.
example.com: TOM10UQBL336NFAQB3P6MOO53LSVG8UI.example.com.
To undo NSEC3 opt-out, change the configuration again:
dnssec-policy "standard" {
nsec3param iterations 10 optout no salt-length 16;
};
Note
NSEC3 hashes the plain text domain name, and we can compute our own
hashes using the tool nsec3hash. For example, to compute the
hashed name for www.example.com using the parameters we listed
above, we can execute this command:
# nsec3hash 1234567890ABCDEF 1 10 www.example.com.
NTQ0CQEJHM0S17POMCUSLG5IOQQEDTBJ (salt=1234567890ABCDEF, hash=1, iterations=10)
Reverting to Unsigned¶
This recipe describes how to revert from a signed zone (DNSSEC) back to an unsigned (DNS) zone.
Whether the world thinks your zone is signed is determined by the presence of DS records hosted by your parent zone; if there are no DS records, the world sees your zone as unsigned. So reverting to unsigned is as easy as removing all DS records from the parent zone.
Below is an example showing how to remove DS records using the GoDaddy web-based interface:
After logging in, click the green “Launch” button next to the domain name you want to manage.
Revert to Unsigned Step #1¶
Scroll down to the “DS Records” section and click Manage.
Revert to Unsigned Step #2¶
A dialog appears, displaying all current keys. Use the far right-hand X button to remove each key.
Revert to Unsigned Step #3¶
Click Save.
Revert to Unsigned Step #4¶
To be on the safe side, wait a while before actually deleting all signed data from your zone, just in case some validating resolvers have cached information. After you are certain that all cached information has expired (usually this means one TTL interval has passed), you may reconfigure your zone.
Here is what named.conf looks like when it is signed:
zone "example.com" IN {
type primary;
file "db/example.com.db";
allow-transfer { any; };
dnssec-policy "default";
};
Change your dnssec-policy line to indicate you want to revert to unsigned:
zone "example.com" IN {
type primary;
file "db/example.com.db";
allow-transfer { any; };
dnssec-policy "insecure";
};
Then use rndc reload to reload the zone.
The “insecure” policy is a built-in policy (like “default”). It will make sure the zone is still DNSSEC maintained, to allow for a graceful transition to unsigned.
When the DS records have been removed from the parent zone, use
rndc dnssec -checkds -key <id> withdrawn example.com to tell named that
the DS is removed, and the remaining DNSSEC records will be removed in a timely
manner. Or if you have parental agents configured, the DNSSEC records will be
automatically removed after BIND has seen that the parental agents no longer
serves the DS RRset for this zone.
After a while, your zone is reverted back to the traditional, insecure DNS format. You can verify by checking that all DNSKEY and RRSIG records have been removed from the zone.
You can then remove the dnssec-policy line from your named.conf and
reload the zone. The zone will now no longer be subject to any DNSSEC
maintenance.
Commonly Asked Questions¶
No questions are too stupid to ask. Below are some common questions you may have and (hopefully) some answers that help.
- Do I need IPv6 to have DNSSEC?
No. DNSSEC can be deployed without IPv6.
- Does DNSSEC encrypt my DNS traffic, so others cannot eavesdrop on my DNS queries?
No. Although cryptographic keys and digital signatures are used in DNSSEC, they only provide authenticity and integrity, not privacy. Someone who sniffs network traffic can still see all the DNS queries and answers in plain text; DNSSEC just makes it very difficult for the eavesdropper to alter or spoof the DNS responses.
- Does DNSSEC protect the communication between my laptop and my name server?
Unfortunately, not at the moment. DNSSEC is designed to protect the communication between end clients (laptop) and name servers; however, there are few applications or stub resolver libraries as of mid-2020 that take advantage of this capability. While enabling DNSSEC today does little to enhance the security of communications between a recursive server and its clients (commonly called the “last mile”), we hope that will change in the near future as more applications become DNSSEC-aware.
- Does DNSSEC secure zone transfers?
No. You should consider using TSIG to secure zone transfers among your name servers.
- Does DNSSEC protect my network from malicious websites?
The answer in the early stages of DNSSEC deployment is, unfortunately, no. DNSSEC is designed to provide confidence that when you receive a DNS response for www.company.com over port 53, it really came from Company’s name servers and the answers are authentic. But that does not mean the web server a user visits over port 80 or port 443 is necessarily safe. Furthermore, 98.5% of domain name operators (as of this writing in mid-2020) have not yet signed their zones, so DNSSEC cannot even validate their answers.
The answer for sometime in the future is that, as more zones are signed and more recursive servers validate, DNSSEC will make it much more difficult for attackers to spoof DNS responses or perform cache poisoning. It will still not protect against users who visit a malicious website that an attacker owns and operates, or prevent users from mistyping a domain name; it will just become less likely that an attacker can hijack other domain names.
- If I enable DNSSEC validation, will it break DNS lookup, since most domain names do not yet use DNSSEC?
No, DNSSEC is backwards-compatible to “standard” DNS. As of this writing (in mid-2020), although 98.5% of the .com domains have yet to be signed, a DNSSEC-enabled validating resolver can still look up all of these domain names as it always has under standard DNS.
There are four (4) categories of responses (see RFC 4035):
- Secure:
Domains that have DNSSEC deployed correctly.
- Insecure:
Domains that have yet to deploy DNSSEC.
- Bogus:
Domains that have deployed DNSSEC but have done it incorrectly.
- Indeterminate:
Domains for which it is not possible to determine whether these domains use DNSSEC.
A DNSSEC-enabled validating resolver still resolves #1 and #2; only #3 and #4 result in a SERVFAIL. You may already be using DNSSEC validation without realizing it, since some ISPs have begun enabling DNSSEC validation on their recursive name servers. Google public DNS (8.8.8.8) also has enabled DNSSEC validation.
- Do I need to have special client software to use DNSSEC?
No. DNSSEC only changes the communication behavior among DNS servers, not between a DNS server (validating resolver) and a client (stub resolver). With DNSSEC validation enabled on your recursive server, if a domain name does not pass the checks, an error message (typically SERVFAIL) is returned to clients; to most client software today, it appears that the DNS query has failed or that the domain name does not exist.
- Since DNSSEC uses public key cryptography, do I need Public Key Infrastructure (PKI) in order to use DNSSEC?
No, DNSSEC does not depend on an existing PKI. Public keys are stored within the DNS hierarchy; the trustworthiness of each zone is guaranteed by its parent zone, all the way back to the root zone. A copy of the trust anchor for the root zone is distributed with BIND 9.
- Do I need to purchase SSL certificates from a Certificate Authority (CA) to use DNSSEC?
No. With DNSSEC, you generate and publish your own keys, and sign your own data as well. There is no need to pay someone else to do it for you.
- My parent zone does not support DNSSEC; can I still sign my zone?
Technically, yes, but you will not get the full benefit of DNSSEC, as other validating resolvers are not able to validate your zone data. Without the DS record(s) in your parent zone, other validating resolvers treat your zone as an insecure (traditional) zone, and no actual verification is carried out. To the rest of the world, your zone still appears to be insecure, and it will continue to be insecure until your parent zone can host the DS record(s) for you and tell the rest of the world that your zone is signed.
- Is DNSSEC the same thing as TSIG?
No. TSIG is typically used between primary and secondary name servers to secure zone transfers, while DNSSEC secures DNS lookup by validating answers. Even if you enable DNSSEC, zone transfers are still not validated; to secure the communication between your primary and secondary name servers, consider setting up TSIG or similar secure channels.
- How are keys copied from primary to secondary server(s)?
DNSSEC uses public cryptography, which results in two types of keys: public and private. The public keys are part of the zone data, stored as DNSKEY record types. Thus the public keys are synchronized from primary to secondary server(s) as part of the zone transfer. The private keys are not, and should not be, stored anywhere other than secured on the primary server. See Key Storage for more information on key storage options and considerations.
- Can I use the same key for multiple zones?
Yes and no. Good security practice suggests that you should use unique key pairs for each zone, just as you should have different passwords for your email account, social media login, and online banking credentials. On a technical level, it is completely feasible to reuse a key, but multiple zones are at risk if one key pair is compromised. However, if you have hundreds or 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 as with password management: use unique passwords for your bank accounts and shopping sites, but use a standard password for your not-very-important logins. First, categorize your zones: high-value 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. Note that at present (mid-2020), fully automatic signing (using the
dnssec-policyclause in yournamedconfiguration file) does not support reuse of keys except when the same zone appears in multiple views (see next question). To use the same key for multiple zones, sign your zones using semi-automatic signing. Each zone wishing to use the key should point to the same key directory.- How do I sign the different instances of a zone that appears in multiple views?
Add a
dnssec-policystatement to eachzonedefinition in the configuration file. To avoid problems when a single computer accesses different instances of the zone while information is still in its cache (e.g., a laptop moving from your office to a customer site), you should sign all instances with the same key. This means setting the same DNSSEC policy for all instances of the zone, and making sure that the key directory is the same for all instances of the zone.- Will there be any problems if I change the DNSSEC policy for a zone?
If you are using fully automatic signing, no. Just change the parameters in the
dnssec-policystatement and reload the configuration file.namedmakes a smooth transition to the new policy, ensuring that your zone remains valid at all times.