<commit_before><!-- === How To Test Recursive Server === -->
<section id="how-to-test-recursive-server">
 <title>How To Test Recursive Server (So You Think You Are Validating)</title>
 <para>Okay, so 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 suggestions below, starting with the easiest.</para>


 <!-- ====== Using Web-based Tools to Verify ===== -->
 <section id="using-web-based-tests-to-verify">
  <title>Using Web-based Tools to Verify</title>
  <para>For most people, the simplest way to check if the recursive name server
  is indeed validating DNS queries, is to use one of the many web-based
  tools.</para>

  <para>Configure your client computer to use the newly reconfigured recursive
  server for DNS resolution, and then you can use any one of these
  web-based tests to see if it is in fact validating answers DNS
  responses.

   <itemizedlist>
    <listitem>
     <ulink url="http://dnssectest.sidnlabs.nl/" />
    </listitem>
    <listitem>
     <ulink url="http://test.dnssec-or-not.com/" />
    </listitem>
    <listitem>
     <ulink url="http://dnssec.vs.uni-due.de/" />
    </listitem>
   </itemizedlist>
  </para>

  <para>For example, opening the URL <ulink
  url="http://dnssectest.sidnlabs.nl/" /> in your web browser will show the
  following before (left) and after (right) DNSSEC validation is enabled:</para>

  <figure>
   <title>DNSSEC Web-based Tests</title>
   <mediaobject>
    <imageobject>
     <imagedata fileref="../img/dnssec-test.png" width="80%" scalefit="1"/>
    </imageobject>
   </mediaobject>
  </figure>

 </section>


 <!-- ====== Using dig to Verify ===== -->
 <section id="using-dig-to-verify">
  <title>Using dig to Verify</title>
  <para>The web-based 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.</para>

  <para>While nslookup is popular, partly because it comes pre-installed on
  most systems, it is not DNSSEC-aware. The Domain Information Groper
  (<command>dig</command>), 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 web site.
  ISC provides pre-compiled Windows versions on its web site.</para>
  
  <para><command>dig</command> is a flexible tool for interrogating DNS name
  servers. It performs DNS lookups and displays the answers that are returned
  from the name server(s) that were queried. Most seasoned DNS administrators
  use <command>dig</command> to troubleshoot DNS problems because of its
  flexibility, ease of use, and clarity of output.</para>

  <para>The example below shows using dig to query the name server 192.168.1.7
  for the A record for <code>www.isc.org</code> before DNSSEC validation is
  enabled. The address 192.168.1.7 is only used as an example, you should
  replace this address with the actual address or host name of your recursive
  name server. Notice although we specifically used the <option> +dnssec
  </option> code line option, we do not see the DNSSEC OK (<code>do</code>) bit
  in the response, nor do we see any DNSSEC resource records.</para>

  <screen>$ <userinput>dig @192.168.1.7 www.isc.org. A +dnssec +multiline</userinput>
; &lt;&lt;>> DiG 9.10.0-P2 &lt;&lt;>> @192.168.1.7 www.isc.org. A +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 20416
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.isc.org.			IN	A

;; ANSWER SECTION:
www.isc.org.		60	IN	A	192.168.127.12</screen>

  <para>Below shows what the results look like querying the same server
  (192.168.1.7) after enabling DNSSEC validation. The exact same command is
  run, and this time notice three key differences, 1) the presence of the
  Authenticated Data (<code>ad</code>) flag in the header, 2) the DNSSEC OK
  (<code>do</code>) flag indicating the recursive server is DNSSEC-aware, and
  3) an additional resource record of type RRSIG, with the same name as the A
  record.</para>

  <screen>$ <userinput>dig @192.168.1.7 www.isc.org. A +dnssec +multiline</userinput>

