mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-31 14:35:26 +00:00
Code Issues Releases Wiki Activity

Merge branch '606-add-the-isc-dnssec-guide-as-a-bind-9-arm-appendix' into 'main'

Browse Source 
Add the ISC DNSSEC Guide as a BIND 9 ARM appendix

Closes #606

See merge request isc-projects/bind9!4471
This commit is contained in:
Michał Kępień
2021-01-08 12:53:13 +00:00
parent b65629f7a5 f96e6a1e1d
commit 06e4004bf0
36 changed files with 6125 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
doc/arm/Makefile.am
View File

@@ -7,6 +7,7 @@ EXTRA_DIST = \
catz.rst \
configuration.rst \
dlz.rst \
dnssec-guide.rst \
dnssec.rst \
dyndb.rst \
general.rst \
@@ -23,6 +24,7 @@ EXTRA_DIST = \
requirements.rst \
security.rst \
troubleshooting.rst \
../dnssec-guide \
../misc/acl.grammar.rst \
../misc/controls.grammar.rst \
../misc/delegation-only.zoneopt.rst \

2
doc/arm/advanced.rst
View File

@@ -635,7 +635,7 @@ crypto hardware device and build the key files. Its usage is similar to
The public keys should be inserted into the zone file by including the
``.key`` files using ``$INCLUDE`` statements.
.. _dnssec_signing:
.. _dnssec_zone_signing:
Signing the Zone
~~~~~~~~~~~~~~~~

22
doc/arm/dnssec-guide.rst Normal file
View File

@@ -0,0 +1,22 @@
..
Copyright (C) Internet Systems Consortium, Inc. ("ISC")
This Source Code Form is subject to the terms of the Mozilla Public
License, v. 2.0. If a copy of the MPL was not distributed with this
file, you can obtain one at https://mozilla.org/MPL/2.0/.
See the COPYRIGHT file distributed with this work for additional
information regarding copyright ownership.
DNSSEC Guide
============
.. include:: ../dnssec-guide/preface.rst
.. include:: ../dnssec-guide/introduction.rst
.. include:: ../dnssec-guide/getting-started.rst
.. include:: ../dnssec-guide/validation.rst
.. include:: ../dnssec-guide/signing.rst
.. include:: ../dnssec-guide/troubleshooting.rst
.. include:: ../dnssec-guide/advanced-discussions.rst
.. include:: ../dnssec-guide/recipes.rst
.. include:: ../dnssec-guide/commonly-asked-questions.rst

1
doc/arm/index.rst
View File

@@ -30,6 +30,7 @@ BIND 9 Administrator Reference Manual
:maxdepth: 2
notes
dnssec-guide
history
general
manpages

1070
doc/dnssec-guide/advanced-discussions.rst Normal file
View File

File diff suppressed because it is too large Load Diff

168
doc/dnssec-guide/commonly-asked-questions.rst Normal file
View File

@@ -0,0 +1,168 @@
..
Copyright (C) Internet Systems Consortium, Inc. ("ISC")
This Source Code Form is subject to the terms of the Mozilla Public
License, v. 2.0. If a copy of the MPL was not distributed with this
file, you can obtain one at https://mozilla.org/MPL/2.0/.
See the COPYRIGHT file distributed with this work for additional
information regarding copyright ownership.
.. _dnssec_commonly_asked_questions:
Commonly Asked Questions
------------------------
No questions are too stupid to ask. Below are some common
questions you may have and (hopefully) some answers that help.
Do I need IPv6 to have DNSSEC?
No. DNSSEC can be deployed without IPv6.
Does DNSSEC encrypt my DNS traffic, so others cannot eavesdrop on my DNS queries?
No. Although cryptographic keys and digital signatures
are used in DNSSEC, they only provide authenticity and integrity, not
privacy. Someone who sniffs network traffic can still see all the DNS
queries and answers in plain text; DNSSEC just makes it very difficult
for the eavesdropper to alter or spoof the DNS responses.
Does DNSSEC protect the communication between my laptop and my name server?
Unfortunately, not at the moment. DNSSEC is designed to protect the
communication between end clients (laptop) and name servers;
however, there are few applications or stub resolver libraries as of
mid-2020 that take advantage of this capability. While enabling DNSSEC today
does little to enhance the security of communications between a recursive
server and its clients (commonly called the "last mile"), we hope that
will change in the near future as more applications become DNSSEC-aware.
Does DNSSEC secure zone transfers?
No. You should consider using TSIG to secure zone transfers among your
name servers.
Does DNSSEC protect my network from malicious websites?
The answer in the early stages of DNSSEC deployment is, unfortunately,
no. DNSSEC is designed to provide
confidence that when you receive a DNS response for www.company.com over
port 53, it really came from Company's name servers and the
answers are authentic. But that does not mean the web server a user visits
over port 80 or port 443 is necessarily safe. Furthermore, 98.5% of
domain name operators (as of this writing in mid-2020) have not yet signed
their zones, so DNSSEC cannot even validate their answers.
The answer for sometime in
the future is that, as more zones are signed and more
recursive servers validate, DNSSEC will make it much more
difficult for attackers to spoof DNS responses or perform cache
poisoning. It will still not protect against users who visit a malicious
website that an attacker owns and operates, or prevent users from
mistyping a domain name; it will just become less likely that an attacker can
hijack other domain names.
If I enable DNSSEC validation, will it break DNS lookup, since most domain names do not yet use DNSSEC?
No, DNSSEC is backwards-compatible to "standard"
DNS. As of this writing (in mid-2020), although 98.5% of the .com domains have yet to
be signed, a DNSSEC-enabled validating resolver can still look up all of
these domain names as it always has under standard DNS.
There are four (4) categories of responses (see :rfc:`4035`):
*Secure*:
Domains that have DNSSEC deployed correctly.
*Insecure*:
Domains that have yet to deploy DNSSEC.
*Bogus*:
Domains that have deployed DNSSEC but have done it incorrectly.
*Indeterminate*:
Domains for which it is not possible to determine whether these domains use DNSSEC.
A DNSSEC-enabled validating resolver still resolves #1 and #2; only #3
and #4 result in a SERVFAIL. You may already be using DNSSEC
validation without realizing it, since some ISPs have begun enabling
DNSSEC validation on their recursive name servers. Google public DNS
(8.8.8.8) also has enabled DNSSEC validation.
Do I need to have special client software to use DNSSEC?
No. DNSSEC only changes the communication
behavior among DNS servers, not between a DNS server (validating resolver) and
a client (stub resolver). With DNSSEC validation enabled on your recursive
server, if a domain name does not pass the checks, an error message
(typically SERVFAIL) is returned to clients; to most client
software today, it appears that the DNS query has failed or that the domain
name does not exist.
Since DNSSEC uses public key cryptography, do I need Public Key Infrastructure (PKI) in order to use DNSSEC?
No, DNSSEC does not depend on an existing PKI. Public keys are stored within
the DNS hierarchy; the trustworthiness of each zone is guaranteed by
its parent zone, all the way back to the root zone. A copy of the trust
anchor for the root zone is distributed with BIND 9.
Do I need to purchase SSL certificates from a Certificate Authority (CA) to use DNSSEC?
No. With DNSSEC, you generate and publish your own keys, and sign your own
data as well. There is no need to pay someone else to do it for you.
My parent zone does not support DNSSEC; can I still sign my zone?
Technically, yes, but you will not get
the full benefit of DNSSEC, as other validating resolvers are not
able to validate your zone data. Without the DS record(s) in your parent
zone, other validating resolvers treat your zone as an insecure
(traditional) zone, and no actual verification is carried out.
To the rest of the world, your zone still appears to be
insecure, and it will continue to be insecure until your parent zone can
host the DS record(s) for you and tell the rest of the world
that your zone is signed.
Is DNSSEC the same thing as TSIG?
No. TSIG is typically used
between primary and secondary name servers to secure zone transfers,
while DNSSEC secures DNS lookup by validating answers. Even if you enable
DNSSEC, zone transfers are still not validated; to
secure the communication between your primary and secondary name
servers, consider setting up TSIG or similar secure channels.
How are keys copied from primary to secondary server(s)?
DNSSEC uses public cryptography, which results in two types of keys: public and
private. The public keys are part of the zone data, stored as DNSKEY
record types. Thus the public keys are synchronized from primary to
secondary server(s) as part of the zone transfer. The private keys are
not, and should not be, stored anywhere other than secured on the primary server.
See :ref:`advanced_discussions_key_storage` for
more information on key storage options and considerations.
Can I use the same key for multiple zones?
Yes and no. Good security practice
suggests that you should use unique key pairs for each zone, just as
you should have different passwords for your email account, social
media login, and online banking credentials. On a technical level, it
is completely feasible to reuse a key, but multiple zones are at risk if one key
pair is compromised. However, if you have hundreds or thousands
of zones to administer, a single key pair for all might be
less error-prone to manage. You may choose to use the same approach as
with password management: use unique passwords for your bank accounts and
shopping sites, but use a standard password for your not-very-important
logins. First, categorize your zones: high-value zones (or zones that have
specific key rollover requirements) get their own key pairs, while other,
more "generic" zones can use a single key pair for easier management. Note that
at present (mid-2020), fully automatic signing (using the ``dnssec-policy``
clause in your ``named`` configuration file) does not support reuse of keys
except when the same zone appears in multiple views (see next question).
To use the same key for multiple zones, sign your
zones using semi-automatic signing. Each zone wishing to use the key
should point to the same key directory.
How do I sign the different instances of a zone that appears in multiple views?
Add a ``dnssec-policy`` statement to each ``zone`` definition in the
configuration file. To avoid problems when a single computer accesses
different instances of the zone while information is still in its cache
(e.g., a laptop moving from your office to a customer site), you
should sign all instances with the same key. This means setting the
same DNSSEC policy for all instances of the zone, and making sure that the
key directory is the same for all instances of the zone.
Will there be any problems if I change the DNSSEC policy for a zone?
If you are using fully automatic signing, no. Just change the parameters in the
``dnssec-policy`` statement and reload the configuration file. ``named``
makes a smooth transition to the new policy, ensuring that your zone
remains valid at all times.

236
doc/dnssec-guide/getting-started.rst Normal file
View File

