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

From: Randy Bush <[email-masked]>
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.

randy

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

---

From: bert hubert <[email-masked]>
Date: Wed, 26 Sep 2001 11:17:45 +0200

> two week last call starts for draft-ietf-dnsext-unknown-rrs-01.txt for

Section 8 mentions addidtional processing. I'm afraid that this is a very
real problem - a lot records of will want to have additional processing,
which can't be expected of a server not understanding the record.

Furthermore, compression is a problem. An AXFR in 'big packet' format will
have label compression. The proposal to forbid compression of RRs which are
not well-known would prevent the more interesting applications which
require compression to reasonably fit in 512 octet packets.

We will implement this in our nameserver, even if only for testing purposes
- it allows us to serve records for which we have no support yet. As we have
no ascii zone representation, but store data directly in a relational
database, section 5 changes slightly of course, but not relevantly so.

But this proposal appears to be a slightly crippled proposal. It rules out:

	non-well-known RRtypes which need additional processing.
	non-well-known RRtypes which need compression 

The problem may not have an easy solution I'm afraid.

Regards,

bert hubert
PowerDNS

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
Trilab                                 The Technology People
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 26 Sep 2001 10:12:06 -0400 (EDT)

> which can't be expected of a server not understanding the record.

Additional section processing allways has been optional, all this document 
is to point out that it is also dependant on modified server deployment. 

> require compression to reasonably fit in 512 octet packets.

This only forbids compression in the right hand side (rdata) of new
rr types. The left hand side can still be compressed. 
If you need large packets use ENDS to increase the packet size, EDNS
is basicly mandatory for any implementation that supports DNSSEC and
A6 (see message-size document that is pending RFC publication). 

> database, section 5 changes slightly of course, but not relevantly so.

Presentation format is optional and is mainly aimed at tools used to 
debug and test DNS setups.

> 	non-well-known RRtypes which need compression 

What this document summarizes is what has been learned over the last
15 years in what area of compression (bad idea to allow it in rdata), 
and point out that additional section processing requires server upgrades. 

Unless someone writes a server that reads from a configuration file 
format of RR types and the additional section rules for that type. 
Now supporting a new type is a simple patch to this file. 

Compression of rdata is a double eged sword, it reduces the  ize of
answers but larger packtes render this less important. Compression
increases work and complexity of servers and resolvers making the system 
less reliable.

> The problem may not have an easy solution I'm afraid.

This document specifies the best possible solution to this problem,
unless we of course ban new types :-) 

	Olafur

---

From: bert hubert <[email-masked]>
Date: Wed, 26 Sep 2001 16:27:30 +0200

> is to point out that it is also dependant on modified server deployment. 

I've never seen additional processing described as optional, although I may
not have looked all that well. I do know that most implementations are
resilient in the face of nameservers that do not perform additional
processing. It does cause a lot of additional traffic though.

> unless we of course ban new types :-) 

Oh I think it is a very good proposal - it may be the best possible. It does
not solve the problem very well however. Rephrasing the limitations you
mentioned, this proposal:

	- Suggests that new RRtypes do not use compression on the right hand
	  side

	- Suggests that everybody interested in new RRtypes use an EDNS
	  compliant nameserver

Regards,

bert

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
Trilab                                 The Technology People
Netherlabs BV / Rent-a-Nerd.nl           - Nerd Available -
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet

---

From: [email-masked] (Andreas Gustafsson)
Date: Wed, 26 Sep 2001 12:04:36 -0700 (PDT)

> which can't be expected of a server not understanding the record.

As you said, there is no easy solution.  Servers can't do
type-specific additional section processing for record types that are
not defined yet.  We only have the choice between rejecting the new
records completely, like many existing servers do, or serving them
without doing additional section processing.  I strongly believe the
latter is more useful.

Servers written after a new RR type has been defined can and will do
additional section processing for them.  The text in section 8 is to
remind those defining new RR types that no matter what they specify,
existing servers in conformance with the draft will transmit the RRs
without doing additional section processing, in preference to dropping
them completely.

> require compression to reasonably fit in 512 octet packets.

