[Bug] Setting a resolver and dnspropagation or timeout silently crashes Caddy

[legionGer]

Issue Details

Hey,

I noticed that Caddy will silently crash wenn using a DNSPropagation Time or Timeout in conjunction with a resolver, at least when using the Netcup Plugin.

Using a Caddyfile like this

your.domain.com {
	...
	tls {
		dns netcup {
			...
		}
		propagation_timeout 900s
		propagation_delay 600s
		resolvers 1.1.1.1
	}
	...
}

Will just cause Caddy to do nothing after 10 minutes. There’s nothing in the log, even when using debug mode. Removing either time won’t change the behavior, however removing the resolvers line will. Resolver line on its own also works fine.

Current version of caddy with netcup plugin, compiled just fresh.

Assistance Disclosure

No response

If AI was used, describe the extent to which it was used.

No response

[steadytao]

A couple quick clarifiers to narrow this down:

1. When you say “silently crash”, does the Caddy process actually exit or does it remain running but appears to hang?
   • If it’s still running, can you grab a goroutine dump at the time it “does nothing”?
     (On Linux: kill -QUIT <pid>; this prints stacks to stderr / the terminal running Caddy.)
2. Please paste caddy version and the exact xcaddy build ... line so we can see module versions, esp. the netcup plugin + certmagic/lego versions.
3. Can you share full logs from a clean run with debug enabled (start-up included), plus the minimal Caddyfile that reproduces? (redacting secrets is fine)

It’d also help to confirm whether removing only propagation_delay reproduces, or whether the process truly exits/hangs regardless

[francislavoie]

