Extension Mechanisms for DNS (EDNS0) (RFC2671)
Original Publication Date: 1999-Aug-01
Included in the Prior Art Database: 2000-Sep-13
Internet Society Requests For Comment (RFCs)
The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow clients to advertise their capabilities to servers. This document describes backward compatible mechanisms for allowing the protocol to grow.
Network Working Group P. Vixie
Request for Comments: 2671 ISC
Category: Standards Track August 1999
Extension Mechanisms for DNS (EDNS0)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (1999). All Rights Reserved.
The Domain Name System's wire protocol includes a number of fixed
fields whose range has been or soon will be exhausted and does not
allow clients to advertise their capabilities to servers. This
document describes backward compatible mechanisms for allowing the
protocol to grow.
1 - Rationale and Scope
1.1. DNS (see [RFC1035]) specifies a Message Format and within such
messages there are standard formats for encoding options, errors,
and name compression. The maximum allowable size of a DNS Message
is fixed. Many of DNS's protocol limits are too small for uses
which are or which are desired to become common. There is no way
for implementations to advertise their capabilities.
1.2. Existing clients will not know how to interpret the protocol
extensions detailed here. In practice, these clients will be
upgraded when they have need of a new feature, and only new
features will make use of the extensions. We must however take
account of client behaviour in the face of extra fields, and design
a fallback scheme for interoperability with these clients.
2 - Affected Protocol Elements
2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit
word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of
1-bit flags. The original reserved Z bits have been allocated to
various purposes, and most of the RCODE values are now in use.
More flags and more possible RCODEs are needed.
2.2. The first two bits of a wire format domain label are used to denote
the type of the label. [RFC1035 4.1.4] allocates two of the four
possible types and reserves the other two. Proposals for use of
the remaining types far outnumber those available. More label
types are needed.
2.3. DNS Messages are limited to 512 octets in size when sent over UDP.
While the minimum maximum reassembly buffer size still allows a
limit of 512 octets of UDP payload, most of the hosts now connected
to the Internet are able to reassemble larger datagrams. Some
mechanism must be created to allow requestors to advertise larger
buffer sizes to responders.
3 - Extended Label Types
3.1. The "0 1" label type will now indicate an extended label type,
whose value is e...