On Tue, Nov 21, 2017 at 3:54 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > On Mon, Nov 20, 2017 at 01:10:43PM +0000, Tony Finch wrote: > >> Viktor's message has lots of sound advice, though I have one correction: >> >> > This language really should have been much more clear. In particular, >> > the last item warrants clarification. It is critical that the CA >> > determine the lack of a validation chain in a robust manner. The >> > simplest approach: >> > >> > * Request the SOA record of the domain. If this lookup fails, >> > (ServFail, Timeout, ...) stop, the domain's DNSSEC status is >> > unknown. >> >> No, you need to lookup the domain's DS records to determine its DNSSEC >> status. > > Actually, I chose my recommendation of SOA lookup after some thought > and with care. A domain may have no DS records, and yet be signed > because it is not a (delegated) zone apex domain. Furthermore, an > SOA query elicts data from the domain itself, not the parent, and > thus ensures that any published DS records up the tree yield working > signatures for records in the zone containing the domain. > > If the SOA lookup fails, then the domain is severely broken beyond > just "stoopid" blocking of CAA and other "novel" RRtypes, and so > there is no reason for the CA to be "forgiving" of such errors. > (Not that I have much sympathy for domains where CAA lookups fail > but other lookups do not, they really should feel some pain to fix > their DNS). > > So I stand by the advice to issue "SOA" queries, they are far > simpler to implement correctly (without having to chase DS records > up the tree, cross check them against NS records, ...) and they > yield more useful information, namely whether: > > * A domain has working "insecure" DNS > * A domain has working "secure" DNS > * A domains is broken, and needs attention before CAA status > can be determined or ignored.
If the domain is broken, validation is going to fail as well. Which may prove a useful cut. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
