Can’t obtain lets encrypt certs with duckdns using docker compose caddy (unexpected response code 'SERVFAIL')

I am trying to follow this guide and this guide in order to have a private vaultwarden instance that is only accessible from within my internal LAN, but I want to utilise HTTPS from lets encrypt. I chose these guides as apparently it’s better to use a DNS challenge for this setup.

I am running the following on a raspberry pi 4 on the latest kernel version. My router is a pfsense box that uses encrypted TLS quad9 as the DNS resolver. It also uses pfblocker but nothing comes up in the pfblocker logs when I try to obtain certs from lets encrypt using caddy. As far as I’m aware no outbound traffic is being blocked in pfsense.

Here is my directory and the necessary files:

The caddy binary was obtained from this link where I selected Linux arm64 and chose the duckdns download. I then renamed it to caddy.

I also ran the file command on the caddy binary and it gives the following output:

caddy: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, Go BuildID=d2CUgHd5v5KarbWhll50/spUmDDdeK-sOxRIzlMTs/ODBKUlz7E8KeiCtYfzIm/dhB6KAm-bEo07d_o6xDW, stripped

The Caddyfile contains the following:

{$DOMAIN} {
  log {
    level INFO
    output file {$LOG_FILE} {
      roll_size 10MB
      roll_keep 10
    }
  }

  # Use the ACME DNS-01 challenge to get a cert for the configured domain.
  tls {
    dns duckdns {$DUCKDNS_TOKEN}
  }

  # This setting may have compatibility issues with some browsers
  # (e.g., attachment downloading on Firefox). Try disabling this
  # if you encounter issues.
  encode zstd gzip

  # Proxy everything to Rocket
  reverse_proxy vaultwarden:80
}

The docker compose file contains the following:

services:
   vaultwarden:
       image: vaultwarden/server:latest
       container_name: vaultwarden
       restart: always
       environment:
         DOMAIN: "https://test111.duckdns.org"  
         SIGNUPS_ALLOWED: "true"
       volumes:
         - ./vw-data:/data # the path before the : can be changed
       #ports:
         #- 8888:80 
     caddy:
       image: caddy:2
       container_name: caddy
       restart: always
       ports:
         - 80:80
         - 443:443
         - 443:443/udp # Needed for HTTP/3.
       volumes:
         - ./caddy:/usr/bin/caddy
         - ./Caddyfile:/etc/caddy/Caddyfile:ro
         - ./caddy-config:/config
         - ./caddy-data:/data
       environment:
         DOMAIN: "test111.duckdns.org"  
         #EMAIL: "admin@example.com" 
         DUCKDNS_TOKEN: "<duck dns token>" 
         LOG_FILE: "/data/access.log"

I pulled the docker images and ran the containers. I then looked at the caddy docker logs:

