During the issuance process I ran into an issue verifying control of one of my domains, turns out I had DNS configured wrong, it was pointing at an individual Application Server instead of the load-balancer. The site was operational so I hadn't caught that this site wasn't being distributed by the l…

Did you manage to resolve this issue? I am dealing with excactly the same bug. I started the veryfication procedure with misconfigurared dns Α record and it seems even though dns is now updated LetsEncrypt’s server is still using old dns data.

I was able to complete the registration at the other IP address as I still controlled it. Not sure if the incorrect value is still cached still, I’ll find out in January when I go to renew that cert.

Update. Domain verification completed. It seems that LetsEncrypt’s server caches dns data for 24 hours.

Depending on your TTL, that might mean that the total time will be even longer, as it is quite likely that the name server from which letsencrypt is getting its records had also cached it. I’m currently roughly 26 hours in, and will report back tomorrow to see what it did.

Where is the problem to actually obey the TTL? Why do you need to violate standards? Edit: This is the same symptom as when you tried to do SMTP by hand and messed up the whole DNS part of it. Just stick to what the Internet agreed on and don’t try to do your own thing. The Internet is smarter.

@TCM : The issue is that folks would have the wrong entry in their DNS, would fix it, and then would be stuck until the TTL expired.

It definitely makes sense for certain types of services to overwrite minimum and/or maximum TTL. The former provides a good mitigation against DNS rebind attacks, while the latter increases UX for services that rely on DNS for verification purposes. As long as you know why you’re doing it, there’s n…

This makes no sense. How does an additional TTL help here? You are actually increasing their problem by increasing their effective TTL. Edit: I misunderstood here that the TTL now has a maximum. You need to stop trying to accomodate every mistake someone makes in completely unrelated scopes. If som…

LE Using Chached DNS lookups during DV process

Issuance Tech

jsha December 21, 2015, 11:36pm 6

We’ve decreased the max TTL we use to a few minutes, so this should no longer be an issue.

DNS challenge is in staging

Topic		Replies	Views
TTL and DNS server used by Lets Encrypt Help	8	9823	June 27, 2018
Concurrent issuances with DNS-01 challenge Issuance Tech	13	432	April 10, 2025
DNS resolution problem during issuance for one domain Help	4	1079	September 2, 2018
Let's Encrypt DNS lookups Help	8	3704	November 8, 2019
DNS01 validation timeouts Client dev	2	1492	March 20, 2020

LE Using Chached DNS lookups during DV process

Related topics