Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

[Michael Casadevall <[e-mail]>]

On 03/26/2018 08:45 AM, Evan Hunt wrote:
> On Mon, Mar 26, 2018 at 02:09:14PM +0200, Ondřej Surý wrote:
>> That’s one of the goals of the document - saying: “it’s ok to not
>> implement those RR Types, and it’s ok to break if you receive them"
> 
> We need to state clearly what is meant by "ok to break".
> 

I think to be more specifically, the end goal should be the ability to
treat obsolete record types as RFC 3597 and remove special casing for
them. That way, new resolvers simply have to implement 3597 and not
worry about associated edge cases with the obsolete types.

> I described my preferred approach as an implementer upthread. Let me
> state it again more formally and let people knock it down:
> 
> 0. types will be flagged as obsolete/deprecated in the IANA registry,
>    and the following guidance is given to DNS implementors in the handling
>    of obsolete/deprecated RR types:
> 
> 1. auth servers SHOULD log a warning when loading zones that contain
>    obsolete/deprecated rrtypes.
> 
> 2. responders SHOULD NOT compress rdata when rendering obsolete/deprecated
>    type records to wire format.
> 

The problem here is that right up until the point the camel declares
these RRtypes dead, the specification specifically allows them to be
compressed.

Specifically quoting RFC 3597 here:
   To avoid such corruption, servers MUST NOT compress domain names
   embedded in the RDATA of types that are class-specific or not well-
   known.  This requirement was stated in [RFC1123] without defining the
   term "well-known"; it is hereby specified that only the RR types
   defined in [RFC1035] are to be considered "well-known".

By definition, the types are in RFC1035; they're well known and thus
compressible. One DNS server may serve a given record uncompressed,
while the next one down the pipe compresses it depending on it's
implementation.

This came up earlier in the thread, but PowerDNS has an open bug about
this and the MB type due to BIND sending the record compressed, and
PowerDNS not recognizing it: https://github.com/PowerDNS/pdns/issues/5687

> 3. queriers which receive obsolete/deprecated type records MAY interpret
>    them as unknown type records (rfc 3597), and MUST NOT interfere with
>    their transmission.
> 
>    3a. note that the choice to parse obsolete/deprecated MAY be contingent
>        on whether the rdata is compressed: an obsolete type record MAY be
>        parsed as a known type if its rdata is uncompressed, but as an
>        unknown type otherwise.
> > 4. validators and signers SHOULD treat rdata for obsolete/deprecated types
>    as opaque with respect to canonical RR ordering and deduplication
> 


On the whole, I'm in favor of removing cruft from the specs wherever
possible, but I'm starting to question if decommissioning RRtypes
qualifies as low hanging fruit.

If we actually want to decommission these RRtypes, and building off your
starting point, I think the reasonable course of action needs to be this:

 1. Authoritative servers SHOULD warn when loading zones with obsolete
record types

 2. Resolvers MUST never send obsolete RRtypes in a compressed format.

 3. Signers MUST treat rdata as opaque

 4. Obsolete RRtypes MUST never be treated as a known-type with respect
to the wire protocol

 5. Resolvers MAY support legacy compression for received data for
backward compatibility if desired, but SHOULD warn if such information
is received. Compressed records MUST never be re-transmitted.

 6. Validators MAY attempt to to use legacy RR ordering and
de-duplication should validation. If legacy validation is required, the
validator SHOULD warn that it was needed to validate the RRSIGs.

In effect, we're basically saying, these RRtypes are now RFC 3597, with
the caveat that it's OK to try and use them as legacy says but it's not
required.

By specifically allowing resolvers to understand compressed records, but
never send them, it allows for the case that there may be people using
these RRtypes, but sets the standard going forward to treat them as RFC
3597. The special case of allowing compressed versions to be accepted
allows for backwards compatibility and notifying where things still need
to be updated.

Then it's essentially a matter of writing a new RFC that describes how
to handle sun-setting a RRtype, and what RRtypes have been put out to
pasture formally. Everyone can understand uncompressed RRtypes, and by
forcing decompression, and those who want to use these for legacy
RRtypes can.

New resolvers don't need to worry about it, and as resolvers get
upgraded, the special case in 5 goes away. For the small handful of
people actually using these types, life continues as long as their
resolver maintains legacy receiving support. New resolvers can just
treat them as RFC 3597.

Plus we now have a procedure if we want to obsolete any other RRtypes.

Michael