NewFuture/DDNS: a standard-library dynamic DNS client for 15+ providers

What NewFuture/DDNS actually replaces

Home connections and small offices get a new public address whenever the line renegotiates, so a hostname that should point at the office silently points at someone else's network. The usual fix is a DDNS client bundled with the router, and those clients only speak the old DynDNS update protocol, which most modern DNS providers no longer expose. NewFuture/DDNS is the client that talks to the provider's real API instead: it reads your current IPv4 or IPv6 address, finds the matching record, and writes the new value. The README lists 15+ providers, split into Chinese and cloud platforms (Alibaba DNS, Alibaba Cloud ESA, DNSPod, Tencent Cloud DNS, Tencent Cloud EdgeOne, EdgeOne DNS, Huawei Cloud DNS, DNS.COM/51DNS, West.cn), international ones (Cloudflare, ClouDNS, DNSPod International, HE.net, NameSilo, No-IP) and two integration targets (a callback API and a Debug provider). The audience is narrow and specific: people who run a server, NAS or container host and want the DNS record to follow the address, not people who want a hosted DNS service. The project is published under the MIT License, and the last push to the default branch was on 2026-09-22.

How the address lookup and record update fit together

The client has two halves. The first half decides what your address is. The README states it supports IPv4 and IPv6, private addresses, public addresses, a URL, a regular expression and a custom command as sources, so the value written to DNS does not have to come from an interface scan. The second half talks to the provider: it looks up the existing DNS record, and according to the README most providers can create the record when it is missing. HE.net and No-IP are named as the exceptions, which matters because those are exactly the providers a reader is most likely to reach for when migrating off router firmware. TTL and resolution line settings are configurable where the provider supports them. A local cache suppresses API calls when the address has not changed, which is the difference between a client that hits the provider's rate limits and one that does not. Configuration comes from three places with a stated precedence: command line arguments, then a JSON config file, then environment variables. A few control options exist only on the command line. Credentials differ per provider and are named API Token, Access Key or Secret depending on which one you use.

Installing NewFuture/DDNS and running a first update

Four installation paths are documented. Docker is described as recommended and aimed at NAS, servers and container platforms with multi-architecture images; the image runs an update every 5 minutes by default. A single binary from the releases page covers Windows, Linux and macOS without Python. pip is for machines that already have Python: the README gives `pip install ddns`. Source runs with `python -m ddns` after unpacking. Linux and macOS also have an install script.

curl -fsSL https://ddns.newfuture.cc/install.sh | sh

That script fetches the binary matching the current platform. Whichever route you take, the README's first step is to verify the pipeline with the Debug provider, which does not touch real DNS records:

ddns --dns=debug --ipv4=home.example.com --debug

Read the output before going further. If the address it resolved and the record name it constructed look right, move to a real provider. The project publishes a browser-based configuration tool that generates and validates config.json locally; the README states it does not call provider APIs, so credentials typed there stay in the browser. Once you have a config file, a single run looks like this:

ddns -c config.json

For a long-running setup with a local console and a sync every 5 minutes in the same process:

ddns -c config.json --interval 5 --open

Passing `--interval` switches the process into Web mode on its own. The README notes that the Web API and the `/mcp` endpoint are unauthenticated when listening on loopback without a configured token, and that any non-loopback or wildcard listener must have a shared HTTP token and should sit behind an HTTPS reverse proxy. That is a deployment decision, not a footnote.

The scheduling trap: Web interval versus a system task

There are two ways to make the client run repeatedly, and the README is explicit that they must not be combined. The first is the Web console's built-in scheduler, enabled by `--interval` or by an `interval` key at the top level of the JSON config. The second is a system task: `ddns task --install 5 -c /etc/ddns/config.json` installs a job that runs every 5 minutes, and `ddns task --status`, `--enable`, `--disable` and `--uninstall` manage it. Running both means two processes writing the same records on overlapping schedules. The README says plainly not to let the system task and the built-in scheduler run at the same time. There is a second, subtler boundary: pausing and resuming in the Web console affects only the current process, so a pause is not a durable state. If you pause the console and later restart the container, the schedule is back. Anyone treating that pause button as an off switch will be surprised.

MCP support and what it does not expose

