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

[Michael Casadevall <[e-mail]>]

On 03/26/2018 10:57 AM, Evan Hunt wrote:
>>> 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.
> 
> But it's always allowed them not to be compressed, too. The trouble
> PowerDNS had was because it wasn't expecting compression, but I would
> expect the opposite problem (failing because something *didn't* compress)
> to be rarer.
> 

Right, it just happens the DNS compression is common. RFC 3597-compliant
resolvers will just take whatever blob they get and kick it along.
Anything with specific support for these types realistically are going
to support the uncompressed variants limiting interop issues.

>>  1. Authoritative servers SHOULD warn when loading zones with obsolete
>> record types
>>
>>  2. Resolvers MUST never send obsolete RRtypes in a compressed format.
> 
> Problem here: If the resolver is treating the record as opaque, then it
> can only send it along in whatever format it was received in, so this
> requirement doesn't work as written. But I think what you mean is that
> even if the resolver is able to parse compressed rdata, it MUST NOT
> compress when sending the answer along to its own client. This is
> re-stated in point 5, below.
> 

Ah, misthink. You got my intent right, but it should be specifically
written as such.

2. Resolvers MUST never generate obsolete RRtypes in a compressed
format. If (in line with below) the resolver receives a record in
compressed form, it MUST be decompressed before being sent to downstream
resolvers as though. Resolvers SHOULD warn that they are unpacking
records in transit.

How's that sound? I'm still somewhat iffy on my understanding of DNSSEC
RRSIG canonical forms, but if I understood the RFCs correctly, the
uncompressed record should match the canonical form the RRSIG validates
against to which in turn is identical to RFC 3597 (aside from WKS,
although RFC 2136 suggests it only applies in the case of DNS update and
not validation)

It specifically states you're allowed to understand, but thou must not
speak. If there's a DNSSEC concern, it should be noted though I don't
think it's a showstopper in and of itself. As previously stated, I very
much doubt these records are commonly if ever signed.

>>  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.
> 
> You use MUSTs where I used SHOULDs, but I think we're both pointing
> in the same direction.
> 

My thought process here with MUST is we're basically saying that
compressing these types is no longer valid behavior. You can understand
it for backwards compatibility, but if you're compliant with this new
RFC, you're basically asserting you will not generate compressed
responses. It also somewhat aids the process of the special case
disappearing from the internet.

I see no reason why we should allow them unless someone can come up with
an actual usecase (I haven't had a chance to read RFC 2136 in-depth but
it looks like it should work just fine with uncompressed records).
Michael