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

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

1 files changed, 864 insertions, 0 deletions

diff --git a/doc/dnssec-guide/validation.rst b/doc/dnssec-guide/validation.rst
new file mode 100644
index 0000000..2830b98
--- /dev/null
+++ b/doc/dnssec-guide/validation.rst
@@ -0,0 +1,864 @@
+.. 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_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,
+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 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.