Sign in Subscribe
Interests

The IPv6 Penalty: Why Your ACME Certificates Are Quietly Failing in 2026

Leon SCOTT

• 7 min read
Share
The IPv6 Penalty: Why Your ACME Certificates Are Quietly Failing in 2026
The IPv6 Penalty: Why Your ACME Certificates Are Quietly Failing in 2026

So damn frustrating. This post is generated from a session with Claude that took 4 hours. It took 4 hours because of a mistake by me, and the reason stated below. I was looking at the Zoraxy logs mainly looking for websocket misconfiguration. This ended up not being the major problem with my Zoraxy reverse proxy.

Why haven't the internet gurus done something about this. IPv6 solves a staggering amount of problems with UPNP, NAT and is now running the worlds internet as you will read below. I mean WTH mates.

Twenty years of warnings, thirty years of the protocol, and your TLS renewal still can't trust it.

The wall

It starts innocently enough. A certificate is due for renewal. Your ACME client fires a DNS-01 challenge, drops a _acme-challenge TXT record via the Cloudflare API, and waits for it to propagate before telling Let's Encrypt to go check. Query the authoritative nameserver over IPv4 and the record is there in seconds. Query the exact same nameserver, for the exact same record, over IPv6 — and it isn't. Not for a while. Sometimes long enough that the propagation timeout gives up first.

Widen the timeout, and it eventually resolves. Which is the annoying part: it isn't broken. It's just slow, on one protocol, for no documented reason, in a way that quietly eats your renewal window every single time.

The instinct is to assume it's a local misconfiguration — a broken resolver, a bad DNS record, something you did. So I went looking for anyone else who'd hit the same wall. What I found is more interesting, and more irritating, than a single misconfigured setup: this is a known, if under-discussed, seam running through the entire DNS-01/ACME ecosystem, and it's been sitting there in plain sight for two decades.

A quick primer, for anyone who hasn't had the pleasure

ACME (Automatic Certificate Management Environment) is the protocol behind Let's Encrypt and most modern free/automated TLS. The DNS-01 challenge type proves you control a domain by asking you to publish a specific TXT record, then having the certificate authority check for it before issuing. Because DNS is a distributed, cached, eventually-consistent system, every serious ACME client builds in a propagation check: create the record, then poll the domain's authoritative nameservers directly (bypassing caches) until the new value is confirmed present, before ever telling Let's Encrypt to look.

That propagation check is where this whole story lives. It assumes querying an authoritative nameserver gets you a fast, protocol-agnostic answer. For a lot of setups, over IPv6, that assumption just doesn't hold.

It isn't just one domain

The first thing worth establishing: this isn't a "my Cloudflare zone is cursed" problem. Three independent trails point at the same underlying weakness.

