Re: [Acme] Support for domains with redundant but not immediately synchronized servers

Jacob Hoffman-Andrews <> Fri, 12 February 2016 23:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4DBF11ABD35 for <>; Fri, 12 Feb 2016 15:00:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.104
X-Spam-Status: No, score=-5.104 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0m3YIfvjEBMg for <>; Fri, 12 Feb 2016 15:00:06 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4A4A61AC3B1 for <>; Fri, 12 Feb 2016 15:00:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=3MZA8WiG4snipC0WvYO0AgozYFUlQ94QWOSQ6PN8Ank=; b=blV5J00wm8C19VGJa0HOwfuNMOizdSkb/p8eNhqSrpgWPvjm4JXbpgFUaK5gBj2ogSMQqhf+fhnOCrqQ7ZSkB+DgBZ3j97jfqOeEsEjVaUfbUgJBsvEfI3VuDqEEpjxv4UCQmMcO/eVFbJS29eY48ytUjjuKhxMnEXcyk4NzSMg=;
Received: ; Fri, 12 Feb 2016 15:00:05 -0800
To: Jonas Wielicki <>,
References: <> <> <> <> <> <> <>
From: Jacob Hoffman-Andrews <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Fri, 12 Feb 2016 15:00:04 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Received-SPF: skipped for local relay
Received-SPF: skipped for local relay
Archived-At: <>
Subject: Re: [Acme] Support for domains with redundant but not immediately synchronized servers
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Feb 2016 23:00:07 -0000

On 02/09/2016 11:52 AM, Jacob Hoffman-Andrews wrote:
> As I said previously, I think it would be better for implementers to
> query each IP they receive, until they get a success.
I thought some more about this from a CA implementation perspective, and
it would actually be rather painful and error-prone to implement.

In Boulder, we have a maximum amount of time we are willing to spend on
validating a challenge. Currently it's 60 seconds. We may increase it at
some point, but there will always be some limit. For hostnames that
return a large number of IP addresses, it's entirely possible we would
timeout before reaching the one IP address that is provisioned with the

That means that instead of the nice clean "Push a challenge to any
server and it will work" guarantee, we would have a "Push a challenge to
any server, and it will work provided you don't have too many IP
addresses and the other instances respond quickly enough" guarantee.