EDNS

EDNS was first introduced in the 1980s when hardware limitations of that era influenced the original DNS specifications. Initially, these limitations included:

• UDP message size restricted to 512 bytes
• Response codes limited to 4 bits (values 0 to 15)
• No mechanism for DNS clients and servers to signal compatibility with newer capabilities

As networks and computers evolved, it became essential for DNS to adapt while maintaining backward compatibility. The challenge of modifying a fundamental Internet protocol was met by repurposing the additional section in the DNS message resource record structure, creating space for enhanced functionalities.

The additional section in a DNS message now supports various resource record types:

To enable extension mechanisms while preserving compatibility with existing resource records, a new concept called pseudo-resource records was introduced. This approach allows the same fields to be reinterpreted under the EDNS system.

Below is an in-depth explanation of how each resource record field in the additional section of a DNS response is repurposed:

1. Name Field:
   In EDNS, the Name field is set to the empty root domain. This contrasts with the answer section, where it contains the queried domain name.

   

2. Type Field:
   The Type field is now used for the OPT record. A value of 41 in this field indicates that extended capabilities are being requested in a DNS query.

3. Class Field:
   This field is redefined to indicate the UDP payload size. EDNS allows for an increased UDP packet size, which is important for modern network demands.

   

4. TTL Field:
   In the EDNS context, the TTL field represents the EDNS version. Currently, version 0 is stable and widely adopted, while higher version numbers are reserved for future enhancements.

   

5. Extended RCODEs:
   With EDNS, response codes can now extend beyond the original limits. Additional response code values start from 16 and upward.

6. DNSSEC Flag:
   A flag for DNSSEC is also incorporated into the EDNS structure. Details on this feature will be discussed later.

   

7. RDATA Field:
   The RDATA field now contains EDNS options and, where applicable, key-value data from records in the additional section.

   

8. RDLength Field:
   Finally, the RDLength field indicates the length of the EDNS options present within the additional section.

By utilizing OPT records, DNS signals its support for EDNS capabilities. This innovative approach allows the protocol to evolve and support new features without the need for an entirely new DNS version.

Since 2013, DNS infrastructure—including resolvers and nameservers—has been required to support EDNS. When an OPT record is detected in a request, compliant responders must include an OPT record in their responses.

One practical method to observe the OPT pseudo-section is by using the dig command. When you see "ADDITIONAL: 1" in the header, it indicates the presence of the OPT record, confirming EDNS support. For example:

$ dig kubernetes.io
; <<>> DiG 9.10.6 <<>> kubernetes.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17646
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
;; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;kubernetes.io.       IN      A

;; ANSWER SECTION:
kubernetes.io.       3600    IN      A       147.75.40.148

;; Query time: 184 msec
;; SERVER: 2806:10c0:ffff::e#53(2806:10c0:ffff:e)
;; WHEN: Sun Jan 19 01:34:20 CST 2025
;; MSG SIZE  rcvd: 58

EDNS introduces several important features:

• Extended response codes (starting from 16)
• DNS security extensions (DNSSEC)
• Client subnet information for CDN optimization

Content delivery networks (CDNs), such as those used by Netflix, utilize multiple edge locations to optimize performance by serving cached data from servers that are geographically closer to the client.

EDNS also enables larger UDP messages—up to a negotiated limit of 4096 bytes. With EDNS, clients can specify support for these larger packet sizes, reducing the need to fall back to TCP. In contrast, traditional DNS required responses larger than 512 bytes to be truncated (indicated by the TC flag) and then resent over TCP.

It is important to note that RFC 6891 specifies that for performance reasons, UDP payload sizes above 512 bytes should still consider a 512-byte baseline.

The widely recommended 4096-byte limit strikes a balance between accommodating larger responses and mitigating security risks, as higher values might expose vulnerabilities.

This evolution in DNS through EDNS provides extended functionality while ensuring backward compatibility—a crucial improvement given the continuously growing demands of the modern Internet.