Subject: [Acme] Proposal for http challenge: Lookup SRV records before A/AAAA records

From: Michael Wyraz <[email-masked]>
Date: Tue, 9 Feb 2016 22:37:03 +0100

Hi,

as discussed before, acme/http-01 is difficult to implement if the
domain being validated does not resolve to the IP address of the machine
where the client runs on.

Common cases are:
- multiple physical servers behind a tcp balancer (A-Record resolves to
the load balancer, not to the server where the acme client runs on).
- geo based dns resolution (A-Record resolves to the "nearest" server
which is not necessarily to the server where the acme client runs on)
- A-Record resolves to a device that is not able to run the acme client
(hardware firewall, router, load balancer)

I've created a proposal for using SRV (with fallback to A/AAAA) to solve
these issues: https://github.com/ietf-wg-acme/acme/pull/83

As you can see, the change only affects a small part of the server side
of the protocol and should have minimal impact to implementations.

Let me know what you think about it.

Kind regards,
Michael.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 10 Feb 2016 15:24:26 +0100

> these issues: https://github.com/ietf-wg-acme/acme/pull/83

This doesn't seem like a great idea. ACME should largely behave the same way
that Web clients do. If you want to muck with DNS just use the DNS
challenges.

-Ekr

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 10 Feb 2016 14:27:07 +0000

> This doesn't seem like a great idea. ACME should largely behave the same way
that Web clients do. If you want to muck with DNS just use the DNS challenges.

As an individual, not co-chair, I strongly agree with this.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 10 Feb 2016 14:35:12 +0000 (UTC)

Seems to me that we should specify a set of use cases, reduce them to requirements and then make sure we have at least one mechanism that covers each use case. 
It is not necessary for every use case to be covered by every mechanism. In fact that is the point of having multiple mechanisms.

Sent from Outlook Mobile