Re: [Acme] DNS challenge spec doesn't support CNAME model

Andrew Ayer <> Thu, 17 December 2015 16:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 82F891B2F18 for <>; Thu, 17 Dec 2015 08:19:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TWG7T-yc5dW2 for <>; Thu, 17 Dec 2015 08:19:49 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 48E751B2EE7 for <>; Thu, 17 Dec 2015 08:19:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=alcazar2; t=1450369188; bh=bEcljGToUcgLzi7442EUlkN3xAbptfoYVF8o0czbf98=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=rNM1SErE+QBZegrjUQcNL5mhwrlekT9PYwY1br95AbCFgD0OLN2f9cjcsixqmcdhS rHO4cwjMcAXOtDZrAWPy0SUkyqOfBduEoN0uWArfBVhp6EW4ImR37bC2v5Y58koDB0 76nwQ4kHb2idQpIrifLy7thiz6C0CSFNggVkXxu4W40PmEAJSAEx+qO4T3bRwcVAIb tSx8MqIrAXy+B/Ue/V2npJXGcFz9JFNnEVYH8bYyqnQqeZ5BtzyC6XuT7HeuF3oCgl /E8AgbCzpxXHD6sFrr5ryB9Ol22LHdIfvDmQZBvUaYyzgGXph/DUtZkFwklOJIysTk +qV0V0eSwSTFw==
Date: Thu, 17 Dec 2015 08:19:48 -0800
From: Andrew Ayer <>
To: Eric Mill <>
Message-Id: <>
In-Reply-To: <>
References: <>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Acme] DNS challenge spec doesn't support CNAME model
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: Thu, 17 Dec 2015 16:19:50 -0000

On Thu, 17 Dec 2015 02:23:20 -0500
Eric Mill <> wrote:

> Since DNS specifies that a CNAME can be thought of as an alias[6],
> this means that a service like Tumblr is capable of setting a TXT
> record for with the validation token for
> A spec-compliant DNS resolver looking for a TXT
> record for should follow the CNAME alias first, and
> then correctly identify the TXT record for as
> applying to
> However, the current ACME spec asks for the record to be set for a
> prefix, not for the requested FQDN. And if I CNAME
> over to Tumblr, Tumblr does not have the ability to set any records
> for a prefix, such as This means
> that services which have users CNAME domains are not able to use DNS
> validation to obtain certificates.
> I think that ACME should revisit the DNS specification and avoid
> using a prefix for the TXT validation, to enable this use case.

I disagree, because of a major restriction that DNS places on CNAMEs:
CNAMEs cannot coexist with other record types.  If ACME didn't use
prefixes, and you CNAME'd over to Tumblr, you would
lose the ability to yourself complete a DNS challenge for, since no other record type could coexist with that
CNAME.  This would pose a major problem for users of third-party
services which do support TLS with user-provided certs but don't
implement ACME.

Meanwhile, there is a simple solution that does enable your use case:
Tumblr can ask you to also CNAME over
to them.  It's slightly inconvenient to have to provision two CNAMEs
instead of one, but this seems preferable to forcing some users
to choose between CNAMEing to a third-party service and being able to
use ACME themselves.

> Also: I can't think of any changes offhand that would enable Let's
> Encrypt to support a use case where users set an A record to point to
> a third party service, such as for apex domains in the services
> mentioned above. But this is another important use case, especially
> for service providers which don't distinguish between apex and
> non-apex domains in their business offerings.[7] It'd be great to
> hear ideas for how that might be achieved.

Again, just CNAME _acme-challenge over to the third-party service :-)