Why AAAA Records Break HTTP-01 Validation

One of the most frustrating certificate failures is when a site looks fine over IPv4, the ACME client is configured correctly on the server you expect, and validation still fails.

The hidden cause is often an AAAA record.

If that IPv6 address is wrong, stale, or points at a different server than the ACME client, HTTP-01 validation can fail even though the IPv4 side looks healthy.

The key behavior to understand

Current Let’s Encrypt documentation states that when a domain publishes both A and AAAA records, it will prefer IPv6 for the initial validation connection.

That single detail explains a lot of mysterious validation failures.

If the IPv6 address is not serving the challenge correctly, the fact that IPv4 works does not save you.

Why this breaks people unexpectedly

Many domain owners do not realize an AAAA record is present.

Sometimes it was added automatically.

Sometimes it points to:

• an older host
• a different edge node
• a server that does not run the ACME client
• infrastructure that responds, but not with the right challenge

From the operator’s point of view, the domain "works" because the main web path over IPv4 looks correct.

From the CA’s point of view, validation is hitting IPv6 first and getting the wrong answer.

The important fallback detail

Let’s Encrypt does not simply treat IPv4 and IPv6 as interchangeable.

Its current IPv6 documentation says the IPv6-to-IPv4 retry happens only when the IPv6 connection fails at the network level, such as a timeout.

That means no retry if:

• the IPv6 host answers with the wrong content
• a web server is listening on IPv6 but does not know the ACME challenge
• redirect behavior causes a later request to prefer IPv6 again

This is why an incorrect but responsive IPv6 endpoint can be worse than a dead one.

A very common scenario

The ACME client is configured on the IPv4 web server.

But the domain also has an AAAA record pointing somewhere else.

Validation uses IPv6 first, reaches the wrong server, and fails before the correctly configured IPv4 host gets a real chance to answer.

That is not a certificate problem. It is a DNS and reachability problem.

Redirects make it worse

Current Let’s Encrypt documentation also notes an important edge case:

If the initial IPv6 request times out and falls back to IPv4, but the IPv4 server immediately redirects to HTTPS, the next request may prefer IPv6 again and fail without another fallback.

That produces a confusing symptom:

• the first step looked like it recovered
• the challenge still failed

So an HTTP-to-HTTPS redirect does not automatically make a broken AAAA record harmless.

The safest way to think about AAAA records

Do not publish an AAAA record unless the IPv6 path is genuinely ready for production.

That means:

• the host is correct
• the web server is reachable
• the challenge path behaves correctly
• the delivery path matches the IPv4 intent closely enough

If IPv6 is not actually part of the intended live service, the safer move is often to remove the AAAA record instead of leaving a half-working configuration in place.

Why this matters for domain lookup

A domain lookup is often the fastest way to notice that a hostname publishes both A and AAAA records.

That matters because the certificate failure might not be on the obvious server at all.

If the lookup shows an IPv6 address, that is part of the validation surface.

This is exactly the kind of issue that sits between pure DNS analysis and pure TLS troubleshooting.

What to check first

1. Check whether the domain publishes an AAAA record

Do not assume the domain is IPv4-only just because you never intended to serve IPv6.

2. Check whether the IPv6 host is the same service you expect

If the IPv6 address points to a different machine, edge node, or provider path, treat that as a likely validation blocker.

3. Check whether the IPv6 path serves the ACME challenge correctly

A live IPv6 web server is not enough. It must serve the correct challenge path and content.

4. Check redirects

If you redirect HTTP to HTTPS, remember that fallback behavior can still break later in the chain if IPv6 stays misconfigured.

5. Remove or fix the AAAA record if IPv6 is not truly ready

Let’s Encrypt is explicit that you cannot ask it to prefer IPv4 instead. The misconfiguration has to be fixed.

When this issue is most likely

You should suspect AAAA problems when:

• certificate issuance used to work and suddenly fails after DNS changes
• the domain has new IPv6 records
• the web stack changed but only the IPv4 path was updated
• the challenge seems correct on the main web server but the CA still reports failure

Common misunderstandings

"If IPv4 works, validation should still pass"

Not necessarily.

If the CA prefers IPv6 first and the IPv6 endpoint is wrong, IPv4 success is not enough.

"A broken IPv6 record is harmless because most users still use IPv4"

No.

Certificate validation systems and modern clients do not ignore IPv6 just because you were focused on IPv4.

"The fallback will save me"

Only sometimes.

The retry behavior is limited, and it does not cover every kind of failure.

FAQ

Why does an AAAA record break Let’s Encrypt validation?

Because Let’s Encrypt prefers IPv6 first for domain validation, and an incorrect or inconsistent IPv6 endpoint can fail before the correct IPv4 server is used effectively.

Will Let’s Encrypt just fall back to IPv4 automatically?

Only on certain network-level failures such as timeouts. If the IPv6 server responds incorrectly, the validation can still fail without a useful fallback.

Should I remove the AAAA record if I am not really using IPv6?

Usually yes. If the IPv6 path is not intentionally configured and validated, leaving it published can create avoidable certificate and reachability issues.

Can redirects make this worse?

Yes. Redirect chains can cause later validation requests to prefer the broken IPv6 path again even after an earlier fallback looked successful.