No, it doesnât.
It does the âsmart thingâ and try to do direct DNS.
I have the firewall logs showing that it DOES do the wrong âsmart thingâ , EVEN with those (10.128.20.1 is the system resolver) and 1.1.1.1 isnât even asked.
The other part to this, I realize that should be asked: to NOT track the DNS, as querying the internal DNS, will yield a different answer from the external DNS as only the external DNS (that ACME server queries) need the CNAME/TXT records, as the internal DNS doesnât, as it contains only the internal IPs, and nothing thatâs âexternalâ
Lets do some logs and tcpdumps to show, the Caddyfile Iâll test/use:
{
acme_dns acmedns /etc/acmedns/clientstorage.json
debug
}
*.sa.see.trosint.ovh sa.see.trosint.ovh {
respond "Hello SSL"
}
Do note The EXTERNAL DNS domain (ie. when you, and ACME/LE/ZeroSSL query youâll get a response for _challenge.sa.see.trosint.ovh) is configured correctly. I am not going to change that. Iâm only going to change the âinternalâ/protected DNS and firewall rules.
FIRST: Internal doesnât have the _acme-challenge.sa.see.trosint.ovh configured, and *.sa.see.trosint.ovh points to sa.see.trosint.ovh, so _challenge would also point to sa.see.trosint.ovh
Caddy log :
https://plik.cloudoffice.co.za/file/YKZRxQ80AOx2qWDW/mojOcNIZpZzWeCAp/AGWsurf20-internal-no_cname.caddy.log
tcpdumpâs port 53
https://plik.cloudoffice.co.za/file/5PnGnWnkeUwnWm4U/UtnTSHYnHijSBrkB/STDIN
the relevant portions (for me):
from DNS showing that it tries to query the _challenge, and got ânothingâ (as expected, you are an internal not needing the external stuff)
10.128.20.11.43474 > 10.128.20.1.53: [bad udp cksum 0x3d64 -> 0x68b1!] 932+ [1au] SOA? _acme-challenge.sa.see.trosint.ovh. ar: . OPT UDPsize=4096 (63)
06:22:04.856588 IP (tos 0x0, ttl 64, id 61757, offset 0, flags [DF], proto UDP (17), length 174)
10.128.20.1.53 > 10.128.20.11.43474: [udp sum ok] 932 q: SOA? _acme-challenge.sa.see.trosint.ovh. 1/1/1 _acme-challenge.sa.see.trosint.ovh. CNAME sa.see.trosint.ovh. ns: see.trosint.ovh. SOA ns1.mwprox.in. sysadmin.hevis.co.za. 2022041901 28800 7200 604800 600 ar: . OPT UDPsize=4096 (146)
06:22:04.856754 IP (tos 0x0, ttl 64, id 9315, offset 0, flags [DF], proto UDP (17), length 75)
10.128.20.11.34178 > 10.128.20.1.53: [bad udp cksum 0x3d54 -> 0xcd5a!] 28823+ [1au] SOA? sa.see.trosint.ovh. ar: . OPT UDPsize=4096 (47)
06:22:04.865809 IP (tos 0x0, ttl 64, id 62013, offset 0, flags [DF], proto UDP (17), length 144)
10.128.20.1.53 > 10.128.20.11.34178: [udp sum ok] 28823 q: SOA? sa.see.trosint.ovh. 0/1/1 ns: see.trosint.ovh. SOA ns1.mwprox.in. sysadmin.hevis.co.za. 2022041901 28800 7200 604800 600 ar: . OPT UDPsize=4096 (116)
From the caddy log:
{"level":"info","ts":1650349324.3459597,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"sa.see.trosint.ovh","challenge_type":"dns-01","ca":"https://acme-v02.api.letsencrypt.org/directory"}
{"level":"error","ts":1650349355.0679355,"logger":"tls.issuance.acme.acme_client","msg":"cleaning up solver","identifier":"*.sa.see.trosint.ovh","challenge_type":"dns-01","error":"no memory of presenting a DNS record for sa.see.trosint.ovh (probably OK if presenting failed)"}
Doesnât matter how many times, it doesnât seem to remember that âpresentingâ DNS record, which I guess is related to it âwantingâ to check the record itself, not trusting the push? Is this perhaps related to the âfunâ with delegating the domain to update/check ?
So Next test to show that caddy/certmagic/whomever does direct DNS and ignores the system resolver:
I added in the INTERNAL DNS _acme-challenge.sa.see.trosint.ovh CNAME to 3b13c262-628e-4576-8a38-3b5f52a77896.auth.acme-dns.io
Caddy debug output: https://plik.cloudoffice.co.za/file/D8ZfCKEJFOb2IDEg/K5ZCOLwpLvMJQSo0/AGWsurf20-internal-internal_cname.caddy.log
the interesting part:
{"level":"error","ts":1650353308.67106,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"*.sa.see.trosint.ovh","issuer":"acme-v02.api.letsencrypt.org-directory","error":"[*.sa.see.trosint.ovh] solving challenges: waiting for solver certmagic.solverWrapper to be ready: checking DNS propagation of _acme-challenge.sa.see.trosint.ovh: dial tcp 46.4.128.227:53: i/o timeout (order=https://acme-v02.api.letsencrypt.org/acme/order/504113820/81429230560) (ca=https://acme-v02.api.letsencrypt.org/directory)"}
The tcpdump -a port 53 output: https://plik.cloudoffice.co.za/file/q85KTCvEegM0RHIu/3jNyyIlDyl2LRwwq/STDIN
the interesting line confirming my statements that certMagic does the DNS direct and not via the system resolver, first a UDP, and then TCP on port 53:
07:28:08.517783 IP 10.128.20.11.33532 > 46.4.128.227.53: 15495 [1au] TXT? 3b13c262-628e-4576-8a38-3b5f52a77896.auth.acme-dns.io. (82)
07:28:18.518476 IP 10.128.20.11.43088 > 10.128.20.1.53: 22295+ AAAA? ns.auth.acme-dns.io. (37)
07:28:18.518537 IP 10.128.20.11.56272 > 10.128.20.1.53: 144+ A? ns.auth.acme-dns.io. (37)
07:28:18.527488 IP 10.128.20.1.53 > 10.128.20.11.56272: 144 1/0/0 A 46.4.128.227 (53)
07:28:18.543452 IP 10.128.20.1.53 > 10.128.20.11.43088: 22295 0/0/0 (37)
07:28:18.543646 IP 10.128.20.11.60674 > 46.4.128.227.53: Flags [S], seq 3673031871, win 64240, options [mss 1460,sackOK,TS val 2349545146 ecr 0,nop,wscale 7], length 0
07:28:19.578246 IP 10.128.20.11.60674 > 46.4.128.227.53: Flags [S], seq 3673031871, win 64240, options [mss 1460,sackOK,TS val 2349546180 ecr 0,nop,wscale 7], length 0
07:28:21.594252 IP 10.128.20.11.60674 > 46.4.128.227.53: Flags [S], seq 3673031871, win 64240, options [mss 1460,sackOK,TS val 2349548196 ecr 0,nop,wscale 7], length 0
07:28:25.846248 IP 10.128.20.11.60674 > 46.4.128.227.53: Flags [S], seq 3673031871, win 64240, options [mss 1460,sackOK,TS val 2349552448 ecr 0,nop,wscale 7], length 0
So the questions:
(i) If there are no resolvers line, why does certMagic/Caddy do direct DNS to the acmedns.io ?
(ii) how can I tell certMagic caddy to explicitly trust the http POST update, and not to check the TXT records?
(iii) how do I tell certMagic/caddy to rather wait/delay a configurable time, for the records (instead of checking) and then to proceed with the solving requests?
What more do I have to produce to show my issues/problems inside a protected internal environment?