On Sat, Sep 9, 2017 at 1:59 PM, Andrew Ayer <[email protected]> wrote: > On Sat, 9 Sep 2017 13:53:52 -0700 > Peter Bowen via dev-security-policy > <[email protected]> wrote: > >> On Sat, Sep 9, 2017 at 1:50 PM, Andrew Ayer <[email protected]> >> wrote: >> > >> > drill is buggy and insecure. Obviously, such implementations can >> > be found. Note that drill is just a "debugging/query" tool, not a >> > resolver you would actually use in production. You'll find that the >> > production-grade resolver from that family (unbound) correctly >> > reports an error when you try to query the CAA record for >> > refused.caatestsuite-dnssec.com: https://unboundtest.com/ >> >> Just as I received this, I finished testing with unbound, to see what >> it does. See the results below. For your blackhole, servfail, and >> refused cases it clearly says insecure, not bogus. > > That is very clearly against RFC4033, which says defines Insecure as: > > The validating resolver has a trust anchor, a chain > trust, and, at some delegation point, signed proof of the > non-existence of a DS record. This indicates that subsequent > branches in the tree are provably insecure. A validating resolver > may have a local policy to mark parts of the domain space as > insecure. > > There is no "signed proof of the non-existence of a DS record" for > blackhole, servfail, and refused, so it cannot possibly be insecure.
I just found another tool that does checks and has a similar but distinct response set: https://portfolio.sidnlabs.nl/check/expired.caatestsuite-dnssec.com/CAA (bogus) https://portfolio.sidnlabs.nl/check/missing.caatestsuite-dnssec.com/CAA (bogus) https://portfolio.sidnlabs.nl/check/blackhole.caatestsuite-dnssec.com/CAA (error) https://portfolio.sidnlabs.nl/check/servfail.caatestsuite-dnssec.com/CAA (error) https://portfolio.sidnlabs.nl/check/refused.caatestsuite-dnssec.com/CAA (error) https://portfolio.sidnlabs.nl/check/sigfail.verteiltesysteme.net/A (bogus) https://portfolio.sidnlabs.nl/check/bogus.d4a16n3.rootcanary.net/A (insecure) https://portfolio.sidnlabs.nl/check/www.google.com/A (insecure) https://portfolio.sidnlabs.nl/check/www.dnssec-failed.org/A (bogus) Given that there does not seem to be a consistent definition on how "broken" DNSSEC should be handled, I think it is reasonable that CAs should be given benefit of the doubt on the broken DNSSEC tests. Thanks, Peter _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
