EDNS

From Wikipedia, the free encyclopedia

 This article or section is in need of attention from an expert on the subject.

WikiProject Information technology or the Information technology Portal may be able to help recruit one.

If a more appropriate WikiProject or portal exists, please adjust this template accordingly.
For the former alternative root system called eDNS, see eDNS (alternative DNS root).

EDNS is an extension of the DNS protocol which allows DNS UDP packets larger than 500 bytes, and expands the number of flags, label types and return codes. The version of EDNS specified by RFC 2671 is known as EDNS0.

Contents

[edit] 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 flags, return codes and label types available in earlier versions of the DNS protocol were not sufficient to support some desired features. In particular, the existing restriction of DNS UDP packet size to 512 bytes presented a major obstacle to adding new features to DNS. These restrictions made an extension of the DNS packet format desirable. In 1999, Paul Vixie proposed extending DNS to allow for new flags and response codes, and to provide support for longer responses in a way which was backwards compatible with previous implementations.

[edit] Mechanism

Since no more flags were available in the DNS header, in order to differentiate between conventional and EDNS format, a so-called "pseudo resource record" was introduced, the OPT resource record. These pseudo RRs are used only on the route of transportation between DNS clients and servers, and never appear in zone files or in caches. A DNS endpoint that would like to mark a DNS packet as EDNS should insert an appropriate pseudo RR into the Additional DATA section of the DNS request or response.

The presence or absence of EDNS OPT records in DNS requests is used to signal EDNS capability in a way that allows backwards compatibility with EDNS-unaware clients and servers. DNS clients should only send an EDNS-formatted request to a DNS server if they are prepared to accept a response in EDNS format. Unless a client request contains an EDNS OPT record, DNS servers should not send EDNS-formatted responses.

Apart from marking a packet as an EDNS packet, the OPT pseudo-RR has the following functions:

  • Provides space for up to 16 additional flags
  • Extends the space for the Response code

In addition, the overall length 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.

Another extension specified in RFC 2671 refers to the label format. Originally there were two label types, which are defined by the first two bits in DNS packets (RFC 1035):

  • 00 = standard label
  • 11 = compressed label

In order to allow for a larger number of label types, the type 01 = "Extended label" is defined. The lower 6 bits of the first byte may be used to define up to 63 new extended labels.

[edit] EDNS in practice

EDNS is essential for the implementation of DNSSEC.

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

An example of an OPT pseudo-record, as displayed by the dig command-line tool:

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

[edit] References

  • RFC 2671 Extension Mechanisms for DNS (EDNS0). Paul Vixie, ISC, 1999.
Languages