Subject: Re: Last call reminder

From: Peter Koch <[email-masked]>
Date: Sun, 31 Oct 1999 22:03:09 +0100

This is a response to multiple comments on the local compression draft.

> From: Edward Lewis <[email-masked]>

> Benefit - I don't think that the bytes saved via compression are
> significant when compared to DNSSEC-enhanced responses.  With multiple keys
> (multiple algorithms), I usually see 2000 bytes of response to even simple
> queries, most of these bytes in the uncompressable key and signature fields.

DNSSEC could question compression in general, not only domain name based,
local or global, but also other techniques applied to the whole message or
single RRs unless the currently small average size of the other (non-key,
non-sig) RR types increases in the future (for future RR types or message
characteristics). But then, we can't know.

> Cost - building the code to do this and executing the code is not trivial.
> Having written some DNSSEC processing code, having yet another compression
> mechanism makes signing and verifying more of a problem.

While I agree with the first statement I can't follow the second. Local
compression is one way of *enabling* verification of unknown [to the verifier]
RR types.

> Another question raised while reading the draft: If the canonical form for
> signing is to use local compression, how will local compression DNSSEC
> interoperate with older server/resolvers that do not do local compression?

That can't happen, because local compression is by RR type. If you do not
do local compression, that means you do not know that RR type, but you can
still verify the RR because it's signed in compressed form.

> From: Brian Wellington <[email-masked]>

> I don't think that the local compression draft should be advanced.  As
> stated before, by Mark Andrews and others, there's a real problem with
> DNSSEC verification of locally compressed data, as it has two valid
> canonical forms.  The only advantage of local compression is a decrease in

That ambiguity should be addressed by the last paragraph in section
five of the current draft.

> packet size when using records which cannot otherwise be compressed, which
> is not a common occurence (especially since BIND compresses MX records).

This example serves pro not contra local compression. In MX, RP (the example
found in the draft) and SRV RRs the domain name(s) found in RDATA and the owner
name often have a common parent (apart from the trivial, root), leading to
some data reduction by local compression.  However, MX is already covered by
RFC1035 (it's not just BIND, compression is a MUST by RFC1123) and for RP and
SRV there is/was no chance because they were specified before local compression.
So indeed local compression can not show any immediate effect, because it will
need new RR types with one or more domain names in their RDATA to proceed.
But since some of the types defined in the past have shown to be good
candidates, it's not unreasonable to think that some future types will be, too.

> There has been mention several times about including a list of
> compressible record types in the EDNSx specifications.  If EDNS1, which is
> in limbo somewhere, were to specify that all record types <= n (where n is
> the highest allocated type code) could be compressed with global
> compression, this would solve the size problem, which not adversely affect
> DNSSEC.  Since we can assume that EDNS will be implemented soon, and in
> use soon afterwards, we can have compression of all record types without
> any real protocol changes or additional code complexity.  This would
> remove any need for local compression.

There are a lot of problems with such a list of known and therefore
compressible types. In a standards track document like EDNSx you'd still have
to deal with experimental RR types or outlaw compression for them, which is
always an option and would not need that list. Then at some time after
publication of this list, additional types would be specified, reinstantiating
the problem. You can, of course, periodically publish lists of "known" RR types
and probably new servers will even be compliant. But the installed base would
still have problems with [compressed] unknown RR types. As others have stated,
people tend to be lazy in upgrading their servers and some samples taken in the
past support that view.

> From: Paul A Vixie <[email-masked]>

> terribly concerned that it won't be good enough.  the only destinations
> available to a local-compression pointer are the rr itself, meaning that
> unless there's a shared substring between the owner name and the name to
> be compressed, or between two names within the RDATA, we don't win.  the

Right, but there are some RR types where these shared substrings exist for
a large number of real world RRs (see above), so I disagree with your next
statement:

> another aspect much harder: there will effectively not be any compression.

It's easy to construct a RR type with optimal compression gain (e.g. list
of all descendants of the owner), but it's hard to predict what RR types
will be on the table in one or two years. Local compression is something
for future RR types only, so it's hard to show or even prove its efficiency
now other than referring to the examples above. On the other hand, there's no
need to implement it until a RR type comes up which can use it efficiently
(and others either do not have domain names in their RDATA or may not be
compressed at all). The last paragraph in section 7 makes local compression
optional per RR type with leaving "no compression" as the other option.

The proposal was made for standards track to have local compression available
for any future RR type that might make use of it regardless of its own
(intended) maturity level. Alternatively, the WG could send it to Experimental,
which would somehow emphasize that local compression still waits for the
'killer RR'.

If the WG decides to let local compression die, we still have to work on
the 'transparency' issue for (among orthers) caching and signature verification.
For caching, this includes taking into account the installed base.

Thanks for the comments so far.

-Peter