The ACME client software has an open, unresolved issue about exactly this. In the go-acme/lego project — the Go library behind a huge share of self-hosted ACME tooling, including reverse proxies like Zoraxy, Traefik, and Caddy — a user filed an issue after watching certificate issuance loop and expire. The cause: lego preferentially queries authoritative nameservers over IPv6 when it's available on the host, and if that authoritative server doesn't respond cleanly over IPv6, lego simply keeps looping until the challenge token times out, rather than falling back to IPv4. That report was against a completely different DNS provider (Gandi), which tells you the fragility lives in the client's assumptions about IPv6 reachability, not in any one provider's backend. (go-acme/lego #1801)

Cloudflare's own users have flagged the same category of gap. On Cloudflare's community forum, someone building an ACME automation hook pointed out that ns.cloudflare.com — the generic nameserver frontend some tooling uses to check for propagation — only serves A records, with no AAAA equivalent, and called it out specifically as a problem for checking ACME TXT records. Different failure shape (missing vs. slow), same theme: Cloudflare's IPv6 story for the "watch for a freshly-written record" use case isn't held to the same bar as IPv4. (Cloudflare Community)

And it's not a new phenomenon — it's a documented, twenty-year-old pattern. RFC 4074, published in 2005 and still the reference document on the subject, exists specifically because authoritative DNS servers have a long history of mishandling IPv6-related queries (AAAA lookups in particular) in ways that cause measurable resolution delay — a misbehavior the RFC's authors note generalizes beyond AAAA to other non-A record types, TXT records included. This isn't a Cloudflare bug. It's a category of authoritative-server behaviour the DNS community has been formally tracking since before Cloudflare existed. (RFC 4074)

Independent academic measurement backs this up in the present tense, not just historically. A 2020 study comparing public DNS resolver performance found Cloudflare's median response time running roughly 30–35% higher over IPv6 than IPv4, for both A and AAAA queries. Not a one-off anecdote — a consistent, measured asymmetry. (Revisiting Comparative Performance of DNS Resolvers, arXiv:2007.00651)

The irony of the timing

Here's what makes this genuinely maddening rather than just a mild inconvenience: this is happening now, at the exact moment IPv6 stopped being the minority protocol.

On 28 March 2026, Google's own traffic measurements recorded native IPv6 crossing 50% of all requests to its services for the first time in the eighteen years it's been tracking the number — a milestone covered by both the Internet Society and APNIC. In parts of the US, IPv6 traffic share is already sitting above that global average, and several major economies — France, Germany, India among them — cleared 70%+ years ago. IPv6 isn't an edge case anymore. It is, quite literally as of this year, the majority way the internet talks to itself.

And yet the tooling responsible for keeping that internet's TLS working — the ACME clients, and by extension the certificate authorities relying on their propagation checks — still treats IPv6 as the path you fall back from, not the path you can depend on. That's not a criticism of IPv6 the protocol. It's a criticism of two decades of infrastructure built with an implicit "IPv4 is the reliable one" assumption that nobody has gone back and re-examined now that the traffic split has flipped.

Why does this actually persist?

Nobody involved — not Cloudflare, not the lego maintainers, not the IETF — has published a clean "here's exactly why" for the specific propagation-lag pattern. So this next part is informed reasoning rather than a documented root cause, and it's worth being upfront about that distinction. A few threads seem to converge:

  • Anycast networks aren't identical twins. IPv4 and IPv6 anycast at the scale Cloudflare operates at don't necessarily share the same routing paths, BGP convergence behaviour, or point-of-presence sets. A record written to a backend can reach IPv4-facing edge nodes and IPv6-facing edge nodes on different timelines even when the write itself was simultaneous.
  • IPv6 is still the minority-traffic path at the edge, even post-milestone. Fifty percent globally still means a lot of infrastructure is disproportionately IPv4-tuned — caching layers, warm paths, engineering attention — because that's where the historical majority of load sat. Freshness guarantees tend to follow where the traffic (and the complaints) have been, not where they're going.
  • ACME client defaults compound the problem instead of hedging against it. The lego behaviour described above — prefer IPv6, and loop rather than fall back — is a reasonable design if you assume both protocols are equally reliable. That assumption is exactly what RFC 4074 said not to make, twenty years ago, and it seems the lesson didn't fully propagate (no pun intended) into ACME tooling built well after that RFC existed.
  • Nobody's incentivized to fix a problem that looks like "just raise your timeout." Every thread I found — Cloudflare's forum, the lego GitHub issues, adjacent complaints about other DNS providers like netcup — ends the same way: someone suggests padding the propagation timeout and forcing a specific resolver, the immediate pain goes away, and the underlying asymmetry never gets filed as a real bug because it's technically "solved" for that one person.

What to actually do about it

If you're running your own ACME automation against Cloudflare (or honestly, against most providers), the workaround is the same one everyone above eventually lands on:

  1. Pin the propagation check to a specific, known-good resolver rather than letting the client auto-select — 1.1.1.1:53 works well in practice — instead of trusting whatever the host's default IPv6-preferring resolution order hands you.
  2. Pad your propagation timeout generously. If your tooling supports it, somewhere in the 1000–1200 second range rather than the 60–120 second defaults most clients ship with, especially for wildcard or multi-domain certificates. Mine was more like 1500 seconds which is 25 bloody minutes - I mean really, for each certificate. A ACME cached certificate was instantaneous. Yeah I did some testing. My latency is 4ms to cloudflare on a 1000Mbps link, and I rarely get latency alerts, via my router, with a house full of gamers, although the link has been maxed out more than once in the last few months.
  3. Watch for clients that let IPv6 preference loop indefinitely rather than falling back to IPv4 on failure — if yours does, that's worth flagging upstream, because it's the exact failure mode described in the lego issue above.

None of that fixes the underlying asymmetry. It just insulates you from it, the same way everyone else currently is.

The actual question

IPv6 is thirty years old as a specification. It's now, as of this year, the majority protocol carrying the world's internet traffic. And a certificate-renewal check — arguably one of the most security-critical, "must not silently fail" pieces of internet plumbing there is — still can't fully trust it to behave consistently against one of the largest DNS operators on the planet.

That's not really an IPv6 problem. IPv6 works fine. It's a prioritization problem, sitting quietly at the intersection of DNS infrastructure that was built IPv4-first and never fully re-leveled, and ACME tooling that inherited assumptions from an internet that no longer exists. Twenty years after RFC 4074 told everyone this exact category of misbehavior existed, we're still building automation on top of it and calling the workaround a config tweak instead of a bug report.

If you've hit this — on Cloudflare, on any other provider, with any ACME client — I'd genuinely like to hear about it. The more of us who file it as a real issue instead of quietly padding a timeout value, the sooner someone with the ability to fix it might actually look.

Sources

So its not just me

#enoughsaid