sudo docker logs -f caddy
{"level":"info","ts":1727605355.2926478,"msg":"using config from file","file":"/etc/caddy/Caddyfile"}
{"level":"info","ts":1727605355.2972434,"msg":"adapted config to JSON","adapter":"caddyfile"}
{"level":"warn","ts":1727605355.2973034,"msg":"Caddyfile input is not formatted; run 'caddy fmt --overwrite' to fix inconsistencies","adapter":"caddyfile","file":"/etc/caddy/Caddyfile","line":2}
{"level":"info","ts":1727605355.3003426,"logger":"admin","msg":"admin endpoint started","address":"localhost:2019","enforce_origin":false,"origins":["//[::1]:2019","//127.0.0.1:2019","//localhost:2019"]}
{"level":"info","ts":1727605355.3008456,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0x40005f9180"}
{"level":"info","ts":1727605355.3009179,"logger":"http.auto_https","msg":"server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS","server_name":"srv0","https_port":443}
{"level":"info","ts":1727605355.3009539,"logger":"http.auto_https","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
{"level":"info","ts":1727605355.3018198,"logger":"http","msg":"enabling HTTP/3 listener","addr":":443"}
{"level":"info","ts":1727605355.3020425,"msg":"failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 7168 kiB, got: 416 kiB). See https://github.com/quic-go/quic-go/wiki/UDP-Buffer-Sizes for details."}
{"level":"info","ts":1727605355.3028066,"logger":"http.log","msg":"server running","name":"srv0","protocols":["h1","h2","h3"]}
{"level":"info","ts":1727605355.30305,"logger":"http.log","msg":"server running","name":"remaining_auto_https_redirects","protocols":["h1","h2","h3"]}
{"level":"info","ts":1727605355.3030806,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["test111.duckdns.org"]}
{"level":"info","ts":1727605355.3036702,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"}
{"level":"info","ts":1727605355.3037133,"msg":"serving initial configuration"}
{"level":"info","ts":1727605355.3042874,"logger":"tls.obtain","msg":"acquiring lock","identifier":"test111.duckdns.org"}
{"level":"info","ts":1727605355.3129718,"logger":"tls","msg":"storage cleaning happened too recently; skipping for now","storage":"FileStorage:/data/caddy","instance":"a16163dc-5a65-4977-a1d2-99f3861efde9","try_again":1727691755.312966,"try_again_in":86399.999998222}
{"level":"info","ts":1727605355.3156607,"logger":"tls","msg":"finished cleaning storage units"}
{"level":"info","ts":1727605355.317196,"logger":"tls.obtain","msg":"lock acquired","identifier":"test111.duckdns.org"}
{"level":"info","ts":1727605355.3174765,"logger":"tls.obtain","msg":"obtaining certificate","identifier":"test111.duckdns.org"}
{"level":"info","ts":1727605355.3214889,"logger":"tls.issuance.acme","msg":"waiting on internal rate limiter","identifiers":["test111.duckdns.org"],"ca":"https://acme-v02.api.letsencrypt.org/directory","account":""}
{"level":"info","ts":1727605355.3219013,"logger":"tls.issuance.acme","msg":"done waiting on internal rate limiter","identifiers":["test111.duckdns.org"],"ca":"https://acme-v02.api.letsencrypt.org/directory","account":""}
{"level":"info","ts":1727605355.3220537,"logger":"tls.issuance.acme","msg":"using ACME account","account_id":"https://acme-v02.api.letsencrypt.org/acme/acct/1972895377","account_contact":[]}
{"level":"info","ts":1727605356.633995,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"test111.duckdns.org","challenge_type":"dns-01","ca":"https://acme-v02.api.letsencrypt.org/directory"}
{"level":"error","ts":1727605360.637146,"logger":"tls.issuance.acme.acme_client","msg":"cleaning up solver","identifier":"test111.duckdns.org","challenge_type":"dns-01","error":"no memory of presenting a DNS record for \"_acme-challenge.test111.duckdns.org\" (usually OK if presenting also failed)"}
{"level":"error","ts":1727605360.817957,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"test111.duckdns.org","issuer":"acme-v02.api.letsencrypt.org-directory","error":"[test111.duckdns.org] solving challenges: presenting for challenge: could not determine zone for domain \"_acme-challenge.test111.duckdns.org\": unexpected response code 'SERVFAIL' for _acme-challenge.test111.duckdns.org. (order=https://acme-v02.api.letsencrypt.org/acme/order/1972895377/309256751337) (ca=https://acme-v02.api.letsencrypt.org/directory)"}
{"level":"error","ts":1727605360.8182611,"logger":"tls.obtain","msg":"will retry","error":"[test111.duckdns.org] Obtain: [test111.duckdns.org] solving challenges: presenting for challenge: could not determine zone for domain \"_acme-challenge.test111.duckdns.org\": unexpected response code 'SERVFAIL' for _acme-challenge.test111.duckdns.org. (order=https://acme-v02.api.letsencrypt.org/acme/order/1972895377/309256751337) (ca=https://acme-v02.api.letsencrypt.org/directory)","attempt":1,"retrying_in":60,"elapsed":5.501031812,"max_duration":2592000}
{"level":"info","ts":1727605420.8193543,"logger":"tls.obtain","msg":"obtaining certificate","identifier":"test111.duckdns.org"}
{"level":"info","ts":1727605420.8230555,"logger":"tls.issuance.acme","msg":"using ACME account","account_id":"https://acme-staging-v02.api.letsencrypt.org/acme/acct/165121373","account_contact":[]}
{"level":"info","ts":1727605421.9944196,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"test111.duckdns.org","challenge_type":"dns-01","ca":"https://acme-staging-v02.api.letsencrypt.org/directory"}
{"level":"error","ts":1727605427.8644516,"logger":"tls.issuance.acme.acme_client","msg":"cleaning up solver","identifier":"test111.duckdns.org","challenge_type":"dns-01","error":"no memory of presenting a DNS record for \"_acme-challenge.test111.duckdns.org\" (usually OK if presenting also failed)"}
{"level":"error","ts":1727605428.0491064,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"test111.duckdns.org","issuer":"acme-v02.api.letsencrypt.org-directory","error":"[test111.duckdns.org] solving challenges: presenting for challenge: could not determine zone for domain \"_acme-challenge.test111.duckdns.org\": unexpected response code 'SERVFAIL' for test111.duckdns.org. (order=https://acme-staging-v02.api.letsencrypt.org/acme/order/165121373/19447977173) (ca=https://acme-staging-v02.api.letsencrypt.org/directory)"}
{"level":"error","ts":1727605428.0493033,"logger":"tls.obtain","msg":"will retry","error":"[test111.duckdns.org] Obtain: [test111 .duckdns.org] solving challenges: presenting for challenge: could not determine zone for domain \"_acme-challenge.test111.duckdns.org\": unexpected response code 'SERVFAIL' for test111.duckdns.org. (order=https://acme-staging-v02.api.letsencrypt.org/acme/order/165121373/19447977173) (ca=https://acme-staging-v02.api.letsencrypt.org/directory)","attempt":2,"retrying_in":120,"elapsed":72.732074094,"max_duration":2592000}

There are a few errors.

I have tried the following:

Ensuring the raspberry pi firewall is allowing the required ports:

Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere                  
51820/udp                  DENY        Anywhere                  
10001/udp                  ALLOW       Anywhere                  
8888/tcp                   ALLOW       Anywhere                  
80                         ALLOW       Anywhere                  
443                        ALLOW       Anywhere                  
443/udp                    ALLOW       Anywhere                  
443/udp (v6)               ALLOW       Anywhere (v6)   

Ensuring the Caddyfile and caddy binary exist within the caddy container:

sudo docker exec -it caddy ls /etc/caddy/
Caddyfile
sudo docker exec -it caddy /usr/bin/caddy version
v2.8.4 h1:q3pe0wpBj1OcHFZ3n/1nl4V4bxBrYoSoab7rL9BMYNk=

Ensuring the caddy container environment variables are set:

sudo docker exec -it caddy env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=095d14f91850
TERM=xterm
DOMAIN=test111.duckdns.org
DUCKDNS_TOKEN=<correct token>
LOG_FILE=/data/access.log
CADDY_VERSION=v2.8.4
XDG_CONFIG_HOME=/config
XDG_DATA_HOME=/data
HOME=/root

Pinged acme-v02.api.letsencrypt.org within the caddy container and raspberry pi host:

sudo docker exec -it caddy ping acme-v02.api.letsencrypt.org
PING acme-v02.api.letsencrypt.org (172.65.32.248): 56 data bytes
64 bytes from 172.65.32.248: seq=0 ttl=54 time=19.950 ms
64 bytes from 172.65.32.248: seq=1 ttl=54 time=19.783 ms
64 bytes from 172.65.32.248: seq=2 ttl=54 time=15.651 ms
64 bytes from 172.65.32.248: seq=3 ttl=54 time=15.698 ms
64 bytes from 172.65.32.248: seq=4 ttl=54 time=15.744 ms
ping acme-v02.api.letsencrypt.org
PING ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com (172.65.32.248) 56(84) bytes of data.
64 bytes from 172.65.32.248 (172.65.32.248): icmp_seq=1 ttl=55 time=28.1 ms
64 bytes from 172.65.32.248 (172.65.32.248): icmp_seq=2 ttl=55 time=19.6 ms
64 bytes from 172.65.32.248 (172.65.32.248): icmp_seq=3 ttl=55 time=26.2 ms
64 bytes from 172.65.32.248 (172.65.32.248): icmp_seq=4 ttl=55 time=16.5 ms

Checked the duckdns api is working from the raspberry pi host:

curl "https://www.duckdns.org/update?domains=test111&token=<correct token>&ip=192.168.117.10"
OK

Ensured my duckdns domain propagates with my private IP:

Other than that I have no idea why I’m getting the errors in the caddy docker log files. I also can’t access my vault warden instance with test111.duckdns.org. If I un-comment the port setting for vaultwarden in the compose file I can access http unencrypted vaultwarden with the private IP address followed by the port.

I did read some similar questions where the solution was to change the DNS resolver but I really want to avoid that as I wish to stick with quad9.

EDIT: To add I also tried running the Linux arm7 32 bit custom caddy binary and got the following errors:

file caddy
caddy: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, Go BuildID=xD1fJhezluuMbPrPc_Kq/OuJE28i4Dq5KmRaJN09u/vqkGaNKplMIedQakHLfX/5CNfhQwQuBK77Orkf_m_, stripped
sudo docker logs -f caddy
{"level":"info","ts":1727622055.889434,"msg":"using config from file","file":"/etc/caddy/Caddyfile"}
{"level":"info","ts":1727622055.8942316,"msg":"adapted config to JSON","adapter":"caddyfile"}
{"level":"warn","ts":1727622055.8944693,"msg":"Caddyfile input is not formatted; run 'caddy fmt --overwrite' to fix inconsistencies","adapter":"caddyfile","file":"/etc/caddy/Caddyfile","line":2}
{"level":"info","ts":1727622055.8972685,"logger":"admin","msg":"admin endpoint started","address":"localhost:2019","enforce_origin":false,"origins":["//[::1]:2019","//127.0.0.1:2019","//localhost:2019"]}
{"level":"info","ts":1727622055.897921,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0x3601440"}
{"level":"info","ts":1727622055.8980148,"logger":"http.auto_https","msg":"server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS","server_name":"srv0","https_port":443}
{"level":"info","ts":1727622055.898221,"logger":"http.auto_https","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
{"level":"info","ts":1727622055.8993847,"logger":"http","msg":"enabling HTTP/3 listener","addr":":443"}
{"level":"info","ts":1727622055.8997521,"msg":"failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 7168 kiB, got: 416 kiB). See https://github.com/quic-go/quic-go/wiki/UDP-Buffer-Sizes for details."}
{"level":"info","ts":1727622055.900686,"logger":"http.log","msg":"server running","name":"srv0","protocols":["h1","h2","h3"]}
{"level":"info","ts":1727622055.9010816,"logger":"http.log","msg":"server running","name":"remaining_auto_https_redirects","protocols":["h1","h2","h3"]}
{"level":"info","ts":1727622055.9011903,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["test111.duckdns.org"]}
{"level":"info","ts":1727622055.9018955,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"}
{"level":"info","ts":1727622055.9020681,"msg":"serving initial configuration"}
{"level":"info","ts":1727622055.903311,"logger":"tls.obtain","msg":"acquiring lock","identifier":"test111.duckdns.org"}
{"level":"info","ts":1727622055.9135754,"logger":"tls","msg":"storage cleaning happened too recently; skipping for now","storage":"FileStorage:/data/caddy","instance":"a16163dc-5a65-4977-a1d2-99f3861efde9","try_again":1727708455.9135637,"try_again_in":86399.999995463}
{"level":"info","ts":1727622055.9159403,"logger":"tls","msg":"finished cleaning storage units"}
{"level":"info","ts":1727622055.9178913,"logger":"tls.obtain","msg":"lock acquired","identifier":"test111.duckdns.org"}
{"level":"info","ts":1727622055.9184067,"logger":"tls.obtain","msg":"obtaining certificate","identifier":"test111.duckdns.org"}
{"level":"info","ts":1727622055.9393327,"logger":"tls.issuance.acme","msg":"waiting on internal rate limiter","identifiers":["test111.duckdns.org"],"ca":"https://acme-v02.api.letsencrypt.org/directory","account":""}
{"level":"info","ts":1727622055.9394164,"logger":"tls.issuance.acme","msg":"done waiting on internal rate limiter","identifiers":["test111.duckdns.org"],"ca":"https://acme-v02.api.letsencrypt.org/directory","account":""}
{"level":"info","ts":1727622055.9394782,"logger":"tls.issuance.acme","msg":"using ACME account","account_id":"https://acme-v02.api.letsencrypt.org/acme/acct/1972895377","account_contact":[]}
{"level":"info","ts":1727622057.0690742,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"test111.duckdns.org","challenge_type":"dns-01","ca":"https://acme-v02.api.letsencrypt.org/directory"}
{"level":"error","ts":1727622080.7703269,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"test111.duckdns.org","issuer":"acme-v02.api.letsencrypt.org-directory","error":"[test111.duckdns.org] solving challenges: waiting for solver certmagic.solverWrapper to be ready: checking DNS propagation of \"_acme-challenge.test111.duckdns.org.\" (relative=_acme-challenge.test111 zone=duckdns.org. resolvers=[127.0.0.11:53]): querying authoritative nameservers: dial tcp 35.183.157.249:53: i/o timeout (order=https://acme-v02.api.letsencrypt.org/acme/order/1972895377/309303011467) (ca=https://acme-v02.api.letsencrypt.org/directory)"}
{"level":"error","ts":1727622080.7706964,"logger":"tls.obtain","msg":"will retry","error":"[test111.duckdns.org] Obtain: [test111.duckdns.org] solving challenges: waiting for solver certmagic.solverWrapper to be ready: checking DNS propagation of \"_acme-challenge.test111.duckdns.org.\" (relative=_acme-challenge.test111 zone=duckdns.org. resolvers=[127.0.0.11:53]): querying authoritative nameservers: dial tcp 35.183.157.249:53: i/o timeout (order=https://acme-v02.api.letsencrypt.org/acme/order/1972895377/309303011467) (ca=https://acme-v02.api.letsencrypt.org/directory)","attempt":1,"retrying_in":60,"elapsed":24.852664933,"max_duration":2592000}
{"level":"info","ts":1727622140.7757854,"logger":"tls.obtain","msg":"obtaining certificate","identifier":"test111.duckdns.org"}
{"level":"info","ts":1727622140.781972,"logger":"tls.issuance.acme","msg":"using ACME account","account_id":"https://acme-staging-v02.api.letsencrypt.org/acme/acct/165121373","account_contact":[]}
{"level":"info","ts":1727622141.8062289,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"test111.duckdns.org","challenge_type":"dns-01","ca":"https://acme-staging-v02.api.letsencrypt.org/directory"}
{"level":"error","ts":1727622164.5756965,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"test111.duckdns.org","issuer":"acme-v02.api.letsencrypt.org-directory","error":"[test111.duckdns.org] solving challenges: waiting for solver certmagic.solverWrapper to be ready: checking DNS propagation of \"_acme-challenge.test111.duckdns.org.\" (relative=_acme-challenge.test111 zone=duckdns.org. resolvers=[127.0.0.11:53]): querying authoritative nameservers: dial tcp 35.183.157.249:53: i/o timeout (order=https://acme-staging-v02.api.letsencrypt.org/acme/order/165121373/19451462643) (ca=https://acme-staging-v02.api.letsencrypt.org/directory)"}
{"level":"error","ts":1727622164.57607,"logger":"tls.obtain","msg":"will retry","error":"[test111.duckdns.org] Obtain: [test111.duckdns.org] solving challenges: waiting for solver certmagic.solverWrapper to be ready: checking DNS propagation of \"_acme-challenge.test111.duckdns.org.\" (relative=_acme-challenge.test111 zone=duckdns.org. resolvers=[127.0.0.11:53]): querying authoritative nameservers: dial tcp 35.183.157.249:53: i/o timeout (order=https://acme-staging-v02.api.letsencrypt.org/acme/order/165121373/19451462643) (ca=https://acme-staging-v02.api.letsencrypt.org/directory)","attempt":2,"retrying_in":120,"elapsed":108.658033911,"max_duration":2592000}

EDIT 2: After leaving it for over a month I’m now getting no errors, but I still cannot access vaultwarden from my duck dns domain:

sudo docker logs -f caddy
{"level":"info","ts":1730509425.2111886,"msg":"using config from file","file":"/etc/caddy/Caddyfile"}
{"level":"info","ts":1730509425.216362,"msg":"adapted config to JSON","adapter":"caddyfile"}
{"level":"info","ts":1730509425.2219846,"logger":"admin","msg":"admin endpoint started","address":"localhost:2019","enforce_origin":false,"origins":["//localhost:2019","//[::1]:2019","//127.0.0.1:2019"]}
{"level":"info","ts":1730509425.2253249,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0x3305440"}
{"level":"info","ts":1730509425.2259152,"logger":"http.auto_https","msg":"server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS","server_name":"srv0","https_port":443}
{"level":"info","ts":1730509425.2260175,"logger":"http.auto_https","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
{"level":"info","ts":1730509425.2274652,"logger":"http","msg":"enabling HTTP/3 listener","addr":":443"}
{"level":"info","ts":1730509425.2283056,"msg":"failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 7168 kiB, got: 416 kiB). See https://github.com/quic-go/quic-go/wiki/UDP-Buffer-Sizes for details."}
{"level":"info","ts":1730509425.2303185,"logger":"http.log","msg":"server running","name":"srv0","protocols":["h1","h2","h3"]}
{"level":"info","ts":1730509425.2311358,"logger":"http.log","msg":"server running","name":"remaining_auto_https_redirects","protocols":["h1","h2","h3"]}
{"level":"info","ts":1730509425.2311902,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["test111.duckdns.org"]}
{"level":"info","ts":1730509425.2411044,"logger":"tls","msg":"storage cleaning happened too recently; skipping for now","storage":"FileStorage:/data/caddy","instance":"a16163dc-5a65-4977-a1d2-99f3861efde9","try_again":1730595825.2410927,"try_again_in":86399.999995389}
{"level":"info","ts":1730509425.243545,"logger":"tls","msg":"finished cleaning storage units"}
{"level":"info","ts":1730509425.2521818,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"}
{"level":"info","ts":1730509425.252234,"msg":"serving initial configuration"}
{"level":"info","ts":1730523225.9665465,"logger":"tls.issuance.acme.acme_client","msg":"got renewal info","names":["test111.duckdns.org"],"window_start":1732733817.6666667,"window_end":1732906617.6666667,"selected_time":1732735151,"recheck_after":1730544825.966436,"explanation_url":""}
{"level":"info","ts":1730523225.971888,"logger":"tls.cache.maintenance","msg":"updated ACME renewal information","identifiers":["test111.duckdns.org"],"cert_hash":"473b1cf067496e9fc3f42fc415ea94d74e9283e57d31fe9d9a881f63aecb0ea3","ari_unique_id":"kydGmAOpUWiOmNbEQkjbI79YlNI.A6tlEWMRO5K6GadhyskBc19w","cert_expiry":1735411047,"selected_time":1732783719,"next_update":1730544825.966436,"explanation_url":""}

Also if I use nslookup to resolve my duck dns domain I get the following back:

nslookup test111.duckdns.org
;; Got SERVFAIL reply from 127.0.0.53
Server:		127.0.0.53
Address:	127.0.0.53#53

** server can't find test111.duckdns.org: SERVFAIL

Any help is appreciated.

Maybe next to ask at a caddy forum?
I have no idea my self.

Try updating your tls section with this:

tls {
    dns duckdns {$DUCKDNS_TOKEN}
    propagation_delay 30s
    propagation_timeout -1
  }

Have you seen this caddy forum thread which mentions unreliable dns challenge with duckdns?

If you try with certbot and/or acme.sh you may get better error messages than from caddy.

That’s interesting actually. I find that even doing an nslookup on my duck dns domain is hit or miss as to weather it resolves or not. I’m beginning to think the issue is duckdns.

Thanks for your answer. I’ll have a look into it.

Yeah I think this issue is external to vaultwarden. Thanks though.

Hi there, I tried that and unfortunately it made no difference.

It turns out you have to add a host override to Pfsenses DNS resolver settings so it can map your subdomain to a private IP on your LAN. With this I’m able to resolve my subdomain and also being able to load the vault warden webpage with the duckdns subdomain over SSL.