Servers also can't do type-specific compression of records types that
are not defined yet.  If we allow compression in new types, it is
simply impossible for existing servers to transmit them correctly - if
they are not dropped, they will be silently corrupted.  When deploying
a new RR type, a minor increase in packet size due to the lack of name
compression is a small price to pay for not having to upgrade every
caching DNS server in the world.

I also think the benefits of RDATA compression in new types are
overrated.  A large fraction of the compression gain comes from
compressing owner names (the left hand side of the RR) rather than
names embeded in the RDATA, and owner names will continue to be
compressed even in the case of new RR types.  Also, it seems likely
that most new RR types will contain application payloads consisting
mostly of data other than domain names, and therefore would not
benefit significantly from compression.

At the Oslo DNSIND meeting, Randy Bush asked the room whether anyone
had any pressing need for any kind of compression inside the RR data
fields of anything but the NS records of the root zone.  No one did.
-- 
Andreas Gustafsson, [email-masked]

---

From: bert hubert <[email-masked]>
Date: Wed, 26 Sep 2001 22:47:05 +0200

> caching DNS server in the world.

Well, a caching DNS server doesn't need the RDATA type - I think this
proposal has the most merit when doing AXFRs to older slave servers.

Just a thought, It may be useful to state that authoritative nameservers
SHOULD warn against RDATA records which it actually does understand
natively - I see possibilities for havoc otherwise.

> fields of anything but the NS records of the root zone.  No one did.

RP comes to mind, but as nobody is using that :-) RDATA may be more useful
than I originally thought. 

Regards,

bert hubert

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 26 Sep 2001 16:27:30 -0400

[email-masked] wrote:

> compression is a small price to pay for not having to upgrade everycaching DNS
> server in the world.

As a general rule, it's probably best to avoid name compression in new types, I
concur. But let's not be overly rigid about this: name compression should be
permissible where the client and server have already established a common
understanding of the new type through EDNS or some similar mechanism.

- Kevin

---

From: [email-masked] (Andreas Gustafsson)
Date: Wed, 26 Sep 2001 14:15:53 -0700 (PDT)

> proposal has the most merit when doing AXFRs to older slave servers.

What do you mean by "a caching DNS server doesn't need the RDATA
type"?  A caching server does need to know the specific layout of
every RR type that can be compressed or that requires specific
additional section processing.  Making it safe for caching servers to
transparently receive, cache and retransmit RRs of unknown type is the
primary motivation for the draft.

> natively - I see possibilities for havoc otherwise.

Such as?

---

From: Mark Gritter <[email-masked]>
Date: Wed, 26 Sep 2001 14:42:39 -0700

I think this draft could use more in the way of requirements on caches
and forwarders--- "transparently" is not very precise.  Specifically, I think 
there is some need to look at requests and responses as whole units.

The language I would like to see is something like:

  A name server performing a recursive query must include any unknown 
  additional RRs which appear in the query.  The name server must not drop
  any unknown RRs appearing in the response it receives.

Motivation:

Extensions to DNS may involve more than new "data" types, as experienced with
DNSSEC.  Name servers being used for recursive queries do not need to 
understand the new RR types introduced as end-to-end protocol extensions,
but could interfere by dropping them from responses.  These RRs may not
be cacheable (which is an issue I'm not sure how to address in the standard---
I would be perfectly happy with not caching any response which includes
unknown RRs in the additional section.)

Merely bypassing such servers is not feasible in firewalled environments.

Most of the extensions I can think of that require such treatment would be 
controversial at best, I admit.
  -- Negotiation with load-balancing DNS.  One of the faults of such
     schemes is that they provide no way of requesting a different server
     if the one returned does not work out.  An RR in the additional section
     of a request could specify the address of a failed server, causing
     the load-balancer to return a different address.
  -- Encrypted responses.  Client public key could be included in request.
  -- Connection setup overlaid with name lookup.  (Yes, my research group
     has actually implemented this.  ;)

Without trying to argue the benefits of these individual examples, I'd 
argue that, realistically, there isn't an alternative to DNS, and so
we need to leave the door open to such protocol extensions that require
not separating unknown RRs from the known RRs they accompany.

Mark

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

---

