Re: [DNSOP] Error handling in CAA

Mark Andrews <marka@isc.org> Sat, 18 November 2017 20:13 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58431241F5 for <dnsop@ietfa.amsl.com>; Sat, 18 Nov 2017 12:13:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouwQTDM6R9Vt for <dnsop@ietfa.amsl.com>; Sat, 18 Nov 2017 12:13:14 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BCFD1200FC for <dnsop@ietf.org>; Sat, 18 Nov 2017 12:13:14 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id BA3CF3BA2D6; Sat, 18 Nov 2017 20:13:11 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 7B937160072; Sat, 18 Nov 2017 20:13:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 6380916006E; Sat, 18 Nov 2017 20:13:10 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RvhAUSX9LGKu; Sat, 18 Nov 2017 20:13:10 +0000 (UTC)
Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 8E98E160044; Sat, 18 Nov 2017 20:13:09 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <3e958c19-016f-b413-78c5-4fd3c7c41daa@eff.org>
Date: Sun, 19 Nov 2017 07:13:09 +1100
Cc: dnsop WG <dnsop@ietf.org>, Phillip Hallam-Baker <phill@hallambaker.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <12877293-384A-4A8B-BC74-F025CCE30765@isc.org>
References: <3e958c19-016f-b413-78c5-4fd3c7c41daa@eff.org>
To: Jacob Hoffman-Andrews <jsha@eff.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/4c_SDvSYXoob7dYfoyaF4kaMBro>
Subject: Re: [DNSOP] Error handling in CAA
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 Nov 2017 20:13:16 -0000

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 <jsha@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: marka@isc.org