Using old nameserver for DNS challenge

[ploni]

Summary
Requesting certs for apps.yfeldman.com and *.apps.yfeldman.com using Caddy and DNS challenge. Have recently changed namserver for apps.yfeldman.com from AWS Route 53 to deSEC. Certs were obtained successfully for apps.yfeldman.com but not the wildcard *.apps.yfeldman.com as LE is checking the old nameservers, although unboundtest.com etc all show the new ones.

Details
I own yfeldman.com which I am using with Fastmail for email. Fastmail manage DNS. I use the subdomains apps.yfeldman.com and various *.apps.yfeldman.com for self hosted apps. Fastmail allows customising their DNS settings and I have set up NS records there for apps.yfeldman.com to point to the nameservers of deSEC, a well known DNS host. (I couldn't use Fastmail for this as they don't have a API caddy can use.) Until today I used AWS route 53 instead of deSEC.

I set up Caddy with their deSEC plugin and configured it to obtain certs for apps.yfeldman.com and *.apps.yfeldman.com

It successfully obtained certs for yfeldman.com but it can't obtain the wildcard. Logs say:

Mar 27 17:50:58 vincentio caddy[2362805]: {"level":"error","ts":1711561858.7265172,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"*.apps.yfeldman.com","issuer":"acme-v02.api.letsencrypt.org-directory","error":"[*.apps.yfeldman.com] solving challenges: waiting for solver certmagic.solverWrapper to be ready: checking DNS propagation of \"_acme-challenge.apps.yfeldman.com\": NS ns-1977.awsdns-55.co.uk. returned REFUSED for _acme-challenge.apps.yfeldman.com. (order=https://acme-staging-v02.api.letsencrypt.org/acme/order/142204064/15558128904) (ca=https://acme-staging-v02.api.letsencrypt.org/directory)"}

The logs show LE is still checking AWS although it should have picked up the new nameservers as indicated by:

• The old NS had a short TTL which is many times passed since the change
• Checking unboundtest.com for apps.yfeldman.com and _acme-challenge.apps.yfeldman.com all show it picking up the correct NS
• The non wildcard cert worked, so LE must be able to see the new NS?!

I also note:

• This config has worked fine till now with AWS and I have made no changes other than the move to deSEC and telling Caddy to use deSEC instead of AWS for validation
• I have confirmed the challenge records are being created
• I chose DNS verification as the domain points to a non publicly routable IP

---

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. crt.sh | 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: apps.yfeldman.com

I ran this command: Caddy

It produced this output:

My web server is (include version): Caddy v2.7.6

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

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): Caddy

[Bruce5051]

Hello @ploni, welcome to the Let's Encrypt community.

Here is what I see for the DNS-01 TXT Records, are they what you expect them to be?

$ nslookup -q=txt _acme-challenge.apps.yfeldman.com ns1.desec.io
Server:         ns1.desec.io
Address:        45.54.76.1#53

_acme-challenge.apps.yfeldman.com       text = "0PNE6qGGEkUpfSQBdEXiWANo4dx3OURkdukSgfpeudo"
_acme-challenge.apps.yfeldman.com       text = "TY8E3ZPG0QC1qk2pc_FkFKSlWJDrKvNGbji_QTsMMj4"
_acme-challenge.apps.yfeldman.com       text = "9mivVs0FxX_1_VOckcDtlnEKMmNkZbpY6TVHoMF7Jic"
_acme-challenge.apps.yfeldman.com       text = "CrpjURFoWR9cJEGSNxPrkeDjmdh7JeiLFgT0HH8iPYM"

[Osiris]

I'm not sure if it's Let's Encrypt that's giving that error message. If I look at my own attempt using Certbot, there's no mentioning of the nameserver anywhere in the error message from Let's Encrypt the log.

My guess is the "checking DNS propagation" is a Caddy feature and for some reason your own server thinks it requires AWS as the DNS server. Maybe the "telling Caddy to use deSEC instead of AWS for validation" step hasn't "stuck" or something like that?

[ploni]

Indeed the problem was at my end. Checking dig showed my server was still fixated on the old NS and a quick sudo resolvectl flush-caches fixed everything. Thank you @Bruce5051 and @Osiris !!!