ArDNSPod: a dynamic DNS client written entirely in shell

What the tool is, and how small it is

ArDNSPod is described as a pure shell dynamic domain client built on the DNSPod user API, and the repository shows how little that means in practice. The top level contains four files of consequence, the `ardnspod` script itself, `ddnspod.sh` which is the configured wrapper around it, a `ddnspod.bat` file for Windows, and the README. There is no package manifest, no build step, no runtime and no service unit. The tool is a loop that looks up your current public address, finds the record that should carry it, and updates it through the DNSPod API, which means the deployment model is a cron entry on a box that already exists, which is exactly the situation dynamic DNS is for. The project describes itself as ArDNSPod, the name of the script, and the homepage points at a blog post explaining the approach. The repository also credits co-maintainers through the contributors graph, which is a reasonable convention for a project that started as one person's script.

Finding the public address, and the difference between IPv4 and IPv6

The address detection is where the interesting engineering lives, and the README describes two different strategies. For IPv4 the script prefers the address of the network interface, and if it cannot obtain a valid public address it fetches the address from a third party interface, and if that still fails it uses the DNSPod interface to auto update. For IPv6 the script also prefers the network interface address, falls back to a third party interface if it cannot get a valid public address, and exits if that fails as well. The difference in the final step is not arbitrary. The 2022 changelog entry explains it, saying that getting the IPv6 address locally is too difficult and the error rate is too high, so it changed to fetching the address from an external interface directly, while for IPv4 the local attempt is tried first. The third party address service is a separate project of the same author, a Docker based geoip API, and the README links its source, so you can run it yourself if you would rather not hand your address to a public service. There is also a note that the official DDNS interface now supports setting IPv6, and that a `v6.1` branch exists for compatibility problems.

Setting it up, and what a successful run looks like

The configuration is a matter of editing three values in `ddnspod.sh`, the path to the `ardnspod` script, the API token called `arToken`, and the record to watch called `arDdnsCheck`. Then you run `ddnspod.sh`, which starts the loop that keeps updating, and the README recommends adding the script to a scheduled task so it keeps running after a reboot. A successful run prints its work, and the example output shows the shape of it, starting with a line naming the host being checked, then the address fetch with a result of Auto, the record type as A, the record id it found, and finally the update call with the new address.

=== Check test.rehi.org ===
Fetching Host Ip
> Host Ip: Auto
> Record Type: A
Fetching RecordId
> Record Id: 998534425
Updating Record value
> arDdnsUpdate - 1.2.3.4

Two details in that output are worth noting. The address came back as Auto, which is the script telling you it did not get a usable local address and fell through to the automatic path, so the output is also a diagnostic. And the record id is resolved before the update, which is the subject of one of the older bug fixes.

The single file mode, for people who do not want a wrapper

There is a second way to run the tool that removes a file from the picture. The README notes that if you need to run it as a single file, you take the configuration items from `ddnspod.sh` and append them to the bottom of `ardnspod`, after which you can run `ardnspod` directly. The configuration format is plain lines appended to the script, which means the credentials end up inside the executable rather than in a separate file that might be shared.

echo "arToken=12345,7676f344eaeaea9074c123451234512d" >> ./ardnspod
echo "arDdnsCheck test.org subdomain" >> ./ardnspod

That format is worth understanding, because it is the whole configuration grammar. The token line carries the API identifier and the token value as a comma separated pair, and the check line carries the domain and the subdomain to update. The convention of appending configuration to the end of a script is old and it works, but it means the token lives in a file that is also the program, so if you copy that file around or commit it, you copy the credential. The wrapper file exists precisely to keep those two things apart, and the 2016 changelog entry that added a configuration file says the point was to separate the script from the configuration and to adapt to internal networks.

The changelog as a history of shell scripting constraints

The recent updates section is dated back to 2011 and it reads like a log of things that broke. In 2025 the project added support for deleting records to make management easier, and support for creating a record when it does not exist. In 2023 it started caching the local address by record id, and it fixed a bug where passing an `@` as the subdomain produced a wildcard result that made the update fail. In 2022 it added the ability to specify a network interface and added an `arRequest` method that wraps curl and wget. In 2021 it improved the validation of the address result and added IPv6 support, and it began preferring the IPv6 address with the longest remaining time. In 2020 it fixed a wrong record id lookup, adapted to the new API of late 2019, made the script fall back to curl when wget is missing, and replaced a `readlink` based path lookup with a manually set path because readlink was unreliable. The 2016 entries show the portability work, with the sed scripts being made POSIX compliant to support Mac and most Linux distributions, plus a separate configuration file and Mac support. The 2015 entry added token authentication, and the 2013 entry records the stable release and the inclusion in the official plugin list.

What it depends on, and where it stands now

The runtime requirements are modest and worth listing because they are the whole footprint. You need a POSIX shell, and either wget or curl, since the 2020 change added a curl fallback for systems without wget. You need the ability to read the network interface address, and the 2022 addition of an explicit interface option exists for the cases where the default guess is wrong. You need a DNSPod API token, which is the only credential in play, and the token has to carry permission to update the records you intend it to update. The 2020 entry that stopped using `readlink` is the clearest warning about the design, since it means the path to the script is something you set rather than something the script works out. On the state of the project, the newest tags are v6.5.0 from 2025-02-24 and v6.5.1 from 2025-11-25, while the last push was on 2026-10-13, so the script is being maintained without a release cadence, and the licence is one that GitHub cannot classify, which is worth checking before you redistribute it.

Editorial conclusion

Adopt ArDNSPod if you run a home server or a router without a dynamic DNS client and you want to point a DNSPod record at a changing address, since the whole thing is a shell script and a cron entry rather than a daemon to supervise. Do not adopt it if your host has a native DDNS client, and do not expect it to manage more than a handful of records, since the design is a loop that checks and updates one record at a time. Before you use it, read the IPv4 and IPv6 notes carefully, because the IPv4 path falls back through a third party address API and then to the DNSPod interface, while the IPv6 path exits if it cannot get a valid address, and the README also points to a `v6.1` branch if the official DDNS interface has compatibility problems. Also read the token permissions, since the API token is the whole of your authentication. The licence is not one GitHub can classify, the last push was on 2026-10-13, and the newest tag is v6.5.1 from 2025-11-25.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. rehiy/dnspod-shell on GitHub
5. Releases