@@ -0,0 +1,236 @@
..
Copyright (C) Internet Systems Consortium, Inc. ("ISC")
This Source Code Form is subject to the terms of the Mozilla Public
License, v. 2.0. If a copy of the MPL was not distributed with this
file, you can obtain one at https://mozilla.org/MPL/2.0/.
See the COPYRIGHT file distributed with this work for additional
information regarding copyright ownership.
.. _getting_started:
Getting Started
---------------
.. _software_requirements:
Software Requirements
~~~~~~~~~~~~~~~~~~~~~
.. _bind_version:
BIND Version
^^^^^^^^^^^^
Most configuration examples given in this document require BIND version
9.16.0 or newer (although many do work with all versions of BIND
later than 9.9). To check the version of ``named`` you have installed,
use the ``-v`` switch as shown below:
::
# named -v
BIND 9.16.0 (Stable Release) <id:6270e602ea>
Some configuration examples are added in BIND version 9.17 and backported
to 9.16. For example, NSEC3 configuration requires BIND version 9.16.9.
We recommend you run the latest stable version to get the most complete
DNSSEC configuration, as well as the latest security fixes.
.. _dnssec_support_in_bind:
DNSSEC Support in BIND
^^^^^^^^^^^^^^^^^^^^^^
All versions of BIND 9 since BIND 9.7 can support DNSSEC, as currently
deployed in the global DNS, so the BIND software you are running most
likely already supports DNSSEC. Run the command ``named -V``
to see what flags it was built with. If it was built with OpenSSL
(``--with-openssl``), then it supports DNSSEC. Below is an example
of the output from running ``named -V``:
::
$ named -V
BIND 9.16.0 (Stable Release) <id:6270e602ea>
running on Linux x86_64 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u4 (2019-07-19)
built by make with defaults
compiled by GCC 6.3.0 20170516
compiled with OpenSSL version: OpenSSL 1.1.0l 10 Sep 2019
linked to OpenSSL version: OpenSSL 1.1.0l 10 Sep 2019
compiled with libxml2 version: 2.9.4
linked to libxml2 version: 20904
compiled with json-c version: 0.12.1
linked to json-c version: 0.12.1
compiled with zlib version: 1.2.8
linked to zlib version: 1.2.8
threads support is enabled
default paths:
named configuration: /usr/local/etc/named.conf
rndc configuration: /usr/local/etc/rndc.conf
DNSSEC root key: /usr/local/etc/bind.keys
nsupdate session key: /usr/local/var/run/named/session.key
named PID file: /usr/local/var/run/named/named.pid
named lock file: /usr/local/var/run/named/named.lock
If the BIND 9 software you have does not support DNSSEC, you should
upgrade it. (It has not been possible to build BIND without DNSSEC
support since BIND 9.13, released in 2018.) As well as missing out on
DNSSEC support, you are also missing a number of security fixes
made to the software in recent years.
.. _system_entropy:
System Entropy
^^^^^^^^^^^^^^
To deploy DNSSEC to your authoritative server, you
need to generate cryptographic keys. The amount of time it takes to
generate the keys depends on the source of randomness, or entropy, on
your systems. On some systems (especially virtual machines) with
insufficient entropy, it may take much longer than one cares to wait to
generate keys.
There are software packages, such as ``haveged`` for Linux, that
provide additional entropy for a system. Once installed, they
significantly reduce the time needed to generate keys.
The more entropy there is, the better pseudo-random numbers you get, and
the stronger the keys that are generated. If you want or need high-quality random
numbers, take a look at :ref:`hardware_security_modules` for some of
the hardware-based solutions.
.. _hardware_requirements:
Hardware Requirements
~~~~~~~~~~~~~~~~~~~~~
.. _recursive_server_hardware:
Recursive Server Hardware
^^^^^^^^^^^^^^^^^^^^^^^^^
Enabling DNSSEC validation on a recursive server makes it a *validating
resolver*. The job of a validating resolver is to fetch additional
information that can be used to computationally verify the answer set.
Below are the areas that should be considered for possible hardware
enhancement for a validating resolver:
1. *CPU*: a validating resolver executes cryptographic functions on many
of the answers returned, which usually leads to increased CPU usage,
unless your recursive server has built-in hardware to perform
cryptographic computations.
2. *System memory*: DNSSEC leads to larger answer sets and occupies
more memory space.
3. *Network interfaces*: although DNSSEC does increase the amount of DNS
traffic overall, it is unlikely that you need to upgrade your network
interface card (NIC) on the name server unless you have some truly
outdated hardware.
One factor to consider is the destinations of your current DNS
traffic. If your current users spend a lot of time visiting ``.gov``
websites, you should expect a jump in all of the above
categories when validation is enabled, because ``.gov`` is more than 90%
signed. This means that more than 90% of the time, your validating resolver
will be doing what is described in
:ref:`how_does_dnssec_change_dns_lookup`. However, if your users
only care about resources in the ``.com`` domain, which, as of mid-2020,
is under 1.5% signed [#]_, your recursive name server is unlikely
to experience a significant load increase after enabling DNSSEC
validation.
.. _authoritative_server_hardware:
Authoritative Server Hardware
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
On the authoritative server side, DNSSEC is enabled on a zone-by-zone
basis. When a zone is DNSSEC-enabled, it is also known as "signed."
Below are the areas to consider for possible hardware
enhancements for an authoritative server with signed zones:
1. *CPU*: a DNSSEC-signed zone requires periodic re-signing, which is a
cryptographic function that is CPU-intensive. If your DNS zone is
dynamic or changes frequently, that also adds to higher CPU loads.
2. *System storage*: A signed zone is definitely larger than an unsigned
zone. How much larger? See
:ref:`your_zone_before_and_after_dnssec` for a comparison
example. Roughly speaking, you should expect your zone file to grow by at
least three times, and frequently more.
3. *System memory*: Larger DNS zone files take up not only more storage
space on the file system, but also more space when they are loaded
into system memory.
4. *Network interfaces*: While your authoritative name servers will
begin sending back larger responses, it is unlikely that you need to
upgrade your network interface card (NIC) on the name server unless
you have some truly outdated hardware.
One factor to consider, but over which you really have no control, is
the number of users who query your domain name who themselves have DNSSEC enabled. It was
estimated in late 2014 that roughly 10% to 15% of the Internet DNS
queries were DNSSEC-aware. Estimates by `APNIC <https://www.apnic.net/>`__
suggest that in 2020 about `one-third <https://stats.labs.apnic.net/dnssec>`__ of all queries are
validating queries, although the percentage varies widely on a
per-country basis. This means that more DNS queries for your domain will
take advantage of the additional security features, which will result in
increased system load and possibly network traffic.
.. [#]
https://rick.eng.br/dnssecstat
.. _network_requirements:
Network Requirements
~~~~~~~~~~~~~~~~~~~~
From a network perspective, DNS and DNSSEC packets are very similar;
DNSSEC packets are just bigger, which means DNS is more likely to use
TCP. You should test for the following two items to make sure your
network is ready for DNSSEC:
1. *DNS over TCP*: Verify network connectivity over TCP port 53, which
may mean updating firewall policies or Access Control Lists (ACL) on
routers. See :ref:`dns_uses_tcp` for more details.
2. *Large UDP packets*: Some network equipment, such as firewalls, may
make assumptions about the size of DNS UDP packets and incorrectly
reject DNS traffic that appears "too big." Verify that the
responses your name server generates are being seen by the rest of the
world: see :ref:`whats_edns0_all_about` for more details.
.. _operational_requirements:
Operational Requirements
~~~~~~~~~~~~~~~~~~~~~~~~
.. _parent_zone:
Parent Zone
^^^^^^^^^^^
Before starting your DNSSEC deployment, check with your parent zone
administrators to make sure they support DNSSEC. This may or may not be
the same entity as your registrar. As you will see later in
:ref:`working_with_parent_zone`, a crucial step in DNSSEC deployment
is establishing the parent-child trust relationship. If your parent zone
does not yet support DNSSEC, contact that administrator to voice your concerns.
.. _security_requirements:
Security Requirements
^^^^^^^^^^^^^^^^^^^^^
Some organizations may be subject to stricter security requirements than
others. Check to see if your organization requires stronger
cryptographic keys be generated and stored, and how often keys need to be
rotated. The examples presented in this document are not intended for
high-value zones. We cover some of these security considerations in
:ref:`dnssec_advanced_discussions`.

BIN
doc/dnssec-guide/img/add-ds-1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 284 KiB

BIN
doc/dnssec-guide/img/add-ds-2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 91 KiB

BIN
doc/dnssec-guide/img/add-ds-3.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 48 KiB

BIN
doc/dnssec-guide/img/add-ds-4.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 85 KiB

BIN
doc/dnssec-guide/img/add-ds-5.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 47 KiB

BIN
doc/dnssec-guide/img/add-ds-6.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 69 KiB

BIN
doc/dnssec-guide/img/dnssec-12-steps.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 90 KiB

BIN
doc/dnssec-guide/img/dnssec-8-steps.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 81 KiB

BIN
doc/dnssec-guide/img/dnssec-inline-signing-1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 116 KiB

BIN
doc/dnssec-guide/img/dnssec-inline-signing-2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 135 KiB

BIN
doc/dnssec-guide/img/dnsviz-example-small.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 114 KiB

BIN
doc/dnssec-guide/img/remove-ds-1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 84 KiB

BIN
doc/dnssec-guide/img/remove-ds-2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 57 KiB

BIN
doc/dnssec-guide/img/remove-ds-3.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 61 KiB

BIN
doc/dnssec-guide/img/signature-generation.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 20 KiB

BIN
doc/dnssec-guide/img/signature-verification.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 32 KiB

BIN
doc/dnssec-guide/img/unsign-1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 212 KiB

BIN
doc/dnssec-guide/img/unsign-2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 84 KiB

BIN
doc/dnssec-guide/img/unsign-3.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 69 KiB

BIN
doc/dnssec-guide/img/unsign-4.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 62 KiB

BIN
doc/dnssec-guide/img/verisign-dnssec-debugger-example.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 69 KiB

393
doc/dnssec-guide/introduction.rst Normal file
View File

@@ -0,0 +1,393 @@
..
Copyright (C) Internet Systems Consortium, Inc. ("ISC")
This Source Code Form is subject to the terms of the Mozilla Public
License, v. 2.0. If a copy of the MPL was not distributed with this
file, you can obtain one at https://mozilla.org/MPL/2.0/.
See the COPYRIGHT file distributed with this work for additional
information regarding copyright ownership.
.. _dnssec_guide_introduction:
Introduction
------------
.. _who_should_read:
Who Should Read this Guide?
~~~~~~~~~~~~~~~~~~~~~~~~~~~
This guide is intended as an introduction to DNSSEC for the DNS
administrator who is already comfortable working with the existing BIND and DNS
infrastructure. He or she might be curious about DNSSEC, but may not have had the
time to investigate DNSSEC, to learn whether DNSSEC should
be a part of his or her environment, and understand what it means to deploy it in the
field.
This guide provides basic information on how to configure DNSSEC using
BIND 9.16.0 or later. Most of the information and examples in this guide also
apply to versions of BIND later than 9.9.0, but some of the key features described here
were only introduced in version 9.16.0. Readers are assumed to have basic
working knowledge of the Domain Name System (DNS) and related network
infrastructure, such as concepts of TCP/IP. In-depth knowledge of DNS and
TCP/IP is not required. The guide assumes no prior knowledge of DNSSEC or
related technology such as public key cryptography.
.. _who_should_not_read:
Who May Not Want to Read this Guide?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you are already operating a DNSSEC-signed zone, you may not learn
much from the first half of this document, and you may want to start with
:ref:`dnssec_advanced_discussions`. If you want to
learn about details of the protocol extension, such as data fields and flags,
or the new record types, this document can help you get started but it
does not include all the technical details.
If you are experienced in DNSSEC, you
may find some of the concepts in this document to be overly simplified for
your taste, and some details are intentionally omitted at times for ease of
illustration.
If you administer a large or complex BIND environment, this
guide may not provide enough information for you, as it is intended to provide
only basic, generic working examples.
If you are a top-level domain (TLD) operator, or
administer zones under signed TLDs, this guide can
help you get started, but it does not provide enough details to serve all of your
needs.
If your DNS environment uses DNS products other than (or in addition to)
BIND, this document may provide some background or overlapping information, but you
should check each product's vendor documentation for specifics.
Finally, deploying
DNSSEC on internal or private networks is not covered in this document, with the
exception of a brief discussion in :ref:`dnssec_on_private_networks`.
.. _what_is_dnssec:
What is DNSSEC?
~~~~~~~~~~~~~~~
The Domain Name System (DNS) was designed in a day and age when the
Internet was a friendly and trusting place. The protocol itself provides
little protection against malicious or forged answers. DNS Security
Extensions (DNSSEC) addresses this need, by adding digital signatures
into DNS data so that each DNS response can be verified for integrity
(the answer did not change during transit) and authenticity (the data
came from the true source, not an impostor). In the ideal world, when
DNSSEC is fully deployed, every single DNS answer can be validated and
trusted.
DNSSEC does not provide a secure tunnel; it does not encrypt or hide DNS
data. It operates independently of an existing Public Key Infrastructure
(PKI). It does not need SSL certificates or shared secrets. It was
designed with backwards compatibility in mind, and can be deployed
without impacting "old" unsecured domain names.
DNSSEC is deployed on the three major components of the DNS
infrastructure:
- *Recursive Servers*: People use recursive servers to lookup external
domain names such as ``www.example.com``. Operators of recursive servers
need to enable DNSSEC validation. With validation enabled, recursive
servers carry out additional tasks on each DNS response they
receive to ensure its authenticity.
- *Authoritative Servers*: People who publish DNS data on their name
servers need to sign that data. This entails creating additional
resource records, and publishing them to parent domains where
necessary. With DNSSEC enabled, authoritative servers respond to
queries with additional DNS data, such as digital signatures and
keys, in addition to the standard answers.
- *Applications*: This component lives on every client machine, from web
servers to smart phones. This includes resolver libraries on different
operating systems, and applications such as web browsers.
In this guide, we focus on the first two components, Recursive
Servers and Authoritative Servers, and only lightly touch on the third
component. We look at how DNSSEC works, how to configure a
validating resolver, how to sign DNS zone data, and other operational
tasks and considerations.
.. _what_does_dnssec_add_to_dns:
What Does DNSSEC Add to DNS?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. note::
Public Key Cryptography works on the concept of a pair of keys: one
made available to the world publicly, and one kept in secrecy
privately. Not surprisingly, they are known as a public key and a private
key. If you are not familiar with the concept, think of it as a
cleverly designed lock, where one key locks and one key unlocks. In
DNSSEC, we give out the unlocking public key to the rest of the
world, while keeping the locking key private. To learn how this is
used to secure DNS messages, see :ref:`how_are_answers_verified`.
DNSSEC introduces eight new resource record types:
- RRSIG (digital resource record signature)
- DNSKEY (public key)
- DS (parent-child)
- NSEC (proof of nonexistence)
- NSEC3 (proof of nonexistence)
- NSEC3PARAM (proof of nonexistence)
- CDS (child-parent signaling)
- CDNSKEY (child-parent signaling)
This guide does not go deep into the anatomy of each resource record
type; the details are left for the reader to research and explore.
Below is a short introduction on each of the new record types:
- *RRSIG*: With DNSSEC enabled, just about every DNS answer (A, PTR,
MX, SOA, DNSKEY, etc.) comes with at least one resource
record signature, or RRSIG. These signatures are used by recursive name
servers, also known as validating resolvers, to verify the answers
received. To learn how digital signatures are generated and used, see
:ref:`how_are_answers_verified`.
- *DNSKEY*: DNSSEC relies on public-key cryptography for data
authenticity and integrity. There are several keys used in DNSSEC,
some private, some public. The public keys are published to the world
as part of the zone data, and they are stored in the DNSKEY record
type.
In general, keys in DNSSEC are used for one or both of the following
roles: as a Zone Signing Key (ZSK), used to protect all zone data; or
as a Key Signing Key (KSK), used to protect the zone's keys. A key
that is used for both roles is referred to as a Combined Signing Key
(CSK). We talk about keys in more detail in
:ref:`advanced_discussions_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
:ref:`chain_of_trust`.
- *NSEC, NSEC3, NSEC3PARAM*: These resource records all deal with a
very interesting problem: proving that something does not exist. We
look at these record types in more detail in
:ref:`advanced_discussions_proof_of_nonexistence`.
- *CDS, CDNSKEY*: The CDS and CDNSKEY resource records apply to
operational matters and are a way to signal to the parent zone that
the DS records it holds for the child zone should be updated. This is
covered in more detail in :ref:`cds_cdnskey`.
.. _how_does_dnssec_change_dns_lookup:
How Does DNSSEC Change DNS Lookup?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Traditional (insecure) DNS lookup is simple: a recursive name server
receives a query from a client to lookup a name like ``www.isc.org``. The
recursive name server tracks down the authoritative name server(s)
responsible, sends the query to one of the authoritative name servers,
and waits for it to respond with the answer.
With DNSSEC validation enabled, a validating recursive name server
(a.k.a. a *validating resolver*) asks for additional resource
records in its query, hoping the remote authoritative name servers
respond with more than just the answer to the query, but some proof to
go along with the answer as well. If DNSSEC responses are received, the
validating resolver performs cryptographic computation to verify the
authenticity (the origin of the data) and integrity (that the data was not altered
during transit) of the answers, and even asks the parent zone as part of
the verification. It repeats this process of get-key, validate,
ask-parent, and its parent, and its parent, all the way until
the validating resolver reaches a key that it trusts. In the ideal,
fully deployed world of DNSSEC, all validating resolvers only need to
trust one key: the root key.
.. _dnssec_12_steps:
The 12-Step DNSSEC Validation Process (Simplified)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The following example shows the 12 steps of the DNSSEC validating process
at a very high level, looking up the name ``www.isc.org`` :
.. figure:: ../dnssec-guide/img/dnssec-12-steps.png
:alt: DNSSEC Validation 12 Steps
1. Upon receiving a DNS query from a client to resolve ``www.isc.org``,
the validating resolver follows standard DNS protocol to track down
the name server for ``isc.org``, and sends it a DNS query to ask for the
A record of ``www.isc.org``. But since this is a DNSSEC-enabled
resolver, the outgoing query has a bit set indicating it wants
DNSSEC answers, hoping the name server that receives it is DNSSEC-enabled
and can honor this secure request.
2. The ``isc.org`` name server is DNSSEC-enabled, so it responds with both
the answer (in this case, an A record) and a digital signature for
verification purposes.
3. The validating resolver requires cryptographic keys to be able to verify the
digital signature, so it asks the ``isc.org`` name server for those keys.
4. The ``isc.org`` 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 can our server trust this answer? If a clever attacker had taken over
the ``isc.org`` 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 ``isc.org`` name server. This
is a critical part of DNSSEC: at some point, the DNS administrators
at ``isc.org`` uploaded some cryptographic information to its
parent, ``.org``, maybe through a secure web form, maybe
through an email exchange, or perhaps in person. In
any event, at some point some verifiable information about the
child (``isc.org``) was sent to the parent (``.org``) for
safekeeping.
5. The validating resolver asks the parent (``.org``) for the
verifiable information it keeps on its child, ``isc.org``.
6. Verifiable information is sent from the ``.org`` server. At this
point, the validating resolver compares this to the answer it received
in #4; if the two of them match, it proves the authenticity of
``isc.org``.
Let's examine this process. You might be thinking to yourself,
what if the clever attacker that took over ``isc.org`` also
compromised the ``.org`` servers? Of course all this information
would match! That's why we turn our attention now to the
``.org`` server, interrogate it for its cryptographic keys, and
move one level up to ``.org``'s parent, root.
7. The validating resolver asks the ``.org`` authoritative name server for
its cryptographic keys, to verify the answers received in #6.
8. The ``.org`` name server responds with the answer (in this case,
keys and signatures). At this point, the validating resolver can
verify the answers received in #6.
9. The validating resolver asks root (``.org``'s parent) for the verifiable
information it keeps on its child, ``.org``.
10. The root name server sends back the verifiable information it keeps
on ``.org``. The validating resolver uses this information
to verify the answers received in #8.
So at this point, both ``isc.org`` and ``.org`` 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.
11. The validating resolver asks the root name server for its cryptographic
keys to verify the answer(s) received in #10.
12. The root name server sends its keys; at this point, the validating
resolver can verify the answer(s) received in #10.
.. _chain_of_trust:
Chain of Trust
^^^^^^^^^^^^^^
But what about the root server itself? Who do we go to verify root's
keys? There's no parent zone for root. In security, you have to trust
someone, and in the perfectly protected world of DNSSEC (we talk later
about the current imperfect state and ways to work around it),
each validating resolver would only have to trust one entity, that is,
the root name server. The validating resolver already has the root key
on file (we discuss later how we got the root key file). So
after the answer in #12 is received, the validating resolver compares it
to the key it already has on file. Providing one of the keys in the
answer matches the one on file, we can trust the answer from root. Thus
we can trust ``.org``, and thus we can trust ``isc.org``. This is known
as the "chain of trust" in DNSSEC.
We revisit this 12-step process again later in
:ref:`how_does_dnssec_change_dns_lookup_revisited` with more
technical details.
.. _why_is_dnssec_important:
Why is DNSSEC Important? (Why Should I Care?)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You might be thinking to yourself: all this DNSSEC stuff sounds
wonderful, but why should I care? Below are some reasons why you may
want to consider deploying DNSSEC:
1. *Being a good netizen*: By enabling DNSSEC validation (as described in
:ref:`dnssec_validation`) on your DNS servers, you're protecting
your users and yourself a little more by checking answers returned to
you; by signing your zones (as described in
:ref:`dnssec_signing`), you are making it possible for other
people to verify your zone data. As more people adopt DNSSEC, the
Internet as a whole becomes more secure for everyone.
2. *Compliance*: You may not even get a say in
implementing DNSSEC, if your organization is subject to compliance
standards that mandate it. For example, the US government set a
deadline in 2008 to have all ``.gov`` subdomains signed by
December 2009 [#]_. So if you operate a subdomain in ``.gov``, you
must implement DNSSEC to be compliant. ICANN also requires
that all new top-level domains support DNSSEC.
3. *Enhanced Security*: Okay, so the big lofty goal of "let's be good"
doesn't appeal to you, and you don't have any compliance standards to
worry about. Here is a more practical reason why you should consider
DNSSEC: in the event of a DNS-based security breach, such as cache
poisoning or domain hijacking, after all the financial and brand
damage done to your domain name, you might be placed under scrutiny
for any preventive measure that could have been put in place. Think
of this like having your website only available via HTTP but not
HTTPS.
4. *New Features*: DNSSEC brings not only enhanced security, but also
a whole new suite of features. Once DNS
can be trusted completely, it becomes possible to publish SSL
certificates in DNS, or PGP keys for fully automatic cross-platform
email encryption, or SSH fingerprints.... New features are still
being developed, but they all rely on a trustworthy DNS
infrastructure. To take a peek at these next-generation DNS features,
check out :ref:`introduction_to_dane`.
.. [#]
The Office of Management and Budget (OMB) for the US government
published `a memo in
2008 <https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/memoranda/2008/m08-23.pdf>`__,
requesting all ``.gov`` subdomains to be DNSSEC-signed by December
2009. This explains why ``.gov`` is the most-deployed DNSSEC domain
currently, with `around 90% of subdomains
signed. <https://fedv6-deployment.antd.nist.gov/cgi-bin/generate-gov>`__
.. _how_does_dnssec_change_my_job:
How Does DNSSEC Change My Job as a DNS Administrator?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
With this protocol extension, some of the things you were used to in DNS
have changed. As the DNS administrator, you have new maintenance
tasks to perform on a regular basis (as described in
:ref:`signing_maintenance_tasks`); when there is a DNS resolution
problem, you have new troubleshooting techniques and tools to use (as
described in :ref:`dnssec_troubleshooting`). BIND 9 tries its best to
make these things as transparent and seamless as possible. In this
guide, we try to use configuration examples that result in the least
amount of work for BIND 9 DNS administrators.

82
doc/dnssec-guide/preface.rst Normal file
View File

@@ -0,0 +1,82 @@
..
Copyright (C) Internet Systems Consortium, Inc. ("ISC")
This Source Code Form is subject to the terms of the Mozilla Public
License, v. 2.0. If a copy of the MPL was not distributed with this
file, you can obtain one at https://mozilla.org/MPL/2.0/.
See the COPYRIGHT file distributed with this work for additional
information regarding copyright ownership.
Preface
-------
.. _preface_organization:
Organization
~~~~~~~~~~~~
This document provides introductory information on how DNSSEC works, how
to configure BIND 9 to support some common DNSSEC features, and
some basic troubleshooting tips. The chapters are organized as follows:
:ref:`dnssec_guide_introduction` covers the intended audience for this
document, assumed background knowledge, and a basic introduction to the
topic of DNSSEC.
:ref:`getting_started` covers various requirements
before implementing DNSSEC, such as software versions, hardware
capacity, network requirements, and security changes.
:ref:`dnssec_validation` walks through setting up a validating
resolver, and gives both more information on the validation process and
some examples of tools to verify that the resolver is properly validating
answers.
:ref:`dnssec_signing` explains how to set up a basic signed
authoritative zone, details the relationship between a child and a parent zone,
and discusses ongoing maintenance tasks.
:ref:`dnssec_troubleshooting` provides some tips on how to analyze
and diagnose DNSSEC-related problems.
:ref:`dnssec_advanced_discussions` covers several topics, including key
generation, key storage, key management, NSEC and NSEC3, and some
disadvantages of DNSSEC.
:ref:`dnssec_recipes` provides several working examples of common DNSSEC
solutions, with step-by-step details.
:ref:`dnssec_commonly_asked_questions` lists some commonly asked
questions and answers about DNSSEC.
.. _preface_acknowledgement:
Acknowledgements
~~~~~~~~~~~~~~~~
This document was originally authored by Josh Kuo of `DeepDive
Networking <https://www.deepdivenetworking.com/>`__. He can be reached
at josh@deepdivenetworking.com.
Thanks to the following individuals (in no particular order) who have
helped in completing this document: Jeremy C. Reed, Heidi Schempf,
Stephen Morris, Jeff Osborn, Vicky Risk, Jim Martin, Evan Hunt, Mark
Andrews, Michael McNally, Kelli Blucher, Chuck Aurora, Francis Dupont,
Rob Nagy, Ray Bellis, Matthijs Mekking, and Suzanne Goldlust.
Special thanks goes to Cricket Liu and Matt Larson for their
selflessness in knowledge sharing.
Thanks to all the reviewers and contributors, including John Allen, Jim
Young, Tony Finch, Timothe Litt, and Dr. Jeffry A. Spain.
The sections on key rollover and key timing metadata borrowed heavily
from the Internet Engineering Task Force draft titled "DNSSEC Key Timing
Considerations" by S. Morris, J. Ihren, J. Dickinson, and W. Mekking,
subsequently published as :rfc:`7583`.
Icons made by `Freepik <https://www.freepik.com/>`__ and
`SimpleIcon <https://www.simpleicon.com/>`__ from
`Flaticon <https://www.flaticon.com/>`__, licensed under `Creative Commons BY
3.0 <https://creativecommons.org/licenses/by/3.0/>`__.

1098
doc/dnssec-guide/recipes.rst Normal file
View File

File diff suppressed because it is too large Load Diff

1588
doc/dnssec-guide/signing.rst Normal file
View File

File diff suppressed because it is too large Load Diff

586
doc/dnssec-guide/troubleshooting.rst Normal file
View File

@@ -0,0 +1,586 @@
..
Copyright (C) Internet Systems Consortium, Inc. ("ISC")
This Source Code Form is subject to the terms of the Mozilla Public
License, v. 2.0. If a copy of the MPL was not distributed with this
file, you can obtain one at https://mozilla.org/MPL/2.0/.
See the COPYRIGHT file distributed with this work for additional
information regarding copyright ownership.
.. _dnssec_troubleshooting:
Basic DNSSEC Troubleshooting
----------------------------
In this chapter, we cover some basic troubleshooting
techniques, some common DNSSEC symptoms, and their causes and solutions. This
is not a comprehensive "how to troubleshoot any DNS or DNSSEC problem"
guide, because that could easily be an entire book by itself.
.. _troubleshooting_query_path:
Query Path
~~~~~~~~~~
The first step in troubleshooting DNS or DNSSEC should be to
determine the query path. Whenever you are working with a DNS-related issue, it is
always a good idea to determine the exact query path to identify the
origin of the problem.
End clients, such as laptop computers or mobile phones, are configured
to talk to a recursive name server, and the recursive name server may in
turn forward requests on to other recursive name servers before arriving at the
authoritative name server. The giveaway is the presence of the
Authoritative Answer (``aa``) flag in a query response: when present, we know we are talking
to the authoritative server; when missing, we are talking to a recursive
server. The example below shows an answer to a query for
``www.example.com`` without the Authoritative Answer flag:
::
$ dig @10.53.0.3 www.example.com A
; <<>> DiG 9.16.0 <<>> @10.53.0.3 www.example.com a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62714
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: c823fe302625db5b010000005e722b504d81bb01c2227259 (good)
;; QUESTION SECTION:
;www.example.com. IN A
;; ANSWER SECTION:
www.example.com. 60 IN A 10.1.0.1
;; Query time: 3 msec
;; SERVER: 10.53.0.3#53(10.53.0.3)
;; WHEN: Wed Mar 18 14:08:16 GMT 2020
;; MSG SIZE rcvd: 88
Not only do we not see the ``aa`` flag, we see an ``ra``
flag, which indicates Recursion Available. This indicates that the
server we are talking to (10.53.0.3 in this example) is a recursive name
server: although we were able to get an answer for
``www.example.com``, we know that the answer came from somewhere else.
If we query the authoritative server directly, we get:
::
$ dig @10.53.0.2 www.example.com A
; <<>> DiG 9.16.0 <<>> @10.53.0.2 www.example.com a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39542
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
...
The ``aa`` flag tells us that we are now talking to the
authoritative name server for ``www.example.com``, and that this is not a
cached answer it obtained from some other name server; it served this
answer to us right from its own database. In fact,
the Recursion Available (``ra``) flag is not present, which means this
name server is not configured to perform recursion (at least not for
this client), so it could not have queried another name server to get
cached results.
.. _troubleshooting_visible_symptoms:
Visible DNSSEC Validation Symptoms
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
After determining the query path, it is necessary to
determine whether the problem is actually related to DNSSEC
validation. You can use the ``+cd`` flag in ``dig`` to disable
validation, as described in
:ref:`how_do_i_know_validation_problem`.
When there is indeed a DNSSEC validation problem, the visible symptoms,
unfortunately, are very limited. With DNSSEC validation enabled, if a
DNS response is not fully validated, it results in a generic
SERVFAIL message, as shown below when querying against a recursive name
server at 192.168.1.7:
::
$ dig @10.53.0.3 www.example.org. A
; <<>> DiG 9.16.0 <<>> @10.53.0.3 www.example.org A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 28947
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: d1301968aca086ad010000005e723a7113603c01916d136b (good)
;; QUESTION SECTION:
;www.example.org. IN A
;; Query time: 3 msec
;; SERVER: 10.53.0.3#53(10.53.0.3)
;; WHEN: Wed Mar 18 15:12:49 GMT 2020
;; MSG SIZE rcvd: 72
With ``delv``, a "resolution failed" message is output instead:
::
$ delv @10.53.0.3 www.example.org. A +rtrace
;; fetch: www.example.org/A
;; resolution failed: SERVFAIL
BIND 9 logging features may be useful when trying to identify
DNSSEC errors.
.. _troubleshooting_logging:
Basic Logging
~~~~~~~~~~~~~
DNSSEC validation error messages show up in ``syslog`` as a
query error by default. Here is an example of what it may look like:
::
validating www.example.org/A: no valid signature found
RRSIG failed to verify resolving 'www.example.org/A/IN': 10.53.0.2#53
Usually, this level of error logging is sufficient.
Debug logging, described in
:ref:`troubleshooting_logging_debug`, gives information on how
to get more details about why DNSSEC validation may have
failed.
.. _troubleshooting_logging_debug:
BIND DNSSEC Debug Logging
~~~~~~~~~~~~~~~~~~~~~~~~~
A word of caution: before you enable debug logging, be aware that this
may dramatically increase the load on your name servers. Enabling debug
logging is thus not recommended for production servers.
With that said, sometimes it may become necessary to temporarily enable
BIND debug logging to see more details of how and whether DNSSEC is
validating. DNSSEC-related messages are not recorded in ``syslog`` by default,
even if query log is enabled; only DNSSEC errors show up in ``syslog``.
The example below shows how to enable debug level 3 (to see full DNSSEC
validation messages) in BIND 9 and have it sent to ``syslog``:
::
logging {
channel dnssec_log {
syslog daemon;
severity debug 3;
print-category yes;
};
category dnssec { dnssec_log; };
};
The example below shows how to log DNSSEC messages to their own file
(here, ``/var/log/dnssec.log``):
::
logging {
channel dnssec_log {
file "/var/log/dnssec.log";
severity debug 3;
};
category dnssec { dnssec_log; };
};
After turning on debug logging and restarting BIND, a large
number of log messages appear in
``syslog``. The example below shows the log messages as a result of
successfully looking up and validating the domain name ``ftp.isc.org``.
::
validating ./NS: starting
validating ./NS: attempting positive response validation
validating ./DNSKEY: starting
validating ./DNSKEY: attempting positive response validation
validating ./DNSKEY: verify rdataset (keyid=20326): success
validating ./DNSKEY: marking as secure (DS)
validating ./NS: in validator_callback_dnskey
validating ./NS: keyset with trust secure
validating ./NS: resuming validate
validating ./NS: verify rdataset (keyid=33853): success
validating ./NS: marking as secure, noqname proof not needed
validating ftp.isc.org/A: starting
validating ftp.isc.org/A: attempting positive response validation
validating isc.org/DNSKEY: starting
validating isc.org/DNSKEY: attempting positive response validation
validating isc.org/DS: starting
validating isc.org/DS: attempting positive response validation
validating org/DNSKEY: starting
validating org/DNSKEY: attempting positive response validation
validating org/DS: starting
validating org/DS: attempting positive response validation
validating org/DS: keyset with trust secure
validating org/DS: verify rdataset (keyid=33853): success
validating org/DS: marking as secure, noqname proof not needed
validating org/DNSKEY: in validator_callback_ds
validating org/DNSKEY: dsset with trust secure
validating org/DNSKEY: verify rdataset (keyid=9795): success
validating org/DNSKEY: marking as secure (DS)
validating isc.org/DS: in fetch_callback_dnskey
validating isc.org/DS: keyset with trust secure
validating isc.org/DS: resuming validate
validating isc.org/DS: verify rdataset (keyid=33209): success
validating isc.org/DS: marking as secure, noqname proof not needed
validating isc.org/DNSKEY: in validator_callback_ds
validating isc.org/DNSKEY: dsset with trust secure
validating isc.org/DNSKEY: verify rdataset (keyid=7250): success
validating isc.org/DNSKEY: marking as secure (DS)
validating ftp.isc.org/A: in fetch_callback_dnskey
validating ftp.isc.org/A: keyset with trust secure
validating ftp.isc.org/A: resuming validate
validating ftp.isc.org/A: verify rdataset (keyid=27566): success
validating ftp.isc.org/A: marking as secure, noqname proof not needed
Note that these log messages indicate that the chain of trust has been
established and ``ftp.isc.org`` has been successfully validated.
If validation had failed, you would see log messages indicating errors.
We cover some of the most validation problems in the next section.
.. _troubleshooting_common_problems:
Common Problems
~~~~~~~~~~~~~~~
.. _troubleshooting_security_lameness:
Security Lameness
^^^^^^^^^^^^^^^^^
Similar to lame delegation in traditional DNS, security lameness refers to the
condition when the parent zone holds a set of DS records that point to
something that does not exist in the child zone. As a result,
the entire child zone may "disappear," having been marked as bogus by
validating resolvers.
Below is an example attempting to resolve the A record for a test domain
name ``www.example.net``. From the user's perspective, as described in
:ref:`how_do_i_know_validation_problem`, only a SERVFAIL
message is returned. On the validating resolver, we see the
following messages in ``syslog``:
::
named[126063]: validating example.net/DNSKEY: no valid signature found (DS)
named[126063]: no valid RRSIG resolving 'example.net/DNSKEY/IN': 10.53.0.2#53
named[126063]: broken trust chain resolving 'www.example.net/A/IN': 10.53.0.2#53
This gives us a hint that it is a broken trust chain issue. Let's take a
look at the DS records that are published for the zone (with the keys
shortened for ease of display):
::
$ dig @10.53.0.3 example.net. DS
; <<>> DiG 9.16.0 <<>> @10.53.0.3 example.net DS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59602
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 7026d8f7c6e77e2a010000005e735d7c9d038d061b2d24da (good)
;; QUESTION SECTION:
;example.net. IN DS
;; ANSWER SECTION:
example.net. 256 IN DS 14956 8 2 9F3CACD...D3E3A396
;; Query time: 0 msec
;; SERVER: 10.53.0.3#53(10.53.0.3)
;; WHEN: Thu Mar 19 11:54:36 GMT 2020
;; MSG SIZE rcvd: 116
Next, we query for the DNSKEY and RRSIG of ``example.net`` to see if
there's anything wrong. Since we are having trouble validating, we
can use the ``+cd`` option to temporarily disable checking and return
results, even though they do not pass the validation tests. The
``+multiline`` option tells ``dig`` to print the type, algorithm type,
and key id for DNSKEY records. Again,
some long strings are shortened for ease of display:
::
$ dig @10.53.0.3 example.net. DNSKEY +dnssec +cd +multiline
; <<>> DiG 9.16.0 <<>> @10.53.0.3 example.net DNSKEY +cd +multiline +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42980
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 4b5e7c88b3680c35010000005e73722057551f9f8be1990e (good)
;; QUESTION SECTION:
;example.net. IN DNSKEY
;; ANSWER SECTION:
example.net. 287 IN DNSKEY 256 3 8 (
AwEAAbu3NX...ADU/D7xjFFDu+8WRIn
) ; ZSK; alg = RSASHA256 ; key id = 35328
example.net. 287 IN DNSKEY 257 3 8 (
AwEAAbKtU1...PPP4aQZTybk75ZW+uL
6OJMAF63NO0s1nAZM2EWAVasbnn/X+J4N2rLuhk=
) ; KSK; alg = RSASHA256 ; key id = 27247
example.net. 287 IN RRSIG DNSKEY 8 2 300 (
20811123173143 20180101000000 27247 example.net.
Fz1sjClIoF...YEjzpAWuAj9peQ== )
example.net. 287 IN RRSIG DNSKEY 8 2 300 (
20811123173143 20180101000000 35328 example.net.
seKtUeJ4/l...YtDc1rcXTVlWIOw= )
;; Query time: 0 msec
;; SERVER: 10.53.0.3#53(10.53.0.3)
;; WHEN: Thu Mar 19 13:22:40 GMT 2020
;; MSG SIZE rcvd: 962
Here is the problem: the parent zone is telling the world that
``example.net`` is using the key 14956, but the authoritative server
indicates that it is using keys 27247 and 35328. There are several
potential causes for this mismatch: one possibility is that a malicious
attacker has compromised one side and changed the data. A more likely
scenario is that the DNS administrator for the child zone did not upload
the correct key information to the parent zone.
.. _troubleshooting_incorrect_time:
Incorrect Time
^^^^^^^^^^^^^^
In DNSSEC, every record comes with at least one RRSIG, and each RRSIG
contains two timestamps: one indicating when it becomes valid, and
one when it expires. If the validating resolver's current system time does
not fall within the two RRSIG timestamps, error messages
appear in the BIND debug log.
The example below shows a log message when the RRSIG appears to have
expired. This could mean the validating resolver system time is
incorrectly set too far in the future, or the zone administrator has not
kept up with RRSIG maintenance.
::
validating example.com/DNSKEY: verify failed due to bad signature (keyid=19036): RRSIG has expired
The log below shows that the RRSIG validity period has not yet begun. This could mean
the validation resolver's system time is incorrectly set too far in the past, or
the zone administrator has incorrectly generated signatures for this
domain name.
::
validating example.com/DNSKEY: verify failed due to bad signature (keyid=4521): RRSIG validity period has not begun
.. _troubleshooting_unable_to_load_keys:
Unable to Load Keys
^^^^^^^^^^^^^^^^^^^
This is a simple yet common issue. If the key files are present but
unreadable by ``named`` for some reason, the ``syslog`` returns clear error
messages, as shown below:
::
named[32447]: zone example.com/IN (signed): reconfiguring zone keys
named[32447]: dns_dnssec_findmatchingkeys: error reading key file Kexample.com.+008+06817.private: permission denied
named[32447]: dns_dnssec_findmatchingkeys: error reading key file Kexample.com.+008+17694.private: permission denied
named[32447]: zone example.com/IN (signed): next key event: 27-Nov-2014 20:04:36.521
However, if no keys are found, the error is not as obvious. Below shows
the ``syslog`` messages after executing ``rndc
reload`` with the key files missing from the key directory:
::
named[32516]: received control channel command 'reload'
named[32516]: loading configuration from '/etc/bind/named.conf'
named[32516]: reading built-in trusted keys from file '/etc/bind/bind.keys'
named[32516]: using default UDP/IPv4 port range: [1024, 65535]
named[32516]: using default UDP/IPv6 port range: [1024, 65535]
named[32516]: sizing zone task pool based on 6 zones
named[32516]: the working directory is not writable
named[32516]: reloading configuration succeeded
named[32516]: reloading zones succeeded
named[32516]: all zones loaded
named[32516]: running
named[32516]: zone example.com/IN (signed): reconfiguring zone keys
named[32516]: zone example.com/IN (signed): next key event: 27-Nov-2014 20:07:09.292
This happens to look exactly the same as if the keys were present and
readable, and appears to indicate that ``named`` loaded the keys and signed the zone. It
even generates the internal (raw) files:
::
# cd /etc/bind/db
# ls
example.com.db example.com.db.jbk example.com.db.signed
If ``named`` really loaded the keys and signed the zone, you should see
the following files:
::
# cd /etc/bind/db
# ls
example.com.db example.com.db.jbk example.com.db.signed example.com.db.signed.jnl
So, unless you see the ``*.signed.jnl`` file, your zone has not been
signed.
.. _troubleshooting_invalid_trust_anchors:
Invalid Trust Anchors
^^^^^^^^^^^^^^^^^^^^^
In most cases, you never need to explicitly configure trust
anchors. ``named`` supplies the current root trust anchor and,
with the default setting of ``dnssec-validation``, updates it on the
infrequent occasions when it is changed.
However, in some circumstances you may need to explicitly configure
your own trust anchor. As we saw in the :ref:`trust_anchors_description`
section, whenever a DNSKEY is received by the validating resolver, it is
compared to the list of keys the resolver explicitly trusts to see if
further action is needed. If the two keys match, the validating resolver
stops performing further verification and returns the answer(s) as
validated.
But what if the key file on the validating resolver is misconfigured or
missing? Below we show some examples of log messages when things are not
working properly.
First of all, if the key you copied is malformed, BIND does not even
start and you will likely find this error message in syslog:
::
named[18235]: /etc/bind/named.conf.options:29: bad base64 encoding
named[18235]: loading configuration: failure
If the key is a valid base64 string but the key algorithm is incorrect,
or if the wrong key is installed, the first thing you will notice is
that virtually all of your DNS lookups result in SERVFAIL, even when
you are looking up domain names that have not been DNSSEC-enabled. Below
shows an example of querying a recursive server 10.53.0.3:
::
$ dig @10.53.0.3 www.example.com. A
; <<>> DiG 9.16.0 <<>> @10.53.0.3 www.example.org A +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29586
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: ee078fc321fa1367010000005e73a58bf5f205ca47e04bed (good)
;; QUESTION SECTION:
;www.example.org. IN A
``delv`` shows a similar result:
::
$ delv @192.168.1.7 www.example.com. +rtrace
;; fetch: www.example.com/A
;; resolution failed: SERVFAIL
The next symptom you see is in the DNSSEC log messages:
::
managed-keys-zone: DNSKEY set for zone '.' could not be verified with current keys
validating ./DNSKEY: starting
validating ./DNSKEY: attempting positive response validation
validating ./DNSKEY: no DNSKEY matching DS
validating ./DNSKEY: no DNSKEY matching DS
validating ./DNSKEY: no valid signature found (DS)
These errors are indications that there are problems with the trust
anchor.
.. _troubleshooting_nta:
Negative Trust Anchors
~~~~~~~~~~~~~~~~~~~~~~
BIND 9.11 introduced Negative Trust Anchors (NTAs) as a means to
*temporarily* disable DNSSEC validation for a zone when you know that
the zone's DNSSEC is misconfigured.
NTAs are added using the ``rndc`` command, e.g.:
::
$ rndc nta example.com
Negative trust anchor added: example.com/_default, expires 19-Mar-2020 19:57:42.000
The list of currently configured NTAs can also be examined using
``rndc``, e.g.:
::
$ rndc nta -dump
example.com/_default: expiry 19-Mar-2020 19:57:42.000
The default lifetime of an NTA is one hour, although by default, BIND
polls the zone every five minutes to see if the zone correctly
validates, at which point the NTA automatically expires. Both the
default lifetime and the polling interval may be configured via
``named.conf``, and the lifetime can be overridden on a per-zone basis
using the ``-lifetime duration`` parameter to ``rndc nta``. Both timer
values have a permitted maximum value of one week.
.. _troubleshooting_nsec3:
NSEC3 Troubleshooting
~~~~~~~~~~~~~~~~~~~~~
BIND includes a tool called ``nsec3hash`` that runs through the same
steps as a validating resolver, to generate the correct hashed name
based on NSEC3PARAM parameters. The command takes the following
parameters in order: salt, algorithm, iterations, and domain. For
example, if the salt is 1234567890ABCDEF, hash algorithm is 1, and
iteration is 10, to get the NSEC3-hashed name for ``www.example.com`` we
would execute a command like this:
::
$ nsec3hash 1234567890ABCEDF 1 10 www.example.com
RN7I9ME6E1I6BDKIP91B9TCE4FHJ7LKF (salt=1234567890ABCEDF, hash=1, iterations=10)
While it is unlikely you would construct a rainbow table of your own
zone data, this tool may be useful when troubleshooting NSEC3 problems.

867
doc/dnssec-guide/validation.rst Normal file
View File

@@ -0,0 +1,867 @@
..
Copyright (C) Internet Systems Consortium, Inc. ("ISC")
This Source Code Form is subject to the terms of the Mozilla Public
License, v. 2.0. If a copy of the MPL was not distributed with this
file, you can obtain one at https://mozilla.org/MPL/2.0/.
See the COPYRIGHT file distributed with this work for additional
information regarding copyright ownership.
.. _DNSSEC_validation:
Validation
----------
.. _easy_start_guide_for_recursive_servers:
Easy-Start Guide for Recursive Servers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This section provides the basic information needed to set up a
working DNSSEC-aware recursive server, also known as a validating
resolver. A validating resolver performs validation for each remote
response received, following the chain of trust to verify that the answers it
receives are legitimate, through the use of public key cryptography and
hashing functions.
.. _enabling_validation:
Enabling DNSSEC Validation
^^^^^^^^^^^^^^^^^^^^^^^^^^
So how do we turn on DNSSEC validation? It turns out that you may not need
to reconfigure your name server at all, since the most recent versions of BIND 9 -
including packages and distributions - have shipped with DNSSEC validation
enabled by default. Before making any configuration changes, check
whether you already have DNSSEC validation enabled by following the steps
described in :ref:`how_to_test_recursive_server`.
In earlier versions of BIND, including 9.11-ESV, DNSSEC
validation must be explicitly enabled. To do this, you only need to
add one line to the ``options`` section of your configuration file:
::
options {
...
dnssec-validation auto;
...
};
Restart ``named`` or run ``rndc reconfig``, and your recursive server is
now happily validating each DNS response. If this does not work for you,
and you have already verified DNSSEC support as described in
:ref:`dnssec_support_in_bind`, you may have some other
network-related configurations that need to be adjusted. Take a look at
:ref:`network_requirements` to make sure your network is ready for
DNSSEC.
.. _effect_of_enabling_validation:
Effects of Enabling DNSSEC Validation
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Once DNSSEC validation is enabled, any DNS response that does not pass
the validation checks results in a failure to resolve the domain name
(often a SERVFAIL status seen by the client). If everything has
been configured properly, this is the correct result; it means that an end user has
been protected against a malicious attack.
However, if there is a DNSSEC configuration issue (sometimes outside of
the administrator's control), a specific name or sometimes entire
domains may "disappear" from the DNS, and become unreachable
through that resolver. For the end user, the issue may manifest itself
as name resolution being slow or failing altogether; some parts of a URL
not loading; or the web browser returning an error message indicating
that the page cannot be displayed. For example, if root name
servers were misconfigured with the wrong information about ``.org``, it
could cause all validation for ``.org`` domains to fail. To end
users, it would appear that all ``.org`` web
sites were out of service [#]_. Should you encounter DNSSEC-related problems, don't be
tempted to disable validation; there is almost certainly a solution that
leaves validation enabled. A basic troubleshooting guide can be found in
:ref:`dnssec_troubleshooting`.
.. [#]
Of course, something like this could happen for reasons other than
DNSSEC: for example, the root publishing the wrong addresses for the
``.org`` nameservers.
.. _how_to_test_recursive_server:
So You Think You Are Validating (How To Test A Recursive Server)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Now that you have reconfigured your recursive server and
restarted it, how do you know that your recursive name server is
actually verifying each DNS query? There are several ways to check, and
we've listed a few of them below.
.. _using_web_based_tests_to_verify:
Using Web-Based Tools to Verify
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
For most people, the simplest way to check if a recursive name server
is indeed validating DNS queries is to use one of the many web-based
tools available.
Configure your client computer to use the newly reconfigured recursive
server for DNS resolution; then use one of these web-based tests to
confirm that it is in fact validating DNS responses.
- `Internet.nl <https://en.conn.internet.nl/connection/>`__
- `DNSSEC Resolver Test (uni-due.de) <https://dnssec.vs.uni-due.de/>`__
- `DNSSEC or Not (VeriSign) <https://www.dnssec-or-not.com/>`__
.. _using_dig_to_verify:
Using ``dig`` to Verify
^^^^^^^^^^^^^^^^^^^^^^^
Web-based DNSSEC-verification tools often employ JavaScript. If you don't trust the
JavaScript magic that the web-based tools rely on, you can take matters
into your own hands and use a command-line DNS tool to check your
validating resolver yourself.
While ``nslookup`` is popular, partly because it comes pre-installed on
most systems, it is not DNSSEC-aware. ``dig``, on the other hand, fully
supports the DNSSEC standard and comes as a part of BIND. If you do not
have ``dig`` already installed on your system, install it by downloading
it from ISC's `website <https://www.isc.org/download>`__. ISC provides pre-compiled
Windows versions on its website.
``dig`` is a flexible tool for interrogating DNS name servers. It
performs DNS lookups and displays the answers that are returned from the
name servers that were queried. Most seasoned DNS administrators use
``dig`` to troubleshoot DNS problems because of its flexibility, ease of
use, and clarity of output.
The example below shows how to use ``dig`` to query the name server 10.53.0.1
for the A record for ``ftp.isc.org`` when DNSSEC validation is enabled
(i.e. the default). The address 10.53.0.1 is only used as an example;
replace it with the actual address or host name of your
recursive name server.
::
$ dig @10.53.0.1 ftp.isc.org. A +dnssec +multiline
; <<>> DiG 9.16.0 <<>> @10.53.0.1 ftp.isc.org a +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48742
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 29a9705c2160b08c010000005e67a4a102b9ae079c1b24c8 (good)
;; QUESTION SECTION:
;ftp.isc.org. IN A
;; ANSWER SECTION:
ftp.isc.org. 300 IN A 149.20.1.49
ftp.isc.org. 300 IN RRSIG A 13 3 300 (
20200401191851 20200302184340 27566 isc.org.
e9Vkb6/6aHMQk/t23Im71ioiDUhB06sncsduoW9+Asl4
L3TZtpLvZ5+zudTJC2coI4D/D9AXte1cD6FV6iS6PQ== )
;; Query time: 452 msec
;; SERVER: 10.53.0.1#53(10.53.0.1)
;; WHEN: Tue Mar 10 14:30:57 GMT 2020
;; MSG SIZE rcvd: 187
The important detail in this output is the presence of the ``ad`` flag
in the header. This signifies that BIND has retrieved all related DNSSEC
information related to the target of the query (``ftp.isc.org``) and that
the answer received has passed the validation process described in
:ref:`how_are_answers_verified`. We can have confidence in the
authenticity and integrity of the answer, that ``ftp.isc.org`` really
points to the IP address 149.20.1.49, and that it was not a spoofed answer
from a clever attacker.
Unlike earlier versions of BIND, the current versions of BIND always
request DNSSEC records (by setting the ``do`` bit in the query they make
to upstream servers), regardless of DNSSEC settings. However, with
validation disabled, the returned signature is not checked. This can be
seen by explicitly disabling DNSSEC validation. To do this, add the line
``dnssec-validation no;`` to the "options" section of the configuration
file, i.e.:
::
options {
...
dnssec-validation no;
...
};
If the server is restarted (to ensure a clean cache) and the same
``dig`` command executed, the result is very similar:
::
$ dig @10.53.0.1 ftp.isc.org. A +dnssec +multiline
; <<>> DiG 9.16.0 <<>> @10.53.0.1 ftp.isc.org a +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39050
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: a8dc9d1b9ec45e75010000005e67a8a69399741fdbe126f2 (good)
;; QUESTION SECTION:
;ftp.isc.org. IN A
;; ANSWER SECTION:
ftp.isc.org. 300 IN A 149.20.1.49
ftp.isc.org. 300 IN RRSIG A 13 3 300 (
20200401191851 20200302184340 27566 isc.org.
e9Vkb6/6aHMQk/t23Im71ioiDUhB06sncsduoW9+Asl4
L3TZtpLvZ5+zudTJC2coI4D/D9AXte1cD6FV6iS6PQ== )
;; Query time: 261 msec
;; SERVER: 10.53.0.1#53(10.53.0.1)
;; WHEN: Tue Mar 10 14:48:06 GMT 2020
;; MSG SIZE rcvd: 187
However, this time there is no ``ad`` flag in the header. Although
``dig`` is still returning the DNSSEC-related resource records, it is
not checking them, and thus cannot vouch for the authenticity of the answer.
If you do carry out this test, remember to re-enable DNSSEC validation
(by removing the ``dnssec-validation no;`` line from the configuration
file) before continuing.
.. _verifying_protection_from_bad_domains:
Verifying Protection From Bad Domain Names
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It is also important to make sure that DNSSEC is protecting your network from
domain names that fail to validate; such failures could be caused by
attacks on your system, attempting to get it to accept false DNS
information. Validation could fail for a number of reasons: maybe the
answer doesn't verify because it's a spoofed response; maybe the
signature was a replayed network attack that has expired; or maybe the
child zone has been compromised along with its keys, and the parent
zone's information tells us that things don't add up. There is a
domain name specifically set up to fail DNSSEC validation,
``www.dnssec-failed.org``.
With DNSSEC validation enabled (the default), an attempt to look up that
name fails:
::
$ dig @10.53.0.1 www.dnssec-failed.org. A
; <<>> DiG 9.16.0 <<>> @10.53.0.1 www.dnssec-failed.org. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 22667
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 69c3083144854587010000005e67bb57f5f90ff2688e455d (good)
;; QUESTION SECTION:
;www.dnssec-failed.org. IN A
;; Query time: 2763 msec
;; SERVER: 10.53.0.1#53(10.53.0.1)
;; WHEN: Tue Mar 10 16:07:51 GMT 2020
;; MSG SIZE rcvd: 78
On the other hand, if DNSSEC validation is disabled (by adding the
statement ``dnssec-validation no;`` to the ``options`` clause in the
configuration file), the lookup succeeds:
::
$ dig @10.53.0.1 www.dnssec-failed.org. A
; <<>> DiG 9.16.0 <<>> @10.53.0.1 www.dnssec-failed.org. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54704
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 251eee58208917f9010000005e67bb6829f6dabc5ae6b7b9 (good)
;; QUESTION SECTION:
;www.dnssec-failed.org. IN A
;; ANSWER SECTION:
www.dnssec-failed.org. 7200 IN A 68.87.109.242
www.dnssec-failed.org. 7200 IN A 69.252.193.191
;; Query time: 439 msec
;; SERVER: 10.53.0.1#53(10.53.0.1)
;; WHEN: Tue Mar 10 16:08:08 GMT 2020
;; MSG SIZE rcvd: 110
Do not be tempted to disable DNSSEC validation just because some names
are failing to resolve. Remember, DNSSEC protects your DNS lookup from
hacking. The next section describes how to quickly check whether
the failure to successfully look up a name is due to a validation
failure.
.. _how_do_i_know_validation_problem:
How Do I Know I Have a Validation Problem?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Since all DNSSEC validation failures result in a general ``SERVFAIL``
message, how do we know if it was really a validation error?
Fortunately, there is a flag in ``dig``, (``+cd``, for "checking
disabled") which tells the server to disable DNSSEC validation. If
you receive a ``SERVFAIL`` message, re-run the query a second time
and set the ``+cd`` flag. If the query succeeds with ``+cd``, but
ends in ``SERVFAIL`` without it, you know you are dealing with a
validation problem. So using the previous example of
``www.dnssec-failed.org`` and with DNSSEC validation enabled in the
resolver:
::
$ dig @10.53.0.1 www.dnssec-failed.org A +cd
; <<>> DiG 9.16.0 <<>> @10.53.0.1 www.dnssec-failed.org. A +cd
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62313
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 73ca1be3a74dd2cf010000005e67c8c8e6df64b519cd87fd (good)
;; QUESTION SECTION:
;www.dnssec-failed.org. IN A
;; ANSWER SECTION:
www.dnssec-failed.org. 7197 IN A 68.87.109.242
www.dnssec-failed.org. 7197 IN A 69.252.193.191
;; Query time: 0 msec
;; SERVER: 10.53.0.1#53(10.53.0.1)
;; WHEN: Tue Mar 10 17:05:12 GMT 2020
;; MSG SIZE rcvd: 110
For more information on troubleshooting, please see
:ref:`dnssec_troubleshooting`.
.. _validation_easy_start_explained:
Validation Easy Start Explained
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In :ref:`easy_start_guide_for_recursive_servers`, we used one line
of configuration to turn on DNSSEC validation: the act of chasing down
signatures and keys, making sure they are authentic. Now we are going to
take a closer look at what DNSSEC validation actually does, and some other options.
.. _dnssec_validation_explained:
``dnssec-validation``
^^^^^^^^^^^^^^^^^^^^^
::
options {
dnssec-validation auto;
};
This “auto” line enables automatic DNSSEC trust anchor configuration
using the ``managed-keys`` feature. In this case, no manual key
configuration is needed. There are three possible choices for the
``dnssec-validation`` option:
- *yes*: DNSSEC validation is enabled, but a trust anchor must be
manually configured. No validation actually takes place until
at least one trusted key has been manually configured.
- *no*: DNSSEC validation is disabled, and the recursive server behaves
in the "old-fashioned" way of performing insecure DNS lookups.
- *auto*: DNSSEC validation is enabled, and a default trust anchor
(included as part of BIND 9) for the DNS root zone is used. This is the
default; BIND automatically does this if there is no
``dnssec-validation`` line in the configuration file.
Let's discuss the difference between *yes* and *auto*. If set to
*yes*, the trust anchor must be manually defined and maintained
using the ``trust-anchors`` statement (with either the ``static-key`` or
``static-ds`` modifier) in the configuration file; if set to
*auto* (the default, and as shown in the example), then no further
action should be required as BIND includes a copy [#]_ of the root key.
When set to *auto*, BIND automatically keeps the keys (also known as
trust anchors, discussed in :ref:`trust_anchors_description`)
up-to-date without intervention from the DNS administrator.
We recommend using the default *auto* unless there is a good reason to
require a manual trust anchor. To learn more about trust anchors,
please refer to :ref:`trusted_keys_and_managed_keys`.
.. _how_does_dnssec_change_dns_lookup_revisited:
How Does DNSSEC Change DNS Lookup (Revisited)?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Now you've enabled validation on your recursive name server and
verified that it works. What exactly changed? In
:ref:`how_does_dnssec_change_dns_lookup` we looked at a very
high-level, simplified version of the 12 steps of the DNSSEC validation process. Let's revisit
that process now and see what your validating resolver is doing in more
detail. Again, as an example we are looking up the A record for the
domain name ``www.isc.org`` (see :ref:`dnssec_12_steps`):
1. The validating resolver queries the ``isc.org`` name servers for the
A record of ``www.isc.org``. This query has the ``DNSSEC
OK`` (``do``) bit set to 1, notifying the remote authoritative
server that DNSSEC answers are desired.
2. Since the zone ``isc.org`` is signed, and its name servers are
DNSSEC-aware, it responds with the answer to the A record query plus
the RRSIG for the A record.
3. The validating resolver queries for the DNSKEY for ``isc.org``.
4. The ``isc.org`` name server responds with the DNSKEY and RRSIG
records. The DNSKEY is used to verify the answers received in #2.
5. The validating resolver queries the parent (``.org``) for the DS
record for ``isc.org``.
6. The ``.org`` name server is also DNSSEC-aware, so it responds with the
DS and RRSIG records. The DS record is used to verify the answers
received in #4.
7. The validating resolver queries for the DNSKEY for ``.org``.
8. The ``.org`` name server responds with its DNSKEY and RRSIG. The DNSKEY
is used to verify the answers received in #6.
9. The validating resolver queries the parent (root) for the DS record
for ``.org``.
10. The root name server, being DNSSEC-aware, responds with DS and RRSIG
records. The DS record is used to verify the answers received in #8.
11. The validating resolver queries for the DNSKEY for root.
12. The root name server responds with its DNSKEY and RRSIG. The DNSKEY is
used to verify the answers received in #10.
After step #12, the validating resolver takes the DNSKEY received and
compares it to the key or keys it has configured, to decide whether
the received key can be trusted. We talk about these locally
configured keys, or trust anchors, in :ref:`trust_anchors_description`.
With DNSSEC, every response includes not just the
answer, but a digital signature (RRSIG) as well, so the
validating resolver can verify the answer received. That is what we
look at in the next section, :ref:`how_are_answers_verified`.
.. _how_are_answers_verified:
How Are Answers Verified?
^^^^^^^^^^^^^^^^^^^^^^^^^
.. note::
Keep in mind, as you read this section, that although words like
"encryption" and "decryption"
are used here from time to time, DNSSEC does not provide privacy.
Public key cryptography is used to verify data *authenticity* (who
sent it) and data *integrity* (it did not change during transit), but
any eavesdropper can still see DNS requests and responses in
clear text, even when DNSSEC is enabled.
So how exactly are DNSSEC answers verified? Let's first see how verifiable information is
generated. On the authoritative server, each DNS record (or message) is
run through a hash function, and this hashed value is then encrypted by a
private key. This encrypted hash value is the digital signature.
.. figure:: ../dnssec-guide/img/signature-generation.png
:alt: Signature Generation
:width: 80.0%
Signature Generation
When the validating resolver queries for the resource record, it
receives both the plain-text message and the digital signature(s). The
validating resolver knows the hash function used (it is listed in the digital
signature record itself), so it can take the plain-text message and run
it through the same hash function to produce a hashed value, which we'll call
hash value X. The validating resolver can also obtain the public key
(published as DNSKEY records), decrypt the digital signature, and get
back the original hashed value produced by the authoritative server,
which we'll call hash value Y. If hash values X and Y are identical, and
the time is correct (more on what this means below), the answer is
verified, meaning this answer came from the authoritative server
(authenticity), and the content remained intact during transit
(integrity).
.. figure:: ../dnssec-guide/img/signature-verification.png
:alt: Signature Verification
:width: 80.0%
Signature Verification
Take the A record ``ftp.isc.org``, for example. The plain text is:
::
ftp.isc.org. 4 IN A 149.20.1.49
The digital signature portion is:
::
ftp.isc.org. 300 IN RRSIG A 13 3 300 (
20200401191851 20200302184340 27566 isc.org.
e9Vkb6/6aHMQk/t23Im71ioiDUhB06sncsduoW9+Asl4
L3TZtpLvZ5+zudTJC2coI4D/D9AXte1cD6FV6iS6PQ== )
When a validating resolver queries for the A record ``ftp.isc.org``, it
receives both the A record and the RRSIG record. It runs the A record
through a hash function (in this example, SHA256 as
indicated by the number 13, signifying ECDSAP256SHA256) and produces
hash value X. The resolver also fetches the appropriate DNSKEY record to
decrypt the signature, and the result of the decryption is hash value Y.
But wait, there's more! Just because X equals Y doesn't mean everything
is good. We still have to look at the time. Remember we mentioned a
little earlier that we need to check if the time is correct? Look
at the two timestamps in our example above:
- Signature Expiration: 20200401191851
- Signature Inception: 20200302184340
This tells us that this signature was generated UTC March 2nd, 2020, at
6:43:40 PM (20200302184340), and it is good until UTC April 1st, 2020,
7:18:51 PM (20200401191851). The validating resolver's current
system time needs to fall between these two timestamps. If it does not, the
validation fails, because it could be an attacker replaying an old
captured answer set from the past, or feeding us a crafted one with
incorrect future timestamps.
If the answer passes both the hash value check and the timestamp check, it is
validated and the authenticated data (``ad``) bit is set, and the response
is sent to the client; if it does not verify, a SERVFAIL is returned to
the client.
.. [#]
BIND technically includes two copies of the root key: one is in
``bind.keys.h`` and is built into the executable, and one is in
``bind.keys`` as a ``trust-anchors`` statement. The two copies of the
key are identical.
.. _trust_anchors_description:
Trust Anchors
~~~~~~~~~~~~~
A trust anchor is a key that is placed into a validating resolver, so
that the validator can verify the results of a given request with a
known or trusted public key (the trust anchor). A validating resolver
must have at least one trust anchor installed to perform DNSSEC
validation.
.. _how_trust_anchors_are_used:
How Trust Anchors are Used
~~~~~~~~~~~~~~~~~~~~~~~~~~
In the section :ref:`how_does_dnssec_change_dns_lookup_revisited`,
we walked through the 12 steps of the DNSSEC lookup process. At the end
of the 12 steps, a critical comparison happens: the key received from
the remote server and the key we have on file are compared to see if we
trust it. The key we have on file is called a trust anchor, sometimes
also known as a trust key, trust point, or secure entry point.
The 12-step lookup process describes the DNSSEC lookup in the ideal
world, where every single domain name is signed and properly delegated,
and where each validating resolver only needs to have one trust anchor - that
is, the root's public key. But there is no restriction that the
validating resolver must only have one trust anchor. In fact, in the
early stages of DNSSEC adoption, it was not unusual for a validating
resolver to have more than one trust anchor.
For instance, before the root zone was signed (in July 2010), some
validating resolvers that wished to validate domain names in the ``.gov``
zone needed to obtain and install the key for ``.gov``. A sample lookup
process for ``www.fbi.gov`` at that time would have been eight steps rather
than 12:
.. figure:: ../dnssec-guide/img/dnssec-8-steps.png
:alt: DNSSEC Validation with ``.gov`` Trust Anchor
1. The validating resolver queried ``fbi.gov`` name server for the A
record of ``www.fbi.gov``.
2. The FBI's name server responded with the answer and its RRSIG.
3. The validating resolver queried the FBI's name server for its DNSKEY.
4. The FBI's name server responded with the DNSKEY and its RRSIG.
5. The validating resolver queried a ``.gov`` name server for the DS
record of ``fbi.gov``.
6. The ``.gov`` name server responded with the DS record and the
associated RRSIG for ``fbi.gov``.
7. The validating resolver queried the ``.gov`` name server for its DNSKEY.
8. The ``.gov`` name server responded with its DNSKEY and the associated
RRSIG.
This all looks very similar, except it's shorter than the 12 steps that
we saw earlier. Once the validating resolver receives the DNSKEY file in
#8, it recognizes that this is the manually configured trusted key
(trust anchor), and never goes to the root name servers to ask for the
DS record for ``.gov``, or ask the root name servers for their DNSKEY.
In fact, whenever the validating resolver receives a DNSKEY, it checks
to see if this is a configured trusted key to decide whether it
needs to continue chasing down the validation chain.
.. _trusted_keys_and_managed_keys:
Trusted Keys and Managed Keys
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Since the resolver is validating, we must have at least one key (trust
anchor) configured. How did it get here, and how do we maintain it?
If you followed the recommendation in
:ref:`easy_start_guide_for_recursive_servers`, by setting
``dnssec-validation`` to *auto*, there is nothing left to do.
BIND already includes a copy of the root key (in the file
``bind.keys``), and automatically updates it when the root key
changes. [#]_ It looks something like this:
::
trust-anchors {
# This key (20326) was published in the root zone in 2017.
. initial-key 257 3 8 "AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
R1AkUTV74bU=";
};
You can, of course, decide to manage this key manually yourself.
First, you need to make sure that ``dnssec-validation`` is set
to *yes* rather than *auto*:
::
options {
dnssec-validation yes;
};
Then, download the root key manually from a trustworthy source, such as
`<https://www.isc.org/bind-keys>`__. Finally, take the root key you
manually downloaded and put it into a ``trust-anchors`` statement as
shown below:
::
trust-anchors {
# This key (20326) was published in the root zone in 2017.
. static-key 257 3 8 "AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
R1AkUTV74bU=";
};
While this ``trust-anchors`` statement and the one in the ``bind.keys``
file appear similar, the definition of the key in ``bind.keys`` has the
``initial-key`` modifier, whereas in the statement in the configuration
file, that is replaced by ``static-key``. There is an important
difference between the two: a key defined with ``static-key`` is always
trusted until it is deleted from the configuration file. With the
``initial-key`` modified, keys are only trusted once: for as long as it
takes to load the managed key database and start the key maintenance
process. Thereafter, BIND uses the managed keys database
(``managed-keys.bind.jnl``) as the source of key information.
.. warning::
Remember, if you choose to manage the keys on your own, whenever the
key changes (which, for most zones, happens on a periodic basis),
the configuration needs to be updated manually. Failure to do so will
result in breaking nearly all DNS queries for the subdomain of the
key. So if you are manually managing ``.gov``, all domain names in
the ``.gov`` space may become unresolvable; if you are manually
managing the root key, you could break all DNS requests made to your
recursive name server.
Explicit management of keys was common in the early days of DNSSEC, when
neither the root zone nor many top-level domains were signed. Since
then, `over 90% <https://stats.research.icann.org/dns/tld_report/>`__ of
the top-level domains have been signed, including all the largest ones.
Unless you have a particular need to manage keys yourself, it is best to
use the BIND defaults and let the software manage the root key.
.. [#]
The root zone was signed in July 2010 and, as at the time of this writing
(mid-2020), the key has been changed once, in October 2018. The intention going
forward is to roll the key once every five years.
.. _whats_edns0_all_about:
What's EDNS All About (And Why Should I Care)?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. _whats-edns0-all-about-overview:
EDNS Overview
^^^^^^^^^^^^^
Traditional DNS responses are typically small in size (less than 512
bytes) and fit nicely into a small UDP packet. The Extension mechanism
for DNS (EDNS, or EDNS(0)) offers a mechanism to send DNS data in
larger packets over UDP. To support EDNS, both the DNS server
and the network need to be properly prepared to support the larger
packet sizes and multiple fragments.
This is important for DNSSEC, since the ``+do`` bit that signals
DNSSEC-awareness is carried within EDNS, and DNSSEC responses are larger
than traditional DNS ones. If DNS servers and the network environment cannot
support large UDP packets, it will cause retransmission over TCP, or the
larger UDP responses will be discarded. Users will likely experience
slow DNS resolution or be unable to resolve certain names at all.
Note that EDNS applies regardless of whether you are validating DNSSEC, because
BIND has DNSSEC enabled by default.
Please see :ref:`network_requirements` for more information on what
DNSSEC expects from the network environment.
.. _edns_on_dns_servers:
EDNS on DNS Servers
^^^^^^^^^^^^^^^^^^^
For many years, BIND has had EDNS enabled by default,
and the UDP packet size is set to a maximum of 4096 bytes. The DNS
administrator should not need to perform any reconfiguration. You can
use ``dig`` to verify that your server supports EDNS and see the UDP packet
size it allows with this ``dig`` command:
::
$ dig @10.53.0.1 www.isc.org. A +dnssec +multiline
; <<>> DiG 9.16.0 <<>> @10.53.0.1 ftp.isc.org a +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48742
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 29a9705c2160b08c010000005e67a4a102b9ae079c1b24c8 (good)
;; QUESTION SECTION:
;ftp.isc.org. IN A
;; ANSWER SECTION:
ftp.isc.org. 300 IN A 149.20.1.49
ftp.isc.org. 300 IN RRSIG A 13 3 300 (
20200401191851 20200302184340 27566 isc.org.
e9Vkb6/6aHMQk/t23Im71ioiDUhB06sncsduoW9+Asl4
L3TZtpLvZ5+zudTJC2coI4D/D9AXte1cD6FV6iS6PQ== )
;; Query time: 452 msec
;; SERVER: 10.53.0.1#53(10.53.0.1)
;; WHEN: Tue Mar 10 14:30:57 GMT 2020
;; MSG SIZE rcvd: 187
There is a helpful testing tool available (provided by DNS-OARC) that
you can use to verify resolver behavior regarding EDNS support:
`<https://www.dns-oarc.net/oarc/services/replysizetest/>`__ .
Once you've verified that your name servers have EDNS enabled, that should be the
end of the story, right? Unfortunately, EDNS is a hop-by-hop extension
to DNS. This means the use of EDNS is negotiated between each pair of
hosts in a DNS resolution process, which in turn means if one of your
upstream name servers (for instance, your ISP's recursive name server
that your name server forwards to) does not support EDNS, you may experience DNS
lookup failures or be unable to perform DNSSEC validation.
.. _support_for_large_packets_network_equipment:
Support for Large Packets on Network Equipment
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If both your recursive name server and your ISP's name servers
support EDNS, we are all good here, right? Not so fast. Since these large
packets have to traverse the network, the network infrastructure
itself must allow them to pass.
When data is physically transmitted over a network, it has to be broken
down into chunks. The size of the data chunk is known as the Maximum
Transmission Unit (MTU), and it can differ from network to
network. IP fragmentation occurs when a large data packet needs to be
broken down into chunks smaller than the
MTU; these smaller chunks then need to be reassembled back into the large
data packet at their destination. IP fragmentation is not necessarily a bad thing, and it most
likely occurs on your network today.
Some network equipment, such as a firewall, may make assumptions about
DNS traffic. One of these assumptions may be how large each DNS packet
is. When a firewall sees a larger DNS packet than it expects, it may either
reject the large packet or drop its fragments because the firewall
thinks it's an attack. This configuration probably didn't cause problems
in the past, since traditional DNS packets are usually pretty small in
size. However, with DNSSEC, these configurations need to be updated,
since DNSSEC traffic regularly exceeds 1500 bytes (a common MTU value).
If the configuration is not updated to support a larger DNS packet size,
it often results in the larger packets being rejected, and to the
end user it looks like the queries go unanswered. Or in the case of
fragmentation, only a part of the answer makes it to the validating
resolver, and your validating resolver may need to re-ask the question
again and again, creating the appearance for end users that the DNS/network is slow.
While you are updating the configuration on your network equipment, make
sure TCP port 53 is also allowed for DNS traffic.
.. _dns_uses_tcp:
Wait... DNS Uses TCP?
^^^^^^^^^^^^^^^^^^^^^
Yes. DNS uses TCP port 53 as a fallback mechanism, when it cannot use
UDP to transmit data. This has always been the case, even long before
the arrival of DNSSEC. Traditional DNS relies on TCP port 53 for
operations such as zone transfer. The use of DNSSEC, or DNS with IPv6
records such as AAAA, increases the chance that DNS data will be
transmitted via TCP.
Due to the increased packet size, DNSSEC may fall back to TCP more often
than traditional (insecure) DNS. If your network blocks or
filters TCP port 53 today, you may already experience instability with
DNS resolution, before even deploying DNSSEC.

10
util/copyrights
View File

@@ -1142,6 +1142,7 @@
./doc/arm/conf.py PYTHON 2020,2021
./doc/arm/configuration.rst RST 2020,2021
./doc/arm/dlz.rst RST 2020,2021
./doc/arm/dnssec-guide.rst RST 2021
./doc/arm/dnssec.rst RST 2020,2021
./doc/arm/dyndb.rst RST 2020,2021
./doc/arm/general.rst RST 2020,2021
@@ -1189,6 +1190,15 @@
./doc/dev/results TXT.BRIEF 1999,2000,2001,2004,2016,2018,2019,2020,2021
./doc/dev/tests TXT.BRIEF 2000,2001,2004,2016,2018,2019,2020,2021
./doc/dev/unexpected TXT.BRIEF 1999,2000,2001,2004,2016,2018,2019,2020,2021
./doc/dnssec-guide/advanced-discussions.rst RST 2021
./doc/dnssec-guide/commonly-asked-questions.rst RST 2021
./doc/dnssec-guide/getting-started.rst RST 2021
./doc/dnssec-guide/introduction.rst RST 2021
./doc/dnssec-guide/preface.rst RST 2021
./doc/dnssec-guide/recipes.rst RST 2021
./doc/dnssec-guide/signing.rst RST 2021
./doc/dnssec-guide/troubleshooting.rst RST 2021
./doc/dnssec-guide/validation.rst RST 2021
./doc/doxygen/Doxyfile.in X 2006,2017,2018,2019,2020
./doc/doxygen/doxygen-input-filter.in PERL 2006,2007,2012,2016,2018,2019,2020
./doc/doxygen/mainpage X 2006,2018,2019,2020,2021

1
util/merge_copyrights
View File

@@ -55,6 +55,7 @@ while (<CHANGES>) {
\.conf$ | # configuration files
\.conf\.in$ | # configuration files
/(dnssafe|openssl)/.*\.[ch]$ | # imported
doc/dnssec-guide/img/ | # images
doc/(draft|expired|rfc)/ | # imported
doc/notes/ | # release notes doesn't really need copyright
\.*in$ | # the generated documentation doesn't really need copyright