Extension mechanisms for DNS

For the former alternative root system called eDNS, see eDNS (alternative DNS root).

Extension mechanisms for DNS (EDNS) is a specification for expanding the size of several parameters of the Domain Name System (DNS) protocol that had size restrictions that the Internet engineering community deemed too limited in the increasing functionality of the protocol. The first set of extensions was published in 1999 by the Internet Engineering Task Force as RFC 2671, also known as EDNS0.^[1]

Motivation

The Domain Name System was first developed in the early 1980s, since which time it has been progressively enhanced with new features, while maintaining compatibility with earlier versions of the protocol.

The restrictions in size of several flags fields, return codes and label types available in the basic DNS protocol were not sufficient to support some desirable features. Moreover, DNS messages carried by UDP were restricted to 512 bytes, not considering the Internet Protocol (IP) and Transport Layer headers.^[2] Resorting to a virtual circuit transport, using the Transmission Control Protocol (TCP), would greatly increase overhead. This presented a major obstacle to adding new features to DNS. In 1999, Paul Vixie proposed extending DNS to allow for new flags and response codes, and to provide support for longer responses in a framework that is backwards compatible with previous implementations.

Mechanism

Since no new flags could be added in the DNS header, the differentiation of the new protocol extensions format was achieved with optional pseudo resource records, the OPT resource records. These are wire-only control records not appearing in any zone files. DNS endpoints insert these optional records in the communications between peers to mark a data transfer using EDNS. This provides a transparently backward compatible mechanism, as older clients without EDNS support simply ignore the new record type. DNS participants should only send EDNS requests to a DNS server if they are prepared to accept a EDNS response. Unless a client request contains an OPT record, DNS servers should not send EDNS responses.

The OPT pseudo record provides space for up to 16 additional flags and it extends the space for the response code. The overall size of the UDP packet and the version number (at present 0) are contained in the OPT record. A variable length data field allows further information to be registered in future versions of the protocol. The original DNS protocol provided two label types, which are defined by the first two bits in DNS packets (RFC 1035): 00 (standard label) and 11 (compressed label). EDNS introduces the label type 01 as extended label. The lower 6 bits of the first byte may be used to define up to 63 new extended labels.

Example

An example of an OPT pseudo-record, as displayed by the Domain Information Groper (dig) utility tool:

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096

Applications

EDNS is essential for the implementation of DNS Security Extensions (DNSSEC).^[3]

Issues

In practice, difficulties can arise when using EDNS traversing firewalls, since some older firewalls assume a maximum DNS message length of 512 bytes and block longer DNS packets.

References