Adding upstream version 1:9.18.19.upstream/1%9.18.19upstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

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.