Re: [DNSOP] Validating responses when following unsigned CNAME chains...

[Ted Lemon <[e-mail]>]

On Apr 29, 2020, at 6:56 PM, Shumon Huque <[e-mail]> wrote:
> I believe a validating resolver always sets the DO-bit in outbound queries. The answer in your example can't be authenticated (i.e. no AD bit can be set) because not all the answers (namely the CNAME) in the response have been authenticated (per RFC 4035, Section 3.2.3).
> 
> But a resolver would still authenticate the RR type at the signed target of the CNAME (assuming the target has an unbroken chain to the trust anchor), and record that RRset as authenticated. Otherwise, if it later received a query directly for the target name/type, it could not return the answer that it incorrectly didn't bother to authenticate.

Maybe the embedded assumption I’m making here wasn’t clear. I’m talking about a stub resolver implementation. I think that all stub resolvers should be able to be asked to do validation, and should do validation if asked. You could argue that they should be required to do it, but I don’t think we’re there yet, and I’m probably a bit in the rough on requiring resolvers to do validation if asked.

The question is, if the stub resolver can validate, and has been asked to validate, in that case what do we do if the CNAME is not in a secure zone?  Your response makes it sound like you know the answer, but I don’t think it’s specified anywhere. So I’m asking (a) if anybody knows that is specified somewhere, and if so where, and (b) if it is not specified, what do we all think the correct answer is.

Your answer actually brings up a second, also interesting, question: if a stub resolver sets the DO bit, and the CNAME is not in a secure zone, but the answer is in a secure zone, do we set the AD bit? It looks like according to RFC4035, section 3.2.3, we do not. So in that case, is the resolver obliged to validate the answer it gets by following the CNAME? It can’t set the AD bit in this case, right?