Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ucbvax!RELAY.PRIME.COM!ARIEL
From: ARIEL@RELAY.PRIME.COM (Robert Ullmann)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: re: compression in new DNS RR's
Message-ID: <9010201545.AA20213@ucbvax.Berkeley.EDU>
Date: 19 Oct 90 21:42:48 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 36

Hi,

I would think that compression must not be used for the
RR data for any RRs >= 16 (i.e. not in the RFC1035 set).

My DNS implementation does not compress the RT referenced
name. It also ran into serious trouble when I first collected
"real" AFSDB RR's from the co-author's system; my DNS is a
combined server/caching-server/resolver.

There is a basic design problem in DNS here: if your system's
resolver doesn't understand an RR format, your application
can't use it if the RR data contains a compressed name.
(using a general block-data LZ77 compression rather than
the ad-hoc method would have been Real Neat. :-)

I conclude that effectively:

    DNS implementations MUST NOT compress names in the
    data part of RR types which are not in the basic set
    that MUST be implemented. (i.e. <= 16 at this time.)
    Owner names MAY (SHOULD) be compressed in any RR.

The "basic set" that is required for internet hosts might
be increased at some future date, but for now it is de facto
defined by RFC 1035.

Bind (in.named) seems to "solve" this problem by discarding
RRs of types it doesn't understand during the receipt of
zone transfers; none of the secondaries for PRIME.COM seem
to have the X25 and RT RRs that RELAY.PRIME.COM has. Does
anyone know if this observation is valid?

Best Regards,
Robert Ullmann
+1 508 620 2800 x1736