Subject: Re: wg last call for draft-ietf-dnsext-unknown-rrs-01.txt

From: [email-masked] (Andreas Gustafsson)
Date: Fri, 5 Oct 2001 12:35:01 -0700 (PDT)

Kevin Darcy writes:
> EDNS0 undercuts the rationale for prohibiting compression in new record types,
> because it provides a "safe", point-to-point way to compress records of those
> types. Agreed, that's not technically the same as "obsoleting" the
> prohibition, but it does raise a significant likelihood that exceptions will
> become necessary.

It doesn't raise the likelihood that exceptions are necessary, it
just makes it easier to implement such exceptions if they turn out to
be necessary.  I don't think they will be.

> I think there should at least be some language in the
> document acknowledging this fact, because -- let's face it -- you're not just
> "documenting" an existing prohibition, you're *reinforcing* it.

And reinforced it should be.  If we leave an explicit loophole for
negotiated compression schemes, people will come up with them whether
they are truly necessary or not.

> It wouldn't necessarily be a manual operation, and it wouldn't necessarily be
> burdensome. If the new record type has only a specialized use, then perhaps
> implementations will default it OFF and only those administrators who go out
> of their way to do so -- presumably with a full understanding of their local
> network/DNS environment and/or the tradeoffs of using the new record type --
> will turn it ON.

All that just to save a couple of bytes?  It's just not worth the effort.
-- 
Andreas Gustafsson, [email-masked]

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Kevin Darcy <[email-masked]>
Date: Tue, 09 Oct 2001 22:10:50 -0400

[email-masked] wrote:

> be necessary.

This is getting a little convoluted. The bottom line is that EDNS0 makes it
*possible* to implement compression safely in new types. If your rationale for
forbidding name compression in new types is that it is invariably unsafe, then to
put it bluntly, that is a false rationale, given EDNS0. So, either the prohibition
is a raw edict with no legitimate rationale, or you make an exception to the
prohibition so that the rationale holds true. Your choice.

> they are truly necessary or not.

I don't think it's appropriate for the draft to be making broad assumptions about
what future extensions may be "necessary" or not. It should be
clarifying/standardizing/documenting how unknown RRs are handled, and leaving the
specifics of how *known* RRs are implemented, up to those who are proposing them,
without imposing unnecessary burdens on them to explicitly override your document
in this regard.

> All that just to save a couple of bytes?  It's just not worth the effort.

1. By the same reasoning, why bother with compression at all?

2. Who is to say it is only "a couple of bytes"? If a future record type were
adopted, with literally dozens of names in its RDATA, ripe for compression, would
that change your answer? We have to look not at just the format of extant record
types, but at the *possible* formats of record types yet to be conceived.
Compression is a tool -- albeit a fairly crude one -- for dealing with the
packet-space impact of resource records, and it may save a little space, or a lot,
depending on the record format and how many resource records are being compressed
in a given packet. To deny the use of that tool based on a fuzzy prediction of what
record formats may or may not be adopted in the future, strikes me as rather
short-sighted. We should leave that tool available for situations where it may come
in useful and can be employed in a safe, interoperable way.

- Kevin

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 10 Oct 2001 10:38:32 -0400 (EDT)

> prohibition so that the rationale holds true. Your choice.

<Flame on>
DNS Compression is evil, adding compression to new types is a
real bad idea. (I speak from personal experiance of implementing new types
allowing compression and test deployment). 
We need a blanket ban on compression of RDATA of new types. 
This is the  only safe thing to do, as it improves the chances that a new
type can  pass through a server that does not know the format of that type. 
<Flame off>

We need to learn from experience, even if a standards document says
something is possible we must be able restrict that based on experience. 
Remember RFC1034 and RFC1035 did not go through the 3 stage standards
process, but the one step to full standard.

The time it takes to upgrade DNS servers is measured in many years. 
First we need to wait the next release of the DNS software (0-12
months), then we wait for the OS vendors to add this to their release
(6-24 months) then customers install (0-36 months), then wait for 
the computer to die or be upgraded (0-120 months).

For the most recently defined  type (APL) we will probably have to wait
for 16 years before over 99% of the DNS servers on the Internet know APL.

> without imposing unnecessary burdens on them to explicitly override your document

It it quite appropriate (see below). 

> 1. By the same reasoning, why bother with compression at all?

