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

Jonas Wielicki <jonas@wielicki.name> Tue, 09 February 2016 19:40 UTC

Return-Path: <jonas@wielicki.name>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B931D1ACED4 for <acme@ietfa.amsl.com>; Tue, 9 Feb 2016 11:40:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
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 AWf5z-u6tHMd for <acme@ietfa.amsl.com>; Tue, 9 Feb 2016 11:40:23 -0800 (PST)
Received: from sol.sotecware.net (sol.sotecware.net [78.47.24.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FD371ACED7 for <acme@ietf.org>; Tue, 9 Feb 2016 11:40:22 -0800 (PST)
Received: from altair.sotecware.net (x4d0d56a3.dyn.telefonica.de [77.13.86.163]) by sol.sotecware.net (Postfix) with ESMTPSA id 2D0192005D1 for <acme@ietf.org>; Tue, 9 Feb 2016 19:40:20 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wielicki.name; s=k001.sol; t=1455046820; bh=q1JqKSrOisX0NZjzOihu0uHQpt84DRoIY8h/W5687VE=; h=Subject:To:References:From:Date:In-Reply-To; b=O7gaGXsM9t9c6imWRdMPfPiZn+x0sEHaKC4D81ZW2ldzyUZmTj4s7d3QHTWREPJLZ sxpvK/8m8hYqFNoaj/kkA41YRqWMCbOBLcyPWO3uxYUQkAghockxgWJWuA3L3XDfnx OMWlZlGMk63cwbKQsVSSkmzaVw/c0jGJjXDSMul8rsirNt9/z9PetTcLNy1qNA+5aL PDPPsg4mmpJXITxhGUWkQKyAwI+JEB7Nto12cpKeW/uqsXltoXvCW37TA20TRSzdR0 1Uj2YdaklpSjIts87OWvO49H6DcEqTrS0p6j/2tdHK/Qw3riu850+YtQVtd/y5z9lF 1A43ffm9/B2Kw==
To: acme@ietf.org
References: <565C84A1.9040102@wielicki.name> <20151204084601.GQ18430@eff.org> <255B9BB34FB7D647A506DC292726F6E13BB473EFFB@WSMSG3153V.srv.dir.telstra.com> <56A0C558.2070202@wielicki.name> <046f30469e8d4cdfafb01b7e7f9d4608@usma1ex-dag1mb1.msg.corp.akamai.com> <56B9BDD8.9010008@wielicki.name> <56B9C501.6000106@wyraz.de> <56B9DEA8.3090009@wielicki.name> <56B9EF4E.4030807@wyraz.de>
From: Jonas Wielicki <jonas@wielicki.name>
Message-ID: <56BA40A1.2040304@wielicki.name>
Date: Tue, 09 Feb 2016 20:40:17 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <56B9EF4E.4030807@wyraz.de>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/EjtJLjjpTykud-Ea5ip6GoUECLg>
Subject: Re: [Acme] Support for domains with redundant but not immediately synchronized servers
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Feb 2016 19:40:25 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



On 09.02.2016 14:53, Michael Wyraz wrote:
> Hello Jonas,
>> 
>>> IMO a better way to support your scenario as well as those I 
>>> described above would be to check for an SRV-Record before
>>> checking A-Records. This would be 100% compatible with existing
>>> acme http-01 clients. In your case you would resolve the SRV
>>> record to the machine that has the acme client running on. The
>>> acme-server would check for the SRV-Record for an address to
>>> lookup the challenge's response at. If no SRV record is
>>> specified, it would continue with A and AAAA records.
>> 
>> I am not entirely sure I get what you want to say here. SRV
>> records contain not only a host name, but also priorities,
>> weights and ports, so I wonder how that information would be used
>> in this context.
>> 
>> Do you suggest to have the client use an SRV record to specify
>> the address (including the port?) to which the server connects to
>> complete the challenge? In that case, what would the effect of
>> multiple SRV records for the target name be?
> correct, that's exactly what I meant. Example:
> 
> _acme.http-01._tcp.mydomain.com. 3600 IN    SRV    10 1 80 
> acme.mydomain.com.
> 
> For multiple SRV weight/priority should be respected.
> 
> Four your case you would resolve www.mydomain.com to several ip
> addresses: www.mydomain.com. IN A IP-Address-Server1 
> www.mydomain.com. IN A IP-Address-Server2
> 
> While acme.mydomain.com resolves to a single ip address of the
> server where the acme client runs on: acme.mydomain.com. IN A
> IP-Address-Server1

So if I understand this correctly, the ACME client would have to set
(or modify) the SRV records in such a way that the host which is
currently running the client is the one with the highest priority?
This sounds like you could just use the DNS challenge, right?

And it is a different use-case from the one I posted initially. If the
clients were able to modify the DNS properly, I could indeed use the
dns-01 challenge in my scenario. This is not the case though.

best regards,
jwi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJWukChAAoJEMBiAyWXYliK18cQAIy62Y2z6Lgd0hKKoUcFWhgh
qoNzwv6MzJTeEbaUXid7yiNkO13eKMtg2eX5cly32yIYjSjO2/nehVCyUVNMFbis
wbWsko57oy+/spIq+ZSjTiEhtU//MNrWz563TC/ug2dZxrAemup/q3QsfvSfBGEc
C+7RedeOxmFcFEpNtP67ILTnXe+/yM9z3q6K8Oif2h/qHz+eVwFPb8b1sIJC5/jT
tbuHQa4f8+fzh3q6UDiNAgEhGrWudBNVUdYwheMCkv7cf/+tmw1xCGbtY2BvQpfj
Qm/KNGb0lzh5WXlmlDvZRGh4GS1tKaQiIKerHkQaxqADwDGVvq8U+76t48AkqXTg
vBfdk8OKKTe8GIGTEaBeKKtc7w0wASA73pehQY8hN278uAOURV43FE8JQFmQRmJp
uWPbgdcPysq/YVxH79zbBH6w4AkVJ6yK5+gJy0XKCtw4W5tcyQmzA+FMIAmSRJa0
u83zJQO+ax8kCOviRlQSzBcxwpeoziUlCtaqhhsnNVliQYMYwba+NnNJ5HDI+Vch
f4oz/WhjgNIDXrOE5+VqecxDMbD/So8ekCn1nIBg2orN+Mz8+OTPdohyr7jhE9fW
04qucj9MQyH9b6vnjSt+yE+rHONlk9ZIHSYwpO0wkY42h21NKd08dQjLvsAiWXWZ
9oIQdJ5IRft4WyN5mdX6
=likc
-----END PGP SIGNATURE-----