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

[Jonas Wielicki <[e-mail]>]

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