Failure to retrieve TXT records with RFC2136 DNS challenge

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. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: paulo-sc.com

I ran this command: certbot renew

It produced this output:

certbot renew --cert-name octoworld.fr
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/octoworld.fr.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Renewing an existing certificate for octoworld.fr and 5 more
Waiting 60 seconds for DNS changes to propagate

Certbot failed to authenticate some domains (authenticator: dns-rfc2136). The Certificate Authority reported these problems:
  Identifier: paulo-sc.com
  Type:   dns
  Detail: During secondary validation: DNS problem: SERVFAIL looking up TXT for _acme-challenge.paulo-sc.com - the domain's nameservers may be malfunctioning

  Identifier: paulo-sc.com
  Type:   dns
  Detail: During secondary validation: DNS problem: SERVFAIL looking up TXT for _acme-challenge.paulo-sc.com - the domain's nameservers may be malfunctioning

Hint: The Certificate Authority failed to verify the DNS TXT records created by --dns-rfc2136. Ensure the above domains are hosted by this DNS provider, or try increasing --dns-rfc2136-propagation-seconds (currently 60 seconds).

Failed to renew certificate octoworld.fr with error: Some challenges have failed.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All renewals failed. The following certificates could not be renewed:
  /etc/letsencrypt/live/octoworld.fr/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

My web server is (include version): nginx 1.24.0

The operating system my web server runs on is (include version): Ubuntu Server 24.04

My hosting provider, if applicable, is: MilkyWAN

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 5.4.0

Hello all,

I've got a problem with my cert renewal. My setup is the following:

  • 3 PowerDNS servers
  • Datacenter or fibre optic access with IPv6 and IPv4 connectivity
  • MariaDB zone replication
  • Functional TSIG key
  • Functional DNSSEC on all zones
  • Functional GLUE records
  • Renewal with Certbot using systemd timers

This architecture, bar some minor changes and updates, has been working flawlessly for more than 8 years. All of a sudden, renewal for this zone won't succeed. I noticed that oddly enough, it only happens with .com domains:

  • .fr-only cert: OK
  • .fr containing .com names as auxiliary objects: NOK
  • .com-only cert: NOK

Because my hardware proved to be reliable enough, I've kept for a long time a propagation time of 15s. I increased it to 1 then 5 minutes, which made no difference. The credential file is known to be good and TXT records are indeed published during a renewal attempt:

paul@nevera:~$ dig TXT _acme-challenge.paulo-sc.com @ns1-auth.octoworld.fr  +short
"SqMKdUR6wl5nWEgzECU-z90dsEmOrHasEkJ0Ey0lumA"
"vIk4fBiNSsgEhLMw0--PUiMspd37CdFfaRbB0laYbkA"

paul@nevera:~$ dig TXT _acme-challenge.paulo-sc.com @ns2-auth.octoworld.fr +short
"SqMKdUR6wl5nWEgzECU-z90dsEmOrHasEkJ0Ey0lumA"
"vIk4fBiNSsgEhLMw0--PUiMspd37CdFfaRbB0laYbkA"

paul@nevera:~$ dig TXT _acme-challenge.paulo-sc.com @ns3-auth.octoworld.fr +short
"SqMKdUR6wl5nWEgzECU-z90dsEmOrHasEkJ0Ey0lumA"
"vIk4fBiNSsgEhLMw0--PUiMspd37CdFfaRbB0laYbkA"

On a Debian 13 machine with only a .fr cert, which also produced errors, I traced it back to an old version of Certbot (2.9.0), which was kept back by apt for some reason. I updated it to version 4. It solved the problem and seeing that led me to believe that the cause was the same on this server, combined with finding out that Certbot was even older (2.8.0). I removed it and installed the snap version, only to find out that it wasn't responsable for the failures either.

So, why would .com domains only fail and where could Let's Encrypt could play a role in this?

Thank you by advance

Your DNS servers seem to be GEO-location blocking

3 Likes

I did not set up any restriction on my authoritative servers, I want them to be as reachable as possible. I just learned today that PowerDNS can do geoblocking, I checked and the backend isn't installed on any instance.

You may need to wait for a better DNS expert but this looks like a problem to me.

