ddclient Publishes the VPN Exit: Fix the Discovery Source

Your DNS name now resolves to a VPN provider address, and the update log looks perfectly healthy. That combination is normal. A web-based discovery probe asks an external service what source it sees, and when the request leaves through a full-tunnel VPN, the answer is the VPN exit rather than your home WAN address. The updater did its job; the job was pointed at the wrong observation.

Confirm what the name is supposed to reach

A public name for an inbound home service needs an address through which approved incoming connections can reach that service. Publishing a shared provider exit does not arrange inbound forwarding there, and no amount of DNS configuration creates that forwarding. Decide this before you touch the updater, because it determines which address is correct.

A private name for a VPN client tunnel address is a different problem with a different answer: it belongs in private DNS, and it does not need a public discovery service at all. Mixing the two requirements is how a working configuration starts publishing an address nobody asked for.

Interface addresses also need interpretation. A laptop address behind a home router is not the public WAN address, and even the router WAN address may sit behind carrier-grade NAT, where publishing it cannot produce inbound reachability.

Reproduce the value before changing anything

Observe the two paths separately. With the tunnel up, a probe reports the exit; with the tunnel down, or with the probe bound to the physical interface, it reports the home address: curl --interface eth0 https://ifconfig.me. If those two answers differ, you have reproduced the fault without touching the updater.

Then run the client in a mode that checks configuration without performing an update, such as ddclient -verbose -noexec, and read which discovery method it selected. The verbose output names the method and the value it obtained, which is the fact you need before editing anything.

Point discovery at the chosen path

If the name must publish the home WAN address, discovery has to observe that address. Three options work, in rough order of preference: let the router publish through its own supported updater; use ddclient router-status discovery against a page the router actually serves; or keep a web probe but bind it to the physical interface so it leaves outside the tunnel.

For the router-status route, newer ddclient releases use the usev4 and fwv4 option family, with an optional skip pattern for the surrounding page text. Check the README for your installed version, because older releases spell the same idea with use and fw, and a copied option name from the wrong release fails at startup.

If you keep web discovery, remember that routing the probe and routing the update API call are separate decisions. The update call delivers the record; the probe decides the value that gets delivered.

Keep secrets and versions straight

Router credentials and provider tokens belong in a protected configuration file, not on a command line that ends up in shell history. Verbose traces can contain both, so redact them before pasting into a ticket. A discovery method that requires scraping an authenticated router page also requires you to keep that credential working across firmware updates. Store it with the same care as the provider token.

The ddclient README documents the discovery approaches and their option names. Do not mix IPv4 and IPv6 results in one record, and do not assume that an option present in one release exists in another.

Verify the value, then the reachability

Compare the proposed address with the intended endpoint before allowing a live update, then check authoritative DNS after one authorized update and allow for resolver caches. A low TTL shortens the wait; it does not make a wrong value right.

Only after the record is correct should you test the inbound service from an independent network with the required firewall and forwarding already approved. A correct A record does not prove a reachable service, and a static VPN lease can simplify private naming without repairing a public hostname that points at the wrong WAN.