EDNS

Encyclopedia : E : ED : EDN : EDNS

This article or section is in need of attention from an expert on the subject.
Please help recruit one, or improve this page yourself}} if you can. See [discussion page] for details.

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

EDNS is an extension of the DNS protocol which allows more flags, label types and retun codes to be defined, and enhances the transport of DNS data in UDP packets. The current version of EDNS is known as EDNS0.

Contents

1 Motivation
2 Mechanism
3 EDNS in practice
4 References

Motivation

The Doman Name System was developed in the first half of the 1980s, since which time it has been progressively enhanced with new features, without breaking compatibility to earlier version 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 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 package format inevitable. In 1999, Paul Vixie proposed extending DNS in RFC 2671 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.

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 appears in zone files or in caches. A DNS endpoint who would like to mark a DNS package as EDNS, inserts 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 non-EDNS-aware 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 ENDS-formatted responses.

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

Supply of 16 additional flags
Extension of the Response code

In addition the overall length of the UDP package and the version number (at present 0) are contained in the OPT record. In a variable length data field further information can be registered in future.

A further 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 packages (RFC 1035):

00 = standard label
11 = compressed label

In order to make a larger number possible of further label types, the type 01 = "Extended label" is defined. From the following 6 bits of the first byte thereby altogether 63 label subtypes can be formed.

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

References

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

From Wikipedia, the Free Encyclopedia. Original article here. Support Wikipedia by contributing or donating.
All text is available under the terms of the GNU Free Documentation License See Wikipedia Copyrights for details.