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

[Shumon Huque <[e-mail]>]

On Thu, Apr 30, 2020 at 2:47 PM Ted Lemon <[e-mail]> wrote:

> On Apr 30, 2020, at 2:31 PM, Michael StJohns <[e-mail]>
> wrote:
>
> Because an attacker can twiddle with a CNAME.  So while the recipient sees
> a CNAME pointing at a validatable end item, that may not have been the end
> name the publisher provided.   I'd probably say unsecure though, as I don't
> expect the client can detect bogus in this case unless there was a rule
> saying this was a bogus configuration.
>
> Mike
>
> ps - What's the validation level for a secured CNAME that points at an
> unsecured CNAME that points to a secured A record?
>
> I think that what we’re really talking about is that we have some chain of
> items where some items are provably not signed, and some are provably
> signed and have been validated. Any items that do not match one of these
> two criteria can be treated as “unknown.”  So:
>
> * If _all_ the items are provably signed and have been validated, the
> answer sets the AD bit.
>

yes.


> * If _some_ of the items have been validated, and others are provably not
> signed, then the answer doesn’t set the AD bit, but an answer is sent.
>

yes.


> * If we have a partial answer because we didn’t get some answers, is that
> any different than the case where we got bogus answers?
>

Depending on what we didn't get, this answer would be Bogus or
Indeterminate, per RFC 4035, Section 4.3. I think the practical effect of
this is the same for any client of the resolver: SERVFAIL (or if client set
checking disabled, return the partial answers with AD=0,CD=1).

Shumon.