SERVFAIL looking up A for

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. |, so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: provided by Google Domains

I ran this command: sudo certbot certonly --standalone -d

It produced this output:
Certbot failed to authenticate some domains (authenticator: standalone). The Certificate Authority reported these problems:
Type: dns
Detail: DNS problem: SERVFAIL looking up A for - the domain's nameservers may be malfunctioning

My web server is (include version): Apache/2.4.41

The operating system my web server runs on is (include version): Ubuntu 20.04.3 LTS

My hosting provider, if applicable, is: N/A

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 1.22.0

When I check via DNSSEC Analyzer -, I have all green lights... not sure what's going on.

I think it's probably due to you using private IP addresses:

Let's Encrypt have their DNS resolvers set up to strip private addresses from responses, which in turns breaks the DNSSEC signatures. Since your domain has DNSSEC enabled, that's where the SERVFAIL is coming from.

You can't use private addresses for --standalone anyway. You will need to use a public IPv4/IPv6 address and port forward ports 80 and 443 to your server.


You can use the DNS-01 authentication method to obtain a cert - which won't need to reach your server.

Of course, when you do get a cert, it won't be reachable via anyone on the Internet (without a VPN into your private network).
So, you need to think this from that perspective...
Where are the clients?
How will the reach your service?


Doesn't that behavior produce a rather less useful error message than people would see otherwise? (if we consider the underlying problem to be the private addresses listed in DNS)

1 Like



This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.