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

["D. J. Bernstein" <djb@cr.yp.to>]

Mark.Andrews@nominum.com writes:
> Not according to RFC 1034 and RFC 1035.  They actually allow
> compression in new types. 

You're not looking at the complete protocol specification. RFC 1123,
section 6.1.3.5, says ``compression must only be used for the contents
of WELL-KNOWN, class-independent RRs.'' (Emphasis added.)

The reason for such restrictions was already made clear in RFC 1035,
section 4.1.4: ``Pointers can only be used for ... If this were not the
case, a name server or [cache] would be required to know the format of
all RRs it handled.'' I agree that the ``...'' isn't broad enough, but
the rationale makes clear what to do.

The fundamental point is that the protocol is extensible. RFC 1035 says
that ``new data types ... should always be expected.'' RFC 1123 makes
this even more clear:

   A name server may acquire, via zone transfer, RRs that the server
   doesn't know how to convert to printable format. A [cache] can
   receive similar information as the result of queries. For proper
   operation, this data must be preserved ...

I realize that this isn't a capitalized MUST, but there's only one
reasonable interpretation of the protocol. BIND's behavior of destroying
unrecognized record types is not ``proper operation.'' BIND's behavior
of compressing new types (now fixed, right?) is indirectly prohibited,
because it doesn't interoperate with caches that do what RFC 1123 says.

> Not that I agree that it should be allowed just that it was.

No. The only compression allowed by the protocol is in owner names, NS
data, CNAME data, PTR data, MX data, and SOA data. My cache and AXFR
client do not decompress anything else. I object to your company's
attempts to portray this as a bad thing.

I'm not saying that decompression of other types should be prohibited by
the protocol. It doesn't affect legitimate packets; I understand that it
simplifies your code. But decompression of other types shouldn't be
_encouraged_. There's no reason that my cache should know about RP
packets and RT packets and AFSDB packets and so on.

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