No valid AAAA records found for

I have a problem I cant update the cert of one of my domains ''
I tried to find some help via google/stackoverflow/forums, but cannot fix it.
All other certs work, just not this one.
I did some dry runs to find out in the logs what the problem might be.

Note the server has NO IPV6 at all, only IPV4
Also I can resolve the domain on another server quite happily, I know the DNS works

dig -t A
;           IN      A
;; ANSWER SECTION:    85567   IN      A

It looks like certbot seems to think there is an IPV6 available, but I know there is NOT:

dig -t AAAA
;           IN      AAAA
;; AUTHORITY SECTION:    2614    IN      SOA 2024032157 14400 1800 1209600 3600

In the apache httpd.conf AND ssl.conf files I turned OFF ipv6 with Listen and Listen respectively.

Certname (contains both the and com versions)

My domain is:

I ran this command (the cert contains the domain in question):
certbot renew --cert-name --dry-run

It produced this output (I cut the other lines):

Certbot failed to authenticate some domains (authenticator: apache). The Certificate Authority reported these problems:
  Type:   dns
  Detail: DNS problem: SERVFAIL looking up A for - the domain's nameservers may be malfunctioning; no valid AAAA records found for
  Type:   dns
  Detail: DNS problem: SERVFAIL looking up CAA for - the domain's nameservers may be malfunctioning
Hint: The Certificate Authority failed to verify the temporary Apache configuration changes made by Certbot. Ensure that the listed domains point to this Apache server and that it is accessible from the internet.

My web server is (include version):
Apache/2.4.37 (AlmaLinux)

The operating system my web server runs on is (include version):
AlmaLinux 8.9

My hosting provider, if applicable, is:
Digital Pacific

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

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

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

Let's Encrypt queries for both A (IPv4) and AAAA (IPv6) records, and uses IPv6 if such an address is found. The problem is that your DNS server is broken and is returning a failure when queried for an A record (which this error tells you). In combination with the lack of an AAAA record (which would be expected if, as you say, you aren't using IPv6), that means you can't get a certificate.

You need to fix or change your DNS server.


I also checked the domain with MXTOOLS.COM.
No error reported.

The nameservers return an A record and the A record is clearly defined in the DNS manager.

dig -t A

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.15 <<>> -t A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45917
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 1232
;           IN      A

;; ANSWER SECTION:    81938   IN      A

;; Query time: 1 msec
;; WHEN: Wed Jul 10 11:16:17 AEST 2024
;; MSG SIZE  rcvd: 64

Is it possible that you have IPV6 enabled somehow, but are not intentionally using it?
@danb35 is correct. DNS is broken here.


That is very interesting. The site queries DNS similar to how Let's Encrypt does it. Yet, unboundtest shows all record lookups are fine.

Note you must use a DNSSEC resolver as if that is present LE validates it. So sometimes that is a reason why some DNS query tools show success but LE fails.

We often use to evaluate DNS config. Yet again that shows everything is fine.

So, why would LE fail? This probably needs someone with more DNS expertise than I have.

Does this problem recur?

LE did make a recent change. Are you familiar with the DNS servers you use? Could this be affecting them somehow?


I think it's more like "letsencrypt" thinking my DNS is broken :laughing:

But yes I accept "something" is broken as I cant get the cert renewed.

Yet ALL DNS checkers I have employed tell me my DNS is good ...

I have launched a ticket to the registrar ...

1 Like

I have checked everwhere:

  • apache has "Listen"
  • there is NO IPV6 interface
  • told ALMA: net.ipv6.conf.all.disable_ipv6=1
    Even the firewall in front is IPv4.

The machine has multiple websites, that's is it's function, therefore not the ONLY cert I am getting from Letsencrypt, all other renewals before worked ...

Tomorrow, I’ll check our internal DNS logs to see if I can get any more information on what is happening here.


Thank you!

I first called my registrar - they have to escalate.
So I sent a ticket to my registrar after the phone call with details of my problem.


The exact error our DNS resolvers is returning is:

SERVFAIL < AAAA IN>: exceeded the maximum nameserver nxdomains

That indicates errors resolving the nameservers.


So there is actually something lingering with IPV6.
This is beyond my pay-grade, but I suspect router, servers configured to serve IPV6 (even though ISP might not provide it)
We are learning here!
But also I have not seen

exceeded the maximum nameserver nxdomains
Just gotta know.


That looks to be an active issue with unbound:


This gets stranger by the hour!

I also read lots of replies in other letsencrypt threads/topics about this problem, also google searches.

It seems the error is usually raised in the case when there are too many nameservers and/or too many do not return the correct information.

In my case there are JUST 3 NS servers and ALL of them return the correct info about the domain "" - I checked this using a different machine on an unrelated network.    14440   IN      NS    14440   IN      NS    14440   IN      NS
1 Like

Not sure this helps but I can reproduce that problem using

It does not fail every time. It took more than a few but less than 10 tries. I happened to be querying an AAAA record but not sure that matters. No query should get SERVFAIL anyway

Here is the URL for the unboundtest results

The SERVFAIL summary

And, below is the entire log of that failure in case the above URL results are discarded. The ending error message is the same as you report.
UnboundTest Log for AAAA salesessentials.txt (377.2 KB)

You say there are only 3 name servers involved but that is not true. Let's Encrypt walks the authoritive tree so all those above yours are queried too. And, the parent name servers for your name servers are getting queried (the digitalpacific tree).

This is all well above my skill level to diagnose. It just looked interesting. Hope this helps