Historical background: DNS was designed in the middle 80's, at that
time general purpose compression was advancing rapidly, but it was not
clear what compression would work well on DNS packets and general purpose
compression was real expensive. Network bandwidth was limited and 
reassembly was not reliable, thus requiring some compression made sense.
The choice of name compression was a reasonable one, it looks inexpensive
and has no complicated binary encodings, but keeping track of compression
pointers and ordering them is more complicated than it seems. Further the
code dealing with compression is interspersed all through the RR type 
processing. 

A better choice would have been to make the RRset the main DNS
wire envelope rather than the RR, something like 
	<name> <type> <class> <ttl> <no in set> [<size> <rdata>]+
Requires a 1 extra byes for RRset structure, but for each additional
RR there is a 2 byte header instead of 12 byte one (assuming full
compression) at much lower cost in computation.

Today the choice could simply be that a header bit signals that 
the remainder of the message is compressed (with zlib). In this case
the transmitting server can make the choice AFTER the message is
assembled and only apply compression when it is beneficial and 
resources are available. Further benefit is that all new types
are covered without any extra complexity.

But we do not have the luxury at this time to change the protocol in
this radical way, instead making the protocol more reliable 
is more important than possibly saving few bytes from some
hyperthetical future RR type. 

> in useful and can be employed in a safe, inter-operable way.
> 

Such a type is a bad idea and I do not think a type like this will ever
get passed the working group and/or IESG. 

DNS main role is to hand out small chucks of data and provide pointers to
data stores containing the larger chucks.

	Olafur

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 10 Oct 2001 21:48:15 -0400

> hyperthetical future RR type.

Well, I would have to agree that, in hindsight, the record-format-dependent compression
scheme of DNS is rather old-fashioned and awful. Something more flexible and effective
should replace it. But I'm still not convinced that "forbid it now, relax the ban later
if appropriate" is the right tack to take with respect to *safe* implementations of
compression in new types, e.g. through EDNS OPTIONs or whatever. I'd still like to see
some sort of limitation or exception in the prohibition, but if that's not the concensus
of the WG, then so be it.

By the way, I'm totally in agreement that RRsets should have been the main DNS wire
envelope from the very beginning. Not only that, but there should have been an
"options" section or something similar, to allow for future extensibility, e.g. new
compression schemes or the use of new record types, without all of this pain. Isn't
hindsight wonderful?

> data stores containing the larger chucks.

As a general rule, I agree. But who knows what the future may bring? Maybe the benefit
of such large RRs might be perceived to outweigh the costs. After all, did anyone in the
RFC 1034/1035 era think that we'd ever be comfortable routinely slinging around RRs the
size of SIGs?

- Kevin

---

From: Randy Bush <[email-masked]>
Date: Thu, 11 Oct 2001 18:13:16 -0700

> Date: Tue, 25 Sep 2001 22:12:00 -0700
> two week last call starts for draft-ietf-dnsext-unknown-rrs-01.txt for
> proposed standard.

the last call has ended.  there has been much discussion of this draft.  see
the thread off

    http://psg.com/lists/namedroppers/namedroppers.2001/msg01066.html

my read is that there is NOT rough consensus.  please feel free to disabuse
me of that notion.

randy

---

From: [email-masked] (Andreas Gustafsson)
Date: Mon, 15 Oct 2001 15:40:32 -0700 (PDT)

> my read is that there is NOT rough consensus.  please feel free to disabuse

This is how I would summarize the discussion:

  Bert Hubert expressed worry about the lack of support for mandatory
  additional section processing, but still said it was a "very good
  proposal".

  Mark Gritter worried about the treatment of meta-RRs, which are
  outside the scope of the draft.

  Dan Bernstein opposed the draft for multiple reasons.

  Kevin Darcy opposed the unconditional prohibition of compression
  in new types and asked that the draft specifically allow for
  compression when negotiated using some future mechanism (e.g.,
  based on EDNS).

  The author, Roy Arends, Mark Andrews, Robert Elz, and Olafur 
  Gudmundsson defended the current text of the draft.

