<commit_before><section id="troubleshooting-examples">
 <title>Troubleshooting Examples</title>
 
 <section id="troubleshooting-example-1">
  <title>Troubleshooting Example #1</title>
  <para>Let's put what we've looked at together into an example and see the steps taken to solve the problem. We start with someone complaining that she is unable to resolve the name <code>www.example.com</code>. We use dig on her machine to verify the behavior, and we received the following output from <command>dig</command>:
   <screen>$ <userinput>dig www.example.com. A</userinput>

; &lt;&lt;>> DiG 9.10.1 &lt;&lt;>> www.example.com. A
;; global options: +cmd
;; Got answer:
;; ->>HEADER&lt;&lt;- opcode: QUERY, status: <userinput>SERVFAIL</userinput>, id: 26068
;; flags: qr rd <userinput>ra</userinput>; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

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

;; Query time: 784 msec
;; SERVER: 192.168.1.7#53(<userinput>192.168.1.7</userinput>)
;; WHEN: Mon Nov 03 20:00:45 CST 2014
;; MSG SIZE  rcvd: 44</screen></para>

  <para>We learned from this output that the recursive name server 192.168.1.7 returned a generic error message when resolving the name <code>www.example.com</code>. The next step is to look at the DNS server configuration on 192.168.1.7 to see how it is configured. Below is an excerpt of <filename>named.conf</filename> from 192.168.1.7:
   <screen>options {
    ...
    forwarders {1192.168.127.12;};
    forward only;
    ...
};</screen></para>

  <para>This tells us that the recursive name server 192.168.1.7 just sends all recursive queries to 192.168.1.11. Let's query 192.168.1.11:
   <screen>$ <userinput>dig @192.168.1.11 www.example.com. A</userinput>

; &lt;&lt;>> DiG 9.10.1 &lt;&lt;>> @192.168.1.11 www.example.com. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER&lt;&lt;- opcode: QUERY, status: <userinput>SERVFAIL</userinput>, id: 24171
;; flags: qr rd <userinput>ra</userinput>; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
...</screen></para>

  <para>And we get the same result as when we queries 192.168.1.7, generic failure message, but we also learned that 192.168.1.11 is not authoritative for <code>example.com</code> (no <code>aa</code> flag), so it is getting this response from somewhere else. Below is the configuration excerpt from 192.168.1.11:
   <screen>options {
    ...
    forwarders {};
    Forward only;
    ...
};

zone "example.com" IN {
    type forward;
    forwarders { 192.168.1.13; };
    forward only;
};</screen></para>

  <para>At first glance, it may look like 192.168.1.11 is just performing recursion itself, querying Internet name servers directly; however, further down the configuration file, we see the forward zone definition, which tell us that 192.168.1.11 is doing conditional forwarding just for <code>example.com</code>, and it is sending all example.com queries to 192.168.1.13.</para>

  <para>We then query 192.168.1.13:
   <screen>$ <userinput>dig @192.168.1.13 www.example.com. A</userinput>

; &lt;&lt;>> DiG 9.10.1 &lt;&lt;>> @192.168.1.13 www.example.com. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 35962
;; flags: qr <userinput>aa</userinput> rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

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

;; ANSWER SECTION:
www.example.com.	600	IN	A	192.168.1.100
<commit_msg>Fixed typo in example configuration file<commit_after><section id="troubleshooting-examples">
 <title>Troubleshooting Examples</title>
 
 <section id="troubleshooting-example-1">
  <title>Troubleshooting Example #1</title>
  <para>Let's put what we've looked at together into an example and see the steps taken to solve the problem. We start with someone complaining that she is unable to resolve the name <code>www.example.com</code>. We use dig on her machine to verify the behavior, and we received the following output from <command>dig</command>:
   <screen>$ <userinput>dig www.example.com. A</userinput>

; &lt;&lt;>> DiG 9.10.1 &lt;&lt;>> www.example.com. A
;; global options: +cmd
;; Got answer:
;; ->>HEADER&lt;&lt;- opcode: QUERY, status: <userinput>SERVFAIL</userinput>, id: 26068
;; flags: qr rd <userinput>ra</userinput>; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

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

;; Query time: 784 msec
;; SERVER: 192.168.1.7#53(<userinput>192.168.1.7</userinput>)
;; WHEN: Mon Nov 03 20:00:45 CST 2014
;; MSG SIZE  rcvd: 44</screen></para>

  <para>We learned from this output that the recursive name server 192.168.1.7 returned a generic error message when resolving the name <code>www.example.com</code>. The next step is to look at the DNS server configuration on 192.168.1.7 to see how it is configured. Below is an excerpt of <filename>named.conf</filename> from 192.168.1.7:
   <screen>options {
    ...
    forwarders {192.168.1.11;};
    forward only;
    ...
};</screen></para>

  <para>This tells us that the recursive name server 192.168.1.7 just sends all recursive queries to 192.168.1.11. Let's query 192.168.1.11:
   <screen>$ <userinput>dig @192.168.1.11 www.example.com. A</userinput>

; &lt;&lt;>> DiG 9.10.1 &lt;&lt;>> @192.168.1.11 www.example.com. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER&lt;&lt;- opcode: QUERY, status: <userinput>SERVFAIL</userinput>, id: 24171
;; flags: qr rd <userinput>ra</userinput>; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
...</screen></para>

  <para>And we get the same result as when we queries 192.168.1.7, generic failure message, but we also learned that 192.168.1.11 is not authoritative for <code>example.com</code> (no <code>aa</code> flag), so it is getting this response from somewhere else. Below is the configuration excerpt from 192.168.1.11:
   <screen>options {
    ...
    forwarders {};
    forward only;
    ...
};

zone "example.com" IN {
    type forward;
    forwarders { 192.168.1.13; };
    forward only;
};</screen></para>

  <para>At first glance, it may look like 192.168.1.11 is just performing recursion itself, querying Internet name servers directly; however, further down the configuration file, we see the forward zone definition, which tell us that 192.168.1.11 is doing conditional forwarding just for <code>example.com</code>, and it is sending all example.com queries to 192.168.1.13.</para>

  <para>We then query 192.168.1.13:
   <screen>$ <userinput>dig @192.168.1.13 www.example.com. A</userinput>

; &lt;&lt;>> DiG 9.10.1 &lt;&lt;>> @192.168.1.13 www.example.com. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 35962
;; flags: qr <userinput>aa</userinput> rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

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

;; ANSWER SECTION:
www.example.com.	600	IN	A	192.168.1.100

{'fraction_non_alphanumeric': 0.14754550468836183, 'fraction_numerical': 0.07404853833425262, 'mean_word_length': 4.057880055788005, 'pattern_counts': {'":': 0, '<': 119, '<?xml version=': 0, '>': 155, 'https://': 0, 'lorem ipsum': 0, 'www.': 22, 'xml': 0}, 'pii_count': 44, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '7227308', 'n_tokens_mistral': 2911, 'n_tokens_neox': 2459, 'n_words': 835}