One document matched: draft-ietf-dnsind-local-compression-01.txt
Differences from draft-ietf-dnsind-local-compression-00.txt
INTERNET-DRAFT Peter Koch
Expires: September 1998 Universitaet Bielefeld
Updates: RFC 1035 March 1998
A New Scheme for the Compression of Domain Names
draft-ietf-dnsind-local-compression-01.txt
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 (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Comments should be sent to the author or the DNSIND WG mailing list
<namedroppers@internic.net>.
Abstract
The compression of domain names in DNS messages was introduced in
[RFC1035]. Although some remarks were made about applicability to
future defined resource record types, no method has been deployed yet
to support interoperable DNS compression for RR types specified since
then.
This document summarizes current problems and proposes a new
compression scheme to be applied to future RR types which supports
interoperability. Also, suggestions are made how to deal with RR
types defined so far.
1. Conventions used in this document
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 [RFC2119].
Koch Expires September 1998 [Page 1]
INTERNET-DRAFT DNS Compression March 1998
Domain names herein are for explanatory purposes only and should not
be expected to lead to useful information in real life [TESTTLD].
2. Background
Domain name compression was introduced in [RFC1035], section 4.1.4,
as an optional protocol feature and later mandated by [RFC1123],
section 6.1.2.4. The intent was to reduce the message length,
especially that of UDP datagrams, by avoiding repetition of domain
names or even parts thereof.
A domain name is usually represented by the concatenation of label
strings, where the first octet denotes the string length, not
including itself. The null string, consisting of a single octet of
zeroes, is the representation of the root domain name and also
terminates every domain name.
As labels may be at most 63 characters long, the two most significant
bits in the length octet will always be zero. Compression works by
overloading the length octet with a second meaning. If the two MSB
have the value '1', the remainder of the length octet and the next
octet form a compression pointer, which denotes the position of the
next label of the current domain name in the message:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 1 1| OFFSET |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
It is important that these pointers always point backwards.
Compression may occur in several places. First, the owner name of an
RR may be compressed. The compression target may be another owner
name or a domain name in the RDATA section of a previous RR. Second,
any domain name within the RDATA section may be compressed and the
target may be part of the same RR, being the owner name or another
domain name in the RDATA section, or it may live in a previous RR,
either as its owner or as a domain name in its RDATA section. In
fact, due to the chaining feature, combinations of the above may
occur.
3. Problems
While implementations shall use and must understand compressed domain
names in the RDATA section of those "well known" RR types initially
defined, there is no interoperable way of applying compression to the
RDATA section of newer RRs:
Quote from [RFC1123], section 6.1.3.5:
Koch Expires September 1998 [Page 2]
INTERNET-DRAFT DNS Compression March 1998
Compression relies on knowledge of the format of data inside a
particular RR. Hence compression must only be used for the
contents of well-known, class-independent RRs, and must never be
used for class-specific RRs or RR types that are not well-known.
The owner name of an RR is always eligible for compression.
DNS records in messages may travel through caching resolvers not
aware of the particular RR type. These caches cannot rearrange
compression pointers in the RDATA section simply because they do not
recognize them. Handing out these RRs in a different context later
will lead to confusion if the target resolver tries to uncompress the
domain names using wrong information.
This is not restricted to intermediate caching but affects any
modification to the order of RRs in the DNS message.
4. Local Compression
We often observe a certain locality in the domain names used as owner
and occuring in the RDATA section, e.g. in MX or NS RRs but also in
newer RR types [RFC1183]:
host.foo.bar.xz RP adm.foo.bar.xz adm.persons.bar.xz
So, to still profit from compression without putting interoperability
at risk, a new scheme is defined which limits the effect of
compression to a single RR.
In contrast to the usual method we start counting at the RR owner and
calculate pointers relative to the start of the RR using the expanded
owner name to avoid context sensitivity. We use an additional
compression indicator for a two octet local pointer:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 1 0| OFFSET |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The indicator "10" will sign the compression relative to the start of
the current RR. Pointers into the owner name and pointers into the
RDATA section are calculated as follows:
Pointers into the owner name are allowed to point to the start of the
first or any other label to allow for efficient compression, starting
with 0 for the first octet in the owner name.
While the owner name may be compressed using the conventional method
of [RFC1035] all offset calculations for local compression MUST be
based on the uncompressed owner name. This is necessary to avoid a
Koch Expires September 1998 [Page 3]
INTERNET-DRAFT DNS Compression March 1998
dependency on the occurence or ordering of RRs in the message.
The internal representation of a domain name has a maximum length of
255 [RFC 1035], with the last octet always being the null string and
thus not qualifying as a compression target. The topmost label is at
least one octet long, so the highest possible value of a compression
pointer pointing into the owner name is 252. The values 253 through
255 are reserved for future use.
Pointers into the RDATA section start at the fixed value 256 for the
first octet and have a maximum value of 16383 limiting possible
targets to the first 16128 octets. [If the need be reserve the upper
half of that address space for "relative" pointers which would point
up to 8K octets backwards.]
Local pointers MUST point to a previous occurence of the same name in
the same RR. Even domain names in another RR of the same type cannot
serve as compression targets since the order in an RRSet is not
necessary stable.
The length of the compressed name(s) MUST be used in the length
calculation for the RDLENGTH field.
Example
Consider a DNS message containing two resource records, one CNAME RR
and one XX RR, undefined and meaningless so far, with an RDATA
section consisting of two domain names:
a.foo.xz IN CNAME bar.xz
bar.xz IN XX a.foo.xz foo.xz
In a message this appears as follows (randomly starting at octet 12):
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
12 | 1 | a |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
14 | 3 | f |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
16 | o | o |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
18 | 2 | x |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
20 | z | 0 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10 octets skipped (TYPE, CLASS, TTL, RDLENGTH)
Koch Expires September 1998 [Page 4]
INTERNET-DRAFT DNS Compression March 1998
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
32 | 3 | b |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
34 | a | r |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
36 | 1 1| 18 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The XX RR with local compression applied:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
38 | 1 1 | 32 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10 octets skipped (TYPE, CLASS, TTL, RDLENGTH)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
50 | 1 | a |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
52 | 3 | f |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
54 | o | o |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
56 | 1 0| 4 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
58 | 1 0| 258 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The first local pointer at position 56 points to the second label of
the XX RR's owner, octet 4 of the expanded owner name.
The second local pointer at position 58 represents the "foo.xz" and
points backwards into the RDATA section, third octet, at absolute
position 52. Note that with conventional compression this example
message would have occupied less space.
5. Old RR types and deployment
Although differences in RDATA sections by class have not yet been
reported and the concept of classes did not really spread, we are
just considering the IN class here.
The following RR types with domain names in the RDATA section have
been defined since [RFC1035] (ignoring withdrawn types): RP
[RFC1183], AFSDB [RFC1183], RT [RFC1183], SIG [RFC2065], PX
[RFC2163], AAAA [IPV6ARR], NXT [RFC2065], SRV [RFC2052], NAPTR
[RFC2168], KX [RFC2230], ERR [ERRORRR]. The specification of the
first three does not mention DNS compression, others explicitly
Koch Expires September 1998 [Page 5]
INTERNET-DRAFT DNS Compression March 1998
suggest it and only in part identify interoperability issues. The KX
RR is safe as the specification prohibits compression.
[BIND compresses all but SIG and KX.]
The specification of RP, AFSDB, RT, PX, NXT, SRV, and NAPTR is hereby
changed in that domain names in the RDATA section SHOULD NOT be
compressed and SHOULD NOT be compression targets.
Local compression MUST NOT be used for owner names and it MUST NOT be
applied to domain names in RDATA sections of any RR type defined so
far.
The specification of future RR types should explicitly select the use
of local compression or forbid RDATA domain name compression at all.
The AAAA [IPV6ARR] and ERR [ERRORRR] record types should be subject
to local compression.
6. Security Considerations
The usual caveats for using unauthenticated DNS apply. This scheme is
believed not to introduce any new security problems. However,
implementations should be aware of problems caused by blindly
following compression pointers of any kind. [RFC1035] and this
document limit compression targets to previous occurences and this
MUST be followed in constructing and decoding messages. Otherwise
applications might be vulnerable to denial of service attacks
launched by sending DNS messages with infinite compression pointer
loops.
7. References
[ERRORRR] Watson,R., Gudmundsson,O., "Error Record (ERR) for DNS",
draft-ietf-dnsind-dns-error-00.txt, work in progress
[IPV6ARR] Huitema,Ch., Thomson,S., "DNS Extensions to support IP
version 6", draft-ietf-ipngwg-aaaa-03.txt, work in progress
[RFC1034] Mockapetris,P., "Domain Names - Concepts and Facilities",
RFC 1034, STD 13, November 1987
[RFC1035] Mockapetris,P., "Domain Names - Implementation and
Specification", RFC 1035, STD 13, November 1987
[RFC1123] Braden,R., "Requirements for Internet Hosts -- Application
and Support", RFC 1123, STD 3, October 1989
[RFC1183] Everhart,C., Mamakos,L., Ullmann,R., Mockapetris,P., "New
Koch Expires September 1998 [Page 6]
INTERNET-DRAFT DNS Compression March 1998
DNS RR Definitions", RFC 1183, October 1990
[RFC2052] Gulbrandsen,A., Vixie,P. "A DNS RR for specifying the
location of services (DNS SRV)", RFC 2052, October 1996
[RFC2065] Eastlake,D., Kaufman,C. "Domain Name System Security
Extensions" RFC 2065, January 1997
[RFC2119] Bradner,S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997
[RFC2163] Allocchio,C., "Using the Internet DNS to Distribute MIXER
Conformant Global Address Mapping (MCGAM)", RFC 2163,
January 1998
[RFC2168] Daniel,R., Mealling,M., "Resolution of Uniform Resource
Identifiers using the Domain Name System", RFC 2168, June
1997
[RFC2230] Atkinson,R., "Key Exchange Delegation Record for the DNS",
RFC 2230, November 1997
[TESTTLD] Eastlake,D., Panitz,A., "Test and Example Top Level DNS
Names", draft-ietf-dnsind-test-tlds-07.txt, work in
progress
8. Author's Address
Peter Koch
Universitaet Bielefeld
Technische Fakultaet
Postfach 10 01 31
D-33501 Bielefeld
Germany
+49 521 106 2902
<pk@TechFak.Uni-Bielefeld.DE>
Koch Expires September 1998 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-23 16:45:04 |