; &lt;&lt;>> DiG 9.10.0-P2 &lt;&lt;>> @192.168.1.7 www.isc.org. A +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 32472<commit_msg>Expanded on the AD and DO bit<commit_after><!-- === How To Test Recursive Server === -->
<section id="how-to-test-recursive-server">
 <title>How To Test Recursive Server (So You Think You Are Validating)</title>
 <para>Okay, so 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 suggestions below, starting with the easiest.</para>


 <!-- ====== Using Web-based Tools to Verify ===== -->
 <section id="using-web-based-tests-to-verify">
  <title>Using Web-based Tools to Verify</title>
  <para>For most people, the simplest way to check if the recursive name server
  is indeed validating DNS queries, is to use one of the many web-based
  tools.</para>

  <para>Configure your client computer to use the newly reconfigured recursive
  server for DNS resolution, and then you can use any one of these
  web-based tests to see if it is in fact validating answers DNS
  responses.

   <itemizedlist>
    <listitem>
     <ulink url="http://dnssectest.sidnlabs.nl/" />
    </listitem>
    <listitem>
     <ulink url="http://test.dnssec-or-not.com/" />
    </listitem>
    <listitem>
     <ulink url="http://dnssec.vs.uni-due.de/" />
    </listitem>
   </itemizedlist>
  </para>

  <para>For example, opening the URL <ulink
  url="http://dnssectest.sidnlabs.nl/" /> in your web browser will show the
  following before (left) and after (right) DNSSEC validation is enabled:</para>

  <figure>
   <title>DNSSEC Web-based Tests</title>
   <mediaobject>
    <imageobject>
     <imagedata fileref="../img/dnssec-test.png" width="80%" scalefit="1"/>
    </imageobject>
   </mediaobject>
  </figure>

 </section>


 <!-- ====== Using dig to Verify ===== -->
 <section id="using-dig-to-verify">
  <title>Using dig to Verify</title>
  <para>The web-based 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.</para>

  <para>While nslookup is popular, partly because it comes pre-installed on
  most systems, it is not DNSSEC-aware. The Domain Information Groper
  (<command>dig</command>), 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 web site.
  ISC provides pre-compiled Windows versions on its web site.</para>
  
  <para><command>dig</command> is a flexible tool for interrogating DNS name
  servers. It performs DNS lookups and displays the answers that are returned
  from the name server(s) that were queried. Most seasoned DNS administrators
  use <command>dig</command> to troubleshoot DNS problems because of its
  flexibility, ease of use, and clarity of output.</para>

  <para>The example below shows using dig to query the name server 192.168.1.7
  for the A record for <code>www.isc.org</code> before DNSSEC validation is
  enabled. The address 192.168.1.7 is only used as an example, you should
  replace this address with the actual address or host name of your recursive
  name server. Notice although we specifically used the <option> +dnssec
  </option> code line option, we do not see the DNSSEC OK (<code>do</code>) bit
  in the response, nor do we see any DNSSEC resource records.</para>

  <screen>$ <userinput>dig @192.168.1.7 www.isc.org. A +dnssec +multiline</userinput>
; &lt;&lt;>> DiG 9.10.0-P2 &lt;&lt;>> @192.168.1.7 www.isc.org. A +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 20416
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.isc.org.			IN	A

;; ANSWER SECTION:
www.isc.org.		60	IN	A	192.168.127.12</screen>

  <para>Below shows what the results look like querying the same server
  (192.168.1.7) after enabling DNSSEC validation. The exact same command is
  run, and this time notice three key differences:
   <orderedlist>
    <listitem>
     <simpara>The presence of the Authenticated Data (<code>ad</code>) flag in
     the header</simpara>
    </listitem>
    <listitem>
     <simpara>The DNSSEC OK (<code>do</code>) flag indicating the recursive
     server is DNSSEC-aware</simpara>
    </listitem>
    <listitem>
     <simpara>An additional resource record of type RRSIG, with the same name
     as the A record.</simpara>
    </listitem>
   </orderedlist>
  </para>

  <para>The DNSSEC OK (<code>do</code>) flag tells us that the recursive server
  we are querying (192.168.1.7 in this example) is DNSSEC-aware. That its
  administrator has enabled DNSSEC on the name server to perform validation.
  The Authenticated Data (<code>ad</code>) flag tells us that the answer
  received has passed the validation process as described in <xref
  linkend="how-are-answers-verified" />. We can have confidence in the
  authenticity and integrity of the answer that <code>www.isc.org</code> really
  points to the IP address 192.168.127.12, and it was not a spoofed answer from a
  clever attacker.</para>

  <screen>$ <userinput>dig @192.168.1.7 www.isc.org. A +dnssec +multiline</userinput>

; &lt;&lt;>> DiG 9.10.0-P2 &lt;&lt;>> @192.168.1.7 www.isc.org. A +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 32472
{'fraction_non_alphanumeric': 0.11530297182554998, 'fraction_numerical': 0.021999228097259745, 'mean_word_length': 3.724247948951686, 'pattern_counts': {'":': 0, '<': 176, '<?xml version=': 0, '>': 200, 'https://': 0, 'lorem ipsum': 0, 'www.': 15, 'xml': 0}, 'pii_count': 18, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2248334', 'n_tokens_mistral': 3483, 'n_tokens_neox': 3210, 'n_words': 1300}