From: [email-masked] (Andreas Gustafsson)
Date: Wed, 26 Sep 2001 14:47:04 -0700 (PDT)

Kevin Darcy writes:
> As a general rule, it's probably best to avoid name compression in new
> types, I concur. But let's not be overly rigid about this: name
> compression should be permissible where the client and server have already
> established a common understanding of the new type through EDNS or some
> similar mechanism.

I doubt the benefits of additional compression will outweigh the cost
of such a mechanism.  But if the working group does decide to
standardize a mechanism for communicating extended compression support
from client to server, its specification can serve as an update to the
unknown-rrs specification, modifying the rules for where compression
is allowed.  There is no need to change the text of the unknown-rrs
draft itself in anticipation of this.
--
Andreas Gustafsson, [email-masked]

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 26 Sep 2001 18:08:39 -0400

> draft itself in anticipation of this.

Sorry, I didn't make myself very clear. I wasn't referring to a generic "extended
compression support" negotiation feature, I simply meant that if a new record type
is only going to be used between clients and servers who are already known to
understand the type, e.g. the server only sends records of that type if the client
sent an EDNS0 OPTION requesting their inclusion, which the server understands and
with which it complies, then I see no reason why they can't use name compression in
their RDATA. Such "negotiated" compression is forbidden under the current draft
wording, and I find that too rigid.

- Kevin

---

From: [email-masked] (Andreas Gustafsson)
Date: Wed, 26 Sep 2001 15:26:13 -0700 (PDT)

>   any unknown RRs appearing in the response it receives.

This is just not how caching servers work.  Caching servers don't
cache entire responses, they cache individual resource record sets.
What you are proposing is not a change to the unknown-rrs draft but
a fundamental change to how the DNS works.

> Name servers being used for recursive queries do not need to 
> but could interfere by dropping them from responses.

There is no such thing as an end-to-end protocol extension in the DNS.
All existing extension that rely on special record types (EDNS0, TSIG,
SIG0) are hop-by-hop, i.e., they don't traverse caching servers.
-- 
Andreas Gustafsson, [email-masked]

---

From: "D. J. Bernstein" <[email-masked]>
Date: 27 Sep 2001 05:23:08 -0000

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: Roy Arends <[email-masked]>
Date: Thu, 27 Sep 2001 16:14:22 +0200 (CEST)

There I go, stating the obvious:

On 27 Sep 2001, D. J. Bernstein wrote:

>      data, CNAME data, PTR data, MX data, and SOA data.

It does not. It only states that domain names in NS, SOA, CNAME, and PTR
rdata section may be compressed. Why ? Because the RDATA sections' format
is known. It does not prohibit RP AFSDB RT SIG PX NXT NAPTR and SRV rdata
sections' domain name compression. Why not ? Those did not exist at the
time.

>      Compression in

RP's and PX's rdata contains two domain names. AFSDB, RT, SIG, NXT, NAPTR
and SRV's rdata contains a domain name. All can be compressed. There is no
documentation that prohibts it. Very legitimate. Very very legitimate
indeed. So, if its compressed, decompress it.

>      exactly the forms of compression allowed by RFC 1035.

I consider Claims with no substantial backing of real-world data are false
claims IMHO.

>      It does _not_ decompress RP, AFSDB, etc. It works just fine.

Hmm, how can that be. Luck I guess. Why luck ? Probably most pointers
point to the question sections QNAME. therefore in most cases that works.

>      for interoperability. It is an abuse of the standards process.

It is necessary, therefor you are wrong.

> completely ignoring the substance of my objections.

For the obvious reasons.

>From the NOTE WELL:

   Statements made outside of an IETF meeting, mailing list or other
   function, that are clearly not intended to be input to an IETF
   activity, group or function, are not subject to these provisions.

Regards,

Roy Arends
Nominum,
The BIND Company

---

From: [email-masked]
Date: Fri, 28 Sep 2001 00:51:36 +1000

>      _not_ want more of these disasters.

	Dan,
	      I presume you are meaning the SRV bug.  If you understood
	the causes the bug you would know that it had nothing to do with
	whether the rdata was compressed or not other than it allowed a
	otherwise hidden bug to become visible.

	For the record the rdata of the SRV record was not compressed.

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