Of these, I view only Dan's and Kevin's messages as significant
opposition to the draft.  Interestingly, these two cases of opposition
represent almost diametrically opposed viewpoints: Dan is saying that
the draft is unnecessary because there already is an absolute
prohibition on compression in new types and that the draft is too
loose, while Kevin is effectively saying that the draft is harmful
because the existing prohibition on compression is not absolute, and
that the draft is too strict.  To me this suggests that the draft
actually is a reasonably compromise consistent with the views of the
majority of the working group.

I'd like to ask all those who have an opinion either for or against
the draft and who have not yet expressed it on the list to please
speak up.
-- 
Andreas Gustafsson, [email-masked]

---

From: Mark Gritter <[email-masked]>
Date: Mon, 15 Oct 2001 16:44:53 -0700

While I still feel that meta-RRs need to be addressed, I accept Andreas'
argument that they are out of the scope of the draft (particularly
since they are likely to be contentious, and I _am_ very interested in
getting something done in this area as soon as possible.)  

So, I support the draft going forward in its current form; I agree that the
proposal is the correct way to handle individual RRs.

Mark Gritter

>   outside the scope of the draft.
[snip]

-- 
Mark Gritter <[email-masked]>
http://www-cs-students.stanford.edu/~mgritter/

---

From: Randy Bush <[email-masked]>
Date: Mon, 15 Oct 2001 16:50:37 -0700

> Dan is saying that the draft is unnecessary because there already is an
> absolute prohibition on compression in new types and that the draft is
> too loose, while Kevin is effectively saying that the draft is harmful
> because the existing prohibition on compression is not absolute, and that
> the draft is too strict.  To me this suggests that the draft actually is
> a reasonably compromise consistent with the views of the majority of the
> working group.

two other hypotheses:
  o compromises are not always the best solution.  sofa beds make neither
    good sofas nor good beds
  o the document is not sufficiently clear

> the draft and who have not yet expressed it on the list to please

voting, schmoting.  i'd rather one comment for each issue, stating the
issue clearly enough that, if folk feel it is salient, that the document
could be revised based on the comment.

randy

---

From: "Jesper G. Hoy" <[email-masked]>
Date: Mon, 15 Oct 2001 20:05:03 -0400

I am for the draft - but...

I agree that we need to establish exactly which RR types may have
compressed RDATA.
And I welcome the formalization of text representation for unknown RR
types.

But banning compression (and additional section processing) for ALL new
RR types could be a problem with the 512 byte limit on UDP messages.

Wouldn't it be possible to set aside a certain range of RR type numbers
that are "safe to cache as unknown" ?
Meaning those RR type numbers (when assigned) won't use compression in
RDATA and won't require additional section processing.
And another "unsafe" range which would be dropped or result in SERVFAIL
when encountered and unknown.

Also, the document does not address compression of record labels.
As far as I can tell this should never cause any problems.
I would like to see an addition to section 4 like "record labels MAY be
compressed for ALL record types"

Jesper G. Hoy

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Andreas Gustafsson
Sent: Monday, October 15, 2001 6:41 PM
To: namedroppers
Subject: Re: wg last call for draft-ietf-dnsext-unknown-rrs-01.txt

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 15 Oct 2001 20:05:36 -0400

Well, I think I've already stated my opinion in sufficient detail. I'd have
preferred that the prohibition on RDATA compression contained an exception for
situations in which it can be used safely, e.g. when negotiated via EDNS or some
similar mechanism. But, as Andreas pointed out, such exceptions can always be
made on a case-by-case basis by whomever may be proposing the new types. As
such, I have no *strong* objection to the advancement of the draft.

- Kevin

---

From: [email-masked]
Date: Tue, 16 Oct 2001 11:53:00 +1000

This draft is really just documenting existing practice as
	described in existing RFCs (not just 1034 and 1035) and how
	to deal some of the mistakes in those RFCs.

	There is only one thing new in this draft.  That is that
	it describes a text format that can be used to in master
	files to describe the contents of a RR and have it be read
	by multiple implementations instead of each implementation
	going and doing it there own way.

	This draft was not intended to extend on wire functionality.

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

---

From: "D. J. Bernstein" <[email-masked]>
Date: 16 Oct 2001 03:04:05 -0000

Andreas Gustafsson writes:
> Dan is saying that the draft is unnecessary because there already is
> an absolute prohibition on compression in new types and that the draft
> is too loose,

That is an astoundingly inaccurate summary. Here's what I actually said:

