lwj@cs.kun.nl (Luc Rooijakkers) (10/16/90)
Several new RR types introduced in RFC 1183 include domain names. The
relevant types are AFSDB (18), RP (17), RT (21). Should name servers
compress the domain names in these RR types ? From RFC 1123,
Requirements For Internet Hosts, section 6.1.3.5 Extensibility:
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.
So, are the new RR types to be considered well-known ? If so, this
creates a problem when resolvers and secondary name servers receive
these RR's but do not know that they contain compressed domain names.
This is also hinted at in RFC 1123:
A name server may acquire, via zone transfer, RRs that
the server doesn't know how to convert to printable
format. A resolver can receive similar information as
the result of queries. For proper operation, this data
must be preserved, and hence the implication is that
DNS software cannot use textual formats for internal
storage.
For secondary nameservers this should not be a problem, I think, since
these can be updated when needed. But caching resolvers are more
difficult to deal with.
Comments or answers, anyone ?
--
Luc Rooijakkers Internet: lwj@cs.kun.nl
Faculty of Mathematics and Computer Science UUCP: uunet!cs.kun.nl!lwj
University of Nijmegen, the Netherlands tel. +3180652271ARIEL@RELAY.PRIME.COM (Robert Ullmann) (10/20/90)
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 x1736braden@VENERA.ISI.EDU (10/23/90)
RFC-1183 defines experimental extensions to the DNS. Let us suppose that the time will come that the experiment is successful, and these RRs are placed in the standards track, and after a year pop out as an Internet standard. It is hard to see how they will be able to avoid being "well-known" RR types at that point, and hence by RFC-1123 must use compression for domain names. That being the case, it would seem a little strange not to define the experiment to require domain name compression. Bob Braden