On Wed, Apr 29, 2020 at 8:02 PM Michael StJohns <[email protected]> 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.
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
