DNS-01 validation fails

Help
1

Greetings community! I have been using LE for many years and now need to auto-manage wild card certs. I am using the example from node-acme-client/examples/dns-01/dns-01.js at master · publishlab/node-acme-client · GitHub and have been testing using the LE staging server.

My DNS server is porkpun.com and am using the latest version of the above mentioned NPM package

I disabled the partition of the code that removes the TXT records in order to get assistance with this issue.

The challengeCreateFn function checks the google DNS API for the record and waits an additional 10 minutes to return.

The domain in question is *.testdns.holycore.quest . It seems to add the records as requested but seems to fail when LE checks the validation with the error

No TXT records found for name: _acme-challenge.testdns.holycore.quest

clearly, there are records https://unboundtest.com/m/TXT/_acme-challenge.testdns.holycore.quest/EK2UIGVE

Here is some other relevant information

csr domains [ 'testdns.holycore.quest', '*.testdns.holycore.quest' ]
start TXT record key=_acme-challenge.testdns.holycore.quest value=kj5PpetGb7rVLUeYjd7-zB2yxEZksr4XlyZZH41xNS4 googleDNS=https://dns.google/resolve?name=_acme-challenge.testdns.holycore.quest&type=TXT
start TXT record key=_acme-challenge.testdns.holycore.quest value=0c2JpFAbFghFf8PobGcJixCNFz2KDkKaZb7aCcprCuo googleDNS=https://dns.google/resolve?name=_acme-challenge.testdns.holycore.quest&type=TXT
1 Like
2

Hello @wmantly, welcome to the Let's Encrypt community. :slightly_smiling_face:

For the DNS-01 challenge here is what the online tool https://unboundtest.com/ shows
https://unboundtest.com/m/TXT/_acme-challenge.testdns.holycore.quest/6CXYYIEI

This is truncated

Query results for TXT _acme-challenge.testdns.holycore.quest

Response:
;; opcode: QUERY, status: NOERROR, id: 20210
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version 0; flags: do; udp: 1232

;; QUESTION SECTION:
;_acme-challenge.testdns.holycore.quest.	IN	 TXT

;; ANSWER SECTION:
_acme-challenge.testdns.holycore.quest.	0	IN	TXT	"0c2JpFAbFghFf8PobGcJixCNFz2KDkKaZb7aCcprCuo"
_acme-challenge.testdns.holycore.quest.	0	IN	TXT	"kj5PpetGb7rVLUeYjd7-zB2yxEZksr4XlyZZH41xNS4"

----- Unbound logs -----
Aug 06 15:52:47 unbound[2341:0] debug: creating udp6 socket ::1 1053
Aug 06 15:52:47 unbound[2341:0] debug: creating tcp6 socket ::1 1053
Aug 06 15:52:47 unbound[2341:0] debug: creating udp4 socket 127.0.0.1 1053
Aug 06 15:52:47 unbound[2341:0] debug: creating tcp4 socket 127.0.0.1 1053
2 Likes
3

Have you tried waiting longer?

I agree the TXT records are there now. And, I believe you when you say a google query found them. But, Let's Encrypt will check from multiple points around the world. For that to work the porkbun DNS servers must sync the data between themselves.

Usually this only takes a few seconds or minutes. But, some DNS systems take much longer.

Can you show the output of the failing command? Perhaps from the log. The full and exact message is helpful

5 Likes
4

Well, thank you! After reviewing the log I have the found the issue. The local ACME client attempts to verify the DNS records before sending the verification request to the LE server. Since I am doing my development and testing on a Vagrant provisioned VM, something along the line nerfs the DNS resolver and that local step to verify failed could not happen. I had no clue that the local client would attempt to verify before asking the remote LE server to do so.

The resolution to this issue: Make sure your local system can verify the records.

5 Likes
5

Yep. This is common with "industrial" clients like cert-manager.

4 Likes
6

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