Is there a Let's Encrypt DNS propagation check?


#1

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


#2

Hi @AstJ

as I know, Letsencrypt doesn’t use cached DNS data.

Use https://letsdebug.net/ (not my service).


#3

Thanks @JuergenAuer I checked that and it’s reporting everything All OK :slight_smile:

However, now I have to wait an hour :cry:

An unexpected error occurred:

There were too many requests of a given type :: Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/


#4

Hi,

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


#5

The rate limiting message has gone and on trying again it failed again - so it seems that site is not accurate…


#6

What makes you think your issue has anything to do with DNS?

This is most assuredly not the case.


#7

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 is the case then?


#8

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.


#9

Ok all sorted :slight_smile:

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.

Thanks all for your help :+1:


#10

Where did you read that?

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.


#11

On this forum…


#12

Reading just a little further down that thread would have seen the Certbot engineer saying that was incorrect.


#13

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?).


#14

there is a tool for doing DNS checks based on how the Let’s Encrypt servers do it

you can find it here: https://unboundtest.com/

Andrei


#15

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.

  "validationRecord": [
    {
      "url": "http://helloworld.letsencrypt.org/.well-known/acme-challenge/oNjzO_wE2ByFhbx4P09PwTXekjiuXc0UHfGlWxx-Bm0",
      "hostname": "helloworld.letsencrypt.org",
      "port": "80",
      "addressesResolved": [
        "52.9.173.94"
      ],
      "addressUsed": "52.9.173.94"
    },
    {
      "url": "https://helloworld.letsencrypt.org/.well-known/acme-challenge/oNjzO_wE2ByFhbx4P09PwTXekjiuXc0UHfGlWxx-Bm0",
      "hostname": "helloworld.letsencrypt.org",
      "port": "443",
      "addressesResolved": [
        "52.9.173.94"
      ],
      "addressUsed": "52.9.173.94"
    }
  ]

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.


#16

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.