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

[Shumon Huque <[e-mail]>]

On Wed, Apr 29, 2020 at 7:30 PM Ted Lemon <[e-mail]> 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.