<commit_before><section id="trust-anchors">
 <title>Trust Anchors</title>
 <para>A trust anchor is a DNSKEY that is placed into a validating resolver so that the validator can verify the results for a given request back to a known public key (the trust anchor). A validating resolver must have at least one trust anchor installed in order to perform DNSSEC validation.</para>

 <para>BIND9 includes a copy of the root key, in the file <code>bind.keys</code>. You can download the root key manually from reputable sources such as <ulink url="https://www.isc.org/bind-keys"/>. The key file must be readable to named.</para>


 <!-- ====== HOw Trust Anchors are Used ====== -->
 <section id="how-trust-anchors-are-used">
  <title>How Trust Anchors are Used</title>
  <para>In the section <xref linkend="how-does-dnssec-change-dns-lookup"/>, we walked through the DNSSEC lookup process (12 steps), and 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 trust key, trust point, or secure entry point.</para>

  <para>The 12-step lookup process describes the DNSSEC lookup in the ideal world where every single domain name is signed and properly delegated, each validating resolver only needs to have one trust anchor, and 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 adaptation, it is not unusual for a validating resolver to have more than one trust anchor.</para>

  <para>For instance, before the root zone was signed (prior to the year 2010), some validating resolvers that wish 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 would thus be only 8 steps rather than 12 steps that look like this:</para>

  <para>
  <!-- TODO: Insert 8-step diagram here -->
  <imagedata fileref="../img/image-placeholder.jpg" align="center"/>
  
   <orderedlist>
    <!-- #1 -->
    <listitem>
     <simpara>Validating resolver queries fbi.gov name server for the A record of www.fbi.gov</simpara>
    </listitem>

    <!-- #2 -->
    <listitem>
     <simpara>FBI's name server responds with answer and RRSIG</simpara>
    </listitem>

    <!-- #3 -->
    <listitem>
     <simpara>Validating resolver queries FBI's name server for DNSKEY</simpara>
    </listitem>

    <!-- #4 -->
    <listitem>
     <simpara>FBI's name server responds with DNSKEY and RRSIG</simpara>
    </listitem>

    <!-- #5 -->
    <listitem>
     <simpara>Validating resolver queries .gov name server for DS record of fbi.gov</simpara>
    </listitem>

    <!-- #6 -->
    <listitem>
     <simpara>.gov name server responds with DS record and RRSIG for fbi.gov</simpara>
    </listitem>

    <!-- #7 -->
    <listitem>
     <simpara>Validating resolver queries .gov name server for DNSKEY</simpara>
    </listitem>

    <!-- #8 -->
    <listitem>
     <simpara>.gov name server responds with DNSKEY and RRSIG</simpara>
    </listitem>
   </orderedlist>
  </para> 

  <para>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 a trusted key (trust anchor), and never goes to the root name servers to ask for the DS record for .gov, or ask the the root name servers for its DNSKEY.</para>

  <para>In fact, whenever the validating resolver receives a DNSKEY, it checks to see if this is a trusted key, to decide whether or not it needs to continue chasing down the validation chain.</para>
 </section>


 <!-- ====== Trust Anchors and Managed Keys ====== -->
 <section id="trusted-keys-and-managed-keys">
  <title>Trusted Keys and Managed Keys</title>
  <para>So we have at least one DNSKEY on file, and it is known as a trust anchor. How did it get here, and how do we maintain it?</para>

  <para>If you followed the recommendation in <xref linkend="easy-start-guide-for-recursive-servers"/>, by setting <code>dnssec-validation</code> to <code>auto</code>, then there is nothing you need to do. BIND already includes a default key (usually in the file <code>bind.keys</code>), that will automatically update itself. It looks something like this:
   <screen>managed-keys {
    . initial-key 257 3 8 "<KEY>
    <KEY>
    <KEY>
    <KEY>
    <KEY>;
};</screen>
  </para>

  <para>You could, of course, decide to manage this key on your own by hand. First, you’ll need to make sure that your <code>dnssec-validation</code> is set to <code>yes</code>:
   <screen>options {
    dnssec-validation yes;
};</screen>
  </para>

  <para>Then make sure that you have the following <code>trust-keys</code> statement configured, after you download the root key manually from a trustworthy source. This installs the root DNSKEY. Whenever the root key changes, this file needs to be updated manually. Failing to do so will break nearly all DNS requests made to this server.<commit_msg>Update "How Trust Anchors are Used" based on feedback<commit_after><section id="trust-anchors">
 <title>Trust Anchors</title>
 <para>A trust anchor is a DNSKEY that is placed into a validating resolver so that the validator can verify the results for a given request back to a known public key (the trust anchor). A validating resolver must have at least one trust anchor installed in order to perform DNSSEC validation.</para>

 <para>BIND9 includes a copy of the root key, in the file <code>bind.keys</code>. You can download the root key manually from reputable sources such as <ulink url="https://www.isc.org/bind-keys"/>. The key file must be readable to named.</para>


 <!-- ====== How Trust Anchors are Used ====== -->
 <section id="how-trust-anchors-are-used">
  <title>How Trust Anchors are Used</title>
  <para>In the section <xref linkend="how-does-dnssec-change-dns-lookup-revisited"/>, we walked through the DNSSEC lookup process (12 steps), and 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 trust key, trust point, or secure entry point.</para>

  <para>The 12-step lookup process describes the DNSSEC lookup in the ideal world where every single domain name is signed and properly delegated, each validating resolver only needs to have one trust anchor, and 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 adaptation, it is not unusual for a validating resolver to have more than one trust anchor.</para>

  <para>For instance, before the root zone was signed (prior to the year 2010), some validating resolvers that wish 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 would thus be only 8 steps rather than 12 steps that look like this:</para>

  <para>
  <!-- TODO: Insert 8-step diagram here -->
  <imagedata fileref="../img/image-placeholder.jpg" align="center"/>
  
   <orderedlist>
    <!-- #1 -->
    <listitem>
     <simpara>Validating resolver queries <code>fbi.gov</code> name server for the A record of <code>www.fbi.gov<code>.</simpara>
    </listitem>
    <!-- #2 -->
    <listitem>
     <simpara>FBI's name server responds with answer and RRSIG.</simpara>
    </listitem>
    <!-- #3 -->
    <listitem>
     <simpara>Validating resolver queries FBI's name server for DNSKEY.</simpara>
    </listitem>
    <!-- #4 -->
    <listitem>
     <simpara>FBI's name server responds with DNSKEY and RRSIG.</simpara>
    </listitem>
    <!-- #5 -->
    <listitem>
     <simpara>Validating resolver queries <code>.gov</code> name server for DS record of <code>fbi.gov</code>.</simpara>
    </listitem>
    <!-- #6 -->
    <listitem>
     <simpara><code>.gov</code> name server responds with DS record and RRSIG for <code>fbi.gov</code>.</simpara>
    </listitem>
    <!-- #7 -->
    <listitem>
     <simpara>Validating resolver queries <code>.gov</code> name server for DNSKEY.</simpara>
    </listitem>
    <!-- #8 -->
    <listitem>
     <simpara><code>.gov</code> name server responds with DNSKEY and RRSIG.</simpara>
    </listitem>
   </orderedlist>
  </para> 

  <para>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 <code>.gov</code>, or ask the the root name servers for its DNSKEY.</para>

  <para>In fact, whenever the validating resolver receives a DNSKEY, it checks to see if this is a configured trusted key, to decide whether or not it needs to continue chasing down the validation chain.</para>
 </section>


 <!-- ====== Trust Anchors and Managed Keys ====== -->
 <section id="trusted-keys-and-managed-keys">
  <title>Trusted Keys and Managed Keys</title>
  <para>So we have at least one DNSKEY on file, and it is known as a trust anchor. How did it get here, and how do we maintain it?</para>

  <para>If you followed the recommendation in <xref linkend="easy-start-guide-for-recursive-servers"/>, by setting <code>dnssec-validation</code> to <code>auto</code>, then there is nothing you need to do. BIND already includes a default key (usually in the file <code>bind.keys</code>), that will automatically update itself. It looks something like this:
   <screen>managed-keys {
    . initial-key 257 3 8 "<KEY>
    <KEY>
    <KEY>;
};</screen>
  </para>

  <para>You could, of course, decide to manage this key on your own by hand. First, you’ll need to make sure that your <code>dnssec-validation</code> is set to <code>yes</code>:
   <screen>options {
    dnssec-validation yes;
};</screen>
  </para>

  <para>Then make sure that you have the following <code>trust-keys</code> statement configured, after you download the root key manually from a trustworthy source. This installs the root DNSKEY. Whenever the root key changes, this file needs to be updated manually. Failing to do so will break nearly all DNS requests made to this server.
{'fraction_non_alphanumeric': 0.10292991191114516, 'fraction_numerical': 0.005936422826503256, 'mean_word_length': 3.6257750221434897, 'pattern_counts': {'":': 0, '<': 229, '<?xml version=': 0, '>': 229, 'https://': 2, 'lorem ipsum': 0, 'www.': 6, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 4, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '918363', 'n_tokens_mistral': 3059, 'n_tokens_neox': 2895, 'n_words': 1386}