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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
