Subject: RDATA compression in draft-ietf-dnsind-dname-02.txt

From: Peter Koch <[email-masked]>
Date: Fri, 04 Dec 1998 17:38:28 +0100

> draft-ietf-dnsind-dname-02.txt
>   o push to iesg as ps unless technical objections

sorry to come up with the same topic again, but the compression issue
for the domain name in the RDATA section of this RR type is not
explicitly dealt with. There was some private discussion whether this
really was necessary given the wording in 1035 and 1123. Practice has
shown, however, that implementations have used domain name compression
for not ``well known'' RR types, too. So, it's probably better to add a
word of clarification, for which there are two alternatives:

a) The domain name in the RDATA section of DNAME MUST be compressed
   with local compression [LCDRAFT].

   The ``MUST'' is copied from 1123, it does of course not force
   any kind of compression when the name cannot be compressed.

   Pro: interoperable, efficient solution. Given the examples in Matt's draft
        quite some gain can be expected due to the relation of owner and
        RDATA names.

   Con: makes normative reference to document in draft status

b) The domain name in the RDATA section of DNAME MUST NOT be compressed.

   Pro: interoperable solution, available immediately

   Con: lower efficiency wrt packet size

Anything else, like disallowing compression now and add local compression
later or marking DNAME as ``well known'' sometime in the future (making
standard compression legal) won't work, because of (then) legacy
implementations. The compression issue is a per-RR type problem to be decided
once.

In contrast to the SRV-RR we have a true choice between (a) and (b).

-Peter

---

From: Paul A Vixie <[email-masked]>
Date: Sat, 05 Dec 1998 19:04:20 -0800

i think the thing we want is that all rdata's should be cacheable, which
means we have to draw various lines in the sand and say something like:

normal DNS:	only permit compression of things mentioned in RFC 1035,
		plus any others like SRV which have strong defenders.

EDNS0:		permit compression as above, but also of every other RRtype
		RDATA known at the time EDNS0 is finalized (which means that
		EDNS0 would have to list them.)

EDNS1:		same as above.

EDNSx:		same as above.

---

From: Robert Elz <[email-masked]>
Date: Sun, 06 Dec 1998 18:10:39 +1100

Date:        Sat, 05 Dec 1998 19:04:20 -0800
    From:        Paul A Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  | i think the thing we want is that all rdata's should be cacheable,

You mean compressible, and yes, provided that the server can tell exactly
what knowledge the resolver must have, because of knowing what version
of the dns it supports, then we could allow compression of more RR types.

Of course, one day, one of those versions might tell us that the resolver
has the ability to go find the rdata encoding of any new RR that is
invented in the future, at which point any name in the rdata would be
able to be compressed.

kre

---

From: Paul A Vixie <[email-masked]>
Date: Sun, 06 Dec 1998 07:51:38 -0800

> of the dns it supports, then we could allow compression of more RR types.

no, i mean cacheable.  right now we can't cache anything we can't uncompress,
and thus any unknown RR type is assumed to be uncacheable by existing BINDs.

> invented in the future, at which point any name in the rdata would be

in the recommendation i sent last night, i gave various milestones where the
server will make certain assumptions about which rr types the a client will
be able to uncompress.

---

From: Robert Elz <[email-masked]>
Date: Mon, 07 Dec 1998 04:31:44 +1100

Date:        Sun, 06 Dec 1998 07:51:38 -0800
    From:        Paul A Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  | i mean cacheable.  right now we can't cache anything we can't uncompress,

But that's why we have the rule that we can't compress anything that
isn't a "known" RR type that contains a name - that allows servers to
assume that anything that is not one of those types will not contain
any compressed names, and consequently is able to be cached.

That's the basic assumption of name compression in the DNS.

This could have gone either way - but caching won over compression,
and that's the situation we're in now.

The question is when, if ever, we can ever enable compression of names
that aren't in the basic standard set (CNAME, PTR, NS, SOA,
and realistically MX - and I guess MB MG, and MR if anyone were to use them)

Nothing else should contain compressed names, and hence, everything else
can be cached.

kre

---

From: Paul A Vixie <[email-masked]>
Date: Sun, 06 Dec 1998 11:46:50 -0800

>> i mean cacheable.  right now we can't cache anything we can't uncompress,
> 

yes.  however, bind has classically compressed every RR type it has handled,
because its maintainers (including mostly me) were long on ambition, short
on caution, and somewhat careless.  we can legislate that bind 4.8.*,
4.9.*, and 8.1.* are all wrong, but will that help anybody?  8.2 will do
the right thing, but we should decide whether to call what 8.1.* (and
earlier) "irretrievably bad" or "retrievably bad."

> and realistically MX - and I guess MB MG, and MR if anyone were to use them)

i think that if an requestor says they can speak EDNSx, then the responder
should feel free to compress the list of RR types which "were" known at the
time of EDNSx's final standardization.  EDNSx should include a list of these.

> Nothing else should contain compressed names, and hence, everything else

i'd like to eventually compress everything and cache everything.  the rule
in 1035 about "only the initial set of types should be compressed" did not
allow for reasonable fillage of the rest of the 64K worth of RR type space.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 7 Dec 1998 03:39:40 -0000

> 		EDNS0 would have to list them.)

If the protocol is changing, why is it necessary to stick to the
original DNS compression scheme?

General-purpose compression methods such as LZ77 are faster and easier
to implement. They don't need to be upgraded for new DNS record types.

---Dan

---

From: [email-masked]
Date: Wed, 09 Dec 1998 00:05:56 +1100

To throw another spanner into the works.  For DNSSEC to work we
	need to know which RR contain dnames regardless of whether they
	are compressed or not or otherwise there is no way to verify a
	signature.  Regardless of whether we can compress it or not.

	Remember a newer client may be talking through a older server
	that is doing the DNSSEC work for the client.

	I think we should just by the bullet and reserve part of the
	type space for RR's containing compressed names and provide
	an initial start to the RDATA of these records whick allows us
	to identify where in the RDATA the compressed domain names are.

	<NUMCOMP><OFFESET1>...<OFFSETN><REST OF RR>

	A SOA RDATA ". . 1 2 3 4 5" would have been encoded like

	00 02 00 06 00 07 00 00 00 00 00 01 00 00 00 02 ...

	NUMCOM and OFFSET# are all 16 bit quantities and are *not* part
	of the text representation of the the RDATA. The offsets assume
	that all earlier domain names in the RDATA are uncompressed (as
	they are in the case above).  This will allow us to generate a
	signature for this record.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Peter Koch <[email-masked]>
Date: Thu, 17 Dec 1998 23:56:42 +0100

> 	that is doing the DNSSEC work for the client.

We can get around this if we sign the locally compressed RR. Any system
then can verify the signature without interpreting the RDATA content.
RDATA->RDATA compression works well, but for RDATA->owner compression
we have to consider wildcards. One cannot pre-compress into a wildcard
owner, because the wildcard may expand to more than one label thus changing
the target label count. With Secure DNS in place, we could calculate
the offset, but without there's no way.

If, however, labels were counted backwards starting at the root (0), an
expanded wildcard would no longer change the ordinal number of any possible
RDATA->owner compression target. 

-Peter