You don't want to set a long delay, that's the opposite of what makes sense (unless your DNS provider is truly awful and you need it as a workaround because their API doesn't actually set the DNS records until 10 minutes later???)

I think you simply misunderstand what those options are for. If you think you're not, please explain why you think you need them.

[legionGer]

A couple quick clarifiers to narrow this down:

1. When you say “silently crash”, does the Caddy process actually exit or does it remain running but appears to hang?

   • If it’s still running, can you grab a goroutine dump at the time it “does nothing”?
     (On Linux: kill -QUIT <pid>; this prints stacks to stderr / the terminal running Caddy.)

2. Please paste caddy version and the exact xcaddy build ... line so we can see module versions, esp. the netcup plugin + certmagic/lego versions.

3. Can you share full logs from a clean run with debug enabled (start-up included), plus the minimal Caddyfile that reproduces? (redacting secrets is fine)

It’d also help to confirm whether removing only propagation_delay reproduces, or whether the process truly exits/hangs regardless

I got it working in the mean time by not specificing a resolver. I got some saved logs but sadly dont have the time to reproduce it today to give you the output of the err stag ...

2026/02/14 18:00:33.529 DEBUG   tls.obtain      trying issuer 1/1       {"issuer": "acme-v02.api.letsencrypt.org-directory"}
2026/02/14 18:00:33.529 DEBUG   tls.issuance.acme       using existing ACME account because key found in storage associated with email  {"email": "email", "ca": "https://acme-v02.api.letsencrypt.org/directory"}
2026/02/14 18:00:33.529 INFO    tls.issuance.acme       waiting on internal rate limiter        {"identifiers": ["*.my-domain.com"], "ca": "https://acme-v02.api.letsencrypt.org/directory", "account": "email@email.com"}
2026/02/14 18:00:33.529 INFO    tls.issuance.acme       done waiting on internal rate limiter   {"identifiers": ["*.my-domain.com"], "ca": "https://acme-v02.api.letsencrypt.org/directory", "account": "email@email.com"}
2026/02/14 18:00:33.529 INFO    tls.issuance.acme       using ACME account      {"account_id": "https://acme-v02.api.letsencrypt.org/acme/acct/accountID", "account_contact": ["mailto:email@email.com"]}
2026/02/14 18:00:33.530 INFO    tls     storage cleaning happened too recently; skipping for now        {"storage": "FileStorage:/root/.local/share/caddy", "instance": "c470552b-e5cf-42fd-a1a3-558bb438502e", "try_again": "2026/02/15 18:00:33.530", "try_again_in": 86399.999999655}
2026/02/14 18:00:33.530 INFO    tls     finished cleaning storage units
2026/02/14 18:00:33.937 DEBUG   http request    {"method": "GET", "url": "https://acme-v02.api.letsencrypt.org/directory", "headers": {"User-Agent":["Caddy/2.10.2 CertMagic acmez (linux; amd64)"]}, "response_headers": {"Cache-Control":["public, max-age=0, no-cache"],"Content-Length":["1033"],"Content-Type":["application/json"],"Date":["Sat, 14 Feb 2026 18:00:33 GMT"],"Server":["nginx"],"Strict-Transport-Security":["max-age=604800"],"X-Frame-Options":["DENY"]}, "status_code": 200}
2026/02/14 18:00:33.938 DEBUG   creating order  {"account": "https://acme-v02.api.letsencrypt.org/acme/acct/accountID", "identifiers": ["*.my-domain.com"]}
2026/02/14 18:00:34.071 DEBUG   http request    {"method": "HEAD", "url": "https://acme-v02.api.letsencrypt.org/acme/new-nonce", "headers": {"User-Agent":["Caddy/2.10.2 CertMagic acmez (linux; amd64)"]}, "response_headers": {"Cache-Control":["public, max-age=0, no-cache"],"Date":["Sat, 14 Feb 2026 18:00:33 GMT"],"Link":["<https://acme-v02.api.letsencrypt.org/directory>;rel=\"index\""],"Replay-Nonce":["qLPTsdtf0uKejryBiSZYtV8APwxJ9g-FOjGLWS6UVa0m3k0l9HM"],"Server":["nginx"],"Strict-Transport-Security":["max-age=604800"],"X-Frame-Options":["DENY"]}, "status_code": 200}
2026/02/14 18:00:34.300 DEBUG   http request    {"method": "POST", "url": "https://acme-v02.api.letsencrypt.org/acme/new-order", "headers": {"Content-Type":["application/jose+json"],"User-Agent":["Caddy/2.10.2 CertMagic acmez (linux; amd64)"]}, "response_headers": {"Boulder-Requester":["accountID"],"Cache-Control":["public, max-age=0, no-cache"],"Content-Length":["344"],"Content-Type":["application/json"],"Date":["Sat, 14 Feb 2026 18:00:34 GMT"],"Link":["<https://acme-v02.api.letsencrypt.org/directory>;rel=\"index\""],"Location":["https://acme-v02.api.letsencrypt.org/acme/order/accountID/480291722806"],"Replay-Nonce":["QkEzerAf4UUMYwvdF7snY39UTti2k6jQiFYySv79ulW2Nk9tpa4"],"Server":["nginx"],"Strict-Transport-Security":["max-age=604800"],"X-Frame-Options":["DENY"]}, "status_code": 201}
2026/02/14 18:00:34.434 DEBUG   http request    {"method": "POST", "url": "https://acme-v02.api.letsencrypt.org/acme/authz/accountID/accountID2", "headers": {"Content-Type":["application/jose+json"],"User-Agent":["Caddy/2.10.2 CertMagic acmez (linux; amd64)"]}, "response_headers": {"Boulder-Requester":["accountID"],"Cache-Control":["public, max-age=0, no-cache"],"Content-Length":["390"],"Content-Type":["application/json"],"Date":["Sat, 14 Feb 2026 18:00:34 GMT"],"Link":["<https://acme-v02.api.letsencrypt.org/directory>;rel=\"index\""],"Replay-Nonce":["qLPTsdtfiZKsA3TExLG8UbvTb-WNWbPa7T_20w50ycyzv6NafPg"],"Server":["nginx"],"Strict-Transport-Security":["max-age=604800"],"X-Frame-Options":["DENY"]}, "status_code": 200}
2026/02/14 18:00:34.435 INFO    trying to solve challenge       {"identifier": "*.my-domain.com", "challenge_type": "dns-01", "ca": "https://acme-v02.api.letsencrypt.org/directory"}
2026/02/14 18:00:35.217 DEBUG   waiting for solver before continuing    {"identifier": "*.my-domain.com", "challenge_type": "dns-01"}

Nothing more would show up in the log after this.

Caddyfile used was:

{
    email mail@mail.com
}
*.my-domain.com {
	tls {
		dns netcup {
			...
		}
		propagation_timeout 900s
		propagation_delay 600s
		resolvers 1.1.1.1
	}
	...
}

caddy version
v2.10.2 h1:g/gTYjGMD0dec+UgMw8SnfmJ3I9+M2TdvoRL/Ovu6U8=
dns.providers.netcup v1.0.0
xcaddy version
v0.4.5 h1:7E4b+3Gm2do/WpuDXh5MWIj+qgCCvQqR487Sm8C6hwc=

"xcaddy build --with github.com/caddy-dns/netcup"

You don't want to set a long delay, that's the opposite of what makes sense (unless your DNS provider is truly awful and you need it as a workaround because their API doesn't actually set the DNS records until 10 minutes later???)

I think you simply misunderstand what those options are for. If you think you're not, please explain why you think you need them.

Yes, netcups nameservers truly are that awful.

[steadytao]

Based on what you’ve shared this doesn’t look like a Caddy crash

With propagation_delay 600s, Caddy will intentionally “do nothing” for ~10 minutes before it even starts propagation checks; with propagation_timeout 900s it may wait up to ~25 minutes total. So the quiet period after ~10 minutes is expected.

The only suspicious part is the resolvers 1.1.1.1 interaction. If you can reproduce again, please confirm the process is still running and grab a goroutine dump while it’s “stuck” (kill -QUIT <pid> or /debug/pprof/goroutine?debug=2). Without that, this looks more like Netcup propagation + the configured delay/timeout than a Caddy bug

[legionGer]

Based on what you’ve shared this doesn’t look like a Caddy crash

With propagation_delay 600s, Caddy will intentionally “do nothing” for ~10 minutes before it even starts propagation checks; with propagation_timeout 900s it may wait up to ~25 minutes total. So the quiet period after ~10 minutes is expected.

The only suspicious part is the resolvers 1.1.1.1 interaction. If you can reproduce again, please confirm the process is still running and grab a goroutine dump while it’s “stuck” (kill -QUIT <pid> or /debug/pprof/goroutine?debug=2). Without that, this looks more like Netcup propagation + the configured delay/timeout than a Caddy bug

The thing is, Caddy did nothing after that 10 minute time period. Didn't recheck with the DNS resolvers, nothing. 10 minutes went by and nothing happened. I even waited up until 25 minutes and the log would remain the same as the one posted above.

I could interrupt it by pressing Ctrl+C, this would then send the normal Caddy shutdown messages to the console.

I had the same behavior putting the propagation time to 300 seconds.

If I got time next week I'll copy the LXC and try to reproduce the behavior.

Leaving the resolvers out of the Caddyfile and Caddy will start checking correctly after the 10min/5min period.

[legionGer]

Based on what you’ve shared this doesn’t look like a Caddy crash

With propagation_delay 600s, Caddy will intentionally “do nothing” for ~10 minutes before it even starts propagation checks; with propagation_timeout 900s it may wait up to ~25 minutes total. So the quiet period after ~10 minutes is expected.

The only suspicious part is the resolvers 1.1.1.1 interaction. If you can reproduce again, please confirm the process is still running and grab a goroutine dump while it’s “stuck” (kill -QUIT <pid> or /debug/pprof/goroutine?debug=2). Without that, this looks more like Netcup propagation + the configured delay/timeout than a Caddy bug

caddy_debug.log

goroutine_dump.txt

Hope this helps. I changed the DNSPropagation Time to 100s for testing and had the same behavior. Dump was done after 10 minutes.

[francislavoie]

@legionGer please try building from #7491 which adds additional debug logging in the DNS manager. You'll need to enable the debug global option in your config as well. To build, add f25bf594 to your xcaddy command, like xcaddy build f25bf594 --with ...

[francislavoie]

I think the change relevant to the behaviour you're seeing is this one:

https://github.com/caddyserver/certmagic/pull/274/changes#diff-0d423173eaa496408ee9e7d82ae770feaa3b860783ca6a155f6d7551cb5d4d14R364

When resolvers are configured, it skips doing the authoritative nameserver check and just checks for TXT record to appear.

If you try the build with debug logging, we should be able to see why it goes wrong in your case. I don't want to make a behaviour change to certmagic yet without understanding more from your logs.

[legionGer]

I think the change relevant to the behaviour you're seeing is this one:

https://github.com/caddyserver/certmagic/pull/274/changes#diff-0d423173eaa496408ee9e7d82ae770feaa3b860783ca6a155f6d7551cb5d4d14R364

When resolvers are configured, it skips doing the authoritative nameserver check and just checks for TXT record to appear.

If you try the build with debug logging, we should be able to see why it goes wrong in your case. I don't want to make a behaviour change to certmagic yet without understanding more from your logs.

With this built I cant quite reproduce it ... Caddy is running and starts properly asking the resolver for the record after the specified time ... I couldnt get the record to propagate to 1.1.1.1 in any timely matter though so that might be issue that caused the apparent hangup before.

[francislavoie]

Yeah... maybe consider using a different DNS provider, tbh. If it takes longer than like a minute, then your DNS provider is kinda shit 😅

I'll close this, I don't see anything actionable now.