The only real way to determine if a lookup failure in internally or not is to query the authoritative servers for the zone directly.
The simple fix is to charge $1000 extra if the CAA lookup fails due to the authoritative servers for the zone failing to support lookups for the CAA record or for the servers being incorrectly delegated. This covers moving the lookup off the automated path. Make sure this fee is clearly stated up front. RFC 1034 had clear instructions for how to handle unknown records. You refuse to load the zone if they present and return SERVFAIL. After that there is no special handling required. As they are not present in the zone the server returns NOERROR or NXDOMAIN as appropriate. Recursive servers treat them as opaque blobs. Add to that RFC 3597 was published in 2003 which provided a master file representation to allow unknown records to be saved in a master file. It also repeated the handling instructions from RFC 1034 in different words. Failing to support CAA lookups include but is not limited to: returning SERVFAIL (rcode 2) returning FORMERR (rcode 1) returning NOTIMP (rcode 4) timing out on CAA lookups but not timing out on one of SOA, A or AAAA Mark > On 18 Nov 2017, at 7:49 am, Jacob Hoffman-Andrews <j...@eff.org> wrote: > > In the SPASM group, we are refining CAA (RFC 6844) based on the changes > that were needed in order to get it passed at the CA/Browser Forum. > There's one sticky bit in particular I'd like input on. Here's the > current language in the BRs: > > https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.4.pdf > >> CAs are permitted to treat a record lookup failure as permission to issue >> if: >> - the failure is outside the CA's infrastructure; >> - the lookup has been retried at least once; and >> - the domain's zone does not have a DNSSEC validation chain to the >> ICANN root. > > It would be nice if we could provide more solid language for a future BR > update, or possibly for a CAA update. > > The goal here is to work around the issue that a small but significant > number of domains return errors when asked for CAA ((I'd guesstimate > 1%?). CAs would like to be able to assume there is no CAA record present > for those domains and issue anyhow. > > However, if you're using a standard recursive resolver inside your own > infrastructure, and you get a SERVFAIL, how do you distinguish whether > that was a DNSSEC validation failure or another type? I realize the > extended-error draft will help enormously with that, but I'm looking for > a solution that can be deployed before that is done. One idea: Run two > recursive resolvers, one validating and one not. If you get an error > from both, it's a network error; if you get an error from the validating > one and success from the non-validating one, it's a DNSSEC error and you > should refuse issuance. > > A second issue: How does one determine automatically whether a failure > is "outside a CA's infrastructure?" This was inserted as a bit of a > handwave to get the ballot passed, but it would be nice if we could > formalize this concept, or declare that it's unenforceable. > > Thanks, > Jacob > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
