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-----
- [Acme] Support for domains with redundant but not… Jonas Wielicki
- Re: [Acme] Support for domains with redundant but… Hugo Landau
- Re: [Acme] Support for domains with redundant but… Jonas Wielicki
- Re: [Acme] Support for domains with redundant but… Salz, Rich
- Re: [Acme] Support for domains with redundant but… Jacob Hoffman-Andrews
- Re: [Acme] Support for domains with redundant but… Martin Thomson
- Re: [Acme] Support for domains with redundant but… Peter Eckersley
- Re: [Acme] Support for domains with redundant but… Ryan Pendleton
- Re: [Acme] Support for domains with redundant but… Yoav Nir
- Re: [Acme] Support for domains with redundant but… Ted Hardie
- Re: [Acme] Support for domains with redundant but… Manger, James
- Re: [Acme] Support for domains with redundant but… Jonas Wielicki
- Re: [Acme] Support for domains with redundant but… Salz, Rich
- Re: [Acme] Support for domains with redundant but… Jonas Wielicki
- Re: [Acme] Support for domains with redundant but… Michael Wyraz
- Re: [Acme] Support for domains with redundant but… Jonas Wielicki
- Re: [Acme] Support for domains with redundant but… Michael Wyraz
- Re: [Acme] Support for domains with redundant but… Jonas Wielicki
- Re: [Acme] Support for domains with redundant but… Jacob Hoffman-Andrews
- Re: [Acme] Support for domains with redundant but… Jonas Wielicki
- Re: [Acme] Support for domains with redundant but… Michael Wyraz
- Re: [Acme] Support for domains with redundant but… Jacob Hoffman-Andrews
- Re: [Acme] Support for domains with redundant but… Jacob Hoffman-Andrews