Extension Mechanisms for DNS (EDNS) is a specification for expanding the size of several parameters of the Domain Name System (DNS) protocol which had size restrictions that the Internet engineering community deemed too limited for 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] which was updated by RFC 6891 in 2013 changing abbreviation slightly to EDNS(0).[2]

Motivation

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

The restrictions in the size of several flags fields, return codes and label types available in the basic DNS protocol prevented the support of some desirable features. Moreover, DNS messages carried by UDP were restricted to 512 bytes, not considering the Internet Protocol (IP) and transport layer headers.[3] 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, EDNS adds information to DNS messages in the form of pseudo-Resource Records ("pseudo-RR"s) included in the "additional data" section of a DNS message. Note that this section exists in both requests and responses.

EDNS introduces a single pseudo-RR type: OPT.

As pseudo-RRs, OPT type RRs never appear in any zone file; they exist only in messages, fabricated by the DNS participants.

The mechanism is backward compatible, because older DNS responders ignore any RR of the unknown OPT type in a request and a newer DNS responder never includes an OPT in a response unless there was one in the request. The presence of the OPT in the request signifies a newer requester that knows what to do with an OPT in the response.

The OPT pseudo-record provides space for up to 16 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 the length octet of a label (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 dig command: 

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

The result of "EDNS: version: 0" indicates full conformance with EDNS0.[4] The result "flags: do" indicates that "DNSSEC OK" is set.[5]

Applications

DNSSEC

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

EDNS Padding

There are standards for using EDNS to set how much padding should be around a DNS message.[7][8] Padding is essential when encrypting DNS, because without padding it may be possible to determine the queried domain name from the encrypted size of the query.

EDNS Keepalive

EDNS is used for indicating how long a TCP connection should be kept alive.[9]

EDNS Client Subnet (ECS)

EDNS is also used for sending general information from resolvers to name servers about clients' geographic location in the form of the EDNS Client Subnet (ECS) option.[10]

Issues

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

The introduction of EDNS made feasible the DNS amplification attack, a type of reflected denial-of-service attack, since EDNS facilitates very large response packets compared to relatively small request packets.

The IETF DNS Extensions working group (dnsext) has finished work on a refinement of EDNS0, which has been published as RFC 6891.

References

  1. ^ RFC 2671, Extension Mechanisms for DNS (EDNS0), P. Vixie, The Internet Society (August 1999)
  2. ^ RFC 6891, Extension Mechanisms for DNS (EDNS(0)), J. Damas, M. Graff, P. Vixie, (April 2013)
  3. ^ RFC 1035, Domain Names - Implementation and Specification, P. Mockapetris (November 1987)
  4. ^ Network Working Group of the IETF, August 1999, RFC 2671: Extension Mechanisms for DNS (EDNS0), page 3, Full conformance with this specification is indicated by version "0."
  5. ^ Network Working Group of the IETF, December 2001, RFC 3225: Indicating Resolver Support of DNSSEC, page 3, The mechanism chosen for the explicit notification of the ability of the client to accept (if not understand) DNSSEC security RRs is using the most significant bit of the Z field on the EDNS0 OPT header in the query. This bit is referred to as the "DNSSEC OK" (DO) bit.
  6. ^ RFC 4035, Protocol Modifications for the DNS Security Extensions, R. Arends, Telematica Instituut, 2005. Section 4.1 EDNS Support
  7. ^ Mayrhofer, Alexander (May 2016). "RFC 7830: The EDNS(0) Padding Option". tools.ietf.org. Retrieved 2018-02-02.
  8. ^ Mayrhofer, Alexander (October 2018). "RFC 8467: Padding Policies for Extension Mechanisms for DNS (EDNS(0))". tools.ietf.org. Retrieved 2018-10-01.
  9. ^ Wouters, Paul (April 2016). "RFC 7828: The edns-tcp-keepalive EDNS0 Option". tools.ietf.org. Retrieved 2018-02-02.
  10. ^ Contavalli, Carlo (May 2016). "RFC 7871: Client Subnet in DNS Queries". tools.ietf.org. Retrieved 2018-02-02.

See also

Categories