Re: [Acme] dns-01 challenge limitations

Ilari Liusvaara <> Fri, 11 September 2020 16:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14BE03A1267 for <>; Fri, 11 Sep 2020 09:07:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ORuwKfmV6rrT for <>; Fri, 11 Sep 2020 09:07:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 07AE13A0B3A for <>; Fri, 11 Sep 2020 09:07:28 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4CFE268408 for <>; Fri, 11 Sep 2020 19:07:25 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id aChSUDg2twHb for <>; Fri, 11 Sep 2020 19:07:25 +0300 (EEST)
Received: from LK-Perkele-VII ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 20E7C2308 for <>; Fri, 11 Sep 2020 19:07:24 +0300 (EEST)
Date: Fri, 11 Sep 2020 19:07:22 +0300
From: Ilari Liusvaara <>
To: "" <>
Message-ID: <20200911160722.GA1530059@LK-Perkele-VII>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
Archived-At: <>
Subject: Re: [Acme] dns-01 challenge limitations
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 Sep 2020 16:07:31 -0000

On Fri, Sep 11, 2020 at 03:41:08PM +0200, Patrik Wallström wrote:
> The missing piece of this puzzle is a standardized API for registrars
> (or DNS operators), where changes can be made for a zone at a registrar.
> Much like registry changes coming from registrars to a registry using
> EPP. Many attempts has been made for this, but for some reason,
> registrars like their lock-in models.
> Perhaps some day there will be an attempt at both creating a really good
> open source zone editor that will be adopted by registrars and other DNS
> opreators, that also implements an API that is generally accepted. Then
> perhaps this API could become a standard for interacting at least with
> DNS operators for changing the content of a zone. (No, and I don't think
> RFC 2136 is good enough for this.)

One another problem is that even if one has programmatic API, the
DNS service has many servers (due to being intended for high-reliability
slow-update serving, not low-reliability fast-update serving), with
potentially painfully slow propagation times.

> For now, this is for many ACME clients a manual step. If you run your
> authoritative DNS service locally in your network, perhaps you could
> look into any options for automatically update the zone content.

I think the current best way is to have _acme-challenge be a CNAME
pointing to zone served by single master with no slaves that accepts
DNS UPDATE with TSIG HMAC-SHA256 authentication for ACME client to
update the records.

The single master is more than reliable enough for the purpose (as
there should be donzens of retries spread over time for renewal before
the certificate expires) and eliminates the propagation times.