BIND DNSSEC Guide
Copyright � 2014, 2015, 2016, 2017 Internet Systems Consortium, Inc.
Abstract
This is version 1.2 of the DNSSEC deployment guide for
BIND 9.
BIND 9 is open source software that implements the Domain Name System
(DNS) protocols for the Internet. It is a reference implementation of
those protocols, but it is also production-grade software, suitable for
use in high-volume and high-reliability applications.
Domain Name System Security Extensions (DNSSEC) extends standard
DNS to provide a measure of security; it proves that the data comes from
the official source and has not been modified in transit.
ISC BIND 9 supports the full set of DNSSEC standards.
Table of Contents
Preface
1. Organization
2. Acknowledgement
1. Introduction
1.1. Who Should Read this Guide?
1.2. Who May Not Want to Read this Guide?
1.3. What is DNSSEC?
1.4. What does DNSSEC Add to DNS?
1.5. How Does DNSSEC Change DNS Lookup?
1.5.1. Chain of Trust
1.6. Why is DNSSEC Important? (Why Should I Care?)
1.7. How does DNSSEC Change My Job as a DNS Administrator?
2. Getting Started
2.1. Software Requirement
2.1.1. BIND Version
2.1.2. DNSSEC Support in BIND
2.1.3. System Entropy
2.2. Hardware Requirement
2.2.1. Recursive Server Hardware
2.2.2. Authoritative Server Hardware
2.3. Network Requirements
2.4. Operational Requirements
2.4.1. Parent Zone
2.4.2. Security Requirements
3. Validation
3.1. Easy Start Guide for Recursive Servers
3.2. How To Test Recursive Server (So You Think You Are Validating)
3.2.1. Using Web-based Tools to Verify
3.2.2. Using dig to Verify
3.2.3. Using delv to Verify
3.2.4. Verifying Protection from Bad Domain Names
3.2.5. How Do I know I Have a Validation Problem?
3.3. Validation Easy Start Explained
3.3.1. dnssec-validation
3.3.2. How Does DNSSEC Change DNS Lookup (Revisited)?
3.3.3. How are Answers Verified?
3.4. Trust Anchors
3.4.1. How Trust Anchors are Used
3.4.2. Trusted Keys and Managed Keys
3.5. What's EDNS All About (And Why Should I Care)?
3.5.1. EDNS Overview
3.5.2. EDNS on DNS Servers
3.5.3. Support for Large Packets on Network Equipment
3.5.4. Wait... DNS Uses TCP?
4. Signing
4.1. Easy Start Guide for Signing Authoritative Zones
4.1.1. Generate Keys
4.1.2. Reconfigure BIND
4.1.3. Verification
4.1.4. Upload to Parent Zone
4.1.5. So... What Now?
4.1.6. Your Zone, Before and After DNSSEC
4.2. How To Test Authoritative Zones (So You Think You Are Signed)
4.2.1. Look for Key Data in Your Zone
4.2.2. Look for Signatures in Your Zone
4.2.3. Examine the Zone File
4.2.4. Check the Parent
4.2.5. External Testing Tools
4.3. Signing Easy Start Explained
4.3.1. Generate Keys Explained
4.3.2. Reconfigure BIND Explained
4.4. Working with Parent Zone
4.4.1. DS Record Format
4.4.2. DNSKEY Format
4.4.3. Trusted Key Format
4.5. Using NSEC3
4.6. Maintenance Tasks
4.6.1. ZSK Rollover
4.6.2. KSK Rollover
5. Basic Troubleshooting
5.1. Query Path
5.2. Visible Symptoms
5.3. Logging
5.3.1. BIND DNSSEC Debug Logging
5.4. Common Problems
5.4.1. Security Lameness
5.4.2. Incorrect Time
5.4.3. Invalid Trust Anchors
5.4.4. Unable to Load Keys
5.5. Negative Trust Anchors
5.6. NSEC3 Troubleshooting
5.7. Troubleshooting Example
6. Advanced Discussions
6.1. Key Generation
6.1.1. Can I Use the Same Key Pair for Multiple Zones?
6.1.2. Do I Need Separate ZSK and KSK?
6.1.3. Which Algorithm?
6.1.4. Key Sizes
6.2. Proof of Non-Existence (NSEC and NSEC3)
6.2.1. NSEC
6.2.2. NSEC3
6.2.3. NSEC or NSEC3?
6.3. Key Storage
6.3.1. Public Key Storage
6.3.2. Private Key Storage
6.3.3. Hardware Security Modules (HSM)
6.4. Key Management
6.4.1. Key Rollovers
6.4.2. Key Management and Metadata
6.4.3. How Long Do I Wait Before Deleting Old Data?
6.4.4. Emergency Key Rollovers
6.4.5. DNSKEY Algorithm Rollovers
6.5. Other Topics
6.5.1. DNSSEC and Dynamic Updates
6.5.2. DNSSEC and Inline Signing
6.5.3. DNSSEC Look-aside Validation (DLV)
6.5.4. DNSSEC on Private Networks
6.5.5. Introduction to DANE
6.6. Disadvantages of DNSSEC
7. Recipes
7.1. Inline Signing Recipes
7.1.1. Master Server Inline Signing Recipe
7.1.2. "Bump in the Wire" Inline Signing Recipe
7.2. Rollover Recipes
7.2.1. ZSK Rollover Recipe
7.2.2. KSK Rollover Recipe
7.3. NSEC and NSEC3 Recipes
7.3.1. Migrating from NSEC to NSEC3
7.3.2. Migrating from NSEC3 to NSEC
7.3.3. Changing NSEC3 Salt Recipe
7.3.4. NSEC3 Optout Recipe
7.4. Reverting to Unsigned Recipe
7.5. Self-signed Certificate Recipe
8. Commonly Asked Questions
List of Figures
1.1.
DNSSEC Validation 12 Steps
3.1.
Signature Generation
3.2.
Signature Verification
3.3.
DNSSEC Validation with .gov Trust Anchor
4.1.
Verisign DNSSEC Debugger
4.2.
DNSViz
5.1.
Query Path
7.1.
Inline Signing Recipe #1
7.2.
Inline Signing Scenario #2
7.3.
Upload DS Record Step #1
7.4.
Upload DS Record Step #2
7.5.
Upload DS Record Step #3
7.6.
Upload DS Record Step #4
7.7.
Upload DS Record Step #5
7.8.
Upload DS Record Step #6
7.9.
Remove DS Record Step #1
7.10.
Remove DS Record Step #2
7.11.
Remove DS Record Step #3
7.12.
Revert to Unsigned Step #1
7.13.
Revert to Unsigned Step #2
7.14.
Revert to Unsigned Step #3
7.15.
Revert to Unsigned Step #4
7.16.
Browser Certificate Warning
7.17.
DNSSEC TLSA Validator
List of Tables
ZSK KSK Comparison
6.1.
Key Metadata Comparison
1.燨rganization
This document provides introductory information on how DNSSEC works,
how to configure BIND 9 to support some common DNSSEC features, as well as
some basic troubleshooting tips. The chapters are organized as such:
Chapter�1,
Introduction
covers the intended audience for this
document, assumed background knowledge, and a basic introduction to the
topic of DNSSEC.
Chapter�2,
Getting Started
covers various requirements that
are needed before implementing DNSSEC, such as software versions, hardware
capacity, network requirements, and security changes.
Chapter�3,
Validation
walks through setting up a
validating resolver, more information on the validation process, as well as
examples of using tools to verify that the resolver is validating answers.
Chapter�4,
Signing
walks through setting up a basic
signed authoritative zone, explains the relationship with the parent zone,
and on-going maintenance tasks.
Chapter�5,
Basic Troubleshooting
provides some tips on how to
analyze and diagnose DNSSEC-related problems.
Chapter�6,
Advanced Discussions
covers several topics,
from key generation, key storage, key management, NSEC and NSEC3, to
disadvantages of DNSSEC.
Chapter�7,
Recipes
provides several working examples of
common solutions, with step-by-step details.
Chapter�8,
Commonly Asked Questions
lists some commonly
asked questions and answers about DNSSEC.
2.燗cknowledgement
This document is 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 and Ray Bellis.
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 meta data 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
The recipe for TLSA self-signed certificate is based on the work of
"A Step-by-Step guide for implementing DANE with a Proof of
Concept" by Sandoche Balakrichenan, Stephane Bortzmeyer, and Mohsen Souissi
(April 15, 2013)
Icons made by
Freepik
and
SimpleIcon
from
http://www.flaticon.com
, licensed under
Creative Commons
BY 3.0
Chapter�1.營ntroduction
1.1.燱ho Should Read this Guide?
This guide is intended to be an introduction to DNSSEC for the DNS
administrator who is comfortable working with the existing BIND and DNS
infrastructure. He or she might be curious about DNSSEC, but has not had the
time to read up about what DNSSEC is (or is not), whether or not DNSSEC should
be a part of her or his environment, and what it means to deploy it in the
field.
This guide provides basic information on how to configure DNSSEC using
BIND 9. 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.
1.2.燱ho 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 the document, and you may want to start with
. 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
won't 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 may be purposely omitted at times for
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
the most basic, generic working examples. If you are a TLD operator, or
administer zones under signed TLDs, this guide can
help you get started, but 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
Section�6.5.4, “DNSSEC on Private Networks”
1.3.燱hat 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
each DNS response can be verified for integrity (message 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 Server
: People use recursive
servers to lookup external domain names such www.example.com. Operators of
recursive servers need to enable DNSSEC validation. With validation
enabled, recursive servers will carry out additional tasks on each DNS
response they received to ensure its authenticity.
Authoritative Server
: 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 will respond to
queries with additional DNS data, such as digital signatures and keys, in
addition to the standard answers.
Application
: This component lives on every
client machine, from web server to smart phones. This includes resolver
libraries on different Operating Systems, and applications such as web
browsers.
In this guide, we will focus on the first two components, Recursive
Server and Authoritative Server, and only lightly touch on the third
component. We will look at how DNSSEC works, how to configure a validating
resolver, how to sign DNS zone data, and other operational tasks and
considerations.
1.4.燱hat does DNSSEC Add to DNS?
Primer on Public Key Cryptography
Public Key Cryptography works on the concept of a pair of keys,
one is made available to the world publicly, and one is kept in secrecy
privately. Not surprisingly, they are known as public key and 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, take a look at
Section�3.3.3, “How are Answers Verified?”
DNSSEC introduces six new resource record types:
RRSIG (digital signature)
DNSKEY (public key)
DS (parent-child)
NSEC (proof of nonexistence)
NSEC3 (proof of nonexistence)
NSEC3PARAM (proof of nonexistence)
This guide will not dissect into the anatomy of each resource record
type, the details are left for the readers 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.) will come with at least one
RRSIG, or resource record signature. 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
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, there are two categories of keys used in DNSSEC,
Zone Signing Key (ZSK) is used to protect all zone data, and Key Signing
Key (KSK) is used to protect other keys. We will talk about keys in
Section�4.3.1, “Generate Keys Explained”
, and again later in
Section�6.1, “Key Generation”
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
Section�1.5.1, “Chain of Trust”
The NSEC, NSEC3, and NSEC3PARAM resource records all deal with a very
interesting problem: proving that something really does not exist.
We will
look at these record types in more detail in
Section�6.2, “Proof of Non-Existence (NSEC and NSEC3) ”
1.5.燞ow Does DNSSEC Change DNS Lookup?
Traditional (insecure) DNS lookup is simple: a recursive name server
receives a query from a client to lookup the name
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 the authoritative name server to respond with the answer.
With DNSSEC validation enabled, a validating recursive name server (a.k.a.
validating resolver
) will ask for additional resource records in its query, hoping the
remote authoritative name servers will 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 will perform cryptographic
computation to verify the authenticity (origin of the data) and integrity (data
was not altered during transit) of the answers, and even ask the parent zone
as part of the verification. It will repeat this process of get-key, validate,
ask-parent, 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 following example shows the DNSSEC validating process of looking up
the name
at a very high level:
Figure�1.1.燚NSSEC Validation 12 Steps
Upon receiving a DNS query from a client to resolve
, the validating resolver follows standard DNS
protocol to track down the name server for
isc.org
, sends it a
DNS query to ask for the A record of
. But since
this is a DNSSEC-enabled resolver, the outgoing query has a bit set
indicating it wants DNSSEC answers, hoping the name server who receives
it speaks DNSSEC and can honor this secure request.
name server is DNSSEC-enabled, and responds
with the answer (in this case, an A record), and with a digital signature
for verification purpose.
The validating resolver needs to be able to verify the digital
signature, and to do so it requires cryptographic keys. So it asks the
name server for those keys.
name 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 could we trust this answer? If a clever attacker had taken over the
name 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 real
name server. This is a
critical part of DNSSEC: at some point, the DNS administrators at
had uploaded some cryptographic information to its
parent,
.org
, maybe it was a secure web submit form, maybe it
was through an email exchange, or perhaps it was done in person. No matter
the case, at some point, some verifiable information about the child
) was sent to the parent (
), for
safekeeping.
The validating resolver asks the parent (
) for the
verifiable information it keeps on its child,
The verifiable information is sent from the
server. At this point, validating resolver compares this to the answer it
received in #4, and the two of them should match, proving the authenticity
of
Let's examine this process.
You might be thinking to yourself,
well, what if the clever attacker that took over
also
compromised the
servers? Of course all this information
would match! That's why we will turn our attention now to the
servers, interrogate it for its cryptographic keys, and
move on one level up to
's parent, root.
The validating resolver asks
authoritative name
servers for its cryptographic keys, for the purpose of verifying the
answers received in #6.
name server responds with the answer (in this
case, keys and signatures). At this point, validating resolver can verify
the answers received in #6.
The validating resolver asks root (
's parent) for
Root name server sends back the verifiable information it keeps on
. The validating resolver now takes this information and
uses it to verify the answers received in #8.
So up to this point, both
check 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.
Validating resolver asks root name server for its cryptographic
keys in order to verify the answer(s) received in #10.
Root name server sends keys, at this point, validating resolver
can verify the answer(s) received in #10.
1.5.1.燙hain 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'll talk about
the current imperfect state later and ways to work around it), each
validating resolver would only have to trust one entity, that is the root
name server. The validating resolver would already have the root key on file
(and we'll talk about later how we got the root key file). So after answers
in #12 are received, validating resolver takes the answer received and
compare it to the key it already has on file, and these two should match.
If they do, it means we can trust the answer from root, thus we can trust
, and thus we can trust
. This is known
as "chain of trust" in DNSSEC.
We will revisit this 12-step process again later in
Section�3.3.2, “How Does DNSSEC Change DNS Lookup (Revisited)?”
with more technical
details.
1.6.燱hy 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:
Be a good netizen
: By enabling DNSSEC
validation (as described in
) on your
DNS servers, you're protecting your users or yourself a little more by
checking answers returned to you; by signing your zones (as described in
), 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
whether or not you want to implement DNSSEC, if your organization is
subject to compliance standards that mandate it. For example, the US
government set a deadline back in 2008, to have all
.gov
sub
domains signed by the December 2009
[1]
. So if you operated a sub domain in
, you must implement DNSSEC in order to be compliant. One
of the widely used compliance standards, PCI DSS for the payment card
industry, has been rumored to list DNSSEC as a requirement or
recommendation, as part of its on-going efforts to enhance security for
online payment transactions.
ICANN also requires that all new top-level domains support DNSSEC.
Enhanced Security (C.Y.A.)
: 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 case 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 preventative measure that could have been put in place. Think of
this like having your web site only available via HTTP but not
HTTPS.
New Features
: DNSSEC brings not only enhanced
security, but with that new level of security, 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... People are still
coming up with new features, but this all relies on a trust-worthy DNS
infrastructure. To take a peek at these next generation DNS features, check
out
Section�6.5.5, “Introduction to DANE”
1.7.燞ow does DNSSEC Change My Job as a DNS Administrator?
With this protocol extension, some of the things you are used to
in DNS will change. As the DNS administrator, you will have new
maintenance tasks to perform on a regular basis (as described in
Section�4.6, “Maintenance Tasks”
); when there's a DNS resolution
problem, you have new troubleshooting techniques and tools to use (as
described in
). BIND tries its
best to make these things as transparent and seamless as possible. In
this guide, we try to use the configuration examples that result in the
least amount of work for DNS administrators.
The Office of
Management and Budget (OMB) for the US government published a memo in 2008
www.whitehouse.gov/sites/default/files/omb/memoranda/fy2008/m08-23.pdf
), requesting all
sub-domains to be DNSSEC signed by
December 2009. This explains why
is the most deployed
DNSSEC domain currently, with more than 80% sub domains
signed.
Chapter�2.燝etting Started
2.1.燬oftware Requirement
2.1.1.燘IND Version
The configuration examples given in this document requires BIND
version
9.9
or newer. To check the version of
named
you have installed, use the
-v
switch as shown below:
named -v
BIND 9.10.1
2.1.2.燚NSSEC Support in BIND
All versions of BIND 9 since BIND 9.7 can support DNSSEC as currently
deployed in the global DNS. The BIND software you are
running most likely already supports DNSSEC as shipped. Run the command
named -V
to see what flags it was built with. If it was
built with OpenSSL (
--with-openssl
), then it supports
DNSSEC. Below is an example screenshot of running
-V
BIND 9.10.1 <id:fe66c6b1> built by make with '--prefix=/opt/local'
'--mandir=/opt/local/share/man' '
=/opt/local'
'--with-libxml2=/opt/local' '--without-libjson' '--enable-threads'
'--enable-ipv6' 'CC=/usr/bin/clang' 'CFLAGS=-pipe -Os -arch x86_64'
'LDFLAGS=-L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64'
'CPPFLAGS=-I/opt/local/include'
compiled by CLANG 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)
using OpenSSL version: OpenSSL 1.0.1i 6 Aug 2014
using libxml2 version: 2.9.1
If the BIND 9 software you have does not support DNSSEC, it may be
necessary to rebuild it from source or upgrade to a newer version.
2.1.3.燬ystem Entropy
If you plan on deploying DNSSEC to your authoritative server, you will
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 provides additional entropy for your system. Once installed, they
will significantly reduce the time needed to generate keys.
The more entropy there is, the better pseudo-random numbers you get,
and stronger keys are generated. If you want or need high quality random
numbers, take a look at
Section�6.3.3, “Hardware Security Modules (HSM)”
for some
of the hardware-based solutions.
2.2.燞ardware Requirement
2.2.1.燫ecursive 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, this 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 will occupy 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 out-dated hardware.
One of the factors to consider is the destinations of your current DNS
traffic. If your current users spend a lot of time visiting
web sites, then you should expect a bigger jump in all of the above
categories when validation is enabled, because
is more than
80% signed. This means, more than 80% of the time, your validating resolver
will be doing what is described in
Section�1.5, “How Does DNSSEC Change DNS Lookup?”
. However, if your users only
care about resources in the
.com
domain, which as of this
writing, is 0.5% signed, then your recursive name server is
unlikely to experience significant load increase after enabling DNSSEC
validation.
2.2.2.燗uthoritative 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 that you should consider for possible hardware enhancements for an
authoritative server with signed zones:
: 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, it also adds to higher CPU
loads.
System storage
: A signed zone is definitely
larger than an unsigned zone. How much larger? See
Section�4.1.6, “Your Zone, Before and After DNSSEC”
for a comparison
example. Roughly speaking, you could expect your zone file to grow at
least three times as large, usually more.
: 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.
: 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 out-dated hardware.
One of the factors to consider, but you really have no
control over, is how many users who query your domain name have
DNSSEC enabled. It was estimated in late 2014, that roughly 10% to
15% of the Internet DNS queries were DNSSEC aware, and since then
Google DNS has become DNSSEC enabled and is used by a further 15%
of global DNS users. This translates to roughly 25% to 30% of the
DNS queries for your domain will take advantage the additional
security features, which result in the increased system load and
possibly network traffic.
2.3.燦etwork 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, this may mean updating firewall policies or Access
Control List (ACL) on routers. See
Section�3.5.4, “Wait... DNS Uses TCP?”
more
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". You should verify that the
responses your nameserver generates are being seen by the rest
of the world.
See
Section�3.5, “What's EDNS All About (And Why Should I Care)?”
more details.
2.4.燨perational Requirements
2.4.1.燩arent 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
Section�4.4, “Working with Parent Zone”
, a crucial step in DNSSEC deployment is
to establish the parent-child trust relationship. If your parent zone does not
support DNSSEC yet, contact them to voice your concern.
ICANN maintains a list of registrars who support DNSSEC:
https://www.icann.org/resources/pages/deployment-2012-02-25-en
2.4.2.燬ecurity 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, or how often keys need to be
rotated. The examples presented in this document are not intended for high
value zones. We cover some of these security considerations in
Chapter�3.燰alidation
3.1.燛asy Start Guide for Recursive Servers
This section provides the minimum amount of information to setup 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 the answers it receives are legitimate
through the use of public key cryptography and hashing functions.
Once DNSSEC validation is enabled, any DNS response that does not pass
the validation checks will result in the domain name not getting resolved
(often a SERVFAIL status seen by the client).
What this means for the DNS
administrator is, if there is a DNSSEC configuration issue (sometimes outside
of the administrator's control), a specific name, or sometimes entire domains,
may "disappear" from DNS, in that it becomes unreachable through that
resolver. What this means for the end user is, name resolution is slow or
fails altogether, or some parts of a URL will not load, or web browser will
display some error message indicating the page cannot be displayed at
all.
For example, if root name servers were misconfigured with the wrong
information about
, it could cause all validation for
domains to fail. To the end users, it would appear that no
one could get to any
web sites.
You may not need to reconfigure your name server at all, since recent
versions of BIND packages and distributions have been shipped with DNSSEC
validation enabled by default. Before making any configuration changes, check
whether or not you already have DNSSEC validation by following steps described
in
Section�3.2, “How To Test Recursive Server (So You Think You Are Validating)”
Enabling DNSSEC validation on a BIND 9 recursive name server is easy,
you only need one line of configuration in your configuration file:
options {
dnssec-validation auto;
};
Restart
or use
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
Section�2.1.2, “DNSSEC Support in BIND”
, you most likely have
some other network-related configurations that need to be adjusted, take a
look at
Section�2.3, “Network Requirements”
to make sure your network is
ready for DNSSEC.
DNSSEC is enabled by default for BIND,
but this line enables automatic trust anchor configuration.
To learn more about this configuration, please refer to
Section�3.3, “Validation Easy Start Explained”
3.2.燞ow To Test Recursive Server (So You Think You Are Validating)
Okay, so 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 suggestions below, starting with the easiest.
3.2.1.燯sing Web-based Tools to Verify
For most people, the simplest way to check if the recursive name server
is indeed validating DNS queries, is to use one of the many web-based
tools.
Configure your client computer to use the newly reconfigured recursive
server for DNS resolution, and then you can use any one of these
web-based tests to see if it is in fact validating answers DNS
responses.
http://en.conn.internet.nl/connection/
http://www.dnssec-tools.org/
http://dnssec.vs.uni-due.de/
3.2.2.燯sing dig to Verify
The web-based tools often employ JavaScript.
If you don't
trust the JavaScript magic that the web-based tools rely on, you
can take matters into your own hands and use a command line DNS
tool to check your validating resolver yourself.
While nslookup is popular, partly because it comes pre-installed on
most systems, it is not DNSSEC-aware. The Domain Information Groper
dig
), on the other hand, fully supports the DNSSEC
standard, and comes as a part of BIND. If you do not have dig already
installed on your system, install it by downloading it from ISC's web site.
ISC provides pre-compiled Windows versions on its web site.
is a flexible tool for interrogating DNS name
servers. It performs DNS lookups and displays the answers that are returned
from the name server(s) that were queried. Most seasoned DNS administrators
use
to troubleshoot DNS problems because of its
flexibility, ease of use, and clarity of output.
The example below shows using dig to query the name server 192.168.1.7
for the A record for
if DNSSEC is disabled.
The address 192.168.1.7 is only used as an example, you should
replace this address with the actual address or host name of your recursive
name server. Notice although we specifically used the
+dnssec
command line option, we do not see the DNSSEC OK (
do
) bit
in the response, nor do we see any DNSSEC resource records.
dig @192.168.1.7 www.isc.org. A +dnssec +multiline
; <<>> DiG 9.10.0-P2 <<>> @192.168.1.7 www.isc.org. A +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20416
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.isc.org.
IN A
;; ANSWER SECTION:
www.isc.org.
60 IN A 149.20.64.69
Below shows what the results look like querying the same server
(192.168.1.7) after enabling DNSSEC validation. The exact same command is
run, and this time notice three key differences:
The presence of the Authenticated Data (
ad
) flag in
the header
The DNSSEC OK (
) flag indicating the recursive
server is DNSSEC-aware
An additional resource record of type RRSIG, with the same name
as the A record.
) flag tells us that the recursive server
we are querying (192.168.1.7 in this example) is DNSSEC-aware but not
necessarily that it is configured to perform DNSSEC validation.
The Authenticated Data (
) flag tells us that the answer
received has passed the validation process as described in
. We can have confidence in the
authenticity and integrity of the answer that
really
points to the IP address 149.20.64.69, and it was not a spoofed answer from a
clever attacker.
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32472
;; flags: qr rd ra
; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
; EDNS: version: 0,
flags: do
; udp: 4096
IN A
4 IN A 149.20.64.69
4 IN RRSIG A 5 3 60 (
20141029233238 20140929233238 4521 isc.org.
DX5BaGVd4KzU2AIH911Kar/UmdmkARyPhJVLr0oyPZaq
5zoobGqFI4efvzL0mcpncuUg3BSU5Q48WdBu92xinMdb
E75zl+adgEBOsFgFQR/zqM3myt/8SngWm4+TQ3XFh9eN
jqExHZZuZ268Ntlxqgf9OmKRRv8X8YigaPShuyU= )
;; Query time: 3 msec
;; SERVER: 192.168.1.7#53(192.168.1.7)
;; WHEN: Fri Oct 03 16:40:04 CST 2014
;; MSG SIZE
rcvd: 223
3.2.3.燯sing delv to Verify
If you have BIND 9.10 or later, you can use Domain Entity Lookup &
Validation (
delv
) to validate your setup. This program is
similar to
, but is specifically tailored for
DNSSEC.
Without DNSSEC:
delv @192.168.1.7 www.isc.org. A
;; no valid RRSIG resolving 'org/DS/IN': 192.168.1.7#53
;; no valid DS resolving 'www.isc.org/A/IN': 192.168.1.7#53
;; resolution failed: no valid DS
also comes with a handy
+rtrace
(trace resolver fetches) switch that shows a little
more information on what was fetched:
delv @192.168.1.7 www.isc.org. A +rtrace
;; fetch: www.isc.org/A
;; fetch: org/DS
After enabling DNSSEC validation, re-running the exact same codes show
us the following results:
delv @192.168.1.7 www.isc.org. A +multiline
; fully validated
60 IN A 149.20.64.69
60 IN RRSIG A 5 3 60 (
And
shows all the glory of what records were
fetched to validate this answer:
delv @192.168.1.7 www.isc.org +rtrace +multiline
;; fetch: isc.org/DNSKEY
;; fetch: isc.org/DS
;; fetch: org/DNSKEY
;; fetch: ./DNSKEY
19 IN A 149.20.64.69
19 IN RRSIG A 5 3 60 (
3.2.4.燰erifying Protection from Bad Domain Names
It is also important to make sure that DNSSEC is protecting you from
domain names that fail to validate; such failures could be caused by attacks
on your system, attempting to get it to accept false DNS information.
Validation could fail for a number of reasons, maybe the answer doesn't
verify because it's a spoofed response; maybe the signature was a replayed
network attack that has expired; or maybe the child zone has been compromised
along with its keys, and the parent zone's information is telling us that
things don't add up.
There is a domain name specifically setup to purposely
fail DNSSEC validation,
www.dnssec-failed.org
Prior to
enabling DNSSEC validation, you should have no trouble visiting the URL
http://www.dnssec-failed.org/
in your web browser:
And no problem resolving the domain name as shown below using
dig @192.168.1.7 www.dnssec-failed.org. A
; <<>> DiG 9.10.1 <<>> @192.168.1.7 www.dnssec-failed.org. A
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28878
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;www.dnssec-failed.org.
www.dnssec-failed.org. 7200 IN A 68.87.109.242
www.dnssec-failed.org. 7200 IN A 69.252.193.191
;; Query time: 955 msec
;; WHEN: Fri Oct 17 07:42:50 CST 2014
rcvd: 82
After DNSSEC validation is enabled, any attempt to loading the URL
should result in some kind of "Sorry, this page cannot be displayed" error
message from your web browser. And looking up this domain name using
should result in SERVFAIL, as shown below:
;; ->>HEADER<<- opcode: QUERY, status:
SERVFAIL
, id: 46592
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; Query time: 2435 msec
;; WHEN: Fri Oct 17 07:44:56 CST 2014
rcvd: 50
3.2.5.燞ow Do I know I Have a Validation Problem?
Since all DNSSEC validation failures result in a general
message, how do we know that it was related to
validation in the first place?
Fortunately, there is a flag in
, (
+cd
, checking disabled)
which tells the server to disable DNSSEC validation.
When you've received a
message, re-run the
query one more time, and throw in the
flag. If the query
succeeds with
, but ends in
without
it, then you know you are dealing with a validation problem.
dig @192.168.1.7 www.isc.org. A +cd
; <<>> DiG 9.10.1 <<>> @192.168.1.7 www.isc.org. A +cd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33590
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
30 IN A 149.20.64.69
For more information on troubleshooting, please see
3.3.燰alidation Easy Start Explained
In
Section�3.1, “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 it
actually does, and some other options.
3.3.1.燿nssec-validation
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 will
actually take place until you have manually configured at
least one trusted key. This is the default.
no
: DNSSEC validation is disabled, and
recursive server will behave in the "old fashioned" way of performing
insecure DNS lookups.
: DNSSEC validation is enabled, and a
default trust anchor (included as part of BIND) for the DNS root zone is
used.
Let's discuss the difference between
. If you set it to
(the default), the trust anchor will need to
be manually defined and maintained using the
trusted-keys
statement in the configuration file; if you set it to
(as shown in the example), then no further
action should be required as BIND includes a copy
[2]
of the
root key. When set to
, BIND will
automatically keep the keys (also known as trust anchors, which we will look
at in
Section�3.4, “Trust Anchors”
) up-to-date without intervention from
the DNS administrator.
We recommend
unless you
have a good reason for requiring a manual trust anchor. To learn
more about trust anchors, please refer to
Section�3.4.2, “Trusted Keys and Managed Keys”
Note
dnssec-enable
needs to be set to yes (default value is
yes) in order for
to be effective.
3.3.2.燞ow Does DNSSEC Change DNS Lookup (Revisited)?
So by now you've enabled validation on your recursive name server, and
verified that it works. What exactly changed? In
we looked at the very high
level, simplified 12-steps of DNSSEC validation process. Let's revisit that
process now and see what your validating resolver is doing in more detail.
Again, we are using the example to lookup the A record for the domain name
Figure�1.1, “DNSSEC Validation 12 Steps”
):
Validating resolver queries
name servers for
the A record of
. This query has the
DNSSEC
OK
) bit set to 1, notifying the remote
authoritative server that DNSSEC answers are desired.
The zone
is signed, and its name servers are
DNSSEC-aware, thus it responds with the answer to the A record query plus
the RRSIG for the A record.
Validating resolver queries for the DNSKEY for
name server responds with the DNSKEY and
RRSIG records. The DNSKEY is used to verify the answers received in
#2.
Validating resolver queries the parent (
DS record for
name server responds with the DS and RRSIG
records. The DS record is used to verify the answers received in
#4.
name server responds with DNSKEY and RRSIG. The
DNSKEY is used to verify the answers received in #6.
Validating resolver queries the parent (root) for the DS record
Root name server responds with DS and RRSIG records. The DS record
is used to verify the answers received in #8.
Validating resolver queries for the DNSKEY for root.
Root name server responds with 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 to the key or keys it has configured, to decide whether or not the
received key can be trusted. We will talk about these locally configured
keys, or trust anchors, in
As you can see here, with DNSSEC, every response includes not just the
answer, but a digital signature (RRSIG) as well. This is so the validating
resolver can verify the answer received, and that's what we will look at in
the next section,
3.3.3.燞ow are Answers Verified?
Keep in mind as you read this section, that although words like
encryption
decryption
are used
from time to time, DNSSEC does not provide you with privacy. Public key
cryptography is used to provide data authenticity (who sent it) and data
integrity (it did not change during transit), but any eavesdropper can still
see your DNS requests and responses in clear text, even when DNSSEC is
enabled.
So how exactly are DNSSEC answers verified? Before we can talk about
how they are verified, let's first see how verifiable information is
generated. On the authoritative server, each DNS record (or message) is run
through a hash function, then this hashed value is encrypted by a private
key. This encrypted hash value is the digital signature.
Figure�3.1.燬ignature Generation
When the validating resolver queries for the resource record, it
receives both the plain-text message and the digital signature(s). The
validating resolver knows the hash function used (listed in the digital
signature record itself), so it can take the plain-text message and run it
through the same hash function to produce a hashed value, let's call it hash
value X. The validating resolver can also obtain the public key (published as
DNSKEY records), decrypt the digital signature, and get back the original
hashed value produced by the authoritative server, let's call it hash value
Y. If hash values X and Y are identical, and the time is correct (more on
what this means below), the answer is verified, meaning we know this answer
came from the authoritative server (authenticity), and the content remained
intact during transit (integrity).
Figure�3.2.燬ignature Verification
Take the A record
for example, the plain text
is:
The digital signature portion is:
20141029233238 20140929233238
4521 isc.org.
When a validating resolver queries for the A record
, it receives both the A record and the RRSIG record.
It runs the A record through a hash function (in this example, it would be
SHA1 as indicated by the number 5, signifying RSA-SHA1) and produces hash
value X. The resolver also fetches the appropriate DNSKEY record to decrypt
the signature, and the result of the decryption is hash value Y.
But wait! There's more! Just because X equals Y doesn't mean everything
is good. We still have to look at the time. Remember we mentioned a little
earlier that we need to check if the time is correct? Well, look at the two
highlighted timestamps in our example above, the two timestamps are:
Signature Expiration: 20141029233238
Signature Inception: 20140929233238
This tells us that this signature was generated UTC September 29th,
2014, at 11:32:38PM (20140929233238), and it is good until UTC October 29th,
2014, 11:32:38PM (20141029233238). And the validating resolver's current
system time needs to fall between these two timestamps. Otherwise the
validation fails, because it could be an attacker replaying an old captured
answer set from the past, or feeding us a crafted one with incorrect future
timestamps.
If the answer passes both hash value check and timestamp check, it is
validated, and the authenticated data (
) bit is set, and
response is sent to the client; if it does not verify, a SERVFAIL is returned
to the client.
3.4.燭rust Anchors
A trust anchor is a key that is placed into a validating resolver so
that the validator can verify the results for a given request back to a known
or trusted public key (the trust anchor). A validating resolver must have at
least one trust anchor installed in order to perform DNSSEC validation.
3.4.1.燞ow Trust Anchors are Used
In the section
, we walked through
the DNSSEC lookup process (12 steps), and at the end of the 12 steps, a
critical comparison happens: the key received from the remote server, and the
key we have on file are compared to see if we trust it. The key we have on
file is called a trust anchor, sometimes also known as a trust key, trust
point, or secure entry point.
The 12-step lookup process describes the DNSSEC lookup in the ideal
world where every single domain name is signed and properly delegated, each
validating resolver only needs to have one trust anchor, and that is the
root's public key. But there is no restriction that the validating resolver
must only have one trust anchor. In fact, in the early stages of DNSSEC
adoption, it was not unusual for a validating resolver to have more than one
trust anchor.
For instance, before the root zone was signed (prior to the year 2010),
some validating resolvers that wish to validate domain names in the
zone needed to obtain and install the key for
. A sample lookup process for
www.fbi.gov
would
thus be only 8 steps rather than 12 steps that look like this:
Figure�3.3.燚NSSEC Validation with .gov Trust Anchor
fbi.gov
name server for
FBI's name server responds with answer and RRSIG.
Validating resolver queries FBI's name server for
DNSKEY.
FBI's name server responds with DNSKEY and RRSIG.
name server for DS
record of
name server responds with DS record and RRSIG
name server responds with DNSKEY and
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
, or ask the root name servers for its DNSKEY.
In fact, whenever the validating resolver receives a DNSKEY, it checks
to see if this is a configured trusted key, to decide whether or not it needs
to continue chasing down the validation chain.
3.4.2.燭rusted Keys and Managed Keys
So, as the resolver is validating, we must have at least one key (trust
anchor) configured. How did it get here, and how do we maintain it?
If you followed the recommendation in
, by setting
to
, then
there is nothing you need to do. BIND already includes a default key (in the
file
bind.keys
), that will automatically update itself.
It looks something like this:
managed-keys {
. initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
QxA+Uk1ihz0=";
You could, of course, decide to manage this key on your own by hand.
First, you'll need to make sure that your
is set to
rather than
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
statement as shown below:
trusted-keys {
. 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
Looking back at the example in
Section�3.4.1, “How Trust Anchors are Used”
, if you wanted to explicitly trust
and only validate domain names under
your
statement would look something like
this:
gov. 257 3 8 "AQO8daaz7B+yshOfL60rytKd9aOSujgponEw3fwBMEC3
/+e9XzHw2k+VKnbJTZ+QaVtpfUd1q9HKZIv/ck83Gl5T
jYKE5jtUZ2kpEDZfVNGv6yx0smtWAXv1nCJS9ohnyOTd
397eMojGDHqkEC+uojEScZheEkMxzgCZwDAs+/CSU7mS
uHtCRZn19xlZUd5Gv7yDQ3mbOUwuy30oSk0z1Q5UUPpo
ihOugIZHFX6Jk7NLiW2wlqfq9qhV4zj7TiBiJY0mCc4z
HN8/aq2VKDHp2Na7mWzvKyTy+SYQkBQ/08LbPwj9YMc+
uCzKL6sU/ObHv17EFhD8aPDftTHZvV9L+OZr";
As the name
suggests, it is possible to
have more than one key configured. You could also leverage
Section�6.5.3, “DNSSEC Look-aside Validation (DLV)”
as part of your trust-anchor management strategy.
While
appear similar, there is an
important difference:
are always
trusted, until they are deleted from
named.conf
(specifically,
initial-key
, which is the only supported type
currently) are only trusted once: for as long as it takes to load
the managed key database and start the key maintenance process.
Warning
Remember, if you choose to manage the keys on your own, whenever the
key changes, the configuration needs to be updated manually. Failing to do so
will result in breaking nearly all DNS queries for the sub domain of the key.
So if you are manually managing
, all domain names in the
space may become unresolvable; if you are manually managing
the root key, you could break all DNS requests made to your recursive name
3.5.燱hat's EDNS All About (And Why Should I Care)?
3.5.1.燛DNS Overview
Traditional DNS responses are typically small in size (less than 512
bytes) and fit nicely into a small UDP packet. Extension
mechanism for DNS (EDNS, or EDNS(0)) gives us a mechanism to send DNS
data in larger packets over UDP. In order to support EDNS, both
the DNS server and the network need to be properly prepared to support
the larger packet size and multiple fragments.
This is important for DNSSEC, since the
+do
bit that
signals DNSSEC-awareness is carried within EDNS, and DNSSEC responses are larger
than traditional DNS.
If DNS servers and network environment cannot
support large UDP packets, it will cause retransmission over
TCP, or the larger UDP responses will be discarded. Users will likely
experience slow DNS resolution or unable to resolve certain names at
Note that EDNS applies whether or not you are validating
DNSSEC because BIND has DNSSEC enabled by default.
Please see
for more
information on what DNSSEC expects from the network environment.
3.5.2.燛DNS on DNS Servers
BIND has been shipped with EDNS enabled by default for over a
decade, and the UDP packet size is set to a maximum of 4096 bytes.
So as the DNS administrator, there should not be any re-configuration
needed. You can use
to verify that your server
supports EDNS and the UDP packet size it is allowing as follows:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63266
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
; EDNS: version: 0, flags: do; udp: 4096
23 IN A 149.20.64.69
23 IN RRSIG A 5 3 60 (
;; Query time: 7 msec
;; WHEN: Fri Oct 03 16:31:33 CST 2014
There is a helpful testing tool available (provided by DNS-OARC)
that you can use to verify resolver behavior regarding EDNS support:
https://www.dns-oarc.net/oarc/services/replysizetest/
So you made sure your name servers have EDNS enabled. That should
be the end of the story, right? Unfortunately, EDNS is a hop-by-hop
extension to DNS. This means the use of EDNS is negotiated between each
pair of hosts in a DNS resolution process, which in turn means if one of
your upstream name servers (for instance, your ISP's recursive name
server that you forward to) does not support EDNS, you may experience
DNS lookup failures or be unable to perform DNSSEC validation.
3.5.3.燬upport for Large Packets on Network Equipment
Okay, so both your recursive name server and your ISP's name
servers support EDNS, we are all good here, right? Not so fast. As these
large packets have to traverse through the network, the network
infrastructure itself must allow them to pass.
When data is physically transmitted over a network, it has to be
broken down into chunks. The size of the data chunk is known as Maximum
Transmission Units (MTU), and it can be different from network to
network. IP fragmentation occurs when a large data packet needs to be
broken down into smaller chunks so that each chunk is smaller than the
MTU, and these smaller chunks need to be reassembled back into the large
data packet. IP fragmentation is not necessarily a bad thing, it most
likely occurs on your network today.
Some network equipment, such as firewalls, may make assumptions about DNS
traffic. One of these assumptions may be how large each DNS packet is. When a
firewall sees a larger DNS packet than it expects, it either rejects the
large packet or drops its fragments because the firewall thinks it's an
attack. This configuration probably didn't cause problems in the past since
traditional DNS packets are usually pretty small in size. However, with
DNSSEC, these configurations need to be updated, since DNSSEC traffic
regularly exceeds 1500 bytes (a common MTU value). If the configuration is
not updated to support larger DNS packet size, it will often result in the
larger packets being rejected, and to the end user it looks like the queries
go un-answered.
Or in the case of fragmentation, only a part of the answer
made it to the validating resolver, and your validating resolver may need to
re-ask the question again and again, creating the appearance "DNS/network is
really slow" for the end users.
And while you're updating configuration on your network equipment, make
sure TCP port 53 is also allowed for DNS traffic.
3.5.4.燱ait... 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 DNSSEC
arrived at the scene. Traditional DNS relies on TCP 53 for operations such as
zone transfer. The use of DNSSEC, or DNS with IPv6 records such as AAAA,
increases the chance that DNS data will be transmitted on TCP.
Due to the increased packet size, DNSSEC may fall back to TCP more
often then traditional (insecure) DNS. If your network is blocking or
filtering TCP port 53 today, you may already experience instability with DNS
resolution before deploying DNSSEC.
BIND
technically includes two copies of the root key, one is in
bind.keys.h
and is built into the executable, and one is
as a
statement. The two copies of the key are identical.
Chapter�4.燬igning
4.1.燛asy Start Guide for Signing Authoritative Zones
working DNSSEC-enabled authoritative name server. A DNSSEC-enabled zone (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 various additional records (DNSKEY, RRSIG, NSEC or NSEC3), and upload
verifiable information (such as DS record) to the parent zone to complete the
chain of trust. For more information about DNSSEC resource records, please see
Section�1.4, “What does DNSSEC Add to DNS?”
In this chapter we assume all configuration files, key files, and zone
files are stored in
/etc/bind
. And most of the times we show
examples of running various commands as the root user. This is arguably not
the best setup, but we don't want to distract you from what's 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 we are not going to cover any of those in this
document. We are trusting you, a responsible DNS administrator, to take the
necessary precautions to secure your system.
For our examples below, we will be working with the assumption that
there is an existing insecure zone
example.com
that we will be
converting to a secure version.
4.1.1.燝enerate Keys
Everything in DNSSEC centers around keys, and we will begin by
generating our own keys. In our example, we are keeping all the keys for
in its own directory,
/etc/bind/keys/example.com
mkdir -p /etc/bind/keys/example.com
cd /etc/bind/keys/example.com
dnssec-keygen -a RSASHA256 -b 1024 example.com
Generating key pair...++++++ .............++++++
Kexample.com.+008+17694
dnssec-keygen -a RSASHA256 -b 2048 -f KSK example.com
Generating key pair........................+++ ..................................+++
Kexample.com.+008+06817
This generated four key files in
, and the only one we care
about for now is the KSK key,
Kexample.com.+008+06817.key
. Remember this file name: we
will need it again shortly. Make sure these files are readable by
Refer to
Section�2.1.3, “System Entropy”
for information on how you
might speed up the key generation process if your random number generator
has insufficient entropy.
4.1.2.燫econfigure BIND
Below is a very simple
, in our example
environment, this file is
/etc/bind/named.conf
. The
lines you most likely need to add are in bold.
directory "/etc/bind";
recursion no;
minimal-responses yes;
zone "example.com" IN {
type master;
file "db/example.com.db";
key-directory "keys/example.com";
inline-signing yes;
auto-dnssec maintain;
When you are done updating the configuration file, tell
to reload:
rndc reload
server reload successful
4.1.3.燰erification
Your zone is now signed. Before moving on to the next step of
coordinating with your parent zone, let's make sure everything looks good
using
. What we want to do is to simulate what a
validating resolver would check, by telling
to use a
specific trust anchor.
First of all, we need to make a copy of the key
Kexample.com.+008+06817.key for editing:
cp /etc/bind/keys/example.com/Kexample.com.+008+06817.key /tmp/example.key
The original key file looks like this (actual key shortened for
display, and comments omitted):
cat /etc/bind/keys/example.com/Kexample.com.+008+06817.key
...
example.com. IN DNSKEY 257 3 8 AwEAAcWDps...lM3NRn/G/R
We want to edit the copy to the be the
format, so that it looks like this:
cat /tmp/example.key
example.com. 257 3 8 "AwEAAcWDps...lM3NRn/G/R";
Now we can run the
command and point it to
using this trusted-key file to validate the answer it receives from the
authoritative name server 192.168.1.13:
delv @192.168.1.13 -a /tmp/example.key +root=example.com example.com. SOA +multiline
example.com.
600 IN SOA ns1.example.com. admin.example.com. (
2014112007 ; serial
1800
; refresh (30 minutes)
900
; retry (15 minutes)
2419200
; expire (4 weeks)
300
; minimum (5 minutes)
600 IN RRSIG SOA 8 2 600 (
20150107091559 20141208081559 17694 example.com.
LwG0rLOm9Q1Lu9bgIz1O+PTCwcCSs1Ev8Eqkqqd3gUJK
qo0FSVv//axNVJFH2Lz8VLgFypD8xARWj1XQBD/9DIf6
A3ncnrFymKdKze+2ghvTUxpwqctK4RF66mhu93e33+Ir
QJVJgdHJVHudQWICA1AbIBYYzLGkKlp7JAJcgBM= )
4.1.4.燯pload to Parent Zone
Everything is done on our name server, now we need to generate some
information to be uploaded to the parent zone to complete the chain of trust.
The formats and the upload methods are actually dictated by your parent
zone's administrator, so contact your registrar or parent zone administrator
to find out what the actual format should be, and how to deliver or upload
the information to your parent zone.
What about your zone between the time you signed it and the time
your parent zone accepts the upload? Well, to the rest of the world,
your zone still appears to be insecure. That is because when a
validating resolver attempts to validate your domain name, it will
eventually come across your parent zone, and your parent zone will
indicate that you are not yet signed (as far as it knows). The
validating resolver will then give up attempting to validate your domain
name, and fall back to the insecure DNS. Basically, before you complete
this final step with your parent zone, your zone is still
insecure.
Before uploading to your parent zone, verify that your newly signed
zone has propagated to all of your name servers (usually 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
will not resolve your domain name.
Here are some examples of what you may upload to your parent zone,
actual keys shortened for display. Note that no matter what formats may be
required, the end result will be the parent zone publishing DS record(s)
based on the information you upload. Again, contact your parent zone
administrator(s) to find out what is the correct format for you.
DS Record Format:
example.com. IN DS 6817 8 1
59194A835ACD78D25D538D5F35CA043A8F3F4446
DNSKEY Format:
example.com. 172800 IN DNSKEY 257 3 8
(AwEAAcjGaU...zuu55If5) ; key id = 06817
Trusted Key Format:
"example.com." 257 3 8
"AwEAAcjGaU...zuu55If5";
The DS record format may be generated using the
dnssec-dsfromkey
tool which is covered in
Section�4.4.1, “DS Record Format”
. For more details and
examples on how to work with your parent zone, please see
4.1.5.燬o... What Now?
Congratulations, your zone is signed, your slave servers have received
the new zone data, and the parent zone has accepted your
upload and published your DS record. Your zone is now officially DNSSEC-enabled.
What happens next? Well, there are a few maintenance
tasks you need to do on a regular basis, which you can find in
. As for updating your zone file, you
can continue to update them the same way you have been prior to signing your
zone, the normal work flow of editing zone file and using the
rndc
command to reload the zone still works the same, and
although you are editing the unsigned version of the zone, BIND will generate
the signed version automatically.
Curious as to what all these commands did to your zone file? Read on to
and find out. If you are
interested in how you can roll this out to your existing master and slave
name servers, check out
Section�7.1, “Inline Signing Recipes”
4.1.6.燳our Zone, Before and After DNSSEC
In the previous section
Section�4.1, “Easy Start Guide for Signing Authoritative Zones”
, we provided the
minimal amount of information to essentially convert a traditional DNS zone
into a DNSSEC-enabled zone. This is what the zone looked like before we
started:
dig @192.168.1.13 example.com. AXFR +multiline +onesoa
; <<>> DiG 9.10.1 <<>> @192.168.1.13 example.com. AXFR +multiline +onesoa
2014102100 ; serial
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
after we have
reloaded the server configuration. As you can see, the zone grew in size, and
the number of records multiplied:
2014102104 ; serial
300 IN RRSIG NSEC 8 2 300 (
20141126120153 20141027112239 60798 example.com.
U1je2BEXY7S/u4An8sKEp2Cb8b90+9mNBoFb9nXgkTvC
cJkT/4OIUIaO7EbsIASmlzjDwJEKSO/nPDFg3y6tsR0m
GT7H7AYAouwBhUlIrDrGQpxqRLJXA1kPkxboX4M2JGx4
rBcBsN/7lG5CGbjtLW3PMnJRELE5fBJBLZM1KLo= )
300 IN NSEC ftp.example.com. NS SOA RRSIG NSEC DNSKEY TYPE65534
600 IN RRSIG NS 8 2 600 (
20141126115318 20141027112239 60798 example.com.
TGC1gAksxHHDoltjJ8ETJ9qdr5MzFjA05vEllSNWBFe7
O71Payf8o4MISHNeUoZpu7Ys4zBiTRLqUaLeI0oSEnzM
r2QJkrfUHl1k8D/wCWApEUhMa1GxLIKMsEfgd3D5nK52
6LAVNihx5BKC1YxuYZXhhBMYQm7bIlUXFvxl3uE= )
20141126122239 20141027112239 60798 example.com.
0ntLprFpg9bKWs5ArGvpZq8uFa9QPEfl6bOmfIwbNnEp
9PgBS97icRs27JDgIXGM4dWxXiPVX6sZ8jFulSp2mi2v
4dhtqMfb4S/rfxSmCphIz5PA+bngKSr5fhRI6tTM8fW1
l5V3zfKCPFracE0CgdcWIt0xViEs56Axj942f5w= )
0 IN RRSIG TYPE65534 8 2 0 (
Sv+7vfHXz4zlLSEuWs5Bt5boqSDVCK2GcOgAzVXnW9/0
zgk3v8VwSXRTRnwdsvl3SK6YsM9S/HNXk32AQs2PjXf4
2/cmv6VCOGSVGin/L5k4KWjpy0ESV2iY0hIIyeXWqUdB
ZUCu1+2GhHiA5+gKODn/8sg6x04g+lZe6wuhU44= )
600 IN RRSIG DNSKEY 8 2 600 (
20141126122239 20141027112239 45319 example.com.
F2vrBJqvloP5yNE6X1+b1XJ4gY6DlH1oyJz6pSULmGgQ
FFztyrCJoV4MI6TeFRXJKLTePewjcTzKlaRKJHZRElcM
QaClWr6RdZ2Uc1fFOBgYocrDZtGWdTVg7XCiLJ/ubrDH
7et9rSexmKEwI44T4Vf7w3e+kUQSzMBGfA9Z5Q8WnnBW
IDn4QFqRx0B02bVLV4giJbVp649ukIApVoHSpJvhrWq8
eSSdP2ojymzr4gAuQZzmZUJnxp7Q3ktuQgIokhLG4FDH
/O9qnhnOkUZFsxbBaDYVn5TIl1Kkmn3LH98JQE0z8a7D
WfqAPAFy0rKHkvyOA8FlimDW09OYeJS00A== )
PoUdallJO0ZF3iFmRoGoKh/iLAJVn52ABVEVku9LK34C
oh4Y29rgK4jd3DwxU7zDLadVs0Fo3JFHp2jdYCEm03BS
XE6d0cijZP5aFt8rO/grO/qbkdv+ScEi1kOhCKcvt3Kg
1mXhiZt4Jx3LeisUpD9mGa+m9ehcPYlAHPKoZMg= )
0 IN TYPE65534 \# 5 ( 08B1070001 )
0 IN TYPE65534 \# 5 ( 08ED7E0001 )
600 IN DNSKEY 256 3 8 (
AwEAAfbc/0ESumm1mPVkm025PfHKHNYW62yx0wyLN5LE
4DifN6FzIVSKSGdMOdq+z6vFGxzzjPDz7QZdeC6ttIUA
Bo4tG7dDrsWK+tG5cm4vuylsEVbnnW5i+gFG/02+RYmZ
ZT9AobXB5bVjfXl9SDBgpBluB35WUCAnK9WkRRUS08lf
) ; ZSK; alg = RSASHA256; key id = 60798
600 IN DNSKEY 257 3 8 (
AwEAAb4N53kPbdRTAwvJT8OYVeVhQIldwppMy7KBJ+8k
Uggx2PU3yP/qlq4Zjl0MMmqRiJhD/S+z9cJLNTZ9tHz1
7aZQjFyGAyuU3DGW16xfMolcIn+c8TpPCzBOFhxk6jvO
VLlz+Wgyi1ES+t29FjYYv5cVNRPmxXLRjlHFdO1DzX3N
dmcUoZ+VVJCvaML9+6UpL/6jitNsoU8JHnxT9B2CGKcw
N7VaK4l9Ida2BqY3/4UVqWzhj03/M5LK6cn1pEQbQMtY
R0TNJURBKdK8bH663h98i23tVX0/85IsCVBL4Dd2boa3
/7HPp7uZN1AjDvcRsOh1mqixwUGmVm1EskDIMy8=
) ; KSK; alg = RSASHA256; key id = 45319
ftp.example.com. 600 IN RRSIG A 8 3 600 (
PNATas8HPjc6tm7Ldfk7P61IlRVSQW085P9lDw8qwITc
TghDdAXHJBkCTXaDRWPyQZbGI5fNcxWLkf/HRbKREzQs
eyztZj2OBnBnnK0t8SWLyM4+OMsGH17z4ZvBmPO/Wgju
iSm98reH7J87yRlUMQHdPSwAP6q5tZeJbwpSkao= )
ftp.example.com. 300 IN RRSIG NSEC 8 3 300 (
ohuvpkqlNR+TYOG79JizEV+SFjVbUKSB3hEfHOJszCIr
bcdPKTS0GgQS62N4ISwfvb735oQzc8pI5R+f+8MMn5c9
/yRnArTpPJOKDnyIiMaMLBU5sEp5wI+OLsLFMkLef4iK
gn+j608Qnoo7dXtWWQPv85FyaT9j3C+EV6rglCk= )
ftp.example.com. 300 IN NSEC ns1.example.com. A RRSIG NSEC
ns1.example.com. 600 IN RRSIG A 8 3 600 (
z1rnlU9oVnIhwxQey3Zo6ENYmWXtf97RiZng3u6VkE0n
yUC5S3sseZgD8Vc+uJsKVAvafM/k7NgS+P3pe5gN01Ln
+geKEMZ3pCHpzHG4UgJj4Xw/iuWOVAFURD26GNnPppDK
RNYPWIhA/9FF18vI3V9evNcHGxN+7rOOXF8Qbss= )
ns1.example.com. 300 IN RRSIG NSEC 8 3 300 (
chH7c6aW6Qk14d4LB866jva9OcH52pJkeHpdslVmUbJ2
OkJQNhbpOekSjsroxDU4av3/Y49Dtg0lqoISvMMqwE5X
5sKmn+CMKFfMmi22ui+RsPXyDqjkx+JOsi/7kCx7DFJz
jF0a6KcsTWNV2QfZjQ50RyrSBBOkw6aqdUC3oF8= )
ns1.example.com. 300 IN NSEC web.example.com. A RRSIG NSEC
web.example.com. 600 IN RRSIG CNAME 8 3 600 (
VgHPC0WllAlHY56xMF3j8FI7MsxDhLJJBDBMSVSQpQkA
z81kfInYQL4YpAt25WrH7xt4pCmjVl3kUcDGAWWuSiQy
nh2O4CoY/tSqQ7Sr9UnE5SIvpW5yws8iROOHvJYuKAmu
8B3gYw1gp9xCMS4iBOIXTTq1KV2OHwo0cPXVyfI= )
web.example.com. 300 IN RRSIG NSEC 8 3 300 (
zh+9fnIQlfpvc0oFRnNIPJoL/S5RQF4HuGwmLxoCxRVp
FCQoZbzNB0IVvaA+0XEslcHq3v4+0j9EeKKQw7xORaGu
TrzcoRGbjuKZlpvnVlxYkjCiEKVbkXd5yEMnbgolFkhH
NjFlozSyzypY0TY0UVRPXWhZ2shASae/ImqFiug= )
web.example.com. 300 IN NSEC www.example.com. CNAME RRSIG NSEC
www.example.com. 600 IN RRSIG A 8 3 600 (
TLkMRs7I3QW8HRS3trNG307Y0/drO4k8uG8Bv8856qPo
33rbEajV49XBBQ+w8jynfKwxMNDfJhpSG0gxo7+0m75Y
HRBZ9Xe3EAMNt2/iu0CL6NHyN99qF9TPNbYnD2Zw077L
GSDOua1KFMxDqFU7rU0+YlKRGbSk1rqAJBqKEH4= )
www.example.com. 300 IN RRSIG NSEC 8 3 300 (
GSyFVBgMROqDuoSJoDegX3EkdqA90skBTvi9tkPxoQPo
i8LlaD+wRmcXpYKE3vf/y0WpOOVQXbasyfFk8wGzFsde
fqpFsscbz3OYgnkwYcTvGXZF9802ytiC5txli9uxUqjc
lGL+SDl0woYhecwJD63fTDIMszlVR/eptIL9dLc= )
www.example.com. 300 IN NSEC example.com. A RRSIG NSEC
But this is a really messy way to tell if your zone is properly setup
with DNSSEC. Fortunately, there are tools to help us with that. Read on to
Section�4.2, “How To Test Authoritative Zones (So You Think You Are Signed)”
to learn more.
4.2.燞ow To Test Authoritative Zones (So You Think You Are Signed)
So we've generated some keys, run some commands, and uploaded some data
to our parent zone. How do we know our zone is signed correctly? Here are a few
ways to check.
4.2.1.燣ook for Key Data in Your Zone
One of the ways to see if your zone is signed, is to check for the
presence of DNSKEY record types. In our example, we created two keys, and we
expect to see both keys returned when we query for them.
dig @192.168.1.13 example.com. DNSKEY +multiline +noall +answer
; <<>> DiG 9.10.1 <<>> @192.168.1.13 example.com. DNSKEY +multiline +noall +answer
300 IN DNSKEY 256 3 8 (
AwEAAclob7q+ccvDwaTVuMM2ddGIynWyMwaZlhFrU6cC
0qknWoPpkq0gIwTrYf3DJY+eIKPVHxrM+o2AoRIVhubG
jfv1bT5wTYrawZstS84ejCQ+ehA+8DxKyeWUEzW0ZMBe
OhyeG0cuQVK/p6Z1E096JLu0DjgbabLspequkw4M+HT7
) ; ZSK; alg = RSASHA256; key id = 57009
300 IN DNSKEY 257 3 8 (
AwEAAdQ2ctHx8VmryndiOgpchXPdj3NwxMeUvAre6uYI
5KELlFJUghTHrz+/CzEc8CXG8wwQ4ZvAey0FGV2nJAFC
ENMxoRiCz0oSiQQxryNhACd3RnE2/D7G+ShwlOM6w53E
wUJ/lsgu5UevSxFC+eA3fKeL3TWR44PH4iJQp9QmfW5v
7qG8Sic/HQvBGBdOGfFtHAl0a4jDPBi57imS4YsHcUYD
9bsWmhYWSHJKZ66+JnTiMS0nQM69YwBF43QfDKurs5R6
qPUDiBlaMCzSxmlaBU6fsI1Mu/yIU8w1ewy26a42rUTU
rPBC3Oa/zf9VQ8kpUrMZgJ7LEAA4xmR+qwWDh6U=
) ; KSK; alg = RSASHA256; key id = 28267
4.2.2.燣ook for Signatures in Your Zone
Another way to see if your zone data is signed is to check for the
presence of signature. With DNSSEC, every record
[3]
now comes with at least one corresponding signature known as
dig @192.168.1.13 example.com. SOA +dnssec +multiline
; <<>> DiG 9.10.1 <<>> @192.168.1.13 example.com. SOA +dnssec +multiline
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31466
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;example.com.
IN SOA
300 IN SOA ns1.example.com. dnsadmin.example.com. (
2014102111 ; serial
10800
; refresh (3 hours)
1080
; retry (18 minutes)
; minimum (15 minutes)
300 IN RRSIG SOA 8 2 300 (
20141121122105 20141022112105 57009 example.com.
NqPGNLkUs40Lg/qq7Fv+bgyCwVB4s9PsHQOK6p9ZWWk3
36z2Qz2WjM+Q19SlVBAPux9jijvcRcjGb6KREuxER9uX
wdVeiGx9a4X+PaO3qTqdkiXuGS2XkK1kBm1CgwhVHTYV
/nxVPrckU4/mpeUoFVjMnT49JkVJmgck63esPEU= )
The serial number was automatically incremented from
the old, unsigned version. Named keeps track of the serial number of the
signed version of the zone independently of the unsigned version.
If the
unsigned zone is updated with a new serial number that's higher than the one
in the signed copy, then the signed copy will be increased to match it, but
otherwise the two are kept separate.
4.2.3.燛xamine the Zone File
Our original zone file
example.com.db
remains
untouched, named has generated 3 additional files automatically for us (shown
below).
The signed DNS data is stored in
example.com.db.signed
and in the associated journal
file.
cd /etc/bind/db
ls
example.com.db example.com.db.jbk
example.com.db.signed.jnl
A quick description of each of the files:
.jbk
: transient file used by
.signed
: signed version of the zone in raw
format
.signed.jnl
: journal file for the signed
version of the zone
These files are stored in raw (binary) format for faster loading. You
could reveal the human-readable version by using
named-compilezone
as shown below. In the example below, we are running the command
on the raw format zone
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
4.2.4.燙heck the Parent
Although this is not strictly related to whether or not the zone is
signed, a critical part of DNSSEC is the trust relationship between the
parent and child. Just because we, the child, have all the correctly signed
records in our zone doesn't mean it can be fully validated by a validating
resolver, unless our parent's data agrees with us. To check if our upload to
the parent is successful, ask the parent name server for the DS record of our
zone, and we should get back the DS record(s) containing the information we
uploaded in
Section�4.1.4, “Upload to Parent Zone”
dig example.com. DS
; <<>> DiG 9.10.1 <<>> example.com. DS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49949
IN DS
61179 IN DS 28267 8 1 66D47CE4B4F551BE5EDA43AC5F3109E8C98E2FAE
61179 IN DS 28267 8 2 71D9335416B7132519190A95685E18CBF478DCF4CA98867062777938F8FEAB89
4.2.5.燛xternal Testing Tools
The easiest ways to see if your domain name is fully secured is to use
one of these excellent online tools.
Verisign Labs DNSSEC Debugger:
http://dnssec-debugger.verisignlabs.com/
DNSViz:
http://dnsviz.net/
4.2.5.1.燰erisign DNSSEC Debugger
URL:
This tool shows a nice summary of checks performed on your domain
name, and you can expand to view more details for each of the items checked
to get a detailed report.
Figure�4.1.燰erisign DNSSEC Debugger
4.2.5.2.燚NSViz
DNSViz provides a visual analysis of the DNSSEC authentication chain
for a domain name and its resolution path in the DNS namespace.
Figure�4.2.燚NSViz
4.3.燬igning Easy Start Explained
4.3.1.燝enerate Keys Explained
Section�4.1.1, “Generate Keys”
, we generated two
pairs of keys: a pair of Zone Signing Keys (ZSK) and a pair of Key Signing
Keys (KSK). To quickly summarize, ZSKs sign the bulk of the zone,
but KSKs only sign the DNSKEYs. This makes ZSKs easier to change
(since you can do so without updating the parent).
We generated
keys by running these commands:
With these commands, we generated NSEC3-compatible key pairs (see
Section�6.2.2, “NSEC3”
to learn more about NSEC3). In the
end, four key files were created in
Kexample.com.+008+06817.private
Kexample.com.+008+17694.key
Kexample.com.+008+17694.private
The two files ending in
.private
need to be kept, well,
private. These are your private keys, guard them carefully. You should at the
very least protect them via file permission settings. Please see
Section�6.3, “Key Storage”
for more information about how
to store your keys.
.key
are your public keys. One is
the zone-signing key (ZSK), and one is the key-signing Key (KSK). We can tell
which is which by looking at the actual file contents (actual keys shortened
for display):
cat Kexample.com.+008+06817.key
; This is a key-signing key, keyid 6817, for example.com.
; Created: 20141120094612 (Thu Nov 20 17:46:12 2014)
; Publish: 20141120094612 (Thu Nov 20 17:46:12 2014)
; Activate: 20141120094612 (Thu Nov 20 17:46:12 2014)
cat Kexample.com.+008+17694.key
; This is a zone-signing key, keyid 17694, for example.com.
; Created: 20141120094536 (Thu Nov 20 17:45:36 2014)
; Publish: 20141120094536 (Thu Nov 20 17:45:36 2014)
; Activate: 20141120094536 (Thu Nov 20 17:45:36 2014)
example.com. IN DNSKEY 256 3 8 AwEAAcjGaU...zuu55If5
The first line of each file tell us what type of key it is. Also, by
looking at the actual DNSKEY record, we could tell them apart: 256 is ZSK,
and 257 is KSK.
So, this is a ZSK:
example.com. IN DNSKEY
256
3 8 AwEAAcjGaU...zuu55If5
And this is a KSK:
257
3 8 AwEAAcWDps...lM3NRn/G/R
The parameters we showed in the example, algorithm of RSASHA256, key
length of 1024 and 2048, and the use of NSEC3 are just suggestions, you need
to evaluate what values work best for your environment. To learn more about
key generation, different algorithm choices, and key sizes, see
The table below summarizes the usage and frequency of use for each of
the keys.
Table�4.1.燴SK KSK Comparison
Key
Usage
Frequency of Use
ZSK Private
Used by authoritative server to create RRSIG for zone
data
Used somewhat frequently depending on the zone, whenever
authoritative zone data changes or re-signing is needed
ZSK Public
Used by recursive server to validate zone data RRset
Used very frequently, whenever recursive server validates a
response
KSK Private
Used by authoritative server to create RRSIG for ZSK and KSK
Public (DNSKEY)
Very infrequently, whenever ZSK's or KSK's change (every
year or every five years in our examples)
KSK Public
Used by recursive server to validate DNSKEY RRset
DNSKEY RRset
4.3.2.燫econfigure BIND Explained
Section�4.1.2, “Reconfigure BIND”
, we
highlighted a few lines, let's explain what each one of them does.
dnssec-enable yes;
4.3.2.1.燿nssec-enable
DNSSEC support is enabled in
by
default.
option is turned
off,
will be unable to serve signed
zones.
4.3.2.2.爇ey-directory
This specifies where
should look for public
and private DNSSEC key files. The default is
's
working directory.
In our example, we organized keys based on zone names, and placed all keys
under one directory
4.3.2.3.爄nline-signing
This option is disabled by default. When enabled, BIND converts
traditional (insecure) zone data to signed (secure) data automatically and
transparently, using keys found in
key-directory
This feature alleviates the burden of re-signing zone data put on
DNSSEC zone administrators. As the zone administrator, you can continue to
manually maintain the unsigned version of the zone just like before, and
automatically creates an internal copy of the
zone, signs it on the fly, and increments the serial number for the signed
zone. The unsigned version of the zone is left intact. With this feature
enabled, whenever
detects that your zone needs to
be signed, either due to a new record being added, removed, or signature
expiration, it will automatically re-sign the zone data.
Inline signing can also be used as a strategy to aid DNSSEC
deployment in the case where the master zone cannot be easily modified
To learn more about inline signing, please see
Section�6.5.2, “DNSSEC and Inline Signing”
4.3.2.4.燼uto-dnssec
With keys, comes the burden of key management.
auto-dnssec
provides varying levels of automatic key
management. There are three possible settings:
off
: this is the default, key management is
done manually
allow
: permits keys to be updated and the
zone fully re-signed whenever the user issues the command
sign [zonename]
maintain
: includes what "allow" has, but
also automatically adjusts the zone's DNSSEC keys on schedule, according
to the key's timing metadata.
We have opted for the "maintain" mode in our example, which provides
the most automated key management. With this option enabled, BIND will
periodically check to see if new keys are available, or old keys need to be
retired, and automatically add or remove the appropriate DNSKEY records from
the zone. The frequency of the check can be controlled via
dnssec-loadkeys-interval
, default is 60 minutes (1
hour).
is a feature to automate many of the
key management tasks, which we discuss in more detail in
Section�6.4.2.1, “Manual Key Management and Signing”
, to
cover topics such as manual signing and key timing metadata.
4.4.燱orking with Parent Zone
As we mentioned in
, the format of the
information you upload to your parent zone is dictated by your parent zone
administrator, and the three main formats are:
DS Record Format
DNSKEY Format
Trusted Key Format
ccTLDs typically maintain their own lists of registrars and
should have a list of which of those support DNSSEC.
ICANN maintains
a list of accredited registrars who support DNSSEC for gTLDs:
Next, we will take a look at how to get each of the three
formats from your existing data.
4.4.1.燚S Record Format
Below is an example of generating DS record formats from the KSK we
created earlier (
Kexample.com.+008+28267.key
) using two
different secure hashing algorithms (SHA-1 and SHA-256, respectively):
dnssec-dsfromkey -a SHA-1 Kexample.com.+008+06817.key
example.com. IN DS 6817 8 1 59194A835ACD78D25D538D5F35CA043A8F3F4446
dnssec-dsfromkey -a SHA-256 Kexample.com.+008+06817.key
example.com. IN DS 6817 8 2 2A5F1DF55D5E64CBD7BCFE1EFA6E9586AF335FA56A2473296E975B89AFD31E11
Some registrars many ask you to manually specify the types of algorithm
and digest used. In the first example, 8 represents the algorithm used, and 1
represents the digest type (SHA-1); in the second example, 8 is the
algorithm, and 2 is the digest type (SHA-256). The key tag or key ID is
28267.
Alternatively, you could generate it from the DNSKEY records like
dig @192.168.1.13 example.com. DNSKEY | dnssec-dsfromkey -f - example.com
4.4.2.燚NSKEY Format
Below is an example of a different key ID (16027) using DNSKEY format
(actual key shortened for display):
example.com. 172800 IN DNSKEY 257 3 8 (AwEAAbGOPf...AX2QHMY8=) ; key id = 16027
The key itself is easy to find (it's kind of hard to miss that big long
base64 string) in the file. Remember, we want the KSK, so look for the presence
of 257.
; This is a key-signing key, keyid
6817
, for example.com.
Some registrars may ask you to manually specify the type of algorithm
used and the key tag number. In our example above, the chosen algorithm is 8,
and the key ID is 6817.
4.4.3.燭rusted Key Format
This format is very similar to the DNSKEY format, the differences are
mostly cosmetic. Below is an example of
format (again, actual key shortened for display):
"example.com." 257 3 8 "AwEAAbGOPf...9AX2QHMY8=";
4.5.燯sing NSEC3
After reloading the server configuration file, additional DNSSEC
resource records are auto-magically generated. By default, BIND will generate
NSEC records. If you wish to use NSEC3 instead, please follow the additional steps
Section�7.3.1, “Migrating from NSEC to NSEC3”
To learn more about
the difference between NSEC and NSEC3, please see
4.6.燤aintenance 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 lookup
information in your zone, they are able to follow the 12-step process as
and verify the authenticity and integrity of the answers.
There is not that much left for you to do, as the DNS administrator, at
an ongoing basis. Whenever you update your zone, BIND will automatically
resign your zone with new RRSIG and NSEC or NSEC3 records, and even increment
the serial number for you.
That leaves DNSKEY records. Just like passwords and underwear, keys should
be changed periodically. There are arguments for and against rolling keys,
which are discussed elsewhere. If you decide to change your keys, we recommend
changing your ZSK pair anually, and your KSK pair every five years. This is
also known as a key rollover.
Why annually for the ZSK? That's just a convenient length of time that
probably coincides with your domain name registration/renewal cycle; And every
five years? That's also a generic length of time, one which happens to be the
same as the root key's rollover schedule. Some people feel or have the need to
do it more frequently, while some argue that there is no need for key rolling.
We discuss those considerations in
Section�6.4.1, “Key Rollovers”
. But
assuming you do not have special security requirements, nor host a
high-valued zone, rotating your ZSK every year and KSK every five years should
suffice. We also provide detailed step-by-step examples of each rollover in
Section�7.2, “Rollover Recipes”
4.6.1.燴SK Rollover
Assuming you are rolling your ZSK every year on January 1st, below is
the timeline of what should happen:
December 1st, a month before rollover date:
Change timer on current ZSK
Generate new ZSK
Publish new DNSKEY
January 1st, day of rollover:
New ZSK used to replace RRSIGs for the bulk of the zone
February 1st, a month after rollover date:
Remove old DNSKEY from zone
DNSKEY signatures made with KSK are changed
This may look like a lot of work, but with
inline-signing
, most
of these are automated. The only things that need to be done manually are just
the first two items:
For an example of how to execute a ZSK rollover, please see
Section�7.2.1, “ZSK Rollover Recipe”
4.6.2.燢SK Rollover
KSK rollover is very similar to ZSK, with the addition of interacting
with the parent zone. In fact, as you can see below, the timeline looks
nearly identical to the ZSK rollover, with the addition of interaction with
parent zone:
Change timer on current KSK
Generate new KSK and DS records
Upload new DS records to parent zone
Use new KSK to sign all DNSKEY RRset, this generates new RRSIGs
Add new RRSIGs to the zone
Remove old RRSIGs from zone
Remove old KSK DNSKEY from zone
Remove old DS records from parent zone
Unfortunately, as of this writing, KSK rollover involves a lot of
manual steps. As described above, the only automated tasks are the ones that
occur on the day of the rollover (January 1st), everything else needs to be
done manually. To see an example of how to perform a KSK rollover, please see
Section�7.2.2, “KSK Rollover Recipe”
Well, almost
every record. NS records and glue records for delegations do not have RRSIG
records like everyone else. If you do not have any delegations, then yes,
every record in your zone will be signed and comes with its own RRSIG.
Chapter�5.燘asic Troubleshooting
In this chapter, we are going to cover some basic
troubleshooting techniques, common DNSSEC symptoms, and their
causes and solutions. This is not a comprehensive "how to troubleshoot
any DNS or DNSSEC problem" guide, because that in and of itself could
easily be an entire book.
5.1.燪uery Path
The first step to your DNS or DNSSEC troubleshooting should be to
determine the query path. This is not a DNSSEC-specific troubleshooting
technique. 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 on to more recursive name servers, before
arriving at the authoritative name server. The giveaway is the presence
of the Authoritative Answer (
aa
) flag: when present, we know
we are talking to the authoritative server; when missing, we are talking
to the recursive server. The example below shows an answer without the
Authoritative Answer flag:
dig www.example.com. A
; <<>> DiG 9.10.1 <<>> www.example.com. A
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41006
;; flags: qr rd
ra
; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;www.example.com.
www.example.com. 600 IN A 192.168.1.100
;; Query time: 21 msec
;; WHEN: Mon Nov 03 19:54:37 CST 2014
rcvd: 60
Not only do we not see the
flag, we see the
presence of an
flag, which represents Recursion
Available. This indicates that the server we are talking to (192.168.1.7
in this example) is a recursive name server. And although we were able to
get an answer for
www.example.com
, the answer came from
somewhere else.
The example below shows when we query the authoritative server
directly and see the presence of the
flag:
dig @192.168.1.13 www.example.com. A
; <<>> DiG 9.10.1 <<>> @192.168.1.13 www.example.com. A
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35962
;; flags: qr
rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
The presence of the
flag tells us that we are now
talking to the authoritative name server for
and 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, if you
look closely, the
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 anyway.
5.2.燰isible Symptoms
After you have figured out the query path, the next thing to do is to
determine whether or not the problem is actually related to DNSSEC validation.
You can use the
flag in
disable validation, as described in
Section�3.2.5, “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 will result in a generic SERVFAIL
message, as shown below when querying against a recursive name server 192.168.1.7:
dig @192.168.1.7 www.isc.org. A
; <<>> DiG 9.10.1 <<>> @192.168.1.7 www.isc.org. A
, id: 8101
;; Query time: 973 msec
;; WHEN: Thu Oct 16 20:28:20 CST 2014
rcvd: 40
With
, a "resolution failed" message is
output instead:
;;
resolution failed: failure
5.3.燣ogging
DNSSEC validation error messages by default will show up in syslog
as a Query-Error. It will have the string "error" at the start of the
message. Here is an example of what it may look like:
error (insecurity proof failed) resolving './NS/IN': 192.168.1.13#53
Usually, this level of error logging should suffice for most. If
you would like to get more detailed information about why DNSSEC
validation failed, read on to
Section�5.3.1, “BIND DNSSEC Debug Logging”
5.3.1.燘IND 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.
With that said, sometimes it may become necessary to
temporarily enable BIND debug logging to see more details of how
DNSSEC is validating (or not).
DNSSEC-related messages are not
recorded in syslog by default, even if query log is enabled, only
DNSSEC errors will show up in syslog.
Enabling debug logging is
not recommended for production servers, as it increases load on
the server.
The example below shows how to enable debug level 3 (to see full
DNSSEC validation messages) in BIND 9 and have it sent to syslog:
logging {
channel dnssec_log {
syslog daemon;
severity debug 3;
print-category yes;
category dnssec { dnssec_log; };
The example below shows how to log DNSSEC messages to their own
file:
file "/var/log/dnssec.log";
After restarting BIND, a large number of log messages will appear
in syslog. The example below shows the log messages as a result of
successfully looking up and validating the domain name
validating @0xb8012d88: . NS: starting
validating @0xb8012d88: . NS: attempting positive response validation
validating @0xb805a9b0: . DNSKEY: starting
validating @0xb805a9b0: . DNSKEY: attempting positive response validation
validating @0xb805a9b0: . DNSKEY: verify rdataset (keyid=19036): success
validating @0xb805a9b0: . DNSKEY: signed by trusted key; marking as secure
validator @0xb805a9b0: dns_validator_destroy
validating @0xb8012d88: . NS: in fetch_callback_validator
validating @0xb8012d88: . NS: keyset with trust 8
validating @0xb8012d88: . NS: resuming validate
validating @0xb8012d88: . NS: verify rdataset (keyid=8230): success
validating @0xb8012d88: . NS: marking as secure, noqname proof not needed
validator @0xb8012d88: dns_validator_destroy
validating @0xb8012d88: www.isc.org A: starting
validating @0xb8012d88: www.isc.org A: attempting positive response validation
validating @0xb805a9b0: isc.org DNSKEY: starting
validating @0xb805a9b0: isc.org DNSKEY: attempting positive response validation
validating @0xb827e298: isc.org DS: starting
validating @0xb827e298: isc.org DS: attempting positive response validation
validating @0xb827fd18: org DNSKEY: starting
validating @0xb827fd18: org DNSKEY: attempting positive response validation
validating @0xb8281798: . NS: starting
validating @0xb8281798: . NS: attempting positive response validation
validating @0xb8281798: . NS: keyset with trust 8
validating @0xb8280790: org DS: starting
validating @0xb8280790: org DS: attempting positive response validation
validating @0xb8280790: org DS: keyset with trust 8
validating @0xb8280790: org DS: verify rdataset (keyid=8230): success
validating @0xb8280790: org DS: marking as secure, noqname proof not needed
validator @0xb8280790: dns_validator_destroy
validating @0xb827fd18: org DNSKEY: in dsfetched
validating @0xb827fd18: org DNSKEY: dsset with trust 8
validating @0xb827fd18: org DNSKEY: verify rdataset (keyid=21366): success
validating @0xb827fd18: org DNSKEY: marking as secure (DS)
validator @0xb827fd18: dns_validator_destroy
validating @0xb827e298: isc.org DS: in fetch_callback_validator
validating @0xb827e298: isc.org DS: keyset with trust 8
validating @0xb827e298: isc.org DS: resuming validate
validating @0xb827e298: isc.org DS: verify rdataset (keyid=33287): success
validating @0xb827e298: isc.org DS: marking as secure, noqname proof not needed
validator @0xb827e298: dns_validator_destroy
validating @0xb805a9b0: isc.org DNSKEY: in dsfetched
validating @0xb805a9b0: isc.org DNSKEY: dsset with trust 8
validating @0xb805a9b0: isc.org DNSKEY: verify rdataset (keyid=12892): success
validating @0xb805a9b0: isc.org DNSKEY: marking as secure (DS)
validating @0xb8012d88: www.isc.org A: in fetch_callback_validator
5.4.燙ommon Problems
5.4.1.燬ecurity Lameness
Similar to Lame Delegation in traditional DNS, this refers to the
symptom when the parent zone holds a set of DS records that point to
something that does not exist in the child zone. The resulting symptom
is that the entire child zone may "disappear", being marked as bogus by
validating resolvers.
Below is an example attempting to resolve the A record for a test
domain name www.example.com. From the user's perspective, as
, only SERVFAIL message is returned. On the validating resolver, we
could see the following messages in syslog:
named[6703]: error (no valid RRSIG) resolving 'example.com/DNSKEY/IN': 149.20.61.151#53
named[6703]: error (broken trust chain) resolving 'www.example.com/DS/IN': 149.20.61.151#53
named[6703]: error (broken trust chain) resolving 'www.example.com/A/IN': 149.20.61.151#53
This gives us a hint that it is a broken trust chain issue. Let's
take a look at the DS records that are published by querying one of the
public DNS resolvers that supports DNSSEC. We have highlighted in the
key tag ID returned, and shortened some keys for display:
dig @8.8.8.8 example.com. DS
; <<>> DiG 9.10.1 <<>> @8.8.8.8 example.com. DS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9640
; EDNS: version: 0, flags:; udp: 512
example.com. 21599 IN DS
53476
8 2 1544D......7DDA7
8 1 CD2AF...0B47B
;; Query time: 212 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Nov 27 17:23:42 CST 2014
rcvd: 133
Next, we query for the DNSKEY and RRSIG of example.com,
to see if there's anything wrong. Since we are having trouble
validating, we flipped on the
option to disable
checking for now to get the results back, even though they do not pass
the validation tests.
The
+multiline
option tells
print the type, algorithm type, and key id for DNSKEY records.
Again, key tag ID's are highlighted, and some long strings are
shortened for display:
dig @8.8.8.8 example.com. DNSKEY +dnssec +cd +multiline
; <<>> DiG 9.10.1 <<>> @8.8.8.8 example.com. DNSKEY +dnssec +cd +multiline
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20329
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
; EDNS: version: 0, flags: do; udp: 512
;example.com. IN DNSKEY
example.com. 299 IN DNSKEY 257 3 8 (
AwEAAePggU...0VPPEX+DE=
) ; KSK; alg = RSASHA256; key id =
48580
example.com. 299 IN DNSKEY 256 3 8 (
AwEAAbMZp6...NRJnwyC/uX
) ; ZSK; alg = RSASHA256; key id =
60426
example.com. 299 IN RRSIG DNSKEY 8 2 300 (
20141227074820 20141127064820
ph3eBXsBQy...fQTRTlpg== )
VaQ0INIa3a...nj3YTPv5A= )
;; Query time: 368 msec
;; WHEN: Fri Nov 28 11:33:00 CST 2014
rcvd: 961
Here is our problem: the parent zone is telling the world that
is using the key 53476, but the
authoritative servers are saying: no no no, I am using keys 48580 and
60426. There might be several causes for this mismatch, one possibility
is that a malicious attacker has compromised one side and change the
data. The more likely scenario is that the DNS administrator for the
child zone did not upload the correct key information to the parent
zone.
5.4.2.營ncorrect Time
In DNSSEC, every record will come with at least one RRSIG, and
RRSIG contains two timestamps indicating when it starts becoming valid,
and when it expires. If the validating resolver's current system time
does not fall within the RRSIG two timestamps, the following error
messages occur in BIND debug log.
First, the example below shows the log messages when the RRSIG has
expired. This could mean the validating resolver system time is
incorrectly set too far in the future, or the zone administrator has not
kept up with RRSIG maintenance.
validating @0xb7b839b0: . DNSKEY:
verify failed due to bad signature (keyid=19036): RRSIG has expired
The logs below show RRSIG validity period has not begun. This
could mean validation resolver system is incorrectly set too far in the
past, or the zone administrator has incorrectly generated signatures for
this domain name.
validating @0xb7c1bd88: www.isc.org A:
verify failed due to bad signature (keyid=4521): RRSIG validity period has not begun
5.4.3.營nvalid Trust Anchors
As we have seen in the section
whenever a DNSKEY is received by the validating resolver, it is actually
compared to the list of keys the resolver has explicitly trusted to see if
further action is needed. If the two keys match, the validating resolver
stops performing further verification and returns the answer(s) as
validated.
But what if the key file on the validating resolver is
misconfigured or missing? Below we show some examples of log messages
when things are not working properly.
First of all, if the key you copied is malformed, BIND will not
even start up and you will likely find this error message in
syslog:
named[18235]: /etc/bind/named.conf.options:29:
bad base64 encoding
named[18235]: loading configuration: failure
If the key is a valid base64 string, but the key algorithm is
incorrect, or if the wrong key is installed, the first thing you will notice
is that pretty much all of your DNS lookups result in SERVFAIL, even when you
are looking up domain names that have not been DNSSEC-enabled. Below shows an
example of querying a recursive server 192.168.1.7:
dig @192.168.1.7 www.example.com. A
; <<>> DiG 9.10.1 <<>> @192.168.1.7 www.example.com. A
, id: 8093
shows similar result:
delv @192.168.1.7 www.example.com. +rtrace
;; fetch: www.example.com/A
The next symptom you will see is in the DNSSEC log
messages:
validating @0xb8b18a38: . DNSKEY: starting
validating @0xb8b18a38: . DNSKEY: attempting positive response validation
validating @0xb8b18a38:
. DNSKEY: unable to find a DNSKEY which verifies the DNSKEY RRset and also matches a trusted key for '.'
validating @0xb8b18a38: . DNSKEY: please check the 'trusted-keys' for '.' in named.conf.
5.4.4.燯nable to Load Keys
This is a simple yet common issue. If the keys files were present
but not readable by
, the syslog messages are
clear, as shown below:
named[32447]: zone example.com/IN (signed): reconfiguring zone keys
named[32447]: dns_dnssec_findmatchingkeys: error reading key file Kexample.com.+008+06817.private: permission denied
named[32447]: dns_dnssec_findmatchingkeys: error reading key file Kexample.com.+008+17694.private: permission denied
named[32447]: zone example.com/IN (signed): next key event: 27-Nov-2014 20:04:36.521
However, if no keys are found, the error is not as obvious. Below
shows the syslog messages after executing
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
loaded the keys and signed
the zone. It will even generate the internal (raw) files:
# cd /etc/bind/db
# ls
If
really loaded the keys and signed the
zone, you should see the following files:
So, unless you see the
*.signed.jnl
file, your zone
has not been signed.
5.5.燦egative 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
mis-configured.
NTAs are added using the
command, e.g:
rndc nta example.com
Negative trust anchor added: example.com/_default, expires 14-Dec-2016 13:39:09.000
The list of currently configured NTAs can also be examined using
, e.g:
rndc nta -dump
example.com: expiry 14-Dec-2016 13:39:09.000
The default lifetime of an NTA is one hour although, by default,
BIND will poll the zone every five minutes to see if the zone now
correctly validates, at which point the NTA will automatically expire.
Both the default lifetime and the polling interval may be configured
via
, and the lifetime can be overriden on a
per-zone basis using the
-lifetime duration
parameter
rndc nta
Both timer values have a permitted maximum
value of one week.
5.6.燦SEC3 Troubleshooting
BIND includes a tool called
nsec3hash
that runs
through the same steps a validating resolver would, 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
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 might be useful to troubleshoot NSEC3
problems.
5.7.燭roubleshooting Example
Let's put what we've looked at together into an example and see the
steps taken to solve the problem. We start with someone complaining that
she is unable to resolve the name
. We use
dig on her machine to verify the behavior, and we received the following
output from
, id: 26068
; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; Query time: 784 msec
;; SERVER: 192.168.1.7#53(
192.168.1.7
;; WHEN: Mon Nov 03 20:00:45 CST 2014
rcvd: 44
We learned from this output that the recursive name server
192.168.1.7 returned a generic error message when resolving the name
. The next step is to look at the DNS server
configuration on 192.168.1.7 to see how it is configured. Below is an
excerpt of
from 192.168.1.7:
forwarders {192.168.1.11;};
forward only;
This tells us that the recursive name server 192.168.1.7 just
sends all recursive queries to 192.168.1.11. Let's query
192.168.1.11:
dig @192.168.1.11 www.example.com. A
; <<>> DiG 9.10.1 <<>> @192.168.1.11 www.example.com. A
, id: 24171
And we get the same result as when we queries 192.168.1.7, generic
failure message, but we also learned that 192.168.1.11 is not
authoritative for
(no
flag), so
it is getting this response from somewhere else. Below is the
configuration excerpt from 192.168.1.11:
forwarders {};
type forward;
forwarders { 192.168.1.13; };
At first glance, it may look like 192.168.1.11 is just performing
recursion itself, querying Internet name servers directly; however,
further down the configuration file, we see the forward zone definition,
which tell us that 192.168.1.11 is doing conditional forwarding just for
, and it is sending all example.com queries to
192.168.1.13.
We then query 192.168.1.13:
;; Query time: 4 msec
;; SERVER: 192.168.1.13#53(192.168.1.13)
;; WHEN: Mon Nov 03 20:06:26 CST 2014
Finally! We found the authoritative name server! Now we know our
query path looks like this:
Figure�5.1.燪uery Path
But 192.168.1.13 has no trouble answering the query for
, so the problem might be between
192.168.1.11 and 192.168.1.13? We know there are no firewalls or network
devices between 192.168.1.11 and 192.168.1.13 that could intercept packets.
Let's query 192.168.1.11 again, but this time, let's purposely turn off DNSSEC
validation by using
(checking disabled), to see if this
error message was caused by DNSSEC validation:
dig @192.168.1.11 www.example.com. A +cd
; <<>> DiG 9.10.1 <<>> @192.168.1.11 www.example.com. A +cd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58332
cd
www.example.com. 562 IN A 192.168.1.100
;; Query time: 2 msec
;; SERVER: 192.168.1.11#53(192.168.1.11)
;; WHEN: Mon Nov 03 20:01:23 CST 2014
Bingo! So the problem is on 192.168.1.11, and specifically, with
DNSSEC validation. Now we can focus our attention on the configuration on
192.168.1.11, examine its logs, check its system time, or check its trust
anchors, to see what may be the root cause.
Examining log messages from 192.168.1.11, we notice the following
two entries:
error (no valid KEY) resolving 'example.com/DNSKEY/IN': 192.168.1.13#53
error (broken trust chain) resolving 'www.example.com/A/IN': 192.168.1.13#53
So it would appear that on the server 192.168.1.11, there is a
broken trust chain. At this point, we can probably conclude the problem
is in one of the trusted-keys statements on 192.168.1.11, but let's turn
on DNSSEC debug logging (as described in
), and re-run the
one more time to
see what log messages get generated:
validating @0xb4b48968: example.com DNSKEY: attempting positive response validation
validating @0xb4b48968: example.com DNSKEY: unable to find a DNSKEY which verifies the DNSKEY RRset and also matches a trusted key for 'example.com'
validating @0xb4b48968: example.com DNSKEY: please check the 'trusted-keys' for 'example.com' in named.conf.
Okay, so we have a confirmed log message telling us to look at
'. The
on
192.168.1.11 contains the following:
example.com. 257 3 8 "AwEAAbluLK0k3dPKnsJNd5tGbO5bgh7WuXzaSDQVwi/qqPdCR65ZDiin
0GTpL++B1iKYDP4rRL/s/2TMppI1fV638f2SuhNQ9zYIuCo/FuHeJB7/
DBQ03eJFvN1QHC0we2uUFrXazz8eT9nkI1SUu0fhcs6CA06gGqauDbpU
mpM7VUX3";
Let's check the authoritative server (192.168.1.13) for the correct
key:
dig @192.168.1.13 example.com. DNSKEY +multiline
; <<>> DiG 9.10.1 <<>> @192.168.1.13 example.com. DNSKEY +multiline
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38451
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
IN DNSKEY
600 IN DNSKEY
256 3 8
AwEAAbluLK0k3dPKnsJNd5tGbO5bgh7WuXzaSDQVwi/q
qPdCR65ZDiin0GTpL++B1iKYDP4rRL/s/2TMppI1fV63
8f2SuhNQ9zYIuCo/FuHeJB7/DBQ03eJFvN1QHC0we2uU
FrXazz8eT9nkI1SUu0fhcs6CA06gGqauDbpUmpM7VUX3
) ; ZSK; alg = RSASHA256; key id = 4974
AwEAAb3lVweaj4dA9dvmcwlkaVpJ4/3ccXbRjgV7jqh1
p0REL8fI0Z42E9SdxdsdTi+2XYcmHDQYEoqwYh70t/4P
4oObZFIUHl+hhKLdXQNZGtzT0xF60k527N9cHPddoXzg
AXYBtGLlLMSJcV8s0rw/i+64xNGdRWpFRdo78RhJ5LU3
1SAPUnhi3OvJgsOpBPntrSyX6iA5ZotitxZJNTqP+Jck
lhPWFgFOBgdvWJ369BRlDGy/m8+pctypZq1hy7ZteHet
r55/cLBXY1BEzz3Q8vLUnSOu5An8IF0v2Gt7hOyY3nqu
bU5vjCbogLj1K5ySBAJbHcCPAFrPGSIfmRize+U=
) ; KSK; alg = RSASHA256; key id = 40327
;; WHEN: Mon Nov 03 21:51:28 CST 2014
rcvd: 888
Did you spot the mistake? We have the correct key data in our
configuration, but the key type was incorrect. In our configuration, the
key was configured as a KSK (257), while the authoritative server
indicates that it is a ZSK (256).
Chapter�6.燗dvanced Discussions
6.1.燢ey Generation
6.1.1.燙an I Use the Same Key Pair for Multiple Zones?
Yes and no. Good security practice suggests that you should use unique
key pairs for each zone, just like how you should have different passwords
for your email account, social media login, and online banking credentials. On
a technical level, this is completely feasible, but then multiple zones are
at risk when one key pair is compromised. If you have hundreds or thousands
(or even hundreds of thousands) of zones to administer, a single key pair for
all might be less error-prone to manage. You may choose to use the same
approach to password management: use unique passwords for your bank accounts
and shopping sites, but use a standard password for your not-very-important
logins. So categorize your zones, high valued zones (or zones that have
specific key rollover requirements) get their own key pairs, while other more
"generic" zones can use a single key pair for easier management.
6.1.2.燚o I Need Separate ZSK and KSK?
No, it is not required that you create two separate sets of keys, but
you should, for operational ease. The DNSSEC protocol itself does not require
two classes of keys, but for operational practicality, having two classes of
keys make the life of a typical DNS(SEC) administrator's life easier. One of
the advantages of having separate ZSKs and KSKs is a better balance between
security and ease of use: the KSK can be stored in a secure and less accessible
area, while the ZSK is easily accessible for routine use. For more details and
considerations on this topic, please refer to
RFC 6781
Section 3
Please refer to
Table�4.1, “ZSK KSK Comparison”
of how each of the keys are used.
6.1.3.燱hich Algorithm?
There are at least three algorithm choices for DNSSEC as of this
writing (late 2016):
RSA
Digital Signature Algorithm (DSA)
Elliptic Curve DSA (ECDSA)
While all three are supported by BIND, RSA is the only one
that is mandated to be implemented with DNSSEC and, at the time of
writing, is the most widely supported algorithm by both name servers
and clients. For the time being, RSA/SHA-256 is the algorithm of
choice.
However, RSA is a little long in the tooth, and ECDSA is emerging as
the next new cryptographic standard. In fact, the US federal government
recommended to stop using RSA altogether by September 2015, and migrate to
using ECDSA or similar algorithms.
So for now, use RSA, but keep your eyes on emerging new
standards or requirements. For details about rolling over DNSKEYs
to a new algorithm, see
Section�6.4.5, “DNSKEY Algorithm Rollovers”
6.1.4.燢ey Sizes
The choice of key sizes is a classic issue of finding the balance
between performance and security. The larger the key size, the longer it
takes for an attacker to crack the key; but larger keys also means more
resources are needed both when generating signatures (authoritative servers)
and verifying signatures (recursive servers).
Of the two sets of keys, ZSK is used much more frequently. Whenever
zone data changes, or when signatures expire, ZSK is used, so performance
certainly is of a bigger concern. As for KSK, it is used less frequently, so
performance is less of a factor, but its impact is bigger because of its role
in signing other keys.
In this guide, the following key length were chosen for each set, with
the recommendation that they be rotated more frequently for better security:
ZSK
RSA 1024 bits, rollover every year
KSK
RSA 2048 bits, rollover every five years
These should be the minimum key sizes one should choose.
At the time
of writing (late 2016) the root zone and many TLDs are already using 2048 bit
ZSKs.
If you choose to implement larger key sizes, keep in mind that larger
key size results in larger DNS responses, and this may mean more load on
network resources. Depending on network configuration, end users may even
experience resolution failures due to the increased response sizes, as we
have discussed in
6.2.燩roof 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 will provide an overview of how
DNSSEC solves the problem.
Why is it even important to have authenticated denial of existence?
Couldn't we just send back a "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? Well, the technical challenge of signing
nothing aside, 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.
We are going to use a little story, and tell it three different times to
illustrate how proof of nonexistence works. In our story, we run a small
company with three employees: Alice, Edward, and Susan. We list their names in
a phone directory, and we hired a nameless intern to answer our phone
calls.
If we followed the approach of giving back the same answer no matter
what was asked, when people called and asked for "Bob", our intern would
simply answer: "Sorry, that person doesn't work here, and to prove that I am
not lying, here's the signature: 'deaf coffee beef'". Now this is a legitimate
answer, but since the signature doesn't change,
an attacker could record this
message, and when the next person called in asking for Susan, she will hear
the exact same message: "Sorry, that person doesn't work here, and to prove
that I am not lying, here's the signature: 'deaf coffee beef'". And this
answer is verifiable, since the magic signature ("deaf coffee beef" ) can be
validated
[4]
. Now the attacker has successfully fooled the caller
into thinking that Susan doesn't work at our company, and might even be able
to convince all callers that no one works at this company (no names
exist).
To solve this problem, two different solutions were created, we will
look at the first one, NSEC, next.
6.2.1.燦SEC
The NSEC record is used to prove that something really does not exist,
by providing the name before it, and the name after it. Using our tiny
company example, this would be analogous to someone calling for Bob over the
phone, and our nameless intern answered the phone with: "I'm sorry, that
person doesn't work here. The name before that is Alice, and the name after
that is Edward". Let's say someone called in again for a non-existent person,
Oliver, the answer would be: "I'm sorry, that person doesn't work here. The
name before that is Edward, and the name after that is Susan". Another caller
asked for Todd, and the answer would be: "I'm sorry, that person doesn't work
here. The name before that is Susan, and there's no other name after that".
So we end up with four NSEC records:
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.
susan.example.com.
300 IN NSEC example.com.
What if the attacker tried to use the same replay method
described earlier? If someone called for Edward, none of the four
answers would fit.
If attacker played message #2, "I'm sorry,
that person doesn't work here. The name before it is Alice, and the
name after it is Edward", it is obviously false, since "Edward" is
in the response; same for #3, Edward and Susan. As for #1 and #4,
Edward does not fall in range before Alice or after Susan, so the
caller can logically deduce that it was an incorrect answer.
In BIND inline signing, your zone data will be automatically sorted on
the fly before generating NSEC records, much like how a phone directory is
sorted.
The NSEC record allows for a proof of non-existence
for record types.
If you ask a signed zone for a name that
exists but for a record type that doesn't (for that name), the
signed NSEC record returned lists all of the record types that
exist for the requested domain name.
NSEC records can also be used to show whether a record was
generated as the result of a wildcard expansion or not.
The details
of this are out of scope for this document, but are described well
RFC 7129
Unfortunately, the NSEC solution has a few drawbacks, one of which is
trivial "zone walking". A curious person can keep calling back, and our
nameless, gullible intern will keep divulging information about our
employees. Imagine if the caller first asked: "Is Bob there?" and received
back the names Alice and Edward. The caller can then call back again: "Is
Edward A. there?", and will get back Edward and Susan. Repeat the process
enough times, the caller will eventually learn every name in our company
phone directory. For many of you, this may not be a problem, since the very
idea of DNS is similar to a public phone book: if you don't want a name to be
known publicly, don't put it in DNS! Consider using DNS views (split DNS) and
only display your sensitive names to a selective audience.
The second drawback of NSEC is a actually increased operational
overhead: no opt-out mechanism for insecure child zones, this generally is a
problem for parent zone operators dealing with a lot of insecure child zones,
such as
. To learn more about opt-out, please see
Section�6.2.2.2, “NSEC3 Opt-Out”
6.2.2.燦SEC3
NSEC3 adds two additional features that NSEC does not have:
No easy zone enumeration.
Provides a mechanism for child zone to opt out.
Recall, in
Section�6.2.1, “NSEC”
, we provided a
range of names to prove that something really does not exist. But as it turns
out, even disclosing these ranges of names becomes a problem: this made it
very easy for the curious minded to look at your entire zone. Not only that,
unlike a zone transfer, this "zone walking" is more resource intensive. So
how do we disclose something, without actually disclosing it?
The answer is actually quite simple, hashing functions, or one-way
hashes. Without going into many details, think of it like a magical meat
grinder. A juicy piece of ribeye steak goes in one end, and out comes a
predictable shape and size of ground meat (hash) with a somewhat unique
pattern. No matter how hard you try, you cannot turn the ground meat back
into the juicy ribeye steak, that's what we call a one-way hash.
NSEC3 basically runs the names through a one-way hash, before giving it
out, so the recipients can verify the non-existence, without any knowledge of
the actual names.
So let's tell our little phone receptionist story for the third time,
this time with NSEC3. This time, our intern is not given a list of actual
names, he is given a list of "hashed" names. So instead of Alice, Edward, and
Susan, the list he is given reads like this (hashes shortened for easier
reading):
FSK5....
(produced from Edward)
JKMA.... (produced from Susan)
NTQ0.... (produced from Alice)
Then, the phone rings, someone's asking for Bob again. Our intern takes
the name Bob through a hash function, and the result is L8J2..., so he tells
them on the phone: "I'm sorry, that person doesn't work here. The name before
that is JKMA..., and the name after that is NTQ0...". There, we proved Bob
doesn't exist, without giving away any names! To put that into proper NSEC3
resource records, they would look like this (again, hashes shortened for
display):
FSK5....example.com. 300 IN NSEC3 1 0 10 1234567890ABCDEF
JKMA... A RRSIG
JKMA....example.com. 300 IN NSEC3 1 0 10 1234567890ABCDEF
NTQ0... A RRSIG
NTQ0....example.com. 300 IN NSEC3 1 0 10 1234567890ABCDEF
FSK5... A RRSIG
Hashes and Privacy
Just because we employed one-way hash functions does not mean there's
no way for a determined individual to figure out what your zone data is.
Someone could still gather all of your 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. This would be like if someone really
wanted to know how you got the ground meat, he could buy all cuts of meat
and ground it up at home using the same model of meat grinder, and compare
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, see about adding salt as described in
Section�6.2.2.3, “NSEC3 Salt”
6.2.2.1.燦SEC3PARAM
The above NSEC3 examples used four parameters: 1, 0, 10,
and 1234567890ABCDEF. The
tool may be used to
set the NSEC3 parameters for a zone; for example:
rndc signing -nsec3param 1 0 10 1234567890abcdef example.com
1 represents the algorithm, 0 represents the opt-out flag, 10
represents the number of iterations, and 1234567890abcedf is the salt. Let's
look at how each one can be configured:
Algorithm
: Not much of a choice here, the
only defined value currently is 1 for SHA-1.
Opt-out
: Set this to 1 if you want to do
NSEC3 opt-out, which we will discuss in
Iterations
: iterations defines the number of
additional times to apply the algorithm when generating an NSEC3 hash.
More iterations yields more secure results, but consumes more resources
for both authoritative servers and validating resolvers. In this regard, we
have similar considerations as we've seen in
Section�6.1.4, “Key Sizes”
of security versus resources.
Salt
: The salt is a string of data expressed
in hexadecimal, or a hyphen ('-') if no salt is to be used. We will learn
more about salt in
For example, to create an NSEC3 chain using the SHA-1 hash algorithm,
no opt-out flag, 10 iterations, and a salt value of "FFFF", use:
rndc signing -nsec3param 1 0 10 FFFF example.com
To set the opt-out flag, 15 iterations, and no salt, use:
rndc signing -nsec3param 1 1 15 - example.com
6.2.2.2.燦SEC3 Opt-Out
One of the advantages of NSEC3 over NSEC is the ability for parent
zones to publish less information about its child or delegated zones. Why
would you ever want to do that? Well, 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 in if you are the
operator of busy top level domains such as
or
.net
, with millions and millions of insecure delegated domain
names, it quickly adds up.
As of late 2016, less than 0.5% of all
zones are signed.
Basically, without opt-out, if you have
1,000,000 delegations, only 5 of which are secure, you still have to generate
NSEC RRset 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 or not to use NSEC3 opt-out is probably not
relevant.
To learn more about how to configure NSEC3 opt-out, please see
Section�7.3.4, “NSEC3 Optout Recipe”
6.2.2.3.燦SEC3 Salt
As described in
, while
NSEC3 doesn't 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 features NSEC3 gives us to provide additional
protection: salt. Basically, salt gives us the ability 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 from time to time, it becomes
difficult to construct a useful rainbow table, 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 what steps to take to change NSEC3, please see
Section�7.3.3, “Changing NSEC3 Salt Recipe”
6.2.3.燦SEC or NSEC3?
So which one should you choose? NSEC or NSEC3? There is not really a
single right answer here that fits everyone. It all comes down to your needs
or requirements.
If you prefer not to make your zone easily enumerable, implementing
NSEC3 paired with a periodically changed salt will provide a certain level of
privacy protection. However, someone could still randomly guess the names in
your zone (such as "ftp" or "www"), as in the traditional insecure
DNS.
If you have many many delegations, and have a need for opt-out to save
resources, NSEC3 is for you.
Other than that, using NSEC is typically a good choice for most zone
administrators, as it relieves the authoritative servers from the additional
cryptographic operations that NSEC3 requires, and NSEC is comparatively easier to
troubleshoot than NSEC3.
6.3.燢ey Storage
6.3.1.燩ublic 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
details), and is published by the parent zone as DS records.
6.3.2.燩rivate Key Storage
Ideally, private keys should be stored offline, in secure devices such
as a smart card. Operationally, however, this creates certain challenges,
since we need the private key to create RRSIG resource records, and it would
be a hassle to bring the private key out of storage every time the zone file
changes or when signatures expire.
A common approach to strike the balance between security and
practicality is to have two sets of keys, a ZSK set, and a KSK set. ZSK
private key is used to sign zone data, and can be kept online for ease of
use; KSK private key is used to sign just the DNSKEY (the ZSK), it is used
less frequently, and can be stored in a much more secure and restricted
fashion.
For example, a KSK private key stored on a USB flash drive that is kept
in a fireproof safe, only brought online once a year to sign a new pair of
ZSK, combined with a ZSK private key stored on the network file-system
available for routine use, maybe be a good balance between operational
flexibility and security.
And if you need to change your keys, please see
6.3.3.燞ardware Security Modules (HSM)
A Hardware Security Module (HSM) comes in different shapes and sizes,
but as the name indicates, it's a physical device or devices, usually with
some or all of the following features:
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 PKCS #11 (Public Key Cryptography Standard #11) for
communication with HSMs and other cryptographic support devices. For more
information on how to configure BIND to work with HSMs, please refer to the
BIND 9 Administrator
Reference Manual
6.4.燢ey Management
Best practice for DNSSEC key management is to use different keys to sign
zone data (ZSK) and DNSKEY data (KSK), as we've discussed in
Section�6.1.2, “Do I Need Separate ZSK and KSK?”
. Since these keys serve different
functions, their timing and methods of rollovers are also different. In
, we have broadly talked about how to
perform a generic ZSK and KSK rollover. In this section, we will discuss two
topics in more detail:
Different considerations and methods of key rollovers.
Key meta data and management
6.4.1.燢ey Rollovers
Generally speaking, ZSKs should be rolled more frequently than KSKs. In
, we described at a very high
level how to roll the ZSK every year using key pre-publication (described below),
and how to roll the KSK every five years using double DS (also described below).
Here, we show some other methods of rolling keys. To see examples of key
rolling, please refer to
. For (far)
deeper discussions and considerations on the topic of key rolling, check out
6.4.1.1.燴SK Rollover Methods
Generally speaking, the ZSK is smaller in size (compared to the KSK) for
performance, but smaller keys take less time to break, thus the ZSK should be
changed, or rolled, more frequently. 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 so the world's
recursive servers know about both keys, then stop using the old key and
generate new RRSIG using the new key. Wait at least another TTL, so the
cached old key data is expunged from world's recursive servers, before
removing the old key.
The benefit of the Pre-publication approach is it does not
dramatically increase the zone size, but 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
that was described in
Section�4.6.1, “ZSK Rollover”
Double Signature
: Publish the new ZSK and new
RRSIG, essentially double the size of the zone. Wait at least one TTL
before removing the old ZSK and old RRSIG.
The benefit of the Double Signature approach is that it is
easier to understand and execute, but suffers from increased zone size
(essentially double) during a rollover event.
6.4.1.2.燢SK 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-DS
: the new DS record is published.
After waiting for this change to propagate into caches, the KSK is
changed.
After a further interval during which the old DNSKEY RRset
expires from caches, the old DS record is removed.
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 remove
the old DS at the parent. The benefit is that the size of the DNSKEY
RRset is kept to a minimum, but interactions with the parent zone is
increased to two events. This is the method that is described in
Section�4.6.2, “KSK Rollover”
Double-KSK
: the new KSK is added to the
DNSKEY RRset which is then signed with both the old and new key.
After
waiting for the old RRset to expire from caches, the DS record in the
parent zone is changed.
After waiting a further interval for this change
to be reflected in caches, the old key is removed from the
RRset.
Basically, the new KSK is added first at the child zone and
being used to sign DNSKEY, then the DS record is changed, followed by the
removal of the old KSK. Double-KSK limits the interaction with the parent
zone to a minim, but for the duration of the rollover, the size of the
DNSKEY RRset is increased.
Double-RRset
DNSKEY RRset which is then signed with both the old and new key, and the
new DS record added to the parent zone.
After waiting a suitable
interval for the old DS and DNSKEY RRsets to expire from caches, the old
DNSKEY and DS record are removed.
Double-RRset is the fastest way to roll the KSK (shortest
rollover time), but has the drawbacks of both of the other methods: a
larger DNSKEY RRset and two interactions with the parent.
6.4.2.燢ey Management and Metadata
Section�4.3.2.4, “auto-dnssec”
, we alluded
that
is doing a lot of automation for us
so we don't have to, and we've also alluded to something called the key
timing metadata. In fact, if you looked at your key file, it likely
already has a section near the top that looks like this:
These are only two of the five metadata fields of a key. Below is
a complete list of each of the metadata fields, and how it affects your
key's behavior:
Publish
: Sets the date on which a key is
to be published to the zone. After that date, the key will be included
in the zone but will not be used to sign it (yet). This is notifying
validating resolvers that we are about to introduce a new key. By
default, if not specified during creation time, this is set to the
current time, meaning the key will be published as soon as
picks it up.
Activate
: Sets the date on which the key
is to be activated. After that date, the key will be included in the
zone and used to sign it. By default, if not specified during creation
time, this is set to the current time, meaning the key will be used to
sign data as soon as
Revoke:
Sets the date on which the key
is to be revoked. After that date, the key will be flagged as revoked.
It will be included in the zone and will be used to sign it. This is
used to notify validating resolvers that this key is about to be
removed or retired from the zone.
Inactive
is to become inactive. After that date, the key will still be included
in the zone, but it will not be used to sign it. This sets the
"expiration" or "retire" date for a key.
Delete
is to be deleted. After that date, the key will no longer be included
in the zone, but it continues to exist on the file system or key
repository.
You can set these metadata fields on a key pair as you've seen in
using commands such as
dnssec-keygen
dnssec-settime
Table�6.1.燢ey Metadata Comparison
Metadata
Included in Zone File?
Used to Sign Data?
Purpose
Yes
No
Introducing a key soon to be active
Activation date for new key
Revoke
Notifying a key soon to be retired
Inactivate or retire a key
Deletion or removal of key from zone
6.4.2.1.燤anual Key Management and Signing
This guide is intended as an introductory to DNSSEC deployment
using BIND. Since BIND comes with a set of features to automate key
loading and signing, that is the recommended configuration for readers
of this document. In this section, we will only briefly cover tools and
commands to manually load keys and manually sign zone data, but not go
into great details.
The directive
auto-dnssec maintain
makes
check for new keys and load them automatically
on an interval. If you wish to not automate this process, you could opt
to change it to
auto-dnssec off
. This makes all key
management manual, and to load new keys, you will need to execute the
command
rndc loadkeys example.com
To manually sign the zone, first, you need to edit the zone file
to make sure the proper DNSKEY entries are included in your zone file,
then use the command
dnssec-signzone
as such:
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:
Signatures dropped:
Signatures successfully verified:
Signatures unsuccessfully verified:
Signing time in seconds:
0.046
Signatures per second:
364.634
Runtime in seconds:
0.055
The -o switch explicitly defines the domain name
in this case), -f switch specifies the output
file name. The second line has 3 parameters, they are the unsigned zone
name (
/etc/bind/db/example.com.db
), ZSK, and KSK
file names. This generated a plain text file
, which you can
verify for correctness.
Finally, you'll need to update
load the signed version of the zone, so it looks something like
file "
db/example.com.signed.db
";
You will need to re-sign periodically as as well as every time
the zone data changes.
6.4.3.燞ow Long Do I Wait Before Deleting Old Data?
If you have followed the examples described in
, old keys and old signatures are
automatically removed from the zone.
However, it is still good to discuss why bother waiting a period
of time before removing any old data, be it DNSKEY or RRSIG. The goal
here is to not "orphan" anyone out there who may be getting a cached
answer, and the information to verify that cached answer doesn't exist
anymore. For example, if you chose to pre-publish your ZSK, but did not
wait long enough before removing the old ZSK, you're running with the
risk that there may be users out there receiving the old RRSIG out of
cache, but they are unable to verify the cached old RRSIG because the
old ZSK has already been removed. To these users, the domain names would
fail validation, until the cached RRSIG entries expire, and their
validating resolver retrieves the new RRSIG signed by the new
ZSK.
, we recommended
using a very generic and easy to remember 30 days as the amount of time
to wait, partly because 30 days is also the default validity time for
RRSIG. If you decide to manage your own zone signing and record
removing, you should wait at least the duration of your old record's TTL
before attempting to removing it from the zone. It is probably better to
err on the safe side and leave the old data in the zone a little
longer.
One of the worst things to happen during a rollover is to "orphan" old
keys, by deleting it too soon from the zone. This will result in the world's
recursive servers come asking "hey, do you have the key(s) for these older
signatures?" and not get an answer to satisfy their needs. The recursive
servers would have to fail the validation, and the users may think you zone
has been compromised because the keys and signatures to match up. This is why
it is a good idea to wait a period of time in-between each phase of the key
rollover, to ensure that not only new information has propogated to the
world, but also that old information that was previously published to the
world have expired from whoever has been caching them. This is why in this
document we have chosen a very conservative period of 30 days. If you have
unusually long TTL or signature expirations, it may be wise to change the
rollover schedule accordingly.
6.4.4.燛mergency Key Rollovers
Keys are generally rolled at a regular schedule (that is, if you choose
to roll them at all). But sometimes, you may have to rollover keys
out-of-schedule due to a security incident. The aim of an emergency rollover
is re-sign the zone with a new key as soon as possible, because when a key is
suspected of being compromised, the malicious attacker (or anyone who has
access to the key) could impersonate you, and trick other validating
resolvers into believing that they are receiving authentic, validated
answers.
During an emergency rollover, you would follow the same operational
procedures as described in
, with the
added task of reducing the TTL of current active (possibly compromised)
DNSKEY RRset, in attempt to phase out the compromised key faster before the
new key takes effect. The time frame should be significantly reduced from the
30-days-apart example, since you probably don't want to wait up to 60 days
for the compromised key to be removed from your zone.
Another method is to always carry a spare key with you at all times.
You could always have a second key (pre)published (and hopefully this one was
not compromised the same time as the first key), so if the active key is
compromised, you could save yourself some time to immediately activate the
spare key, and all the validating resolvers should already have this spare
key cached, thus saving you some time.
With KSK emergency rollover, you would have to also consider factors
related to your parent zone, such as how quickly they can remove the old DS
record and published the new ones.
As usual, there is a lot more to consider when it comes to emergency
key rollovers. For more in-depth considerations, please check out
6.4.5.燚NSKEY 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 must be done with care in a stepwise fashion
to avoid breaking DNSSEC validation.
As with other DNSKEY rollovers, when the zone is of type
master, an algorithm rollover can be accomplished using dynamic
updates or automatic key rollovers. For zones of type slave, only
automatic key rollovers are possible, but the
utility can be used to control
the timing of such.
In any case the first step is to put DNSKEYs using the
new algorithm in place. You must generate the
K*
files for the new algorithm and put them in the zone's key
directory where
can access them. Take
care to set appropriate ownership and permissions on the keys.
zone option is set to
will
automatically sign the zone with the new keys based on their
timing metadata when the
elapses or you issue the
rndc loadkeys
command.
Otherwise for zones of type master, you can use
nsupdate
to add the new DNSKEYs to the zone.
This will cause named to use them to sign the zone.
For zones
of type slave, e.g. on a bump-in-the-wire inline signing server,
cannot be used.
Once the zone has been signed by the new DNSKEYs, you must
inform the parent zone and any trust anchor repositories of the
new KSKs, e.g. you might place DS records in the parent zone
through your DNS registrar's website.
Before starting to remove the old algorithm from a zone,
you must allow the maximum TTL on its DS records in the parent
zone to expire. This will assure that any subsequent queries will
retrieve the new DS records for the new algorithm. After the TTL
has expired, you can remove the DS records for the old algorithm
from the parent zone and any trust anchor repositories. You must
then allow another maximum TTL interval to elapse so that the
old DS records disappear from all resolver caches.
The next step is to remove the DNSKEYs using the old
algorithm from your zone. Again this can be accomplished using
to delete the old DNSKEYs (master
zones only) or by automatic key rollover when
You can cause the automatic key rollover to take place immediately
by using the
utility to set
the
date on all keys to any time in
the past. (See
dnssec-settime -D <date/offset>
option.)
After adjusting the timing metadata, the
loadkeys
command will cause
to remove the DNSKEYs and RRSIGs for the old algorithm from the
zone. Note also that with the
method,
removing the DNSKEYs also causes
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.
6.5.燨ther Topics
6.5.1.燚NSSEC and Dynamic Updates
Dynamic DNS (DDNS) actually is independent of DNSSEC. DDNS provides a
mechanism other than editing the zone file or zone database, to edit DNS
data. Most clients and DNS servers have the capability to handle dynamic
updates, and DDNS can also be integrated as part of your DHCP
environment.
When you have both DNSSEC and dynamic updates in your environment,
updating zone data works the same way as with traditional (insecure) DNS: you
can use
rndc freeze
before editing the zone file, and
rndc thaw
when you have finished editing, or you could use
the command
to add, edit, or remove records like
> server 192.168.1.13
> update add xyz.example.com. 300 IN A 1.1.1.1
> send
> quit
The examples provided in this guide will make
automatically re-sign the zone whenever its content has changed. If you
decide to sign your own zone file manually, you will need to remember to
executed the
whenever your zone file has
been updated.
As far as system resources and performance is concerned, be mindful
that when you have a DNSSEC zone that changes frequently, every time the zone
changes, your system is executing a series of cryptographic operations to
(re)generate signatures and NSEC or NSEC3 records.
6.5.2.燚NSSEC and Inline Signing
ISC introduces the "inline-signing" option with the release of BIND
9.9, which allows
to sign zones completely
transparently.
does this by automatically creating
an internal version of the zone that is signed on the fly, and only the
signed version of the zone is presented to queries. The unsigned version of
the zone file is untouched on the file system, but not served.
This features simplifies DNSSEC deployment, below are two common
scenarios of how this feature can be used:
You administer the master server, with zone
transfers to other slave servers
: This is what most
examples in this guide describes, you have control over the master
server, you you can follow the instruction in
to generate
key pairs and modify
. A signed version
of the zone is either generated on the fly by inline-signing, and
zone transfers will take care of synchronizing the signed zone data
to all slave name servers.
You cannot easily modify the master sever
configuration, but still would like all slave servers to get DNSSEC
zones
: you can setup a "middle box" that all slave name
servers transfer data from, and your middle box gets its zone from
the master server. You do not need to modify the master name server
configuration at all, on the middle box, set it up to have inline
signing enabled, whenever your middle box receives zone transfer
(unsigned) from the master server, a signed version is generated on
the fly, and this is the version that will be transferred out to the
other slave name servers.
For more details and configuration examples on Inline Signing,
please see
6.5.3.燚NSSEC Look-aside Validation (DLV)
DNSSEC Look-aside Validation (DLV) is an extension
to the DNSSEC protocol. It was designed to assist in early DNSSEC
adoption by simplifying the configuration of recursive servers and
lessen the burden of key management for the administrators. Without DLV,
in the absence of a fully signed path from root to a zone,
administrators wishing to enable DNSSEC validation would have to
configure and maintain multiple trust anchors or managed keys in their
configuration.
DLV removes the need for manual key management by identifying a
trusted repository through which those keys can be securely retrieved by
the validating resolver when it needs them. Basically, someone else (in
this case, ISC) is performing the tedious task of trust anchor
management, and your validating resolver just needs to trust that that
someone else is doing a good job maintaining these
trust anchors for you.
To enable DLV on your validating resolver, place this line in your
configuration file and reload
dnssec-lookaside auto;
DNSSEC deployment has matured to a stage where most
top level domains are signed and more and more registrars are
DNSSEC-ready. If you are currently relying on DLV service provided
by ISC, be aware that the service will not be available forever.
ISC stopped accepting new zones into the DLV registry in July 2016
and plans to discontinue the DLV service in early 2017.
6.5.4.燚NSSEC on Private Networks
Before we discuss DNSSEC on private networks, let's clarify what
we mean by private networks. In this section, private networks really
refers to a private or internal DNS view. Most DNS products offer the
ability to have different version of DNS answers, depending on the
origin of the query. This feature is often called DNS views or split
DNS, and is most commonly implemented as an "internal" versus an
"external" setup.
For instance, your organization may have a version of
that is offered to the world, and its names
most likely resolves to publicly reachable IP addresses. You may also
have an internal version of
that is only
accessible when you are on the company's private networks or via a VPN
connection. These private networks typical fall under 10.0.0.0/8,
172.16.0.0.0/12, or 192.168.0.0.0/16 for IPv4.
So what if you want to offer DNSSEC for your internal version of
? This is actually a more involving question,
and we can only cover this topic briefly in this document.
Deploying DNSSEC in this context is possible.
Because
private networks are usually trusted, there may be less need to
worry about someone hijacking your DNS traffic. This is commonly
known as the "last mile" in DNS delivery. If you wish to deploy
DNSSEC on your private networks, here are some scenarios to
consider:
If your name server is configured as both the validating resolver and
the internal authoritative server, the answers returned to your clients
will not be validated at all. This is because the answer is coming directly
from the authoritative server, thus the Authoritative Answer
) bit is set and, by definition, it is not validated.
What
this means is, to a regular client making the query, the secure
authoritative answer looks exactly the same as the insecure authoritative
answer.
It
is
technically possible to
achieve validation and authoritative serving within a single
instance of BIND by using separate views for each, however the
details of doing so are outside the scope of this document.
There is a good example of this technique for serving a locally
validatable copy of the root zone in Appendix A of
RFC
7706
If you have two name server instances running, one acting
as the validating resolver, and one acting as the internal
authoritative name server, it is possible to actually validate
answers, provided that you have installed the trust anchor(s)
necessary for your internal zones on the validating resolver.
In this setup, the client gets back the Authenticated Data
) bit when querying against the validating
resolver.
If no trust anchors are installed, your validating
resolver will go out to root, and attempt to validate internal
answers against external authorities (and fail).
DNSSEC is designed to protect the communication between
the client and the nameserver, however there are few applications
or stub resolver libraries that take advantage of this.
can help with last mile security in a managed environment, by
deploying validating resolvers (such as BIND) on client
machines.
In addition, early efforts have concentrated on getting
DNSSEC deployed between authoritative servers and recursive
servers as that is a prerequisite for working DNSSEC between
the recursive server and the application.
These efforts also
provide a degree of protection for applications that are not
DNSSEC-aware.
6.5.5.營ntroduction to DANE
With your DNS infrastructure now secured with DNSSEC, information can
now be stored in DNS and its integrity and authenticity can be proved. One of
the new features that takes advantage of this is the DNS-Based Authentication
of Named Entities, or DANE.
Below is a list of features currently being
developed and tested by the DANE community:
Use DANE as a verification mechanism to verify SSL/TLS
certificates received over HTTPS for added security. You can see a
live demonstration here:
http://dane.verisignlabs.com/
Store self-signed X.509 certificates, bypass having to pay a
third party (such as a Certificate Authority) to sign the
certificates.
Integrate with Mail Transfer Agents (MTA) to provide seamless
email encryption.
DANE is an exciting area for DNS administrators.
If you would like
to learn more about the standards being proposed or new features being
discussed, check out the DANE working group:
https://datatracker.ietf.org/wg/dane/charter/
. You can also check
Section�7.5, “Self-signed Certificate Recipe”
6.6.燚isadvantages of DNSSEC
DNSSEC, like many things in this world, is not without its
own 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 new
concerns are still being identified and addressed by the Internet
community.
More complexity
: If you have read this far,
you probably already concluded this yourself. With additional resource
records, keys, signatures, rotations, DNSSEC adds a lot 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. In the absence of DNSSEC,
DNS was essentially "add something to the zone and forget".
With DNSSEC,
each new component - re-signing, key rollover, interaction with parent
zone, key management - adds more scope for error. It is entirely possible
that the failure to validate a name is down to errors on the part of one or
more zone operators rather than the result of a deliberate attack on the
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 late 2016, that roughly 28% of the global Internet DNS
traffic is validating
[5]
, that doesn't mean that many of the DNS zones are
actually signed. What this means is, if you signed your company's zone
today, only less than 30% of the Internet users are taking advantage of
this extra security. It gets worse: with less than 1% of the .com domains
signed, if you enabled DNSSEC validation today, it's not likely to buy you
or your users a whole lot more protection until these popular domains
names decide to sign their zones.
The last point may have more impact than you realize. Consider
this: HTTP and HTTPS traffic make up majority of the web. 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 their
own domain, or if your web page loads contents and components from
insecure domains, the end users may experience validation problems when
trying to access your web page. For example, although I may have signed
the zone
, but my web address
is actually a CNAME to
96d719dc5612761de516fc.random-cloud-provider.com
. As long
as
random-cloud-provider.com
remains an insecure DNS zone,
users cannot fully validate everything when they visit my web page and
could be redirected elsewhere by a cache poisoning attack.
Actually it cannot be verified, read
to review why this would not
work.
based on APNIC statistics at
http://stats.labs.apnic.net/dnssec/XA
Chapter�7.燫ecipes
This chapter provides step-by-step examples of some common
configurations.
7.1.營nline Signing Recipes
There are two recipes here, the first shows an example of using inline
signing on the master server, which is what we have covered in this guide thus
far; the second example shows how to setup a "bump in the wire" between the
hidden master and the slave servers to seamlessly sign the zone on the
fly.
7.1.1.燤aster Server Inline Signing Recipe
In this recipe, our servers are illustrated as shown in
Figure�7.1, “Inline Signing Recipe #1”
: we have a master server 192.168.1.1 and three
slave servers (192.168.1.2, 192.168.1.3, and 192.168.1.4) that receive zone
transfers. In order to get the zone signed, we need to reconfigure the master
server, as described in
. Once reconfigured, a
signed version of the zone is generated on the fly by inline-signing, and
zone transfers will take care of synchronizing the signed zone data to all
slave name servers, without configuration or software changes on the slave
servers.
Figure�7.1.營nline Signing Recipe #1
Below is what the
looks like on the
master server, 192.168.1.1:
allow-transfer { 192.168.1.2; 192.168.1.3; 192.168.1.4; };
On the slave servers,
does not need to
be updated, and it looks like this:
type slave;
masters { 192.168.1.1; };
In fact, the slave servers do not even need to be running BIND, it could be
running any other DNS product that has DNSSEC support.
7.1.2.�"Bump in the Wire" Inline Signing Recipe
In this recipe, we are taking advantage of the power of inline signing
by placing an additional name server 192.168.1.5 between the hidden master
(192.168.1.1) and the DNS slaves (192.168.1.2, 192.168.1.3, and 192.168.1.4).
The additional name server 192.168.1.5 acts as a "bump in the wire", taking
unsigned zone from the hidden master on one end, and sending out signed data
on the other end to the slave name servers. The steps described in this
recipe may be used as part of the DNSSEC deployment strategy, since it
requires minimal changes made to the existing hidden DNS master and DNS
slaves.
Figure�7.2.營nline Signing Scenario #2
It is important to remember that 192.168.1.1 in this case is a hidden
master not exposed to the world, it must not be listed in the NS RRset.
Otherwise the world will get conflicting answers, unsigned answers from the
hidden master, and signed answers from the other name servers.
The only configuration change needed on the hidden master 192.168.1.1 is to
make sure it allows our middle box to perform a zone transfer:
allow-transfer { 192.168.1.5; };
On the middle box 192.168.1.5, all the tasks described in
still need to be
performed, such as generating key pairs and uploading information to parent
zone. This server is configured as slave to the hidden master 192.168.1.1,
receiving the unsigned data, and then using keys accessible to this middle
box, sign data on the fly, and send out the signed data via zone transfer to
the other three DNS slaves. Its
looks like
zone example.com {
Finally, on the three slave servers, configuration should be updated to
receive zone transfer from 192.168.1.5 (middle box) instead of 192.168.1.1
(hidden master). If using BIND, the
looks
like this:
masters { 192.168.1.5; };
# this was 192.168.1.1 before!
7.2.燫ollover Recipes
7.2.1.燴SK Rollover Recipe
This recipe covers how to perform a ZSK rollover using what is known as
the Pre-Publication method. For other ZSK rolling methods, please see
Section�6.4.1.1, “ZSK Rollover Methods”
Below is the timeline for a ZSK rollover to occur on January 1st,
2017:
December 1st, 2016, a month before rollover
Add DNSKEY for new ZSK to zone
January 1st, 2017, day of rollover
February 1st, 2017
Remove old ZSK DNSKEY RRset from zone
The current active ZSK has the ID 17694 in this example. For more
information on key management (such as what inactive date is, and why 30 days
for example), please see
Section�6.4, “Key Management”
7.2.1.1.燨ne Month Before ZSK Rollover
On December 1st, 2016, a month before the planned rollover, you should
change the parameters on the current key (17694) to become inactive on
January 1st, 2017, and be deleted from the zone on February 1st, 2017, as
well as generate a successor key (51623):
dnssec-settime -I 20170101 -D 20170201 Kexample.com.+008+17694
./Kexample.com.+008+17694.key
./Kexample.com.+008+17694.private
dnssec-keygen -S Kexample.com.+008+17694
Generating key pair..++++++ ...........++++++
Kexample.com.+008+
51623
The first command gets us into the key directory
/etc/bind/keys/example.com/
, where keys
are stored.
The second
sets an inactive (-I) date
of January 1st, 2017, and a deletion (-D) date of February 1st, 2017 for the
current ZSK (Kexample.com.+008+17694).
Then the third command
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.
Don't forget to make sure the successor keys are readable by
You can see in
's logging messages informing
you when the next key checking event is scheduled to occur, the frequency of
which can be controlled by
. The log
message looks like this:
zone example.com/IN (signed): next key event: 01-Dec-2016 00:13:05.385
And you can check the publish date of the key by looking at the key
# cat Kexample.com.+008+51623.key
; This is a zone-signing key, keyid 11623, for example.com.
; Created: 20161130160024 (Mon Dec
1 00:00:24 2016)
Publish: 20161202000000 (Fri Dec
2 08:00:00 2016)
; Activate: 20170101000000 (Sun Jan
1 08:00:00 2017)
Since the publish date is set to the morning of December 2nd, 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
AwEAAcWDps...lM3NRn/G/R
) ; KSK; alg = RSASHA256; key id = 6817
AwEAAbi6Vo...qBW5+iAqNz
AwEAAcjGaU...0rzuu55If5
) ; ZSK; alg = RSASHA256; key id = 17694
20170101000000 20161201230000 6817 example.com.
LAiaJM26T7...FU9syh/TQ= )
20170101000000 20161201230000 17694 example.com.
HK4EBbbOpj...n5V6nvAkI= )
And for good measures, 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 or not
the new ZSK is in effect:
2016120102 ; serial
20161230160109 20161130150109
17694
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
everything else is automated for you.
7.2.1.2.燚ay 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 like you did a month
ago:
2016112011 ; serial
20170131000000 20161231230000
J4RMNpJPOmMidElyBugJp0RLqXoNqfvo/2AT6yAAvx9X
zZRL1cuhkRcyCSLZ9Z+zZ2y4u2lvQGrNiondaKdQCor7
uTqH5WCPoqalOCBjqU7c7vlAM27O9RD11nzPNpVQ7xPs
y5nkGqf83OXTK26IfnjU1jqiUKSzg6QR7+XpLk0= )
As you can see, the signature generated by the old ZSK (17694)
disappeared, replaced by a new signature generated from the new ZSK
(51623).
Life Time of the Signatures
Not all signatures will disappear magically on the same day,
depending on when each one is generated. Worst case scenario is that a new
signature could have been signed by the old ZSK (17695) moments before it
was deactivated, thus the signature could live for almost 30 more days, all
the way up to right before February 1st.
This is why it is important that you should keep the old ZSK in the
zone for a little bit longer and not delete it right away.
7.2.1.3.燨ne Month After ZSK Rollover
Again, technically there should be 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.
will not touch
on your file system.
Running the same
command for DNSKEY should
suffice:
dig @192.168.1.13 example.com. DNSKEY +multiline +dnssec
AwEAAdeCGr...1DnEfX+Xzn
) ; ZSK; alg = RSASHA256; key id = 51623
20170203000000 20170102230000 6817 example.com.
KHY8P0zE21...Y3szrmjAM= )
20170203000000 20170102230000 51623 example.com.
G2g3crN17h...Oe4gw6gH8= )
Congratulations, the ZSK rollover is complete! As for the actual key
files (the
files), they may be deleted at this point, but it's not required.
7.2.2.燢SK Rollover Recipe
This recipe describes how to perform KSK rollover using the Double-DS
method. For other KSK rolling methods, please see
Section�6.4.1.2, “KSK Rollover Methods”
. The registrar used in this recipe
GoDaddy
. Also for this recipe, we are keeping the number of DS records down
to just one per active set using just SHA-1, for the sake of better clarity,
although in practice most zone operators choose to upload 2 DS records as we
have shown in
. For more
Below is the timeline for a KSK rollover to occur on January 1st,
Change timer on the current KSK
Add DNSKEY for the new KSK to zone
Use the new KSK to sign all DNSKEY RRset, this generates new
RRSIGs
Remove RRSIG for the old ZSK from zone
Start using the new KSK to sign DNSKEY
Remove the old KSK DNSKEY from 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
7.2.2.1.燨ne Month Before KSK Rollover
change the parameters on the current key to become inactive on January 1st,
2017, and be deleted from the zone on February 1st, 2017, as well as
generate a successor key (23550). Finally, you should generate a new DS
record based on the new key 23550:
dnssec-settime -I 20170101 -D 20170201 Kexample.com.+007+24828
./Kexample.com.+007+24848.key
./Kexample.com.+007+24848.private
dnssec-keygen -S Kexample.com.+007+24848
Generating key pair.......................................................................................++ ...................................++
Kexample.com.+007+23550
dnssec-dsfromkey -a SHA-1 Kexample.com.+007+23550.key
example.com. IN DS 23550 7 1 54FCF030AA1C79C0088FDEC1BD1C37DAA2E70DFB
, where keys for
sets an inactive (-I)
date of January 1st, 2017, and a deletion (-D) date of February 1st, 2017
for the current KSK (Kexample.com.+007+24848).
as the current KSK. The new key pair created in our example is
Kexample.com.+007+23550.
The fourth and final command
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.
You can see in syslog the messages informing you when the next key
checking event is, and it looks like this:
cat Kexample.com.+007+23550.key
; This is a key-signing key, keyid 23550, for example.com.
; Created: 20161130160024 (Thu Dec
; Publish: 20161202000000 (Fri Dec
Since the publish date is set to the morning of December 2nd, the next morning you will notice that your zone has gained a new DNSKEY record based on your new KSK, but no corresponding RRSIG yet. Below is the abbreviated output with shortened DNSKEY and RRSIG when querying the authoritative name server, 192.168.1.13:
300 IN DNSKEY 256 3 7 (
AwEAAdYqAc...TiSlrma6Ef
) ; ZSK; alg = NSEC3RSASHA1; key id = 29747
300 IN DNSKEY 257 3 7 (
AwEAAeTJ+w...O+Zy9j0m63
) ; KSK; alg = NSEC3RSASHA1; key id = 24828
AwEAAc1BQN...Wdc0qoH21H
) ; KSK; alg = NSEC3RSASHA1; key id =
23550
300 IN RRSIG DNSKEY 7 2 300 (
20161206125617 20161107115617 24828 example.com.
4y1iPVJOrK...aC3iF9vgc= )
20161206125617 20161107115617 29747 example.com.
g/gfmPjr+y...rt/S/xjPo= )
Any time after you have generated the DS record, you could upload it,
you don't have to wait for the DNSKEY to be published in your zone, since
this new KSK is not active yet. You could choose to do it immediately after
the new DS record has been generated on December 1st, or you could wait
until the next day after you have verified that the new DNSKEY record is
added to the zone. Below are the screenshots from using GoDaddy's web-based
interface to add a new DS record.
After logging in, click the green "Launch" button next to the
domain name you want to manage.
Figure�7.3.燯pload DS Record Step #1
Scroll down to the "DS Records" section and click
Manage.
Figure�7.4.燯pload DS Record Step #2
A dialog appears, displaying the current key (24828). Click "Add
DS Record".
Figure�7.5.燯pload DS Record Step #3
Enter the Key ID, algorithm, digest type, and the digest, then
click "Next".
Figure�7.6.燯pload DS Record Step #4
Address any errors and click "Finish".
Figure�7.7.燯pload DS Record Step #5
Both DS records are shown. Click "Save".
Figure�7.8.燯pload 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 could verify whether or not 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:
example.com. 21552 IN DS 24828 7 1 D4A33E8DD550A9567B4C4971A34AD6C4B80A6AD3
example.com. 21552 IN DS
7 1 54FCF030AA1C79C0088FDEC1BD1C37DAA2E70DFB
You could 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 do not query your own name
servers for them. In this recipe, the parent zone is
, so
querying a few of the
name servers is another appropriate
verification.
7.2.2.2.燚ay of KSK Rollover
If you have followed the examples in this document as described in
, 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 like you did a month ago:
) ; KSK; alg = NSEC3RSASHA1; key id = 23550
example.com. 300 IN RRSIG DNSKEY 7 2 300 (
20170201074900 20170101064900
mydnssecgood.org.
S6zTbBTfvU...Ib5eXkbtE= )
20170105074900 20161206064900 29747 mydnssecgood.org.
VY5URQA2/d...OVKr1+KX8= )
As you can see, the signature generated by the old KSK (24828)
disappeared, replaced by a new signature generated from the new KSK
(23550).
7.2.2.3.燨ne Month After KSK Rollover
While the removal of the old DNSKEY from zone should be automated by
, 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, and this time we expect to see one less
DNSKEY, namely the key with ID of 24828:
example.com. 300 IN DNSKEY 256 3 7 (
example.com. 300 IN DNSKEY 257 3 7 (
20170208000000 20170105230000 23550 mydnssecgood.org.
Qw9Em3dDok...bNCS7KISw= )
20170208000000 20170105230000 29747 mydnssecgood.org.
OuelpIlpY9...XfsKupQgc= )
Now, we can remove the old DS record for key 24828 from our parent
zone. Be careful to remove the correct DS record. If we accidentally removed
the new DS record(s) of key ID 23550, it could lead to a problem called
"security lameness", as discussed in
Section�5.4.1, “Security Lameness”
, and may cause users unable
to resolve any names in our zone.
After logging in and launched the domain, scroll down to the "DS
Records" section and click Manage.
Figure�7.9.燫emove DS Record Step #1
A dialog appears, displaying both keys (24828 and 23550). Use the
far right hand X button to remove the key 24828.
Figure�7.10.燫emove DS Record Step #2
Key 24828 now appears crossed out, click "Save" to complete the
removal.
Figure�7.11.燫emove DS Record Step #3
Congratulations, the KSK rollover is complete! As for the actual key
7.3.燦SEC and NSEC3 Recipes
7.3.1.燤igrating from NSEC to NSEC3
This recipe describes how to go from using NSEC to NSEC3, as described
in both
Section�4.5, “Using NSEC3”
. This recipe assumes
that the zones are already signed, and
configured according to the steps described in
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
ensures that older validating resolvers that don't understand NSEC3 will
fallback to treating the zone as unsecured (rather than "bogus") as described in
Section 2 of RFC 5155
This command below enables NSEC3 for the zone
using a pseudo-random string 1234567890abcdef for its salt:
You'll know it worked if you see the following log messages:
Oct 21 13:47:21 received control channel command 'signing -nsec3param 1 0 10 1234567890abcdef example.com'
Oct 21 13:47:21 zone example.com/IN (signed): zone_addnsec3chain(1,CREATE,10,1234567890ABCDEF)
You can also verify that this worked by querying for a name you know
that does not exist, and check for the presence of the NSEC3 record, such as
dig @192.168.1.13 thereisnowaythisexists.example.com. A +dnssec +multiline
TOM10UQBL336NFAQB3P6MOO53LSVG8UI.example.com. 300 IN
NSEC3
1 0 10 1234567890ABCDEF (
TQ9QBEGA6CROHEOC8KIH1A2C06IVQ5ER
NS SOA RRSIG DNSKEY NSEC3PARAM )
Our example used four parameters: 1, 0, 10, and 1234567890ABCDEF, in
the order they appeared. 1 represents the algorithm, 0 represents the opt-out
flag, 10 represents the number of iterations, and 1234567890abcedf is the
salt. To learn more about each of these parameters, please see
Section�6.2.2.1, “NSEC3PARAM”
7.3.2.燤igrating from NSEC3 to NSEC
This recipe describes how to migrate from NSEC3 to NSEC.
Migrating from NSEC3 back to NSEC is easy, just use the
command like this:
rndc signing -nsec3param none example.com
You know that it worked if you see these messages in log:
named[14093]: received control channel command 'signing -nsec3param none example.com'
named[14093]: zone example.com/IN: zone_addnsec3chain(1,REMOVE,10,1234567890ABCDEF)
Of course, you can query for a name that you know that does not exist,
and you should no longer see any traces of NSEC3 records.
dig @192.168.1.13 reieiergiuhewhiouwe.example.com. A +dnssec +multiline
300 IN NSEC aaa.example.com. NS SOA RRSIG NSEC DNSKEY
7.3.3.燙hanging NSEC3 Salt Recipe
, we've discussed
the reasons why you may want to change your salt once in a while for better
privacy. In this recipe, we will look at what command to execute to actually
change the salt, and how to verify that it has been changed.
To change your NSEC3 salt to "fedcba0987654321", you may run the
rndc signing
command like
rndc signing -nsec3param 1 1 10 fedcba0987654321 example.com
You should see the following messages in log, assuming your old salt
was "1234567890abcdef":
named[15848]: zone example.com/IN: zone_addnsec3chain(1,REMOVE,10,1234567890ABCDEF)
named[15848]: zone example.com/IN: zone_addnsec3chain(1,CREATE|OPTOUT,10,FEDCBA0987654321)
You can of course, try to query the name server (192.168.1.13 in our
example) for a name that does not exist, and check the NSEC3 record
returned:
NSEC3 1 0 10 FEDCBA0987654321
Pseudo-Random Salt
You can use a pseudo-random source to create the salt for you. Here is
an example on Linux to create a 16-character hex string:
# rndc signing -nsec3param 1 0 10 $(head -c 300 /dev/random | sha1sum | cut -b 1-16) example.com
BIND 9.10 and newer provides the keyword
which may be used in place of the salt field for
to generate a random salt.
7.3.4.燦SEC3 Optout Recipe
This recipe discusses how to enable and disable NSEC3 opt-out, and show
the results of each action. As discussed in
, NSEC3 opt-out is a feature
that can help conserve resources on parent zones that have many delegations
that have yet been signed.
Before starting, for this recipe we will assume the zone
has the following 4 entries (for this example, it is not relevant what record
types these entries are):
ns1.example.com
ftp.example.com
web.example.com
And the zone example.com has 5 delegations to 5 sub domains, only one
of which is signed and has a valid DS RRset:
aaa.example.com, not signed
bbb.example.com, signed
ccc.example.com, not signed
ddd.example.com, not signed
eee.example.com, not signed
Before enabling NSEC3 opt-out, the zone
contains ten NSEC3
records, below is the list with 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.
JKMAVHL8V7EMCL8JHIEN8KBOAB0MGUK2.example.com.
FSK5TK9964BNE7BPHN0QMMD68IUDKT8I.example.com.
D65CIIG0GTRKQ26Q774DVMRCNHQO6F81.example.com.
NTQ0CQEJHM0S17POMCUSLG5IOQQEDTBJ.example.com.
TOM10UQBL336NFAQB3P6MOO53LSVG8UI.example.com.
We can enable NSEC3 opt-out with this command, changing the opt-out bit
(the second parameter of the 4) from 0 to 1 (see
to review what each parameter
is):
# rndc signing -nsec3param 1
10 1234567890abcdef example.com
After NSEC3 opt-out is enabled, the number of NSEC3 records is reduced.
Notice that the unsigned delegations
aaa
ccc
ddd
, and
eee
now don't have corresponding NSEC3
records.
To undo NSEC3 opt-out, run the same
with the opt-out bit set to 0:
NSEC3 hashes the plain text domain name, and we can compute our own
hashes using the tool
. For example, to compute
the hashed name for "www.example.com" using the parameters we listed above,
we would execute the command like this:
nsec3hash 1234567890ABCDEF 1 10 www.example.com.
NTQ0CQEJHM0S17POMCUSLG5IOQQEDTBJ (salt=1234567890ABCDEF, hash=1, iterations=10)
7.4.燫everting to Unsigned Recipe
This recipe describes how to revert from signed zone (DNSSEC) back to
unsigned (DNS).
Whether or not the world thinks your zone is signed really comes down
to the DS records hosted by your parent zone. If there are no DS records, the
world thinks your zone is not signed. So reverting to unsigned is as easy as
removing all DS records from the parent zone.
Below is an example of removing using
web-based interface to remove all DS records.
Figure�7.12.燫evert to Unsigned Step #1
Figure�7.13.燫evert to Unsigned Step #2
A dialog appears, displaying all current keys. Use the far right
hand X button to remove each key.
Figure�7.14.燫evert to Unsigned Step #3
Click Save
Figure�7.15.燫evert to Unsigned Step #4
To be on the safe side, you should wait a while before actually
deleting all signed data from your zone, just in case some validating
resolvers out there have cached information. After you are certain that all
cached information have expired (usually this means TTL has passed), you may
reconfigure your zone. This is the
when it is
signed, with DNSSEC-related configurations in bold:
allow-transfer { any; };
Remove the 3 lines so your
this, then use
to reload the zone:
Your zone is now reverted back to the traditional, insecure DNS format.
7.5.燬elf-signed Certificate Recipe
This recipe describes how to configure DNS(SEC) to include a TLSA record
that acts as a different channel to provide verification for a self-signed
x509 (SSL) certificate.
TLSA is still in an early stage of deployment. One of the
road blocks that exists as of late 2016 is the lack of built-in
application support in web browsers and mail applications. As these
applications add support for TLSA, steps described in this recipe
will become more relevant and practical. Today (as of late 2016),
unfortunately, most applications lack native support and will likely
result in some kind of error message or warning even if you have
deployed TLSA correctly.
Wikipedia page for DANE
contains a
list of current applications, libraries and plugins that provide
TLSA support.
For this recipe, we are assuming that you already have a working web
server configured with a self-signed x509 certificate. Although the steps
described below works for self-signed certificates, it can also be used for
"real" certificates that were signed by a Certificate Authority (usually a
service you pay for). This is one of several possible uses of DNS-Based
Authentication of Named Entities, or DANE (we briefly talked about DANE in
).
First, let's take a look at the certificate used by you web
server:
cat server.crt
-----BEGIN CERTIFICATE-----
MIICVTCCAb4CCQChk/gPoAqkWjANBgkqhkiG9w0BAQsFADBvMQswCQYDVQQGEwJV
UzELMAkGA1UECAwCQ0ExFjAUBgNVBAcMDVNhbiBGcmFuY2lzY28xITAfBgNVBAoM
GEludGVybmV0IFdpZGdpdHMgUHR5IEx0ZDEYMBYGA1UEAwwPd3d3LmV4YW1wbGUu
Y29tMB4XDTE0MTIwODA2MDMxNFoXDTI0MTIwNTA2MDMxNFowbzELMAkGA1UEBhMC
VVMxCzAJBgNVBAgMAkNBMRYwFAYDVQQHDA1TYW4gRnJhbmNpc2NvMSEwHwYDVQQK
DBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQxGDAWBgNVBAMMD3d3dy5leGFtcGxl
LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzovVMAexPZHg8MaL2xfE
IfwPKxCdcCzF2eEvl3euIk2esQ0r3GE+xEVqf/lggCC0OH0q6TXs+6XFYvc4+O/m
LEh6DFnfn8Kz3T0d6mG2l8YuhhkLLrwugvvaAcHqMoVeZRPqFLhlfaUsoGxb+CPs
3B8xYFisUqNJp6Tr26MhSVECAwEAATANBgkqhkiG9w0BAQsFAAOBgQC7lQbdSkaM
x8B6RIs+PMOZ14RlA1UcPNUPPAK0vK23/ie1SfxSHIw6PlOba+ZQZusrDRYooR3B
viM+cUnhD5UvhU4bn3ZP0cp+WNsimycf/gdfkAe47Em1oVNZP6abUgqMPStongIB
7uonP6j74A/BTF5kdUsaDPoDfvGnCjZMsQ==
-----END CERTIFICATE-----
Next, use
openssl
to generate a SHA-256 fingerprint
of this certificate, this is what you will list in DNS as a TLSA record. Also,
you need to remove all the colons, hence the added
sed
at
the end to filter out all ":" characters:
openssl x509 -noout -fingerprint -sha256 < server.crt | tr -d :
SHA256 Fingerprint=294874DA378148CDD1B9C57D2E891E8C294D2958F0BCA7400A0D6D6F50C4A3BB
Now you can insert the TLSA record by editing the zone file the old
fashioned way, or if your DNS server is allowing dynamic updates, you could
like this to inject the TLSA record:
> server localhost
> update add _443._tcp.www.example.com. 3600 IN TLSA 3 0 1 294874DA378148CDD1B9C57D2E891E8C294D2958F0BCA7400A0D6D6F50C4A3BB
Let's talks briefly about the record you just added. The name is a
specifically formed "_443._tcp.www.example.com", which specifies the usage of
TCP port 443, for the name "www.example.com". It is followed by three parameters,
each representing usage, selector, and matching type. For this recipe, we will
not dissect into all the possible combinations of these parameters. The
examples listed here are 3, 0, and 1, which represent:
Usage: 3 = self-signed certificate
Selector 0 = full certificate is included
Matching Type 1 = SHA-256
If you are interested in learning (a lot) more about the TLSA record type,
check out
Assuming you have successfully added the new TLSA record and generated
the appropriate signature(s), now you can query for it:
dig _443._tcp.www.example.com. TLSA
_443._tcp.www.example.com. 3600 IN TLSA 3 0 1 294874DA378148CDD1B9C57D2E891E8C294D2958F0BCA7400A0D6D6F 50C4A3BB
Great! But that's still only half of the equation. We still need to make
your web browser utilize this new information. For this recipe, we are showing
you results of using Firefox with a plugin called DNSSEC TLSA Validator from
https://www.dnssec-validator.cz
Once the plugin is installed, activated, and Firefox restarted, when you
visit the URL https://www.example.com, your browser will prompt you for a
warning, because this is a self-signed certificate:
Figure�7.16.燘rowser Certificate Warning
Although the certificate is not trusted by the browser itself (if you
want to you'll have to install a custom CA root or make the browser trust the
certificate individually), the plugin shows that it was able to verify the
information it received via HTTPS (port 443), and that it matches the
information it received via TLSA lookup over DNS (port 53).
Figure�7.17.燚NSSEC TLSA Validator
Chapter�8.燙ommonly Asked Questions
No questions are too stupid to ask, below is a collection of such questions and answers.
Q:
Do I need IPv6 to have DNSSEC?
Does DNSSEC encrypt my DNS traffic, so others cannot
eavesdrop on my DNS queries?
Does DNSSEC protect the communication between my laptop and
my name server?
Does DNSSEC secure zone transfers?
Is DNSSEC going to protect me from malicious web
sites?
If I enable DNSSEC validation, will it break DNS lookup for
majority of the domain names, since most domains names don't have DNSSEC
yet?
Do I need to have special client software to use
DNSSEC?
Since DNSSEC uses public key cryptography, do I need Public
Key Infrastructure (PKI) in order to use DNSSEC?
Do I need to purchase SSL certificates from a Certificate
Authority (CA) to use DNSSEC?
My parent zone does not support DNSSEC, can I still sign my
zone?
Is DNSSEC the same thing as TSIG that I have between my
master and slave servers?
How are keys copied from master to slave
server(s)?
A:
No. DNSSEC can be deployed independent of
IPv6.
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.
Unfortunately, currently, no. DNSSEC is designed to protect
the communication between the end clients (laptop) and the name servers,
however, there are few applications or stub resolver libraries as of late
2016 that take advantage of this capability. This communication between the
recursive server to the clients are commonly called the "last mile", while
enabling DNSSEC today does little to enhance the security for the last mile,
we hope that will change in the near future as more and more applications
become DNSSEC-aware.
No. You should consider using TSIG to secure zone transfers
among your name servers.
The answer for now is, unfortunately for early stages of
DNSSEC deployment, no. DNSSEC is designed so you can have confidence that
when you received the DNS response for www.isc.org over port 53, you know it
really came from the ISC name servers, and the answers are authentic. But
that does not mean the web server you visit over port 80 or port 443 is
necessarily safe. Further more, 99% of the domain names (as of this writing)
have not signed their zones yet, so DNSSEC cannot even validate their
The answer for sometime in the future is, as more and more zones are
signed and more and more recursive servers are validating, DNSSEC will make
it much more difficult for attackers to spoof DNS responses or perform cache
poisoning. It still does not protect users from visiting a malicious web
site that the attacker owns and operates, or prevent users from mis-typing a
domain name, it just becomes unlikely that the attacker can hijack other
domain names.
No, DNSSEC is backwards compatible to "standard" DNS. As of
this writing, although 99.5% of the .com domains have yet to be signed, a
DNSSEC-enabled validating resolver can still lookup all of these domain
names following the "old fashioned way". There are four (4) categories of
responses (
RFC 4035 Sec 4.3
Secure
Domains that have DNSSEC deployed correctly
Insecure
Domains that have yet to deploy DNSSEC
Bogus
Domains that deployed DNSSEC but did it incorrectly
Indeterminate
Unable to determine whether or not to use DNSSEC
A validating resolver will still resolve #1 and #2, only #3 and #4
will result in a SERVFAIL.You may already be using DNSSEC validation without
realizing it, since some ISP's have begun enabling DNSSEC validation on
their recursive name servers. Google public DNS (8.8.8.8) also has enabled
DNSSEC validation.
The short answer is no, DNSSEC only changes the communication
behavior among DNS servers, not DNS server (validating resolver) and client
(stub resolver). With DNSSEC validation enabled on your recursive server, if
a domain name doesn't pass the checks, an error message (typically SERVFAIL)
is returned to the clients, and to most client software today, it looks as
if the DNS query has failed, or the domain name does not exist.
The longer answer is although you don't have to, you may want to.
There are more and more client softwares that take advantage of the new
DNSSEC features and give user better feedback about the domain name they are
visiting. CZ.NIC Labs has created a plugin for several popular web
browsers, and Mozilla has created a new web browser Bloodhound that performs
As DNSSEC deployment becomes more common place, we are sure to see
more and more software libraries and applications be updated to support its
features.
No.
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.
Technically, yes, you can sign your zone, but you wouldn't be
getting the full benefit of DNSSEC, as other validating resolvers would not
be able to validate your zone data. Without the DS record(s) in your parent
zone, other validating resolvers will treat your zone as an insecure
(traditional) zone, thus no actual verification is carried out. The end
result is, 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 DS
record(s) for you, effectively telling the rest of the world that your zone
is signed.
An interim solution is to take advantage of DLV (DNSSEC Look-aside
Validation), by submitting your key to a DLV registry such as
https://dlv.isc.org/
, you can still get the benefits of DNSSEC even
if your parent zone is not yet supporting it.
No. TSIG is typically used between master and slave name
servers to secure zone transfers, DNSSEC secures DNS lookup by validating
answers. Even if you enabled DNSSEC, zone transfers are still not validated,
and if you wish to secure the communication between your master and slave
name servers, you should consider setting up TSIG or similar secure
channels.
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 master to slave server(s) as part of the zone
transfer. The private keys do not, and should not be stored anywhere
else but the master server in a secured fashion. See
for more information on
key storage options and considerations.