---

From: [email-masked]
Date: Fri, 28 Sep 2001 02:08:56 +1000

>      where decompression of RP, AFSDB, etc. will accomplish anything.

	It will allow you to interoperate with implementations that
	followed the bad recommendations to compress the domainnames
	in some of the RFCs that describe this records.

>      decompress RP, AFSDB, etc. It works just fine.

	Provided you don't get answers from any of the above
	implementations.

>      for interoperability. It is an abuse of the standards process.

	Actually it is as we (the working group) stuffed up and put out
	RFCs that said you could compress what we shouldn't have.

> a MUST,'' completely ignoring the substance of my objections.

	Well I'd make it MUST decompress or MUST detect compression
	and return SERVFAIL if found.  That we those that just want
	to make this work can be happy and those that feel they
	need to force people to upgrade can be happy.  In no case
	should they be sent on in compressed form.

	Mark

---

From: Mark Gritter <[email-masked]>
Date: Thu, 27 Sep 2001 09:21:32 -0700

> a fundamental change to how the DNS works.

I realize that this is the case for caching servers, and I do not wish
to force such a change.  As I pointed out a little later, the best thing to 
do with messages such as the ones I envision might be to not cache the
RRs at all (which can be done by setting TTL=0 and doesn't require 
software changes.)

My concern is primarily with forwarding behavior.

> SIG0) are hop-by-hop, i.e., they don't traverse caching servers.

That does not imply that there cannot or should not be such extensions.

The change I am asking for is a requirement that unknown records 
not be dropped from either requests or responses.  This need not 
apply to answers generated from a cache.

This does require that caching DNS servers build their (non-cached) responses 
directly from the answers they receive rather than putting the RRs into a 
cache and then synthesizing the result.  It is not hard, in my experience, 
to do so, since the necessary mapping between pending responses and client 
requests already exists.

I admit that other decisions might be the technically correct thing to do.  

However, it will be impossible to deploy any future extensions without
defining explicitly what a recursive name server is supposed to do with
unknown RRs, and "transparently" doesn't cut it.  So, stepping back
for a moment, I think there _is_ behavior that needs to be specified.

If a query contains unknown RRs, is the correct behavior
  1. Ignore them
  2. Send back SERVFAIL (seen in the wild) or FORMERR
  3. Pass them along if no answer found in the cache
  4. Always forward the query rather than looking in the cache

(Some existing DNS servers return SERVFAIL if the query _type_ is unknown...)

Similarly, if a reponse contains unknown RRs, is the correct behavior
  1. Pass just the answers back to the original requester
  2. Pass both answers and additional records back to the original requester
  3. Pass back only CNAME records and those matching QTYPE, doing own
     additional section processing?

If some of the response types do not match QTYPE, what is the proper
"transparent" behavior?

Even if we don't agree on what transparent _should_ mean, I hope that
we can come up with some language that at least allows designers to
know more specifically what to expect.

---

From: [email-masked]
Date: Fri, 28 Sep 2001 02:13:35 +1000

> handling of new types is already required by the existing DNS standards.

	The existing RFC's failed to cover master file formats for
	unknown types.  As such they were incomplete.

>From RFC 1034.

The standard format of master files allows them to be exchanged between
hosts (via FTP, mail, or some other mechanism); this facility is useful
when an organization wants a domain, but doesn't want to support a name
server.  The organization can maintain the master files locally using a 
text editor, transfer them to a foreign host which runs a name server,
and then arrange with the system administrator of the name server to get
the files loaded.

	Mark

---

From: "D. J. Bernstein" <[email-masked]>
Date: 27 Sep 2001 17:19:24 -0000

The existing DNS standards already state clearly that caches should save
RRs of unknown types. This is, as an engineering matter, obviously
incompatible with servers that compress new types.

Inescapable conclusion: Servers must not compress new types.

Roy Arends writes:
> D. J. Bernstein wrote:
> It does not.

RFC 1035 says

   Since the domain system is intentionally extensible, new data types
   ... should always be expected. ...

   Pointers can only be used for occurances [sic] of a domain name where
   the format is not class specific. If this were not the case, a name
   server or resolver would be required to know the format of all RRs it
   handled.