The delegations for your name servers have this problem

octoworld.fr zone: The following NS name(s) did not resolve to address(es): ns2-auth.octoworld.fr2026-01-20nsdns.info, ns3-auth.octoworld.fr2026-01-20nsdns.info

As shown by: ns1-auth.octoworld.fr | DNSViz

It could have just been luck that the LE primary center worked and the above caused a failure at one of the (currently 4) secondary centers.

Not sure why other domains would work unless they used the glue records instead of having to query A/AAAA records for the name servers.

Given the names (fr2026-01-20) this looks like a recent change :slight_smile:

3 Likes

I'm aware of it and this is when I last updated the GLUE records. This is absolutely bizarre and I don't know why this is, but the odd thing is that they are related to the zone whose renewals work. So I didn't mention it, believing it wouldn't add much to the story. As opposed to my .com zone whose GLUE records are normal and renewal attempts fail:

paul@nevera:~$ dig NS paulo-sc.com @a.gtld-servers.net

; <<>> DiG 9.18.47 <<>> NS paulo-sc.com @a.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63966
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;paulo-sc.com.                  IN      NS

;; AUTHORITY SECTION:
paulo-sc.com.           172800  IN      NS      ns1-auth.octoworld.fr.
paulo-sc.com.           172800  IN      NS      ns2-auth.octoworld.fr.
paulo-sc.com.           172800  IN      NS      ns3-auth.octoworld.fr.

;; Query time: 14 msec
;; SERVER: 2001:503:a83e::2:30#53(a.gtld-servers.net) (UDP)
;; WHEN: Tue Mar 31 23:37:49 CEST 2026
;; MSG SIZE  rcvd: 122

With no sensible reason coming to my mind for my registrar to write bogus records in the parent zone, I just think that this is because they are absolute trash. Their panel is one of the buggiest in existence and issues countless error messages. Originally registered at Google Domains, my domains have been automatically transferred to Squarespace when they closed down their activity. I've wanted to switch registrars for a long time, because it didn't click from the beginning, but didn't because of letting it slide when problems stopped and out of pure procrastination. If mandatory, I'll take care of it.

The problem I pointed out was the query for the A/AAAA records for your name servers. Not the domain itself.

Let's Encrypt walks the authoritative DNS tree. Every path defined must provide a valid response. This is part of the anti-spoofing protection before granting a certificate. When trying to resolve the A/AAAA for your NS there are errors.

Frankly, I am not expert at the unbound DNS resolver that LE uses. So, I am not certain these are what are causing your problem. But, it seems problematic. Not only did the DNSViz site report a problem but also Let's Debug reports a SERVFAIL for your .com domain. Let's Debug is not identical to Let's Encrypt but also uses unbound and tries to mimic LE. See: Let's Debug

We also see "Secondary" in the error message in your first post. That means the Primary LE center passed but one or more of (currently 4) secondary centers failed. They may have walked a different path than the primary. Or, maybe that name server replies differently to requests from different global perspectives.

Note a dig trace for your name servers give an error for two of its NS. From below trace note these. I believe LE is failing when querying for and validating the A/AAAA records for your name servers because of these errors.

couldn't get address for 'ns3-auth.octoworld.fr2026-01-20nsdns.info': not found
couldn't get address for 'ns2-auth.octoworld.fr2026-01-20nsdns.info': not found

I am not sure what benefit these two NS records have anyway. Can you remove them to see if it resolves the problem? Or, more drastically, change the DNS provider for the .com domain at your registrar to try a different provider? You wouldn't have to change registrars.

Above errors from:

dig +trace A ns1-auth.octoworld.fr

; <<>> DiG 9.20.18-1~deb13u1-Debian <<>> +trace A ns1-auth.octoworld.fr
;; global options: +cmd
.                       86369   IN      NS      l.root-servers.net.
.                       86369   IN      NS      j.root-servers.net.
.                       86369   IN      NS      f.root-servers.net.
.                       86369   IN      NS      h.root-servers.net.
.                       86369   IN      NS      d.root-servers.net.
.                       86369   IN      NS      b.root-servers.net.
.                       86369   IN      NS      k.root-servers.net.
.                       86369   IN      NS      i.root-servers.net.
.                       86369   IN      NS      m.root-servers.net.
.                       86369   IN      NS      e.root-servers.net.
.                       86369   IN      NS      g.root-servers.net.
.                       86369   IN      NS      c.root-servers.net.
.                       86369   IN      NS      a.root-servers.net.
;; Received 239 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms

