Re: [DNSOP] Error handling in CAA

Tony Finch <> Mon, 20 November 2017 13:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B044812783A for <>; Mon, 20 Nov 2017 05:10:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6n-LsrgyPD_y for <>; Mon, 20 Nov 2017 05:10:47 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7648812702E for <>; Mon, 20 Nov 2017 05:10:47 -0800 (PST)
X-Cam-AntiVirus: no malware found
Received: from ([]:39570) by ( []:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eGlqW-000bpm-04 (Exim 4.89) (return-path <>); Mon, 20 Nov 2017 13:10:44 +0000
Date: Mon, 20 Nov 2017 13:10:43 +0000
From: Tony Finch <>
To: Jacob Hoffman-Andrews <>, dnsop WG <>
In-Reply-To: <>
Message-ID: <>
References: <> <>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Archived-At: <>
Subject: Re: [DNSOP] Error handling in CAA
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Nov 2017 13:10:50 -0000

Viktor Dukhovni <> wrote:
> On Fri, Nov 17, 2017 at 12:49:33PM -0800, Jacob Hoffman-Andrews wrote:

This is a topic of operational interest to me :-)

I previously posted about CAA checks and private domains at:

Our CA has updated their implementation to issue certs if (I am told)
"a lookup error is returned (like a SERVFAIL from an internal DNS server)
AND the domain does not have a valid DNSSEC signature (or a parent domain
does not have valid DNSSEC)."

I hope that by "valid DNSSEC signature" they actually mean signed DS
RRset, but I have not tested their new behaviour.

We have worked around this problem by making a public empty view for our
private subdomain, so the fix comes a bit too late to help us. (And it
turns out there are other advantages to our workaround.)

The other entertaining CAA checking bug was due to checkers getting in
loops when CNAMEs closer to the root point at subdomains of themselves -

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

Apart from that I agree with Viktor's points.

f.anthony.n.finch  <>  -  I xn--zr8h punycode
Fair Isle, Faeroes: Northeast veering east 4 or 5, occasionally 6 later.
Moderate or rough. Wintry showers, rain later. Good occasionally poor.