Replacing DDclient With Inadyn: Restoring Dynamic DNS Updates Reliability
ddclient troubles
Over the past 18 months, I’ve encountered a growing number of bugs with ddclient, a very popular Perl-based dynamic DNS client. There are numerous edge cases where things just break without any warning, and these issues are often challenging to debug. The codebase is extensive, filled with legacy functions that are no longer in use. This, combined with the fact that it’s written in Perl, might explain some of the problems I’ve been facing.
To add to these challenges, the owner of the project has decided to stop maintaining it. After a bit of drama on Github, it doesn’t seem like the maintainership will be transferred to anyone else. For something as critical as DNS, this lack of support is simply unacceptable in any infrastructure.
Enters inadyn.
Inadyn is a much more recent and lean client. It supports most well-known providers. It’s coded in C, which is generally more secure for this type of application due to its low-level nature and control over memory. You can check out the project here.
I recently decided to replace ddclient with inadyn, and I must say, the transition was smooth. It took me less than half an hour to get up and running, which is less than it takes to debug any ddclient config change alone!
For my setup, I used Docker and OVH as my dynamic DNS provider (they offer a free service if you register your domain with them). Below is a quick extract of my docker-compose.yml and ovh.com configuration for inadyn.
version: '3.8'
services:
inadyn:
image: troglobit/inadyn:latest
container_name: inadyn
restart: unless-stopped
volumes:
- ./inadyn.conf:/etc/inadyn.conf
deploy:
resources:
limits:
cpus: '0.5'
memory: 512m
Quick note on the deploy block: this does not appear in the inadyn documentation but block is a best practice when deploying containers, as it sets limits on the resources that the container can use.
In this case, we’re limiting the container to use only 0.5 CPU and 512MB of memory. This is not only more secure, as it prevents a single container from consuming all available resources, but it also ensures that other processes running on your machine won’t be starved of resources. This should be way more that enough (when idling, the container is using 5MB).
The inadyn.conf file is configured as follows:
period = 300
user-agent = Mozilla/5.0
provider [email protected]:1 {
username = domain.tld-username
password = password123
hostname = subdomain.domain.tld
checkip-ssl = true
checkip-server = ifconfig.me
checkip-path = /ip
}
provider [email protected]:2 {
username = domain.tld-username
password = password123
hostname = subdomain.domain.tld
checkip-ssl = true
checkip-server = ifconfig.me
checkip-path = /ip
}
If you have a single domain for any given provider, simply use provider [email protected]. If you have more than one, number them like provider [email protected]:#.
In my case, I prefer to use `ifconfig.me`` to check for the current IP, as I’m currently in a double-NAT situation until we switch back to a business broadband plan at the end of the year.
In the end
For the past month, this deployment has been rock-stable. I can’t recommend the switch enough.
If you’re having trouble with ddclient, consider giving inadyn a shot. It’s lean, efficient, and best of all, it’s reliable.
Cheers!