In case that isn't clear enough: RFC 1123 says

   DNS software ... SHOULD be written to minimize the trauma associated
   with the introduction of new well-known types and local
   experimentation with non-standard types. ...

   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. ...

   A resolver can receive [unrecognized data types] as the result of
   queries. For proper operation, this data must be preserved.

Pretty damn clear.

> indeed. So, if its compressed, decompress it.

Wrong. As I said, compression is RP, AFSDB, etc. is inexcusable. BIND
hasn't screwed this up since version 8.1.2, right?

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 27 Sep 2001 17:45:57 -0000

[email-masked] writes:
> If you understood the causes the bug you would know that it had
> nothing to do with whether the rdata was compressed or not

According to a bugtraq message, the SRV bug was ``a bug in the handling
of the compression pointer tables'' when a BIND 8.2.2-P6 cache received
certain types of SRV records.

This disaster would never have happened if BIND had simply treated SRV
as opaque data.

---Dan

---

From: [email-masked] (Andreas Gustafsson)
Date: Thu, 27 Sep 2001 10:42:45 -0700 (PDT)

> wording, and I find that too rigid.

Even then, I would prefer that exceptions to the "no compression" rule
be stated in the proposals defining the RR types and/or EDNS0 options
they apply to, to ensure that their consequences get carefully weighed
on a case-by-case basis.  Including a blanket endorsement of
negotiated compression schemes in the unknown-rrs draft itself would
only encourage their indiscriminate use.
-- 
Andreas Gustafsson, [email-masked]

---

From: [email-masked] (Andreas Gustafsson)
Date: Thu, 27 Sep 2001 11:29:14 -0700 (PDT)

>      data, CNAME data, PTR data, MX data, and SOA data.

RFC1035 neither clearly allows nor clearly prohibits compression in
future types.  It only touches on the subject in the following
paragraph:

  Pointers can only be used for occurances of a domain name where the
  format is not class specific.  If this were not the case, a name server
  or resolver would be required to know the format of all RRs it handled.
  As yet, there are no such cases, but they may occur in future RDATA
  formats.

This is confusing and self-contradictory.  It implies that future
non-class-specific RRs can be compressed without servers or resolvers
knowing the format of all RRs, but as we all know, that is not
actually the case.

>      Compression in RP, AFSDB, etc. is inexcusable.

I fully agree.  That is why the draft says it MUST NOT be done.

>      There are no legitimate situations

It will accomplish interoperability with existing broken implementations
that are in widespread use.

>      for interoperability. It is an abuse of the standards process.

Even interoperating with common broken implementations counts as
interoperability.

> handling of new types is already required by the existing DNS standards.

I don't have a problem with adding a reference to RFC1123.
-- 
Andreas Gustafsson, [email-masked]

---

From: [email-masked] (Andreas Gustafsson)
Date: Thu, 27 Sep 2001 12:29:12 -0700 (PDT)

> My concern is primarily with forwarding behavior.

You seem to be making a distinction between caching and forwarding
servers that doesn't really exist.  In existing caching servers,
forwarding is just a way to override the mechanism for determining
which servers to ask.  The response to a forwarded query is processed
and cached just like the response to any other query.

> not be dropped from either requests or responses.

The intent of the draft is that servers should treat records of
unknown type the same way it treats records of known type.  Existing
servers will drop records of known type that are irrelevant to the
query (e.g., BIND 9 would always drop an unexpected PTR in the
additional section of a response to an A query, and BIND 8 would drop
it when answering from the cache), and I expect them to treat records
of unknown type the same way.  The treatment of unexpected records in
queries and responses (whether of known or unknown type) may be poorly
specified in the existing DNS standards, but that issue is orthogonal
to the issue the draft is trying to address.

Besides, your hypothetical end-to-end extension should allocate its
special RR type from the range reserved for meta-types in RFC2929,
which is specifically excluded from the definition of "unknown type"
in the unknown-rrs draft.  Therefore, the treatment of such records is
outside the scope of the draft.  If you wish to propose a standard way
of handling unknown meta-records, I suggest you do that as a separate
draft.
-- 
Andreas Gustafsson, [email-masked]

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 27 Sep 2001 17:56:55 -0400