fr.                     172800  IN      NS      g.ext.nic.fr.
fr.                     172800  IN      NS      f.ext.nic.fr.
fr.                     172800  IN      NS      d.nic.fr.
fr.                     86400   IN      DS      65381 13 2 8163ABF45792942CF4EE38CCA31F6A6832FCDC6D402338FC68782769 0C4132F6
fr.                     86400   IN      RRSIG   DS 8 1 86400 20260413210000 20260331200000 21831 . EwK8dlTnEAnUpd9Aci3ROMINaJhMzNEP38vFnXcUhX+8+9fUeaTq5F9c TmTea3Ghcl/JKWvgFjXfOXcElgmHw8ovprWkXJRGir832wMDd6Dn2g1k MMlFGgK9ZasAks9E1M0XZO0ZhDieL34svTg2MJP4fTON0iEzmSbNqhG0 oRdZpsm6twz22ziKXZjcvtGNqRFx1KbFGjMWvF3UhWMn5MDYIWcBuhzp dJII9rFUUM405E9XDnMe7RiSCppujGXucSD11zzKMrqcxydAetldU5EK mWQGRRFeY0+qtskfkODCZq69wxLO5qo+KEXOhHc1e9c4tdwDhaQm8lY0 CPKsgA==
;; Received 611 bytes from 192.33.4.12#53(c.root-servers.net) in 3 ms

octoworld.fr.           3600    IN      NS      ns3-auth.octoworld.fr2026-01-20nsdns.info.
octoworld.fr.           3600    IN      NS      ns2-auth.octoworld.fr2026-01-20nsdns.info.
octoworld.fr.           3600    IN      NS      ns1-auth.octoworld.fr.
octoworld.fr.           3600    IN      DS      51952 16 4 5119F84B6CE42B63BE1E35DAE6C7E0AD13AC9EC4CEB71B3EB53B79E2 38502D51A923440F917942E71B004327E001821E
octoworld.fr.           3600    IN      DS      51952 16 2 026B83E79B5CB90E050751AA9287F43BB5833B393833D9E9D5C42AF5 255CD4CB
octoworld.fr.           3600    IN      RRSIG   DS 13 2 3600 20260427233340 20260329101202 64412 fr. veFmMrO00E8EcFHIHCW9MhHkbORIHFPmTT+1G7iMm5QsKW5mNNkPYcVi ZZLXCzQtKAApIaqJ8fJX8lgliRbrBg==

couldn't get address for 'ns3-auth.octoworld.fr2026-01-20nsdns.info': not found
couldn't get address for 'ns2-auth.octoworld.fr2026-01-20nsdns.info': not found

;; Received 424 bytes from 2001:678:c::1#53(d.nic.fr) in 107 ms

ns1-auth.octoworld.fr.  3600    IN      RRSIG   A 16 3 3600 20260409000000 20260319000000 51952 octoworld.fr. 01PctVYHUro4x8WbGmm0bfa7TGBEihjWFP0+DQ+Sa/gdveOjkgVZLdw6 sYbwnGMu445xIMefzcWAK2Z9zR4ja6DAoIPr4XicnKKo256hajmTobTW Crsq3m4dnAbolXOTqoAy/lue+CfP9c8gT0eDBz4A
ns1-auth.octoworld.fr.  3600    IN      A       45.13.104.83
;; Received 224 bytes from 2a0e:e701:114f::2#53(ns1-auth.octoworld.fr) in 75 ms
3 Likes

No, I can't remove these 026-01-20nsdns.info: my registrar generates that from the valid names I entered in the GLUE records! I'd of course never do that on my own. I can by no means figure out why they insert this portion in the middle of the FQDNs.

Again, it only affects the zone that does work and I just realized that I made a mistake by showing the wrong potentially misleading example in the original post, because this .fr cert contains my .com as a SAN. Despite this oddity, renewals for octoworld.fr work. The main cert for paulo-sc.com or any cert including it is the one where they don't.

