<commit_before><section id="whats-edns0-all-about">
 <title>What's EDNS All About (And Why Should I Care)?</title>

 <!-- ====== Overview ====== -->
 <section id="whats-edns0-all-about-overview">
  <title>EDNS Overview</title>

  <para>Traditional DNS responses are typically small in size (less than 512
  bytes) and fit nicely into a small UDP packet. Extension
  mechanism for DNS (EDNS, or EDNS(0)) gives us a mechanism to send DNS
  data in larger packets over UDP. In order to support EDNS, both
  the DNS server and the network need to be properly prepared to support
  the larger packet size and multiple fragments.</para>

  <para>This is important for DNSSEC, since the <command>+do</command> bit that
  signals DNSSEC-awareness is carried within EDNS, and DNSSEC responses are larger
  than traditional DNS.  If DNS servers and 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 unable to resolve certain names at
  all.</para>

  <para>Note that EDNS applies whether or not you are validating
  DNSSEC because BIND has DNSSEC enabled by default.</para>

  <para>Please see <xref linkend="network-requirements"/> for more
  information on what DNSSEC expects from the network environment.</para>

 </section>

 <!-- ====== EDNS on DNS Servers ====== -->
 <section id="edns-on-dns-servers">
  <title>EDNS on DNS Servers</title>
  <para>BIND has been shipped with EDNS enabled by default for over a
  decade, and the UDP packet size is set to a maximum of 4096 bytes.
  So as the DNS administrator, there should not be any re-configuration
  needed. You can use <command>dig</command> to verify that your server
  supports EDNS and the UDP packet size it is allowing as follows:

   <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: 63266
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
<userinput>; EDNS: version: 0, flags: do; udp: 4096</userinput>
;; QUESTION SECTION:
;www.isc.org.		IN A

;; ANSWER SECTION:
www.isc.org.		23 IN A	172.16.58.3
www.isc.org.		23 IN RRSIG A 5 3 60 (
				20141029233238 20140929233238 4521 isc.org.
				DX5BaGVd4KzU2AIH911Kar/UmdmkARyPhJVLr0oyPZaq
				5zoobGqFI4efvzL0mcpncuUg3BSU5Q48WdBu92xinMdb
				E75zl+adgEBOsFgFQR/zqM3myt/8SngWm4+TQ3XFh9eN
				jqExHZZuZ268Ntlxqgf9OmKRRv8X8YigaPShuyU= )

;; Query time: 7 msec
;; SERVER: 192.168.1.7#53(192.168.1.7)
;; WHEN: Fri Oct 03 16:31:33 CST 2014
;; MSG SIZE  rcvd: 223</screen>

  </para>

  <para>There is a helpful testing tool available (provided by DNS-OARC)
  that you can use to verify resolver behavior regarding EDNS support:
  <ulink url="https://www.dns-oarc.net/oarc/services/replysizetest/"
  /></para>

  <para>So you made sure 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 you forward to) does not support EDNS, you will still
  experience packet fragmentation.</para>

<!-- TODO: If an upstream server doesn't support
EDNS then you will NOT get fragmentation? -->