> only encourage their indiscriminate use.

I think that, without some sort of broad exception like that, the compression
prohibition oversteps the self-announced charter of the draft, inasmuch as it prohibits
compression even in "known" RRs ("known" to all relevant parties, that is, i.e. the
client and server), and basically declares all new record types guilty until proven
innocent in this regard. If you want to sweep that broadly, you should rename the draft
to "Rules for Addition of New Record Types" or something similar.

- Kevin

---

From: [email-masked]
Date: Fri, 28 Sep 2001 11:59:54 +1000

> This disaster would never have happened if BIND had simply treated SRV

	Dan,
	      I'd describe how to trigger the bug in detail except that
	then people would be deliberating DoS the existing servers that
	havn't upgraded yet.

	I fixed the bug and had to workout which version of BIND were
	affected.  The bug exists in more versions that those listed
	on http://www.isc.org/products/BIND/bind-security.html but
	it cannot be triggered in the earlier versions.  Only the
	version listed can be DoS'd.  The bug predates SRV by many
	years.

	Mark

---

From: Matt Crawford <[email-masked]>
Date: Fri, 28 Sep 2001 08:42:06 -0500

>    the format is not class specific. 

And this (class-independence) was clearly the wrong condition.

> [...]

Elsewhere RFC 1123 says
         At every layer of the protocols, there is a general rule whose
         application can lead to enormous benefits in robustness and
         interoperability:

                "Be liberal in what you accept, and
                 conservative in what you send"

         Software should be written to deal with every conceivable
         error, no matter how unlikely; sooner or later a packet will
         come in with that particular combination of errors and
         attributes, and unless the software is prepared, chaos can
         ensue.  In general, it is best to assume that the network is
         filled with malevolent entities that will send in packets
         designed to have the worst possible effect.  This assumption
         will lead to suitable protective design, although the most
         serious problems in the Internet have been caused by
         unenvisaged mechanisms triggered by low-probability events;
         mere human malice would never have taken so devious a course!

         Adaptability to change must be designed into all levels of
         Internet host software.  As a simple example, consider a
         protocol specification that contains an enumeration of values
         for a particular header field -- e.g., a type field, a port
         number, or an error code; this enumeration must be assumed to
         be incomplete.  Thus, if a protocol specification defines four
         possible error codes, the software must not break when a fifth
         code shows up.  An undefined code might be logged (see below),
         but it must not cause a failure.

As you say, "Pretty damn clear".

---

From: [email-masked] (Andreas Gustafsson)
Date: Fri, 28 Sep 2001 10:44:22 -0700 (PDT)

> I think that, without some sort of broad exception like that, the
> compression prohibition oversteps the self-announced charter of the
> draft, inasmuch as it prohibits compression even in "known" RRs
> ("known" to all relevant parties, that is, i.e. the client and
> server), and basically declares all new record types guilty until
> proven innocent in this regard. If you want to sweep that broadly, you
> should rename the draft to "Rules for Addition of New Record Types" or
> something similar.

I disagree.  The prohibition on compression is not a new requirement.
The draft is only documenting an existing, though poorly documented,
restriction.

Even negotiated compression should be considered unsafe until proven
safe.  As a hypothetical example of what it might break, consider a
DNS translator unit built into a NAT or firewall modifying DNS packets
on the fly.
-- 
Andreas Gustafsson, [email-masked]

---

From: Robert Elz <[email-masked]>
Date: Fri, 28 Sep 2001 13:22:23 +0700

Date:        Thu, 27 Sep 2001 17:56:55 -0400
    From:        Kevin Darcy <[email-masked]>
    Message-ID:  <[email-masked]>

  | inasmuch as it prohibits compression even in "known" RRs

Didn't we once have at least an agreement in principle that some later
EDNS version could degree that RR types <list of types> are "well known"
to implementations that understand that EDNS version, and hence compression
would be allowed in the RDATA for those RR types?

The EDNS doc would need to explicitly say which RRs it was including.

