Ensure Container is available at Domain Name before proceeding to Let's Encrypt Checks

[claytondaley]

Your image is perfect for Amazon's Elastic Container Service (ECS) because it requires no local bindings/files. Unfortunately, it's hard to provision a static IP on ECS unless you use (and pay for) a load balancer.

I don't need/want to pay for a load balancer so I must manually update my DNS (+time to propagate) each time I deploy a new container. As a result, I'm running afoul of Let's Encrypt's rate limits, specifically a Failed Validation limit of 5 failures per account, per hostname, per hour.

Given that hard cap, I'd like to suggest adjusting the retry interval to something like minute 0, 1, 5, 15, (and every 15 minutes after that i.e. 30, 45, 60, 75). In theory, min 45 (and probably 60) will rate limit, but this provides a simple rule-of-thumb that is otherwise rate-friendly.

EDIT: Per the discussion in #23, the long-term goal is to simulate the acme check:

• Create a small file in a random (but known) location
• Ensure that the connection can be made and finds this file (possibly multiple times)

PR #23 (merged) is a first step in this direction, providing a simple check that a server (but not necessarily this one) responds with 200 to a call to the domain name. This issue has been left open to track potential improvements.

[claytondaley]

Come to think of it, even better if you could guard against the issue. Before starting the Let's Encrypt process:

1. Make sure the DNS name resolves to an A record
2. (configurable) Make a request against that domain to ensure it's reaching the right machine (the instance making the request). This would guard against old A records that are no longer valid.

The second check needs to be optional as it's theoretically possible that the container won't be able to initiate outbound connections.

[claytondaley]

• both checks need to be optional

If the server can't make an outbound connection, it might not be able to check a DNS name either. I think both of these are very rare -- I just try to anticipate the worst case.

[echohtp]

im having a similar issue! and hitting lets encrypt rate limits without wanting to

[claytondaley]

To further refine my suggestion, this thread says Lets Encrypt uses Google's DNS servers and this thread says they don't cache the requests.

• If possible you should run your DNS checks against the Google DNS (i.e. 8.8.8.8 or 2001:4860:4860::8888).
• You can Flush the Google DNS cache by completing the form here. Your debug/helper text for the DNS check phase could point users to this form to accelerate the change on Google's DNS.