Maybe fr requires that the NS records have valid glue A or AAAA records (IP address records for the nameserver).

I don't know what interface you have however you could try adding the IP address of the nameservers first then adding the NS records for them.

Edit: The fact that fr2026-01-20nsdns.info doesn't exist and your registrar is adding NS records pointing to this domain would indicate a bug in your registrar, maybe you should contact them.

2 Likes

The diagnosis from the thread is correct, those malformed nameserver records in the parent zone are what's killing the secondary validation. Let me add a bit more on how to confirm exactly what's happening and what to push the registrar on.

The dig queries showing the TXT records exist on your PowerDNS servers are checking your own authoritative servers directly. What matters for LE's validators is what the .com TLD zone tells them when walking the tree. Run this to check what Verisign's registry actually has for paulo-sc.com:

dig NS paulo-sc.com @a.gtld-servers.net

If that returns ns2-auth.octoworld.fr2026-01-20nsdns.info in the answer section, that's definitive confirmation that the corruption is in the registry data itself, not just in your registrar's panel display.

When you contact the registrar, the specific thing to ask them to fix is the EPP object they submitted to Verisign. The malformed string looks like their system concatenated your NS hostname (ns2-auth.octoworld.fr) with a date-formatted internal field (2026-01-20) and another suffix (nsdns.info) when writing the nameserver delegation to the .com registry. This is a data submission bug on their end, not a GLUE record issue on yours.

On why .fr works but .com doesn't: .fr is managed by AFNIC which has different registry procedures. If your registrar's bug only affects the EPP submission path they use for .com (Verisign), .fr domains would be unaffected. That's consistent with what you're seeing.

The resolution path is to get the registrar to delete and correctly resubmit the NS delegation for paulo-sc.com to Verisign. Specifically ask them to confirm the NS hostnames they submitted match exactly what you entered, with no additional characters.

2 Likes

Alright, thank you for the required deep diving into the specs. I've contacted Squarespace, making sure that I mentioned the EPP object.

I hope they'll get back to me soon because I've been running in this error message for a month just trying to check the IP addresses in my GLUE records. I bet the bug has been here for God knows how longer and I've still not got any reply to my e-mail from 2 weeks ago.

If your registrar isn't working, I'd suggest exercising your right as a domain name holder to switch registrars.

I know switching away from squarespace might be difficult as they're also hosting your webpages but it might be quicker and more effective to switch registrars than to wait for squarespace to fix their bug.

1 Like

I was very skeptical about this being the solution, but I came home to renewed certificates!

The following certificates are not due for renewal yet:
  /etc/letsencrypt/live/octoworld.fr/fullchain.pem expires on 2026-07-08 (skipped)
  /etc/letsencrypt/live/paulo-sc.com/fullchain.pem expires on 2026-07-08 (skipped)
  /etc/letsencrypt/live/paulo-sc.fr/fullchain.pem expires on 2026-05-18 (skipped)
No renewals were attempted.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The support kept telling me that because they didn’t manage the zone, I had to check with the MSP who does… (which is me) although this is not where root servers read the records and where the problem lies.

I had to fight them a bit but it worked. Here is their answer:

I synced your domain with our domain registration partner, Key Systems, and this loaded the wrong name servers for your domain into Squarespace. After that, I was able to update the name servers for you; they are now correct. You can view them here.

I did some research and found that:

"When a domain expires, some registrars or parking services automatically tag existing name server records with the expiration date and a tracking domain (in this case, _nsdns.info_)."

I just want to confirm that the name servers were not changed in Squarespace; this change likely occurred on the Key Systems side. I’ll make a note of this so it can be reviewed with our team.

I checked during the day and I saw that the nsdns.info part is gone from the root servers. It probably allowed for the systemd timers to run successfully afterwards.

So, it looks like they use a partner for NS records broadcasting to the root servers. I also came across an occasional issue during my research, affecting domains that use NS addresses outside of themselves (an “out-of-Bailiwick” thing…), which, if applicable when the records are bogus, could have been a possible cause.

3 Likes