Skip to content

caddy: fix Dynamic DNS zone detection for subdomain domain entries#5302

Draft
0xMH wants to merge 1 commit intoopnsense:masterfrom
0xMH:fix/caddy-dyndns-zone-detection
Draft

caddy: fix Dynamic DNS zone detection for subdomain domain entries#5302
0xMH wants to merge 1 commit intoopnsense:masterfrom
0xMH:fix/caddy-dyndns-zone-detection

Conversation

@0xMH
Copy link

@0xMH 0xMH commented Mar 8, 2026

Important notices
Before you submit a pull request, we ask you kindly to acknowledge the following:


Related issue
#5303


Describe the problem

When a non-wildcard domain entry like blog.example.com has Dynamic DNS enabled, the Caddyfile template generates blog.example.com @ in the dynamic_dns domains block. The caddy-dynamicdns module treats the first field as the DNS zone name, but blog.example.com is not a DNS zone - example.com is. The DNS provider lookup fails silently and the record never gets updated.

This only works correctly for:

  • Wildcard entries (*.example.com -> example.com *)
  • Subdomains nested under a wildcard parent (lines 161-164 already have the correct split logic)

The current workaround is to create a wildcard parent domain and nest subdomains under it, which is unintuitive and unnecessary.


Describe the proposed solution

When a non-wildcard domain entry has more than two parts (e.g. blog.example.com), split it into zone + record name using the same logic already present for subdomain entries:

  • blog.example.com -> example.com blog
  • example.com -> example.com @ (unchanged)
  • *.example.com -> example.com * (unchanged)

When a non-wildcard domain entry like "blog.example.com" has DynDns
enabled, the template generates "blog.example.com @" in the dynamic_dns
domains block, treating the full FQDN as the DNS zone name. The
caddy-dynamicdns module then fails to find a matching zone in the DNS
provider since "blog.example.com" is not a zone - "example.com" is.

This fix splits multi-part domain names into zone and record components
(e.g. "blog.example.com" becomes "example.com blog"), matching the same
logic already used for subdomain entries on lines 161-164.

Bare domains like "example.com" continue to generate "example.com @"
as before.
@0xMH 0xMH marked this pull request as draft March 10, 2026 01:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant