Stale TXT Records Blocking DNS-01 Validation
Issue with Stale TXT Records Blocking acme DNS-01 Validation
I'm seeing unexpected TXT records when querying _acme-challenge.example.com via 1.1.1.1 (Cloudflare’s resolver). These records are stale and not present in my zone file I see from my cloudlfare dashboard, yet they're returned in DNS responses and interfere with Let’s Encrypt’s DNS-01 challenge when using --challenge-alias.
Example query:
dig TXT _acme-challenge.example.com @1.1.1.1 +short
Returns:
"stale-record-1"
"stale-record-2"
But in my Cloudflare-managed zone, _acme-challenge.example.com is only configured as a CNAME to _acme-challenge.aliasdomain.com, and no TXT records exist.
These unexpected TXT responses break validation, as Let’s Encrypt sees incorrect values and never follows the CNAME as expected.
Could this be related to Cloudflare’s Universal SSL or internal automation? Are these records being injected as part of their certificate management process? If so, how can this behavior be suppressed or bypassed when managing ACME challenges externally?
This hasn't happened before and have been using cloudflare for a good 10+ years and my configuration hasn't changed either and has worked every 60 days for years. I have support ticket open but hadn't really thought about how Universal SSL works. From their June 12, 2025 outage write up, it doesn't seem like it can be explained by that. I have tried to use: https://one.one.one.one/purge-cache/ but these TXT records still exist after using that tool. What is even stranger is that it disappeared for one query and was right back a few seconds later. 8.8.8.8 mirrored that result and now it also has the stale entries. Amost like something is failing on the cloudflare side and it's in some sort of loop to insert.
Thoughts?
1.1.1.1 — One of the Internet’s Fastest, Privacy-First DNS Reso...
✌️✌️ Browse a faster, more private internet.
1 Reply
Update: Ticket still open after a week with no updates. What I am observing is that the first request to _acme-challenge.example.com will have a TTL of 300 for both stale RRs. At first, I thought the TTL of 300 was random but it is 100% reproducible and then you can query again and again and watch the TTL count down as expected. It is almost like they have a trigger on this TXT RR should it not exist which then populates the same 2 stale records for our zone. What purpose would the values of those 2 stale RR be the same after a week given how repeatable this is. DNS-01 would expect different values. Something definitely still broken after June 12.
Workaround and solution: If you have stale TXT records present LE will search and find the correct one for DNS-01 even if there are stale RR present so I dropped the --challenge-alias option with acme.sh and wrote the TXT record directly. Validation happened immediately. Even better is that those old stale TXT records are finally gone and without them, my CNAME value was being returned on lookup for the _acme-challenge TXT record so I added back the --challenge-alias option and that is also validating again as before.