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

[Shumon Huque <[e-mail]>]

On Wed, Apr 29, 2020 at 8:02 PM Michael StJohns <[e-mail]>
wrote:

> See this chain
> https://mailarchive.ietf.org/arch/msg/dnsext/_kxMmGeBUI8OW03tWlcgcCW9QlU/
> (Yup - 12 years ago).
>
> I don't think I ever managed to convince anyone this was a problem.
>

Mike, perhaps there was some confusion on this point 12 years ago, but
deployed validator code all agree on what the state is. I encourage
implementers to confirm (or correct me if I misstate something).


> If you've got a validated CNAME, that points into an unsecured zone,
> then your state is probably Unsecure (if you treat it similar to a
> secure delegation to an unsigned zone) or Unknown.
>

Assuming the unsecured target zone can be proved to such (because of an
authenticated "insecure" referral, or opt-out referral on the way down to
that
zone), then the state is Insecure - the validator will return the answer,
but not
set AD=1. If the zone is unsigned, yet had a secure referral from the parent
(signed DS), then the state is Bogus, and the validator will return SERVFAIL
(unless the downstream querier set CD=1 and the validator implements a
BAD cache, in which case it will return the bogus answer).

If you've got an securely insecure (e.g. delegation was to an insecure
> zone at some point) CNAME that points into a secure zone, I would say
> your result is probably Bogus  or Unsecure as you haven't any way to
> evaluate trust.  I don't think you can bootstrap security this way.
>

Deployed validator code says Insecure. It can't be Bogus, because the
validator
has determined that the CNAME is a demonstrably insecure zone,

Shumon.