: Gustafsson's document says that caches ``SHOULD also decompress RRs of
: type RP, AFSDB, RT, SIG, PX, NXT, NAPTR, and SRV.''
: 
: I objected to that text in December 2000, and I continue to object to
: it, for several reasons:
: 
:    * RFC 1035 clearly prohibits compression except in owner names, NS
:      data, CNAME data, PTR data, MX data, and SOA data. Compression in
:      RP, AFSDB, etc. is inexcusable. There are no legitimate situations
:      where decompression of RP, AFSDB, etc. will accomplish anything.
: 
:    * My cache, which is deployed at tens of thousands of sites, handles
:      exactly the forms of compression allowed by RFC 1035. It does _not_
:      decompress RP, AFSDB, etc. It works just fine.
: 
:    * Gustafsson's text violates RFC 2119, section 6. It is not necessary
:      for interoperability. It is an abuse of the standards process.
: 
:    * BIND's support for bogus compressed records was exactly what led to
:      the http://www.cert.org/advisories/CA-2000-20.html disaster. We do
:      _not_ want more of these disasters.
: 
: The text should be replaced by the opposite recommendation. Implementors
: should be encouraged to make their decompression code as limited as
: possible, handling RFC 1035 compression and nothing else.
: 
: Gustafsson's only response to these points has been ``it's a SHOULD, not
: a MUST,'' completely ignoring the substance of my objections.
: 
: I also object to this document's failure to point out that transparent
: handling of new types is already required by the existing DNS standards.
: See http://cr.yp.to/djbdns/newtypes.html.

---Dan

---

From: [email-masked]
Date: Tue, 16 Oct 2001 14:11:03 +1000

> That is an astoundingly inaccurate summary. Here's what I actually said:
	Dan, we can all look up what you said.  It appears to have
	little bearing on reality and is more based on wishful
	thinking that no RFC was written that said you could use
	compression.  Deal with reality.

	Mark

---

From: Robert Elz <[email-masked]>
Date: Tue, 16 Oct 2001 17:20:30 +0700

Date:        Mon, 15 Oct 2001 20:05:03 -0400
    From:        "Jesper G. Hoy" <[email-masked]>
    Message-ID:  <000a01c155d6$34929af0$6400a8c0@hp>

  | But banning compression (and additional section processing) for ALL new
  | RR types could be a problem with the 512 byte limit on UDP messages.

Other than knowing RDATA encodings, and knowing that they're known, it
is the only way.

  | Wouldn't it be possible to set aside a certain range of RR type numbers
  | that are "safe to cache as unknown" ?
  | Meaning those RR type numbers (when assigned) won't use compression in
  | RDATA and won't require additional section processing.

Additional section processing isn't a big issue - it's really just an
efficiency win, so there's no real need to say anything about that at all.
If it doesn't happen because a cache doesn't understand the RR type, then
more queries happen.   Not optimal, but not fatal either.

For compression, define the "certain range" as "all except for the magic N",
and that's what we have today.

  | And another "unsafe" range which would be dropped or result in SERVFAIL
  | when encountered and unknown.

This is what you're really proposing - defining a range of RR identifiers
which might contain weird stuff (compressed labels) and which thus can
never be cached by anyone who doesn't understand them.   The effect of that
would be largely to set aside a range of RR identifiers as unusable, as in
practice, an RR that can't get through random caches isn't going to work
very well.   Just about anyone who wants a new RR type will define it to
not permit compression of any labels in its RDATA just to avoid this.

And even if it was to be considered, there's still the problem of all those
other caches out there which don't know there's this magic set of RR types
they've never heard of, and they're not allowed to cache.

  | Also, the document does not address compression of record labels.
  | As far as I can tell this should never cause any problems.
  | I would like to see an addition to section 4 like "record labels MAY be
  | compressed for ALL record types"

It wouldn't hurt adding that, but that's also pretty much given - compression
of labels is allowed in 1035, there's nothing new about that - it isn't really
in any doubt at all.

kre

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 16 Oct 2001 13:33:17 -0700 (PDT)

> that are "safe to cache as unknown" ?

One problem with this approach is that the NXT record deals poorly
with high-numbered types.

> compressed for ALL record types"

This is already noted in RFC1123 section 6.1.3.5.  I will add a
reference to this section in the next revision of the draft.
-- 
Andreas Gustafsson, [email-masked]