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?
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?
Browse a faster, more private internet.
