Re: draft-ietf-dnsext-apl-rr-01.txt

[Mark.Andrews@nominum.com]

> I have a web page on this issue: http://cr.yp.to/djbdns/newtypes.html
> 
> In short: There is no need for a protocol change. The standards already
> make perfectly clear that DNS caches (and AXFR secondaries) must handle
> unknown record types. The only problem is that one widespread DNS
> implementation is ignoring the standards.

	RFC 1034 and RFC 1035 are incomplete and badly worded w.r.t.
	treating new RR types as opaque data.  Even after correcting
	the wording to say that new RR types should be treated as
	opaque data they are still incomplete.

> 
> Andreas Gustafsson writes:
> > An RR containing compressed names will be silently corrupted if it is
> > transmitted as a mere block of bits.
> 
> The protocol does not allow that situation to occur in the first place.
> Compression is forbidden in new record types.

	Not according to RFC 1034 and RFC 1035.  They actually allow
	compression in new types.  Not that I agree that it should be
	allowed just that it was.

> BIND used to screw this up
> too, but it hasn't had a problem since version 8.1.2, right?
> 
> I strongly object to your draft-ietf-dnsext-unknown-rrs-00. We don't
> need more disasters like http://www.cert.org/advisories/CA-2000-20.html.
> Handling the compression allowed by the protocol---owner names, NS data,
> CNAME data, PTR data, MX data, and SOA data---already takes way too much
> code; adding more code to decompress bogus records is a really bad idea.

	Actually the server was only doing *less* than what RFC 1034 and
	RFC 1035 allowed it to do.  It was not compressing SRV rdata.  If
	it was still compressing (as earlier versions did) the bug would
	not have been triggered.  In fact it was treating the RDATA as
	opaque data, the only additional thing it did was to add the
	servers to the list of potential additional data to be added.

	draft-ietf-dnsext-unknown-rrs-00 doesn't want to add compression
	to new RRs.  It also doesn't want the server to have to know where
	domain names are in rdata hence the changes to DNSSEC in there.  

> 
> ---Dan
> 
> 
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@nominum.com


to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.