The Web console serves an MCP Streamable HTTP endpoint at `/mcp`, and there is also a stdio server started with `ddns mcp -c /etc/ddns/config.json`. The README states the stdio service uses only the standard library, does not listen on a network port, and does not expose configuration credentials to the model. It supports MCP `2026-07-28` and is compatible with the `2025-11-25` revision used by GitHub Copilot CLI. Clients that cannot start a local process can instead run `ddns mcp -c /etc/ddns/config.json --transport http`. The intended uses are narrow and worth stating precisely: query cache state, or trigger a full sync after a human has confirmed it. This is not a general remote-control surface for your DNS. If you expose the HTTP transport, the same authentication caveat as the Web console applies, because it is the same listener.

Where NewFuture/DDNS is the wrong tool

The clearest failure case is a router or optical modem that only supports the traditional DDNS protocol. NewFuture/DDNS will not speak it. The project's own answer is a separate utility, edge-ddns-proxy, which converts those legacy updates into modern provider API calls. If you were hoping to flash nothing and change nothing, this is a two-piece deployment. The second limitation is record creation: the README states that most providers can create a missing record automatically, but HE.net and No-IP cannot, so on those two you must create the record by hand first and keep it present. Third, the MCP and Web surfaces are unauthenticated by default on loopback and require you to supply a token otherwise; a reader who exposes the Web UI to a LAN without reading that paragraph has created an open DNS-writing endpoint. Finally, the project carries Python 2.7 compatibility and a `requires-python = ">=2.7"` declaration in pyproject.toml. That is a deliberate reach decision, and it also means the codebase carries constraints a Python-3-only tool would not. If your environment is Python 3.12 or newer, nothing forces you to care, but it is a signal about how the project prioritizes compatibility.

Alternatives and the real difference in approach

The related searches around this project point at a recognizable cluster: ddns-go, qmcgaw/ddns-updater, Timothyjmiller/cloudflare-ddns, godns and Willswire's UniFi DDNS. The meaningful split is provider breadth versus depth. A Cloudflare-only client can lean on Cloudflare's API shape, its token scopes and its record semantics, and it can be small because it never has to abstract over fifteen different credential models. NewFuture/DDNS goes the other way: the README describes a provider abstraction with per-provider credentials (API Token, Access Key, Secret), HMAC-SHA256 signing for the cloud providers that require it, and a documented provider development guide under docs/dev/provider.md. If you use exactly one provider and never expect a second, a single-provider client will be simpler to reason about. If you already run DNSPod for one domain and Cloudflare for another, one client with one config file and one schedule is the smaller operational surface. The callback provider is the escape hatch: providers not on the list can be reached through a callback API rather than a new integration.

Maintenance, upgrades and the licence

The repository is not archived and the last push was on 2026-09-22, one day before this review, so the project is being worked on now. Releases are frequent and the most recent ones are betas: v4.2.1-beta3 on 2026-09-06 and v4.2.1-beta2 on 2026-08-28, with v4.2.0 on 2026-08-27 as the last stable tag. That pattern means you should pin a version rather than track latest if you run in production. The Docker image is tagged with semver, so pinning is available. Upgrade cost is low in one direction and non-trivial in another: because the runtime depends only on the Python standard library, there is no dependency resolution to redo, but the config schema is a real interface. The repository contains a schema/ directory and a browser configuration tool, and the README warns that a few control options are command-line only, so a config that works today can still need a new flag after a major bump. Read the changelog on the GitHub repository before moving between major versions. The project is MIT licensed, which permits commercial and closed-source use; the README asks that you strip real credentials from logs, issues and config examples, which is an operational hygiene point rather than a licence term. Nothing here is legal advice, and the LICENSE file in the repository is the authoritative text.

Editorial conclusion

Adopt NewFuture/DDNS if you already run a Python environment, a NAS or a container host and you want one client covering Cloudflare, DNSPod, Alibaba DNS and Huawei Cloud without a dependency tree. Do not adopt it if your router only speaks the classic DynDNS protocol and you are unwilling to run edge-ddns-proxy in front of it, and do not run the Web console and a system task at the same time. Before trusting it, run the documented debug command to confirm the address-resolution path, then check that your provider can create the record automatically: the README states HE.net and No-IP cannot.

Frequently asked questions

Official sources

1. License: MIT
2. NewFuture/DDNS on GitHub
3. Project website
4. README
5. Releases