Certbot: DNS SERVFAIL while the website still opens

Certbot fails with DNS problem: SERVFAIL, yet the website still opens in your browser. Different DNS paths can explain the apparent contradiction. In the documented incident, a CNAME led to a DDNS target with inconsistent authoritative responses. That observation concerns the reported configuration; it is not evidence that all DDNS services are unreliable. Q1

Understand which layer failed

SERVFAIL does not identify an Apache password issue or a damaged certificate key. It means the requested DNS lookup could not complete successfully. Meanwhile, your browser or local resolver may still have a usable cached address. Start with the exact name and record type mentioned in the failure, before changing the web server.

Five checks that produce useful evidence

1. Preserve the original error. Record the time, complete domain name, A or AAAA query and the Certbot invocation with private options removed. A working neighbouring subdomain is a comparison point, not proof that the failing name resolves correctly.
2. Map the alias chain. Use a DNS query tool and follow each CNAME to its destination. Record the first name that stops returning a usable answer. This separates a problem in your own zone from one in an upstream provider's zone.
3. Compare authoritative servers individually. Identify the responsible nameservers and ask each the same question. Missing or inconsistent answers are much more actionable for the DNS operator than a single screenshot saying that a website sometimes works.
4. Investigate validation separately. If additional diagnostics mention DNSSEC, have the operator check delegation and the signature chain. Do not disable DNSSEC merely because SERVFAIL appears. The code alone does not establish that cause.
5. Observe the correction before retrying. Allow for still-valid caches and compare independent resolution paths. Only after the answers are consistent will a fresh certificate test meaningfully assess the remaining challenge path. Certbot documents a dry-run option for renewal testing. Q2

Choose the appropriate repair

When the failure is at a DDNS destination, provide that operator with the affected nameservers, timestamps and queries. Replacing the alias with an address record is only sustainable if the address and its maintenance process support that choice. Hard-coding a changing address can create a second outage later.

Prepare the DNS outputs, alias chain, failure interval and recent DNS changes for handoff. There is no need to disclose a private key or account password for this initial investigation. After the DNS correction, check ordinary name resolution from outside your network as well as the certificate renewal path.

Frequently asked questions

Will switching Certbot from Apache to webroot fix it?

Not while the public DNS chain remains faulty. The challenge handler is a later stage.

Why does one public resolver still work?

It may have a cached answer or may have reached an authoritative server that happened to respond successfully.

Describe your case