On Thu, Apr 30, 2020 at 2:47 PM Ted Lemon <mel...@fugue.com> wrote: > On Apr 30, 2020, at 2:31 PM, Michael StJohns <m...@nthpermutation.com> > 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.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
