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

Jonas Wielicki <jonas@wielicki.name> Tue, 09 February 2016 13:09 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 CAF4A1A8AAD for <acme@ietfa.amsl.com>; Tue, 9 Feb 2016 05:09:02 -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 Ef05SrHdmjWH for <acme@ietfa.amsl.com>; Tue, 9 Feb 2016 05:09:00 -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 905131A8AB6 for <acme@ietf.org>; Tue, 9 Feb 2016 05:08:16 -0800 (PST)
Received: from altair.sotecware.net (x4d0d56a3.dyn.telefonica.de [77.13.86.163]) by sol.sotecware.net (Postfix) with ESMTPSA id C9B782001A4 for <acme@ietf.org>; Tue, 9 Feb 2016 13:08:13 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wielicki.name; s=k001.sol; t=1455023293; bh=wtDyvDbTq10aHKxkkHvzO0QeQRXkDytbINPoekZXedc=; h=From:Subject:To:References:Date:In-Reply-To; b=h1XcgSFe5dMUEXkVSpZ85BhLkjf+BhJjnDvgLDtyTvX2zYZN+doRtEZB/UGgaPN32 nnlV8liTrgVvD0hGAQ8EpZCtOlG/wnMSLCbR68A+saojiOesos+jwjaZUB25jjknEf 0ZjygpF0uENrtFTxMY2AhdGLcOyuM+EKhLHhS1tDYInrUgpVu1Kx4wev1HA61W4O9O lN9P6fjFdEjjKivzOxMN4V/zY0SuoCdbwPDLSVXJHVTOtmUfitqm1I59xxpvMRr/wF 0qZm27aCuBJ0w2yPeVx6rRobwwhS/wS/xgTI4aJ4p9kdGuZYjjaE+WZKiN22Y+JvYt 0bpBlCT6JCrdw==
From: Jonas Wielicki <jonas@wielicki.name>
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>
Message-ID: <56B9E4BB.3090900@wielicki.name>
Date: Tue, 9 Feb 2016 14:08:11 +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: <56B9C501.6000106@wyraz.de>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/lqLIrAthg-nAoDTHWwNntZHEuIM>
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 13:09:03 -0000

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

Hello Michael,

(re-sent to include the list, sorry for the noise, Michael)

On 09.02.2016 11:52, Michael Wyraz wrote:
> thank you for the proposal. I think addressing such setups is a 
> good idea.

Thank you for your feedback!

> The solution you propose works only if dns round robin is used 
> (i.e. all the real server ips in A or AAAA). But there are similar 
> setups where the redundant servers are behind some load balancer 
> where a completely different ip is used. Another widely used 
> scenario is geo-based dns. In this case, the Acme server would
> only see his "nearest" ip address.

I agree.

> 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?

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

iQIcBAEBCgAGBQJWueS7AAoJEMBiAyWXYliK57UP/ROcqyPJmLjHPTmPc8bxJNX0
HHxGbGMiUDmiUwcubkflzhOpwIYD+Zl9MyL58bz78wdyw/sVWDxIVEWWM4C79jKB
0cUW3NzLYG2uWXHNy7BtqyFbYp2Z7MkixY+miXCxxvtleuo4m4G67ttCHrzumaT8
M9Fj94TqDfI+0M2IVtw/FUah4rdFgguJMEfgrcK41HFy+liLOYZzZXwG8XdOCjQm
v5H0K8dspHFzIrTnvwbALTbz3fW1z1dv+r3GPe3LcOpmSBC4G8Hz/rHDdKDQH/eE
8qIqYZxx54yT40nmee8cPWUjwxnnTCQaa3IwimDSs12V0LTfl98oQkAqIkoBdQST
1TNpMHE9v4KtR5lY8lLfiI74Gb+Cu/tf0V4rYeGi6uUgNVFSuVdumN71DhbN5MVP
XArfAtXEAsJ3Xm2sq/6ZWf01weufXIb/85tzrnkZC/tqVn6da22U30geuI+5hcxZ
v1UMZGQDx7NXYWKbIVqageYbBClbi8hRECr0Nl5nu4ejXaNkZ7dLkZZVnLzfXUWU
lKk8M2LdvcIo28kbXZxsio40nK2seB96GkW+aIGqVpyn1VjJaR5iktWUEBeIVUEi
AaeGgfZSxL9sig4ceCTawvvnSdIi2XZ4gJ2rY6ZxlO0AQ3ZATQyHZLx1aMF2OxGq
iSbK90o/cIiHHd0c3IKh
=IeGZ
-----END PGP SIGNATURE-----