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

[Ondřej Surý <[e-mail]>]

Michael,

while I generally agree with your “let’s write a I-D on how to deprecate old RR Types in general”, I would like to keep this document focused on MB, MG, MR, MINFO.

I’ll kick out WKS into a separate document, and add MAILB, MAILA, MD and MF in.

I would appreciate that in this discussion, instead of saying “RR Types” we should talk about specific RR Types we want to remove from DNS. Saying “removing RR Types” is scary. Saying “removing MB RR Type” is less scary as most people even don’t remember what it was used for.

Cheers,
--
Ondřej Surý
[e-mail]

> On 26 Mar 2018, at 16:22, Michael Casadevall <[e-mail]> wrote:
> 
> 
> 
> 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
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop