New nameserver not used for DNS01 chnallenge

Help
1

We deployed new two additional nameservers for the domain dyndns.loxonecloud.com as we are decommissioning our old ones:

dig NS dyndns.loxonecloud.com

; <<>> DiG 9.11.3-1ubuntu1-Ubuntu <<>> NS dyndns.loxonecloud.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47195
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;dyndns.loxonecloud.com.                IN      NS

;; ANSWER SECTION:
dyndns.loxonecloud.com. 3600    IN      NS      ns1.remcov3.loxonecloud.com.
dyndns.loxonecloud.com. 3600    IN      NS      ns2.remcov3.loxonecloud.com.
new servers ^^^^^^^
dyndns.loxonecloud.com. 3600    IN      NS      dns2.loxonecloud.com.
dyndns.loxonecloud.com. 3600    IN      NS      dns3.loxonecloud.com.
old servers ^^^^^^^^

All of the server return the same CAA value:

~ # dig +short CAA dyndns.loxonecloud.com @dns2.loxonecloud.com
0 issuewild "letsencrypt.org"
~ # dig +short CAA dyndns.loxonecloud.com @dns3.loxonecloud.com
0 issuewild "letsencrypt.org"
~ # dig +short CAA dyndns.loxonecloud.com @ns1.remcov3.loxonecloud.com
0 issuewild "letsencrypt.org"
~ # dig +short CAA dyndns.loxonecloud.com @ns2.remcov3.loxonecloud.com
0 issuewild "letsencrypt.org"

All of them return proper NS records for the zone (one old, one new as example):

~ # dig +short NS dyndns.loxonecloud.com @ns2.remcov3.loxonecloud.com
ns1.remcov3.loxonecloud.com.
ns2.remcov3.loxonecloud.com.
dns2.loxonecloud.com.
dns3.loxonecloud.com.
~ # dig +short NS dyndns.loxonecloud.com @dns2.loxonecloud.com
dns3.loxonecloud.com.
dns2.loxonecloud.com.
ns1.remcov3.loxonecloud.com.
ns2.remcov3.loxonecloud.com.

We do log all requests on the servers, and this brought up the issue that Let's Encrypt is ONLY using the old dns2.loxonecloud.com & dns3.loxonecloud.com servers to perform the DNS01 Challenge. Not a single _acme-challenge... TXT request on the new servers.

An test TXT request to one to the new servers looks like that (strange casing comes form log entries of the raw queries):

 ~ # dig TXT  _acmE-cHAllENgE.504F94******.dYNDNs.LOxONeclOuD.COm @ns1.remcov3.loxonecloud.com

; <<>> DiG 9.11.3-1ubuntu1-Ubuntu <<>> TXT _acmE-cHAllENgE.504F94******.dYNDNs.LOxONeclOuD.COm @ns1.remcov3.loxonecloud.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11595
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: db0bbfaf47fcebda (echoed)
;; QUESTION SECTION:
;_acmE-cHAllENgE.504F94******.dYNDNs.LOxONeclOuD.COm. IN        TXT

;; ANSWER SECTION:
_acmE-cHAllENgE.504F94******.dYNDNs.LOxONeclOuD.COm. 600 IN TXT "3IeHCS************************************eNbpa0I"

;; Query time: 14 msec
;; SERVER: 91.99.238.249#53(91.99.238.249)
;; WHEN: Mon Aug 18 23:04:43 CEST 2025
;; MSG SIZE  rcvd: 199

Note: Does not work on old ([dns3|dns3].loxoncloud.com) as the storage with the challenges is different and cleared after certificates are issued there. That we explicitly disabled for the new implementation for testing the challenges.

The request is also immediately visible in the servers logs - so missing logging is as well not cause...

ns1.remcov3.loxoncloud.com is now several days (since Aug 14th) listed in the NS record - at least this mus have made it through all caching layers.

What am I missing in my setup? Already spend lot of time debugging and I'm clueless what I do wrong missing. Are there any tools avaIilable can use to perform my requests EXACTELY as LE does them for validation?

Thanks in advance for any hint & kind regards
Christian

2

https://unboundtest.com is a public tool that closely mirrors what LetsEncrypt is configured with

This what it's seeing for A records:

https://unboundtest.com/m/A/dyndns.loxonecloud.com/2PCXOEFD

4 Likes
3

Thanks a lot for quick reply and hit to unboundtest.com. I did a few test there and never returnd the value -> not using my new servers.

We are not issuing certificates for the dyndns.loxonecloud.com domain directly but for subdomains like *.dyndns.loxonecloud.com like in the example queries I added.

That is also the reason why we return the CAA 0 issuewild "letsencrypt.org" and not "issue"

Doing a dig TXT _acme... without @ for specific from time to time hits the new servers and returns the values (then i also see the logs for those requests)
So it looks like something in our config seems to prevent LE from using our new servers.

regards,
chris

4

Let's Encrypt walks the authoritative DNS tree. It is not affected by TTL propagation. Any error in the delegation can cause problems.

In your case there is a problem with the glue records at Route53. See:

From: dyndns.loxonecloud.com | DNSViz

We have seen that sometimes the glue records at Route53 get out of sync. Not sure if this happens spontaneously for some odd reason or whether some other error occurred. In any case, you can check below for help with that

