On Wed, Apr 29, 2020 at 7:30 PM Ted Lemon <mel...@fugue.com> wrote: > 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. >
If there is an unsigned CNAME (or DNAME) in the path the answer, then I'm 100% sure that the answer cannot be deemed authenticated. You may be right that this case is not clearly explained in the spec (I can't recall really, maybe some else can quote specific text if they know). But conceptually, DNSSEC requires you to prove an unbroken chain of authenticated signatures from the queried name back to the trust anchor (including paths redirected via aliases). Otherwise attackers have a trivial points (the unsigned aliases) at which to spoof answers. The answer obtained is still viable, just insecure. Downstream clients of the stub that need confirmed authenticated answers (e.g. DANE) could determine this by inspecting the AD bit in the response from the stub. 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? > It definitely can't set the AD bit. So, I suppose your argument is why bother authenticating the target. That's a defensible question. It might be reasonable behavior if the stub has no cache. But I'd expect validating stubs to have some sort of cache to amortize the cost of extra queries and computation. If it's caching, then the unvalidated target cannot reasonably be returned if a subsequent query comes directly for the target, so why would it not bother to validate it earlier. Shumon.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
