INTERNET-DRAFT Peter Koch Expires: May 1999 Universitaet Bielefeld Updates: RFC 1035 November 1998 A New Scheme for the Compression of Domain Names draft-ietf-dnsind-local-compression-03.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 (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). 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 May 1999 [Page 1]
INTERNET-DRAFT DNS Compression November 1998 Domain names herein are for explanatory purposes only and should not be expected to lead to useful information in real life. 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 internally 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 May 1999 [Page 2]
INTERNET-DRAFT DNS Compression November 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 or calculate pointers relative to the start of the RDATA to avoid context sensitivity. We use an additional compression indicator for a two octet local pointer: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 1 0| OFFSET | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ The "10" bits will indicate the use of local compression and distinguish it from conventional compression, plain labels and EDNS label codes [EXT2DNS]. Two types of pointers need to be specified: those pointing into the owner name and those pointing into RDATA. A) Pointers into the owner name are interpreted as the ordinal label number (starting at 0 for the first, least significant label). This way we avoid the need for extra decompression of the owner name during message composition or decomposition. The internal representation of a domain name has a maximum length of 255 [RFC 1035]. Any label consists of at least two octets, Koch Expires May 1999 [Page 3]
INTERNET-DRAFT DNS Compression November 1998 leading to at most 127 labels per domain name plus the terminating zero octet, which does not qualify as a compression target. The highest possible value of a compression pointer pointing into the owner name is 126. The value 127 is reserved for future use. B) Pointers into the RDATA section start at the fixed value 128 for the first octet and have a maximum value of 16383 limiting possible targets to the first 16256 octets. 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 of RRs in an RRSet is not necessarily 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) +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 32 | 3 | b | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 34 | a | r | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 36 | 1 1| 18 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Koch Expires May 1999 [Page 4]
INTERNET-DRAFT DNS Compression November 1998 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| 1 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 58 | 1 0| 130 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ The first local pointer at position 56 points to the second label of the XX RR's owner. 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] (Standards Track, Experimental and Informational RFCs, ignoring withdrawn types): RP [RFC1183], AFSDB [RFC1183], RT [RFC1183], SIG [RFC2065], PX [RFC2163], NXT [RFC2065], SRV [RFC2052], NAPTR [RFC2168], KX [RFC2230]. Some specifications do not mention DNS compression at all, others explicitly suggest it and only in part identify interoperability issues. The KX RR is safe as the specification prohibits compression. The specification of RP, AFSDB, RT, PX, 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 Koch Expires May 1999 [Page 5]
INTERNET-DRAFT DNS Compression November 1998 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. 6. Security Considerations The usual caveats for using unauthenticated DNS apply. This scheme is believed not to introduce any new security problems. However, implementors 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. In addition, pointers should be verified to really point to the start of a label (for conventional and local RDATA pointers) and not beyond the end of the domain name (for local owner name pointers). The maximum length of 255 applies to domain names in uncompressed wire format, so care must be taken during decompression not to exceed this limit to avoid buffer overruns. 7. Acknowledgements The author would like to thank Andreas Gustafsson, Paul Vixie and Bob Halley for their review and constructive comments. 8. References [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 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 Koch Expires May 1999 [Page 6]
INTERNET-DRAFT DNS Compression November 1998 [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 [EXT2DNS] Vixie,P., "Extension mechanisms for DNS (EDNS0)", draft- ietf-dnsind-edns0-XX.txt, work in progress 9. 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 May 1999 [Page 7]