Once you get the glue records fixed retry the DNSViz test and see if that eliminates some or all of the invalid response errors. Fixing the glue records might be sufficient to avoid the errors you get from LE

3 Likes
5

thanks a lot for the hint will have a look at that and let you know

chris

2 Likes
6

Thanks a lot for you help - pointed me in right direction and I found the reason and a workaround for my issue:

Problem was that we have nested wildcard domains - *.loxoneclud.com and *.remcov3.loxonecloud.com.
dig correctly resolves ns1.remcov3.loxonceloud.com from the remcov3.loxonecloud.com zone

dig ns1.remcov3.loxonecloud.com

; <<>> DiG 9.20.10 <<>> ns1.remcov3.loxonecloud.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22775
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;ns1.remcov3.loxonecloud.com.   IN      A

;; ANSWER SECTION:
ns1.remcov3.loxonecloud.com. 84359 IN   A       91.99.238.249

wheraas LE somow resolves the *.loxonclud.com A Records.

;; AUTHORITY SECTION:
dyndns.loxonecloud.com.	0	IN	NS	ns1.remcov3.loxonecloud.com.
dyndns.loxonecloud.com.	0	IN	NS	ns2.remcov3.loxonecloud.com.
dyndns.loxonecloud.com.	0	IN	NS	dns2.loxonecloud.com.
dyndns.loxonecloud.com.	0	IN	NS	dns3.loxonecloud.com.
dyndns.loxonecloud.com.	0	IN	NSEC	dyndns\000.loxonecloud.com. NS RRSIG NSEC
dyndns.loxonecloud.com.	0	IN	RRSIG	NSEC 13 3 86400 20250820081234 20250819061234 46353 loxonecloud.com. iiWCC6IU/nwyQrIaNMHncyoRD0IsML1GEcvNtlRFpYDlvle9O4Y3+LqiPgcZqa7jXESMmhLkNxmFvOTEDoDzMg== ;{id = 46353}

;; ADDITIONAL SECTION:
dns2.loxonecloud.com.	0	IN	A	159.69.36.128
dns3.loxonecloud.com.	0	IN	A	78.47.141.0
ns1.remcov3.loxonecloud.com.	0	IN	A	159.69.36.131 
ns1.remcov3.loxonecloud.com.	0	IN	A	188.34.183.236
ns2.remcov3.loxonecloud.com.	0	IN	A	188.34.183.236
ns2.remcov3.loxonecloud.com.	0	IN	A	159.69.36.131
^^^^^^ those are actiually *.loxoncloud.com

As workaround I placed my A records directly in the loxoncloud.com zone ([ns1,ns2].loxoncloud.com) and in started to work right away.

Of course I'd be thankfull for any hint what was actually wrong with the setup of the ns1.remcov3.loxoncloud.com records...

kind regards & thx for the support
Chris

7

Start by fixing your glue records (as noted earlier). This is still a problem

com to loxonecloud.com: Authoritative AAAA records exist for ns-502.awsdns-62.com, but there are no corresponding AAAA glue records. See RFC 1034, Sec. 4.2.2.

As reported here: remcov3.loxonecloud.com | DNSViz

Missing glue records at Route53 is rare. Something unusual has gone wrong there. Contact whoever is responsible for setting that up.

3 Likes
8

The title of this thread says "DNS Challenge". LE does not lookup A records to satisfy a DNS Challenge.

3 Likes
9

Hi,

I thought so too - the reason why I brought this up is that the unboundtest.com (https://unboundtest.com/m/TXT/_acmE-cHAllENgE.504F94*****.dYNDNs.LOxONeclOuD.COm/OWQMY7CJ) debug output showed the wrong IPs for the servers:

;; AUTHORITY SECTION:
dyndns.loxonecloud.com.	0	IN	NS	ns1.remcov3.loxonecloud.com.
[...]

;; ADDITIONAL SECTION:
ns1.remcov3.loxonecloud.com.	0	IN	A	159.69.36.131 
ns1.remcov3.loxonecloud.com.	0	IN	A	188.34.183.236
ns2.remcov3.loxonecloud.com.	0	IN	A	188.34.183.236
ns2.remcov3.loxonecloud.com.	0	IN	A	159.69.36.131

These IPs for ns1.remcov3.loxonecloud.com are actually those from *.loxoncloud.com (dig asdf.loxonecloud.com)

dig asdf.loxonecloud.com

; <<>> DiG 9.20.10 <<>> asdf.loxonecloud.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42456
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;asdf.loxonecloud.com.          IN      A

;; ANSWER SECTION:
asdf.loxonecloud.com.   600     IN      A       159.69.36.131
asdf.loxonecloud.com.   600     IN      A       188.34.183.236

vs

dig ns1.remcov3.loxonecloud.com

; <<>> DiG 9.20.10 <<>> ns1.remcov3.loxonecloud.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11583
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;ns1.remcov3.loxonecloud.com.   IN      A

;; ANSWER SECTION:
ns1.remcov3.loxonecloud.com. 86400 IN   A       91.99.238.249

So again, thanks a lot for the help :slight_smile: - I will do further investigation to get this fixed.

kind regards
Chris

10

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