mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-29 13:38:26 +00:00
Code Issues Releases Wiki Activity

remove

Browse Source
This commit is contained in:
Bob Halley 1999-08-27 01:34:01 +00:00
parent 35a7ec9864
commit 10a05eabf2
3 changed files with 0 additions and 1158 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

337
doc/draft/draft-ietf-dnsind-binary-labels-05.txt
View File

@ -1,337 +0,0 @@
DNSIND Working Group Matt Crawford
Internet Draft Fermilab
May 5, 1999
Binary Labels in the Domain Name System
<draft-ietf-dnsind-binary-labels-05.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Introduction and Terminology
This document defines a ``Bit-String Label'' which may appear within
domain names. This new label type compactly represents a sequence
of ``One-Bit Labels'' and enables resource records to be stored at
any bit-boundary in a binary-named section of the domain name tree.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KWORD].
2. Motivation
Binary labels are intended to efficiently solve the problem of
storing data and delegating authority on arbitrary boundaries when
the structure of underlying name space is most naturally represented
in binary.
Expires November 10, 1999 Crawford [Page 1]
Internet Draft Binary DNS Labels May 5, 1999
3. Label Format
Up to 256 One-Bit Labels can be grouped into a single Bit-String
Label. Within a Bit-String Label the most significant or "highest
level" bit appears first. This is unlike the ordering of DNS labels
themselves, which has the least significant or "lowest level" label
first. Nonetheless, this ordering seems to be the most natural and
efficient for representing binary labels.
Among consecutive Bit-String Labels, the bits in the first-appearing
label are less significant or "at a lower level" than the bits in
subsequent Bit-String Labels, just as ASCII labels are ordered.
3.1. Encoding
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+
|0 1| ELT | Count | Label ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+
(Each tic mark represents one bit.)
ELT 000001 binary, the six-bit extended label type [EDNS0]
assigned to the Bit-String Label.
Count The number of significant bits in the Label field. A
Count value of zero indicates that 256 bits are
significant. (Thus the null label representing the DNS
root cannot be represented as a Bit String Label.)
Label The bit string representing a sequence of One-Bit Labels,
with the most significant bit first. That is, the One-Bit
Label in position 17 in the diagram above represents a
subdomain of the domain represented by the One-Bit Label
in position 16, and so on.
The Label field is padded on the right with zero to seven
pad bits to make the entire field occupy an integral
number of octets. These pad bits MUST be zero on
transmission and ignored on reception.
A sequence of bits may be split into two or more Bit-String Labels,
but the division points have no significance and need not be
preserved. An excessively clever server implementation might split
Expires November 10, 1999 Crawford [Page 2]
Internet Draft Binary DNS Labels May 5, 1999
Bit-String Labels so as to maximize the effectiveness of message
compression [DNSIS]. A simpler server might divide Bit-String
Labels at zone boundaries, if any zone boundaries happen to fall
between One-Bit Labels.
3.2. Textual Representation
A Bit-String Label is represented in text -- in a zone file, for
example -- as a <bit-spec> surrounded by the delimiters "\[" and
"]". The <bit-spec> is either a dotted quad or a base indicator and
a sequence of digits appropriate to that base, optionally followed
by a slash and a length. The base indicators are "b", "o" and "x",
denoting base 2, 8 and 16 respectively. The length counts the
significant bits and MUST be between 1 and 32, inclusive, after a
dotted quad, or between 1 and 256, inclusive, after one of the other
forms. If the length is omitted, the implicit length is 32 for a
dotted quad or 1, 3 or 4 times the number of binary, octal or
hexadecimal digits supplied, respectively, for the other forms.
In augmented Backus-Naur form [ABNF],
bit-string-label = "\[" bit-spec "]"
bit-spec = bit-data [ "/" length ]
/ dotted-quad [ "/" slength ]
bit-data = "x" 1*64HEXDIG
/ "o" 1*86OCTDIG
/ "b" 1*256BIT
dotted-quad = decbyte "." decbyte "." decbyte "." decbyte
decbyte = 1*3DIGIT
length = NZDIGIT *2DIGIT
slength = NZDIGIT [ DIGIT ]
OCTDIG = %x30-37
NZDIGIT = %x31-39
If a <length> is present, the number of digits in the <bit-data>
MUST be just sufficient to contain the number of bits specified by
the <length>. If there are insignificant bits in a final
hexadecimal or octal digit, they MUST be zero. A <dotted-quad>
always has all four parts even if the associated <slength> is less
Expires November 10, 1999 Crawford [Page 3]
Internet Draft Binary DNS Labels May 5, 1999
than 24, but, like the other forms, insignificant bits MUST be zero.
Each number represented by a <decbyte> must be between 0 and 255,
inclusive.
The number represented by <length> must be between 1 and 256
inclusive.
The number represented by <slength> must be between 1 and 32
inclusive.
When the textual form of a Bit-String Label is generated by machine,
the length SHOULD be explicit, not implicit.
3.2.1. Examples
The following four textual forms represent the same Bit-String
Label.
\[b11010000011101]
\[o64072/14]
\[xd074/14]
\[208.116.0.0/14]
The following represents two consecutive Bit-String Labels which
denote the same relative point in the DNS tree as any of the above
single Bit-String Labels.
\[b11101].\[o640]
3.3. Canonical Representation and Sort Order
Both the wire form and the text form of binary labels have a degree
of flexibility in their grouping into multiple consecutive Bit-
String Labels. For generating and checking DNS signature records
[DNSSEC] binary labels must be in a predictable form. This
canonical form is defined as the form which has the fewest possible
Bit-String Labels and in which all except possibly the first (least
significant) label in any sequence of consecutive Bit-String Labels
is of maximum length.
For example, the canonical form of any sequence of up to 256 One-Bit
Labels has a single Bit-String Label, and the canonical form of a
sequence of 513 to 768 One-Bit Labels has three Bit-String Labels of
which the second and third contain 256 label bits.
Expires November 10, 1999 Crawford [Page 4]
Internet Draft Binary DNS Labels May 5, 1999
The canonical sort order of domain names [DNSSEC] is extended to
encompass binary labels as follows. Sorting is still label-by-
label, from most to least significant, where a label may now be a
One-Bit Label or a standard (code 00) label. Any One-Bit Label
sorts before any standard label, and a 0 bit sorts before a 1 bit.
The absence of a label sorts before any label, as specified in
[DNSSEC].
For example, the following domain names are correctly sorted.
foo.example
\[b1].foo.example
\[b100].foo.example
\[b101].foo.example
bravo.\[b10].foo.example
alpha.foo.example
4. Processing Rules
A One-Bit Label never matches any other kind of label. In
particular, the DNS labels represented by the single ASCII
characters "0" and "1" do not match One-Bit Labels represented by
the bit values 0 and 1.
5. Discussion
A Count of zero in the wire-form represents a 256-bit sequence, not
to optimize that particular case, but to make it completely
impossible to have a zero-bit label.
6. IANA Considerations
This document defines one Extended Label Type, termed the Bit-String
Label, and requests registration of the code point 000001 binary in
the space defined by [EDNS0].
7. Security Considerations
All security considerations which apply to traditional ASCII DNS
labels apply equally to binary labels. he canonicalization and
sorting rules of section 3.3 allow these to be addressed by DNS
Security [DNSSEC].
Expires November 10, 1999 Crawford [Page 5]
Internet Draft Binary DNS Labels May 5, 1999
8. References
[ABNF] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234.
[DNSIS] P.V. Mockapetris, "Domain names - implementation and
specification", RFC 1035.
[DNSSEC]D. Eastlake, 3rd, C. Kaufman, "Domain Name System Security
Extensions", RFC 2065.
[EDNS0] P. Vixie, "Extension mechanisms for DNS (EDNS0)", Currently
draft-dnsind-edns0-01.txt.
[KWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119.
9. Author's Address
Matt Crawford
Fermilab MS 368
PO Box 500
Batavia, IL 60510
USA
Phone: +1 630 840-3461
EMail: crawdad@fnal.gov
Expires November 10, 1999 Crawford [Page 6]

502
doc/draft/draft-ietf-dnsind-dname-03.txt
View File

@ -1,502 +0,0 @@
DNSIND Working Group Matt Crawford
Internet Draft Fermilab
March 21, 1999
Non-Terminal DNS Name Redirection
<draft-ietf-dnsind-dname-03.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress."
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
1. Introduction
This document defines a new DNS Resource Record called ``DNAME'',
which provides the capability to map an entire subtree of the DNS
name space to another domain. It differs from the CNAME record
which maps a single node of the name space.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KWORD].
2. Motivation
This Resource Record and its processing rules were conceived as a
solution to the problem of maintaining address-to-name mappings in a
context of network renumbering. Without the DNAME mechanism, an
authoritative DNS server for the address-to-name mappings of some
network must be reconfigured when that network is renumbered. With
DNAME, the zone can be constructed so that it needs no modification
when renumbered. DNAME can also be useful in other situations, such
as when an organizational unit is renamed.
Expires September 26, 1999 Crawford [Page 1]
Internet Draft Non-Terminal Nicknames March 21, 1999
3. The DNAME Resource Record
The DNAME RR has mnemonic DNAME and type code 39 (decimal).
DNAME has the following format:
<owner> <ttl> <class> DNAME <target>
The format is not class-sensitive. All fields are required. The
RDATA field <target> is a <domain-name> [DNSIS].
The DNAME RR causes type NS additional section processing.
The effect of the DNAME record is the substitution of the record's
<target> for its <owner> as a suffix of a domain name. A "no-
descendants" limitation governs the use of DNAMEs in a zone file:
If a DNAME RR is present at a node N, there may be other data at
N (except a CNAME or another DNAME), but there MUST be no data
at any descendant of N. This restriction applies only to
records of the same class as the DNAME record.
This rule assures predictable results when a DNAME record is cached
by a server which is not authoritative for the record's zone. It
MUST be enforced when authoritative zone data is loaded. Together
with the rules for DNS zone authority [DNSCLR] it implies that DNAME
and NS records can only coexist at the top of a zone which has only
one node.
The compression scheme of [DNSIS] MUST NOT be applied to the RDATA
portion of a DNAME record unless the sending server has some way of
knowing that the receiver understands the DNAME record format.
Signalling such understanding is expected to be the subject of
future DNS Extensions.
Naming loops can be created with DNAME records or a combination of
DNAME and CNAME records, just as they can with CNAME records alone.
Resolvers, including resolvers embedded in DNS servers, MUST limit
the resources they devote to any query. Implementors should note,
however, that fairly lengthy chains of DNAME records may be valid.
4. Query Processing
To exploit the DNAME mechanism the name resolution algorithms
[DNSCF] must be modified slightly for both servers and resolvers.
Both modified algorithms incorporate the operation of making a
Expires September 26, 1999 Crawford [Page 2]
Internet Draft Non-Terminal Nicknames March 21, 1999
substitution on a name (either QNAME or SNAME) under control of a
DNAME record. This operation will be referred to as "the DNAME
substitution".
4.1. Processing by Servers
For a server performing non-recursive service steps 3.c and 4 of
section 4.3.2 [DNSCF] are changed to check for a DNAME record before
checking for a wildcard ("*") label, and to return certain DNAME
records from zone data and the cache.
DNS clients sending Extended DNS [EDNS0] queries with Version 0 or
non-extended queries are presumed not to understand the semantics of
the DNAME record, so a server which implements this specification,
when answering a non-extended query, SHOULD synthesize a CNAME
record for each DNAME record encountered during query processing to
help the client reach the correct DNS data. The behavior of clients
and servers under Extended DNS versions greater than 0 will be
specified when those versions are defined.
The synthesized CNAME RR, if provided, MUST have
The same CLASS as the QCLASS of the query,
TTL equal to zero,
An <owner> equal to the QNAME in effect at the moment the DNAME
RR was encountered, and
An RDATA field containing the new QNAME formed by the action of
the DNAME substitution.
If the server has the appropriate key on-line [DNSSEC, SECDYN], it
MAY generate and return a SIG RR for the synthesized CNAME RR.
The revised server algorithm is:
1. Set or clear the value of recursion available in the response
depending on whether the name server is willing to provide
recursive service. If recursive service is available and
requested via the RD bit in the query, go to step 5, otherwise
step 2.
2. Search the available zones for the zone which is the nearest
ancestor to QNAME. If such a zone is found, go to step 3,
otherwise step 4.
Expires September 26, 1999 Crawford [Page 3]
Internet Draft Non-Terminal Nicknames March 21, 1999
3. Start matching down, label by label, in the zone. The matching
process can terminate several ways:
a. If the whole of QNAME is matched, we have found the node.
If the data at the node is a CNAME, and QTYPE doesn't match
CNAME, copy the CNAME RR into the answer section of the
response, change QNAME to the canonical name in the CNAME
RR, and go back to step 1.
Otherwise, copy all RRs which match QTYPE into the answer
section and go to step 6.
b. If a match would take us out of the authoritative data, we
have a referral. This happens when we encounter a node with
NS RRs marking cuts along the bottom of a zone.
Copy the NS RRs for the subzone into the authority section
of the reply. Put whatever addresses are available into the
additional section, using glue RRs if the addresses are not
available from authoritative data or the cache. Go to step
4.
c. If at some label, a match is impossible (i.e., the
corresponding label does not exist), look to see whether the
last label matched has a DNAME record.
If a DNAME record exists at that point, copy that record
into the answer section. If substitution of its <target>
for its <owner> in QNAME would overflow the legal size for a
<domain-name>, set RCODE to YXDOMAIN [DNSUPD] and exit;
otherwise perform the substitution and continue. If the
query was not extended [EDNS0] with a Version indicating
understanding of the DNAME record, the server SHOULD
synthesize a CNAME record as described above and include it
in the answer section. Go back to step 1.
If there was no DNAME record, look to see if the "*" label
exists.
If the "*" label does not exist, check whether the name we
are looking for is the original QNAME in the query or a name
we have followed due to a CNAME. If the name is original,
set an authoritative name error in the response and exit.
Otherwise just exit.
If the "*" label does exist, match RRs at that node against
QTYPE. If any match, copy them into the answer section, but
Expires September 26, 1999 Crawford [Page 4]
Internet Draft Non-Terminal Nicknames March 21, 1999
set the owner of the RR to be QNAME, and not the node with
the "*" label. Go to step 6.
4. Start matching down in the cache. If QNAME is found in the
cache, copy all RRs attached to it that match QTYPE into the
answer section. If QNAME is not found in the cache but a DNAME
record is present at an ancestor of QNAME, copy that DNAME
record into the answer section. If there was no delegation from
authoritative data, look for the best one from the cache, and
put it in the authority section. Go to step 6.
5. Use the local resolver or a copy of its algorithm (see resolver
section of this memo) to answer the query. Store the results,
including any intermediate CNAMEs and DNAMEs, in the answer
section of the response.
6. Using local data only, attempt to add other RRs which may be
useful to the additional section of the query. Exit.
Note that there will be at most one ancestor with a DNAME as
described in step 4 unless some zone's data is in violation of the
no-descendants limitation in section 3. An implementation might
take advantage of this limitation by stopping the search of step 3c
or step 4 when a DNAME record is encountered.
4.2. Processing by Resolvers
A resolver or a server providing recursive service must be modified
to treat a DNAME as somewhat analogous to a CNAME. The resolver
algorithm of [DNSCF] section 5.3.3 is modified to renumber step 4.d
as 4.e and insert a new 4.d. The complete algorithm becomes:
1. See if the answer is in local information, and if so return it
to the client.
2. Find the best servers to ask.
3. Send them queries until one returns a response.
4. Analyze the response, either:
a. if the response answers the question or contains a name
error, cache the data as well as returning it back to the
client.
b. if the response contains a better delegation to other
servers, cache the delegation information, and go to step 2.
Expires September 26, 1999 Crawford [Page 5]
Internet Draft Non-Terminal Nicknames March 21, 1999
c. if the response shows a CNAME and that is not the answer
itself, cache the CNAME, change the SNAME to the canonical
name in the CNAME RR and go to step 1.
d. if the response shows a DNAME and that is not the answer
itself, cache the DNAME. If substitution of the DNAME's
<target> for its <owner> in the SNAME would overflow the
legal size for a <domain-name>, return an implementation-
dependent error to the application; otherwise perform the
substitution and go to step 1.
e. if the response shows a server failure or other bizarre
contents, delete the server from the SLIST and go back to
step 3.
A resolver or recursive server which understands DNAME records but
sends non-extended queries MUST augment step 4.c by deleting from
the reply any CNAME records which have an <owner> which is a
subdomain of the <owner> of any DNAME record in the response.
5. Examples of Use
5.1. Organizational Renaming
If an organization with domain name FROBOZZ.EXAMPLE became part of
an organization with domain name ACME.EXAMPLE, it might ease
transition by placing information such as this in its old zone.
frobozz.example. DNAME frobozz-division.acme.example.
MX 10 mailhub.acme.example.
The response to an extended recursive query for www.frobozz.example
would contain, in the answer section, the DNAME record shown above
and the relevant RRs for www.frobozz-division.acme.example.
5.2. Classless Delegation of Shorter Prefixes
The classless scheme for in-addr.arpa delegation [INADDR] can be
extended to prefixes shorter than 24 bits by use of the DNAME
record. For example, the prefix 192.0.8.0/22 can be delegated by
the following records.
Expires September 26, 1999 Crawford [Page 6]
Internet Draft Non-Terminal Nicknames March 21, 1999
$ORIGIN 0.192.in-addr.arpa.
8/22 NS ns.slash-22-holder.example.
8 DNAME 8.8/22
9 DNAME 9.8/22
10 DNAME 10.8/22
11 DNAME 11.8/22
A typical entry in the resulting reverse zone for some host with
address 192.0.9.33 might be
$ORIGIN 8/22.0.192.in-addr.arpa.
33.9 PTR somehost.slash-22-holder.example.
The same advisory remarks concerning the choice of the "/" character
apply here as in [INADDR].
5.3. Network Renumbering Support
If IPv4 network renumbering were common, maintenance of address
space delegation could be simplified by using DNAME records instead
of NS records to delegate.
$ORIGIN new-style.in-addr.arpa.
189.190 DNAME in-addr.example.net.
$ORIGIN in-addr.example.net.
188 DNAME in-addr.customer.example.
$ORIGIN in-addr.customer.example.
1 PTR www.customer.example.
2 PTR mailhub.customer.example.
; etc ...
This would allow the address space 190.189.0.0/16 assigned to the
ISP "example.net" to be changed without the necessity of altering
the zone files describing the use of that space by the ISP and its
customers.
Renumbering IPv4 networks is currently so arduous a task that
updating the DNS is only a small part of the labor, so this scheme
may have a low value. But it is hoped that in IPv6 the renumbering
task will be quite different and the DNAME mechanism may play a
useful part.
Expires September 26, 1999 Crawford [Page 7]
Internet Draft Non-Terminal Nicknames March 21, 1999
6. IANA Considerations
This document defines a new DNS Resource Record type with the
mnemonic DNAME and type code 39 (decimal). The naming/numbering
space is defined in [DNSIS]. This name and number have already been
registered with the IANA.
7. Security Considerations
The DNAME record is similar to the CNAME record with regard to the
consequences of insertion of a spoofed record into a DNS server or
resolver, differing in that the DNAME's effect covers a whole
subtree of the name space. The facilities of [DNSSEC] are available
to authenticate this record type.
8. References
[DNSCF] P.V. Mockapetris, "Domain names - concepts and facilities",
RFC 1034.
[DNSCLR] R. Elz, R. Bush, "Clarifications to the DNS Specification",
RFC 2181.
[DNSIS] P.V. Mockapetris, "Domain names - implementation and
specification", RFC 1035.
[DNSSEC] D. Eastlake, 3rd, C. Kaufman, "Domain Name System Security
Extensions", RFC 2065.
[DNSUPD] P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, "Dynamic
Updates in the Domain Name System", RFC 2136.
[EDNS0] P. Vixie, "Extensions mechanisms for DNS (EDNS0)", Currently
draft-dnsind-edns0-01.txt.
[INADDR] H. Eidnes, G. de Groot, P. Vixie, "Classless IN-ADDR.ARPA
delegation", RFC 2317.
[KWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119.
[SECDYN] D. Eastlake, 3rd, "Secure Domain Name System Dynamic
Update", RFC 2137.
Expires September 26, 1999 Crawford [Page 8]
Internet Draft Non-Terminal Nicknames March 21, 1999
9. Author's Address
Matt Crawford
Fermilab MS 368
PO Box 500
Batavia, IL 60510
USA
Phone: +1 630 840-3461
EMail: crawdad@fnal.gov
Expires September 26, 1999 Crawford [Page 9]

319
doc/draft/draft-ietf-dnsind-edns0-01.txt
View File

@ -1,319 +0,0 @@
DNSIND Working Group Paul Vixie
INTERNET-DRAFT ISC
<draft-dnsind-edns0-01.txt> January, 1999
Extension mechanisms for DNS (EDNS0)
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
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.
Expires July 1999 [Page 1]
INTERNET-DRAFT EDNS0 January 1999
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 encoded in the lower six bits of the first octet of a
label. All subsequently developed label types should be encoded using
an extended label type.
3.2. The ``1 1 1 1 1 1'' extended label type will be reserved for future
expansion of the extended label type code space.
4 - OPT pseudo-RR
4.1. The OPT pseudo-RR can be added to the additional data section of
either a request or a response. An OPT is called a pseudo-RR because it
pertains to a particular transport level message and not to any actual
DNS data. OPT RRs shall never be cached, forwarded, or stored in or
loaded from master files.
Expires July 1999 [Page 2]
INTERNET-DRAFT EDNS0 January 1999
4.2. An OPT RR has a fixed part and a variable set of options expressed
as {attribute, value} pairs. The fixed part holds some DNS meta data
and also a small collection of new protocol elements which we expect to
be so popular that it would be a waste of wire space to encode them as
{attribute, value} pairs.
4.3. The fixed part of an OPT RR is structured as follows:
Field Name Field Type Description
------------------------------------------------------
NAME domain name empty (root domain)
TYPE u_int16_t OPT
CLASS u_int16_t sender's UDP payload size
TTL u_int32_t extended RCODE and flags
RDLEN u_int16_t describes RDATA
RDATA octet stream {attribute,value} pairs
4.4. The variable part of an OPT RR is encoded in its RDATA and is
structured as zero or more of the following:
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | OPTION-CODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | OPTION-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: | |
/ OPTION-DATA /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
OPTION-CODE (Assigned by IANA.)
OPTION-LENGTH Size (in octets) of OPTION-DATA.
OPTION-DATA Varies per OPTION-CODE.
4.5. The sender's UDP buffer size (which OPT stores in the RR CLASS
field) is the number of octets of the largest UDP payload that can be
reassembled and delivered in the sender's network stack. Note that path
MTU, with or without fragmentation, may be smaller than this.
Expires July 1999 [Page 3]
INTERNET-DRAFT EDNS0 January 1999
4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP
reassembly buffer. Choosing 1280 on an Ethernet connected requestor
would be reasonable. The consequence of choosing too large a value may
be an ICMP message from an intermediate gateway, or even a silent drop
of the response message. Requestors are advised to retry in such cases.
4.5.2. Both requestors and responders are advised to take account of the
path's already discovered MTU (if known) when considering message sizes.
4.6. The extended RCODE and flags (which OPT stores in the RR TTL field)
are structured as follows:
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | EXTENDED-RCODE | VERSION |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | Z |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. Note that
EXTENDED-RCODE value "0" indicates that an unextended
RCODE is in use (values "0" through "15").
VERSION Indicates the implementation level of whoever sets it.
Full conformance with this specification is indicated by
version ``0.'' Note that both requestors and responders
should set this to the highest level they implement,
that responders should send back RCODE=BADVERS and that
requestors should be prepared to probe using lower
version numbers if they receive an RCODE=BADVERS.
Z Set to zero by senders and ignored by receivers, unless
modified in a subsequent specification.
5 - Transport Considerations
5.1. The presence of an OPT pseudo-RR in a request should be taken as an
indication that the requestor fully implements the given version of
EDNS, and can correctly understand any response that conforms to that
feature's specification.
5.2. Lack of use of these features in a request must be taken as an
indication that the requestor does not implement any part of this
specification and that the responder may make no use of any protocol
Expires July 1999 [Page 4]
INTERNET-DRAFT EDNS0 January 1999
extension described here in its response.
5.3. Responders who do not understand these protocol extensions are
expected to send a response with RCODE NOTIMPL, FORMERR, or SERVFAIL.
Therefore use of extensions should be ``probed'' such that a responder
who isn't known to support them be allowed a retry with no extensions if
it responds with such an RCODE. If a responder's capability level is
cached by a requestor, a new probe should be sent periodically to test
for changes to responder capability.
6 - Security Considerations
Requestor-side specification of the maximum buffer size may open a new
DNS denial of service attack if responders can be made to send messages
which are too large for intermediate gateways to forward, thus leading
to potential ICMP storms between gateways and responders.
7 - IANA Considerations
IANA is hereby requested to assign an RR type code for OPT.
It is the recommendation of this document and its working group that
IANA create a registry for EDNS Extended Label Types, for EDNS Option
Codes, and for EDNS Version Numbers.
This document assigns label type 0b01xxxxxx as "EDNS Extended Label
Type." We request that IANA record this assignment.
This document assigns extended label type 0bxx111111 as "Reserved for
future extended label types." We request that IANA record this
assignment.
This document assigns option code 65535 to "Reserved for future
expansion."
This document expands the RCODE space from 4 bits to 12 bits. This will
allow IANA to assign more than the 16 distinct RCODE values allowed in
[RFC1035].
This document assigns EDNS Extended RCODE "16" to "BADVERS".
IESG approval should be required to create new entries in the EDNS
Extended Label Type or EDNS Version Number registries, while any
published RFC (including Informational, Experimental, or BCP) should be
grounds for allocation of an EDNS Option Code.
Expires July 1999 [Page 5]
INTERNET-DRAFT EDNS0 January 1999
8 - Acknowledgements
Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley,
Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas
Narten were each instrumental in creating and refining this
specification.
9 - References
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification,'' RFC 1035, USC/Information Sciences
Institute, November 1987.
10 - Author's Address
Paul Vixie
Internet Software Consortium
950 Charter Street
Redwood City, CA 94063
+1 650 779 7001
<paul@vix.com>
Expires July 1999 [Page 6]