summaryrefslogtreecommitdiffstats
path: root/doc/dnssec-guide/introduction.rst
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-07 15:59:48 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-07 15:59:48 +0000
commit3b9b6d0b8e7f798023c9d109c490449d528fde80 (patch)
tree2e1c188dd7b8d7475cd163de9ae02c428343669b /doc/dnssec-guide/introduction.rst
parentInitial commit. (diff)
downloadbind9-3b9b6d0b8e7f798023c9d109c490449d528fde80.tar.xz
bind9-3b9b6d0b8e7f798023c9d109c490449d528fde80.zip
Adding upstream version 1:9.18.19.upstream/1%9.18.19upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'doc/dnssec-guide/introduction.rst')
-rw-r--r--doc/dnssec-guide/introduction.rst394
1 files changed, 394 insertions, 0 deletions
diff --git a/doc/dnssec-guide/introduction.rst b/doc/dnssec-guide/introduction.rst
new file mode 100644
index 0000000..7f13155
--- /dev/null
+++ b/doc/dnssec-guide/introduction.rst
@@ -0,0 +1,394 @@
+.. 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.9 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.9. Readers are assumed to have basic
+working knowledge of the Domain Name System (DNS) and related network
+infrastructure, such as concepts of TCP/IP. In-depth knowledge of DNS and
+TCP/IP is not required. The guide assumes no prior knowledge of DNSSEC or
+related technology such as public key cryptography.
+
+.. _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 [#]_. 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.