[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

INTERNET-DRAFT                                                   P. Koch
Expires: May 1998                                 Universitaet Bielefeld
Updates: RFC 1035                                          November 1997

            A New Scheme for the Compression of Domain Names

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


   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

   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",
   document are to be interpreted as described in [RFC2119].

Koch                        Expires May 1998                    [Page 1]

INTERNET-DRAFT              DNS Compression                November 1997

   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  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

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

Koch                        Expires May 1998                    [Page 2]

INTERNET-DRAFT              DNS Compression                November 1997

        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.xy   RP      adm.foo.bar.xy  adm.persons.bar.xy

   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. For all pointer calculations, the length of the
   expanded owner name must be taken into account, 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

   The length of the compressed name(s) MUST be used in the length
   calculation for the RDLENGTH field.

Koch                        Expires May 1998                    [Page 3]

INTERNET-DRAFT              DNS Compression                November 1997

   NB: The maximum length of the owner name is 257, since the internal
   representation of a domain name other than the root uses two more
   octets than the external representation: one for the terminating zero
   octet and one for the fact that the number of labels is by one larger
   than the number of separators.  [This is a conflict between
   [RFC1035], section 3.1, [RFC1123], section and [RFC2181],
   section 11.]


   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.xy   IN  CNAME  bar.xy
         bar.xy     IN  XX     a.foo.xy  foo.xy

   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 |           y           |           0           |

       8 octets skipped (TYPE, CLASS, TTL, RDLENGTH)

       30 |           3           |           b           |
       32 |           a           |           r           |
       34 | 1  1|                 18                      |

   The XX RR with local compression applied:

       36 | 1 1 |                 30                      |

       8 octets skipped

Koch                        Expires May 1998                    [Page 4]

INTERNET-DRAFT              DNS Compression                November 1997

       46 |           1           |           a           |
       48 |           3           |           f           |
       50 |           0           |           0           |
       52 | 1  0|                 4                       |
       54 | 1  0|                18                       |

   The first local pointer at position 50 points to the second label of
   the XX RR's owner, octet 4 of the expanded owner name. The length of
   this name is 8, so the RDATA section starts at position 16 (There is
   always an offset of eight octets between the end of the owner name an
   the start of the RDATA section).  The second local pointer at
   position 54 represents the "foo.xy" and points backwards into the
   RDATA section, third octet, at absolute position 48.  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, AFSDB,
   RT, SIG, PX, AAAA, NXT, SRV, NAPTR, KX.  The specification of the
   first three, [RFC1183], does not mention DNS compression, others
   explicitly suggest it and only in part identify interoperability
   issues.  The KX RR is safe as the specification prohibits

   Their specification is hereby changed in that domain names in the
   RDATA section SHOULD NOT be compressed and SHOULD NOT be compression

   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

   The specification of future RR types should explicitly select the use
   of local compression or forbid RDATA domain name compression at all.

   DNS compression should be carried out as efficient as possible.

Koch                        Expires May 1998                    [Page 5]

INTERNET-DRAFT              DNS Compression                November 1997

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

7. References

   [TESTTLD] Eastlake,D., Panitz,A., "Test and Example Top Level Domain
             Names", draft-ietf-dnsind-test-tlds-04.txt, work in

   [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

   [RFC2119] Bradner,S., "Key words for use in RFCs to Indicate
             Requirement Levels", RFC 2119, BCP 14, March 1997

   [RFC2181] Elz,R., Bush,R., "Clarifications to the DNS Specification",
             RFC 2181, July 1997

8. Author's Address

   Peter Koch
   Universitaet Bielefeld
   Technische Fakultaet
   Postfach 10 01 31
   D-33501 Bielefeld
   +49 521 106 2902

Koch                        Expires May 1998                    [Page 6]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/