Jacob, thank you for your feedback. The http-01 challenge/response already relies on static DNS (A-Record). Nevertheless http is used for challenge. So using a (static) DNS record other than A-record won't change anything to the http challenge itself. The role of DNS is still the same (a directory).
The DNS challenge is completely different. It relies on dynamic DNS updates during challenge which brings a lot of extra complexity. The reason why DNS round robin or geo-based DNS is an issue with ACME is that http challenge assumes that the A-record resolves to exactly one static IP address and the device at this address is able to solve the challenge (or at least to provide the solution of the challenge at the well-known URI). IMO there are lot of situations where this assumption is wrong. But there's a simple fix (decouple the challenge from A-record) without the need for a completely different challenge type (like DNS challenge). The big advantage of http challenge is that it is simple to implement and generally available. Regards, Michael. > On 12/11/2015 12:50 PM, Michael Wyraz wrote: >> I'm new to this mailing list. Today I started a discussion on IRC about >> the fact that ACME with http-01 won't work if the A record points to an >> intranet IP address > In general, publicly trusted CAs are supposed to verify that a name is > available on the public Internet. > >> or is resolved dynamically dependent on geo locations or similar. > This is a potential issue, and is similar to recently discussed issue > about choosing from multiple available IPs, but is a harder problem to > solve. If you push a challenge to just one geo region, a validation > attempt from a different geo region may not see any relevant IPs. > >> The idea to solve these issues is simple: why not using some special dns >> record to resolve an URL that is responsible for ACME-challenges for a >> certian domain? This is more flexible than building the URL based on >> A-Record on a fixed scheme. > If you're willing to accept a dependency on DNS, it makes sense to just > use the DNS challenge instead. I think that's probably the ideal > solution for services that have many frontends and do geo load balancing. > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
