1. Caddy version (caddy version
):
v2.4.6 h1:HGkGICFGvyrodcqOOclHKfvJC0qTU7vny/7FhYp9hNw=
Built using xcaddy
.\xcaddy.exe build --with github.com/caddy-dns/glesys
2. How I run Caddy:
Running from command line using caddyfile.
a. System environment:
Windows 10 x64
Running from a PowerShell terminal
b. Command:
.\caddy.exe run -watch
c. Service/unit/compose file:
d. My complete Caddyfile or JSON config:
(glesys) {
tls {
issuer acme {
email "<secret>"
propagation_timeout "20m"
resolvers "ns1.namesystem.se"
dns glesys {
project "<secret>"
api_key "<secret>"
}
}
}
}
*.kapi.kmpm.dev {
import glesys
handle {
respond "Site not served from here"
}
}
3. The problem Iām having:
The DNS lookup that caddy tries to do to create the certificate takes forever to be successfull and it only works after several retries. Eventually it goes through and creates a certificate.
Why canāt caddy get a response when Resolve-DnsName (or dig) can. I have seen the same with 2 different DNS providers but have no explanation as to why?
4. Error messages and/or full log output:
This is not a full log output but itās the relevant parts.
2022/04/22 08:29:46.913 INFO tls.issuance.acme.acme_client trying to solve challenge {"identifier": "*.kapi.kmpm.dev", "challenge_type": "dns-01", "ca": "https://acme-v02.api.letsencrypt.org/directory"}
2022/04/22 08:49:49.126 ERROR tls.obtain could not get certificate from issuer {"identifier": "*.kapi.kmpm.dev", "issuer": "acme-v02.api.letsencrypt.org-directory", "error": "[*.kapi.kmpm.dev] solving challenges: waiting for solver certmagic.solverWrapper to be ready: timed out waiting for record to fully propagate; verify DNS provider configuration is correct - last error: <nil> (order=https://acme-v02.api.letsencrypt.org/acme/order/507916187/82291298347) (ca=https://acme-v02.api.letsencrypt.org/directory)"}
2022/04/22 08:49:49.127 INFO tls.obtain releasing lock {"identifier": "*.kapi.kmpm.dev"}
2022/04/22 08:49:49.129 ERROR tls job failed {"error": "*.kapi.kmpm.dev: obtaining certificate: [*.kapi.kmpm.dev] Obtain: [*.kapi.kmpm.dev] solving challenges: waiting for solver certmagic.solverWrapper to be ready: timed out waiting for record to fully propagate; verify DNS provider configuration is correct - last error: <nil> (order=https://acme-v02.api.letsencrypt.org/acme/order/507916187/82291298347) (ca=https://acme-v02.api.letsencrypt.org/directory)"}
5. What I already tried:
- I have verified that the required _acme-challenge records are created using the providers API.
- I have checked that I can get the challenge record on the same computer as caddy (using Resolve-DnsName and dig in WSL)
- I have watched the DNS traffic using wireshark and can see that caddy does a large amount of queries that all get a āNo such nameā response but that Resolve-DnsName works during the same time.
When trying to use the built in Resolve-DnsName
in PowerShell I get a proper response from the server but caddy doesnāt.
I have looked at it using wireshark and I have a dump of a successful response using Resolve-DnsName with a failed one from caddy a short while later. There is a difference in that OPT
is set on the caddy query but there might be something else that matters as well.
The following is the output from wireshark from a query-response using Resolve-DnsName as well as one triggered by caddy.
Request from using Resolve-DnsName -Server ns1.namesystem.se -Type txt _acme-challenge.kapi.kmpm.dev
Frame 1: 89 bytes on wire (712 bits), 89 bytes captured (712 bits) on interface \Device\NPF_{51E5A288-6AE3-4E1E-97AE-CB93A4EAEA02}, id 0
Ethernet II, Src: HewlettP_2f:5b:5d (ec:b1:d7:2f:5b:5d), Dst: Ubiquiti_cd:18:59 (b4:fb:e4:cd:18:59)
Internet Protocol Version 4, Src: 172.16.10.23, Dst: 195.238.76.18
User Datagram Protocol, Src Port: 25515, Dst Port: 53
Domain Name System (query)
Transaction ID: 0x50c3
Flags: 0x0100 Standard query
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
_acme-challenge.kapi.kmpm.dev: type TXT, class IN
Name: _acme-challenge.kapi.kmpm.dev
[Name Length: 29]
[Label Count: 4]
Type: TXT (Text strings) (16)
Class: IN (0x0001)
[Response In: 2]
Reply to Resolve-DnsName
Frame 2: 145 bytes on wire (1160 bits), 145 bytes captured (1160 bits) on interface \Device\NPF_{51E5A288-6AE3-4E1E-97AE-CB93A4EAEA02}, id 0
Ethernet II, Src: Ubiquiti_cd:18:59 (b4:fb:e4:cd:18:59), Dst: HewlettP_2f:5b:5d (ec:b1:d7:2f:5b:5d)
Internet Protocol Version 4, Src: 195.238.76.18, Dst: 172.16.10.23
User Datagram Protocol, Src Port: 53, Dst Port: 25515
Domain Name System (response)
Transaction ID: 0x50c3
Flags: 0x8500 Standard query response, No error
Questions: 1
Answer RRs: 1
Authority RRs: 0
Additional RRs: 0
Queries
_acme-challenge.kapi.kmpm.dev: type TXT, class IN
Name: _acme-challenge.kapi.kmpm.dev
[Name Length: 29]
[Label Count: 4]
Type: TXT (Text strings) (16)
Class: IN (0x0001)
Answers
_acme-challenge.kapi.kmpm.dev: type TXT, class IN
Name: _acme-challenge.kapi.kmpm.dev
Type: TXT (Text strings) (16)
Class: IN (0x0001)
Time to live: 3600 (1 hour)
Data length: 44
TXT Length: 43
TXT: QN0yBxJUfcKlhCno_wY_ZOCSTklHcNk8OwGCGUlz6ic
[Request In: 1]
[Time: 0.008665000 seconds]
Caddy Request
Frame 3: 100 bytes on wire (800 bits), 100 bytes captured (800 bits) on interface \Device\NPF_{51E5A288-6AE3-4E1E-97AE-CB93A4EAEA02}, id 0
Ethernet II, Src: HewlettP_2f:5b:5d (ec:b1:d7:2f:5b:5d), Dst: Ubiquiti_cd:18:59 (b4:fb:e4:cd:18:59)
Internet Protocol Version 4, Src: 172.16.10.23, Dst: 195.238.76.18
User Datagram Protocol, Src Port: 25516, Dst Port: 53
Domain Name System (query)
Transaction ID: 0x7edb
Flags: 0x0100 Standard query
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 1
Queries
_acme-challenge.kapi.kmpm.dev: type TXT, class IN
Name: _acme-challenge.kapi.kmpm.dev
[Name Length: 29]
[Label Count: 4]
Type: TXT (Text strings) (16)
Class: IN (0x0001)
Additional records
<Root>: type OPT
Name: <Root>
Type: OPT (41)
UDP payload size: 4096
Higher bits in extended RCODE: 0x00
EDNS0 version: 0
Z: 0x0000
0... .... .... .... = DO bit: Cannot handle DNSSEC security RRs
.000 0000 0000 0000 = Reserved: 0x0000
Data length: 0
[Response In: 4]
Response to Caddy
Frame 4: 169 bytes on wire (1352 bits), 169 bytes captured (1352 bits) on interface \Device\NPF_{51E5A288-6AE3-4E1E-97AE-CB93A4EAEA02}, id 0
Ethernet II, Src: Ubiquiti_cd:18:59 (b4:fb:e4:cd:18:59), Dst: HewlettP_2f:5b:5d (ec:b1:d7:2f:5b:5d)
Internet Protocol Version 4, Src: 195.238.76.18, Dst: 172.16.10.23
User Datagram Protocol, Src Port: 53, Dst Port: 25516
Domain Name System (response)
Transaction ID: 0x7edb
Flags: 0x8503 Standard query response, No such name
Questions: 1
Answer RRs: 0
Authority RRs: 1
Additional RRs: 1
Queries
_acme-challenge.kapi.kmpm.dev: type TXT, class IN
Name: _acme-challenge.kapi.kmpm.dev
[Name Length: 29]
[Label Count: 4]
Type: TXT (Text strings) (16)
Class: IN (0x0001)
Authoritative nameservers
kapi.kmpm.dev: type SOA, class IN, mname ns1.namesystem.se
Name: kapi.kmpm.dev
Type: SOA (Start Of a zone of Authority) (6)
Class: IN (0x0001)
Time to live: 3600 (1 hour)
Data length: 57
Primary name server: ns1.namesystem.se
Responsible authority's mailbox: registry.glesys.se
Serial Number: 35
Refresh Interval: 10800 (3 hours)
Retry Interval: 2700 (45 minutes)
Expire limit: 1814400 (21 days)
Minimum TTL: 10800 (3 hours)
Additional records
<Root>: type OPT
Name: <Root>
Type: OPT (41)
UDP payload size: 1232
Higher bits in extended RCODE: 0x00
EDNS0 version: 0
Z: 0x0000
0... .... .... .... = DO bit: Cannot handle DNSSEC security RRs
.000 0000 0000 0000 = Reserved: 0x0000
Data length: 0
[Request In: 3]
[Time: 0.006742000 seconds]
I do have a pcapng file from wireshark if neccesary.