I am trying to issue a cert for a domain that I have just moved on to a new server, unfortunately it seems the DNS has not propagated into Let’s Encrypt servers and so the request is failing.
I’ve searched the forum and I’ve read that Let’s Encrypt uses Google’s DNS servers (https://dns.google.com) and Google themselves allow you to flush their cache via this page (which I’ve done and is now showing the latest DNS records), however it seems Let’s Encrypt may not be using this after all as the request to issue a cert is still failing.
So my questions are:
Is there a web service that allows you to see what Let’s Encrypt sees when it looks up DNS records?
If not, is it possible this could be added please?
Perhaps add a way to flush DNS too?
It might stop others getting blocked for issuing too many failed requests
Let's encrypt query (directly) to the authoritive root server of your domain to look up records... There might be time that the DNS server need time to propergate.. (but I suspect that time is very very short, or your DNS provider is in trouble...)
Because I've just moved to a new server. Other domains on the server were moved too - and after a few hours I was able to get a cert for them - they had displayed the same error too.
What @stevenzhu said--LE directly queries the authoritative DNS servers for your domain(s). Whatever the problem is, it's therefore unlikely that it's DNS propagation.
It was the AAAA records. I remembered that for this particular domain I had set them differently to the other domains that were also moved to this server.
Sometimes, it takes a while for edits to a web panel become actually active in the authoritative DNS server. Not that uncommon that a hoster edits its zone file only a few times a day and processes all the edits in the web panels of the customers on those moments.
Unfortunately I did not read all of the thread/s (I was reading the posts that the forum was listing after searching for the issue).
It might be worth changing the accepted answer to this one, since your own post does not come across as definitive (or perhaps edit your post so that the answer is more certain?).
To the best of my knowledge, Let's Debug (my tool, which does use Unbound) is marginally more accurate than unboundtest for DNS resolution, because jsha (from what I can tell) has not updated unboundtest's Unbound parameters with a number of changes that Let's Encrypt has adopted over the last year.
In any case, there's a direct, completely accurate way to identify how Let's Encrypt's production environment resolves your domain, and that's just open up the authz URL (e.g. https://acme-v02.api.letsencrypt.org/acme/challenge/Z7njoye55PD8LonpLZyWVib6XFCQC-dukJEEoD10mSw/6516277258) from your ACME client's logs.
Correct, the rate limiting information is inaccurate due to backlog problems with the crt.sh. There is no other free to use public API (which rules out Censys and Google Certificate Transparency) so I'm waiting for crt.sh to resolve its scaling issue.