horok/bind9
1
0
Fork 0
Code Activity
bind9/doc/dnssec-guide/introduction.rst
Daniel Baumann f66ff7eae6
Adding upstream version 1:9.20.9. 
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
2025-06-21 13:32:37 +02:00

394 lines
18 KiB
ReStructuredText
Raw Permalink Blame History

.. Copyright (C) Internet Systems Consortium, Inc. ("ISC")
..
.. SPDX-License-Identifier: MPL-2.0
..
.. 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), of 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. [#omb_memo]_ 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`.
.. [#omb_memo]
The Office of Management and Budget (OMB) for the US government
published `a memo in
2008 <https://georgewbush-whitehouse.archives.gov/omb/memoranda/fy2008/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://usgv6-deploymon.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.
View git blame Copy permalink