<!-- TODO: also if doesn't support EDNS, then won't get DNSSEC -->

 </section>

 <!-- ====== Support for Large Packets on Network Equipment ====== -->
 <section id="support-for-large-packets-on-network-equipment">
  <title>Support for Large Packets on Network Equipment</title>
  <para>Okay, so both your recursive name server and your ISP's name
  servers support EDNS, we are all good here, right? Not so fast. As these
  large packets have to traverse through the network, the network
  infrastructure itself must allow them to pass.</para>

  <para>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 Maximum
  Transmission Units (MTU), and it can be different from network to
  network. IP fragmentation occurs when a large data packet needs to be
  broken down into smaller chunks so that each chunk is smaller than the
  MTU, and these smaller chunks need to be reassembled back into the large<commit_msg>correct text about fragmentation<commit_after><section id="whats-edns0-all-about">
 <title>What's EDNS All About (And Why Should I Care)?</title>

 <!-- ====== Overview ====== -->
 <section id="whats-edns0-all-about-overview">
  <title>EDNS Overview</title>

  <para>Traditional DNS responses are typically small in size (less than 512
  bytes) and fit nicely into a small UDP packet. Extension
  mechanism for DNS (EDNS, or EDNS(0)) gives us a mechanism to send DNS
  data in larger packets over UDP. In order to support EDNS, both
  the DNS server and the network need to be properly prepared to support
  the larger packet size and multiple fragments.</para>

  <para>This is important for DNSSEC, since the <command>+do</command> bit that
  signals DNSSEC-awareness is carried within EDNS, and DNSSEC responses are larger
  than traditional DNS.  If DNS servers and 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 unable to resolve certain names at
  all.</para>

  <para>Note that EDNS applies whether or not you are validating
  DNSSEC because BIND has DNSSEC enabled by default.</para>

  <para>Please see <xref linkend="network-requirements"/> for more
  information on what DNSSEC expects from the network environment.</para>

 </section>

 <!-- ====== EDNS on DNS Servers ====== -->
 <section id="edns-on-dns-servers">
  <title>EDNS on DNS Servers</title>
  <para>BIND has been shipped with EDNS enabled by default for over a
  decade, and the UDP packet size is set to a maximum of 4096 bytes.
  So as the DNS administrator, there should not be any re-configuration
  needed. You can use <command>dig</command> to verify that your server
  supports EDNS and the UDP packet size it is allowing as follows:

   <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: 63266
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
<userinput>; EDNS: version: 0, flags: do; udp: 4096</userinput>
;; QUESTION SECTION:
;www.isc.org.		IN A

;; ANSWER SECTION:
www.isc.org.		23 IN A	172.16.58.3
www.isc.org.		23 IN RRSIG A 5 3 60 (
				20141029233238 20140929233238 4521 isc.org.
				DX5BaGVd4KzU2AIH911Kar/UmdmkARyPhJVLr0oyPZaq
				5zoobGqFI4efvzL0mcpncuUg3BSU5Q48WdBu92xinMdb
				E75zl+adgEBOsFgFQR/zqM3myt/8SngWm4+TQ3XFh9eN
				jqExHZZuZ268Ntlxqgf9OmKRRv8X8YigaPShuyU= )

;; Query time: 7 msec
;; SERVER: 192.168.1.7#53(192.168.1.7)
;; WHEN: Fri Oct 03 16:31:33 CST 2014
;; MSG SIZE  rcvd: 223</screen>

  </para>

  <para>There is a helpful testing tool available (provided by DNS-OARC)
  that you can use to verify resolver behavior regarding EDNS support:
  <ulink url="https://www.dns-oarc.net/oarc/services/replysizetest/"
  /></para>

  <para>So you made sure 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 you forward to) does not support EDNS, you may experience
  DNS lookup failures or be unable to perform DNSSEC validation.</para>

 </section>

 <!-- ====== Support for Large Packets on Network Equipment ====== -->
 <section id="support-for-large-packets-on-network-equipment">
  <title>Support for Large Packets on Network Equipment</title>
  <para>Okay, so both your recursive name server and your ISP's name
  servers support EDNS, we are all good here, right? Not so fast. As these
  large packets have to traverse through the network, the network
  infrastructure itself must allow them to pass.</para>

  <para>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 Maximum
  Transmission Units (MTU), and it can be different from network to
  network. IP fragmentation occurs when a large data packet needs to be
  broken down into smaller chunks so that each chunk is smaller than the
  MTU, and these smaller chunks need to be reassembled back into the large
{'fraction_non_alphanumeric': 0.09261094593106486, 'fraction_numerical': 0.034577689681753114, 'mean_word_length': 4.020453289110005, 'pattern_counts': {'":': 0, '<': 97, '<?xml version=': 0, '>': 109, 'https://': 2, 'lorem ipsum': 0, 'www.': 12, 'xml': 0}, 'pii_count': 10, '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': '238679', 'n_tokens_mistral': 3205, 'n_tokens_neox': 2831, 'n_words': 1203}