That seems to me to be the right way to gradually permit compression in
more RR types - EDNS negotiation is point to point, so it works in all
the right cases (which is also needed for packet length changes, etc).

Doing it this way (even using a flag bit to say "the compression part of
EDNSn is implemented" if that seems better than just "must be implemented")
provides the negotiation mechanism to allow sender & recipient (and
any intervening caches) all know what is going on, or avoid the issue.

What's more, as that would be a later RFC than this one, it can update this
one without caring what the current doc says must or must not be done.

This doesn't sound to me like an issue that we really need to be wasting
time on now.

kre

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 28 Sep 2001 17:11:02 -0400

> The draft is only documenting an existing, though poorly documented,

If all you're doing is "documenting" requirements, shouldn't you at least
be noting the fact that the prohibition -- or at least the rationale for
the prohibition -- is partially obsoleted by EDNS0? If you don't note that,
then I'd say your documentation is incomplete.

> DNS translator unit built into a NAT or firewall modifying DNS packets

Then turn the extension OFF if you're behind one of those beasts! That's
one of the main strengths of negotiated extensions -- they can always be
turned off if talking to/through something that doesn't understand them.

- Kevin

---

From: "D. J. Bernstein" <[email-masked]>
Date: 28 Sep 2001 19:44:54 -0000

> unknown types.  As such they were incomplete.

This issue is explicitly addressed in RFC 1123:

   A name server may acquire, via zone transfer, RRs that the server
   doesn't know how to convert to printable format. ... For proper
   operation, this data must be preserved, and hence the implication is
   that DNS software cannot use textual formats for internal storage.

It's not my fault that you haven't read RFC 1123. The tinydns data
format has supported unknown types for nearly two years.

I understand that you've finally extended the BIND input format to allow
unknown types. I have no objections to documenting that format. I do
object, however, to your pretense that BIND's previous behavior was
acceptable.

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 29 Sep 2001 00:51:36 -0000

[email-masked] writes:
> The bug exists in more versions
  [ ... ]
> but it cannot be triggered in the earlier versions

You're splitting hairs. The bottom line is that CERT Advisory 2000-20
would never have happened if you had treated all new record types as
opaque data. Other implementors should be encouraged to _avoid_ your
mistakes, not to imitate them.

---Dan

---

From: [email-masked]
Date: Sat, 29 Sep 2001 11:12:50 +1000

>    that DNS software cannot use textual formats for internal storage.

	Which just proves to point that RFC 1034 / RFC 1035 were
	incomplete as they didn't meet their intent of allowing
	zones to be moved between nameservers (from different vendors)
	using textual means.

	The correct fix when this was identified back when 1123 was
	written should have been to do what we are doing now and
	define a mechanism.

	Mark

---

From: [email-masked] (Andreas Gustafsson)
Date: Fri, 28 Sep 2001 16:14:09 -0700 (PDT)

Kevin Darcy writes:
> the prohibition -- is partially obsoleted by EDNS0?

EDNS0 does not change the rules for compression - it's a general
purpose negotiation mechanism that could be used to change any number
of aspects of the DNS protocol, including the rules for compression.
If some future EDNSn (n>0) does this, it will obsolete certain parts
of the unknown-rrs specification, but EDNS0 itself does not.

> Then turn the extension OFF if you're behind one of those beasts!

Then you are imposing the requirement that extended compression is
configurable, and the administrative burden of manually configuring
it.
-- 
Andreas Gustafsson, [email-masked]

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 28 Sep 2001 21:57:17 -0400

> of the unknown-rrs specification, but EDNS0 itself does not.

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. 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.

> configurable, and the administrative burden of manually configuring

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.

- Kevin

---

From: [email-masked]
Date: Sat, 29 Sep 2001 17:15:35 +1000

> mistakes, not to imitate them.

	Sure they should be encouraged not to make the same mistake.

	However you need to know what the mistake is before you
	start encouraging people not to do something.  You quite
	evidently don't know what the actual mistake was or you
	would not be complaining about SRV records being treated
	as non-opaque data.  You would/should be encouring them to
	fix the root cause of the problem rather than spouting
	nonsense about ignoring the rdata field contents of known
	RR types.

	Mark