Browse Prior Art Database

Extension Mechanisms for DNS (EDNS0) (RFC2671)

IP.com Disclosure Number: IPCOM000003262D
Original Publication Date: 1999-Aug-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 6 page(s) / 14K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

P. Vixie: AUTHOR

Abstract

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.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 19% of the total text.

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 Notice

Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract

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

...