Dynamic-IP client for multiple providers.
Modular DDNS client in Python that syncs the public IP with any DNS provider via API. In-house tool built in Zaragoza.
An extensible DDNS client written in Python that syncs the host's public IP with any DNS provider that exposes an API. It grew out of the need to host services on a home connection without being tied to a single registrar, and the desire to rotate between providers based on pricing, reliability or DNS latency.
Problem
Traditional DDNS clients (ddclient, no-ip-client) ship with hard-coded integrations for a handful of providers and one config file per provider. Switching DNS = recompiling the package or swapping the binary. For a home setup with several subdomains pointing at several services — some on Cloudflare, others on a self-hosted registrar — the only option was maintaining N different scripts.
Design
The client exposes a Provider interface that each plugin implements with three methods: get_current_ip(), update_record(name, ip), auth_headers(). Adding a new provider takes ~30 lines of Python plus registering it in the TOML config. The daemon checks the public IP every N seconds and only issues an update when it changes — no hammering DNS APIs for free.
Stack
- Python 3 with
httpxfor HTTP/2 keep-alive andtomllibfor native config - Plugins already implemented: Cloudflare, OVH, DynDNS, GoDaddy
- Daemon running on a Raspberry Pi 4, ~3 MB RSS, automatic restart via systemd
Operation
The daemon runs as a systemd service with automatic restart and a minimal memory footprint (~3 MB RSS), designed to live indefinitely on modest hardware like a Raspberry Pi. The public-IP check is lightweight: it only issues an update to the DNS provider when the IP actually changes, avoiding needless calls to the APIs and respecting their rate limits.
Adding support for a new provider is deliberately cheap — roughly 30 lines of Python implementing the Provider interface plus a registration in the TOML config — which makes it possible to cover niche registrars or rotate between providers based on pricing, reliability or DNS latency without touching the core. That extensibility, free of any single-DNS lock-in, is exactly the point of the project.
A scratch-your-own-itch project. Useful as an example of a small plugin architecture without overengineering.