Dynamic DNS failure with ddclient and Namecheap
TLDR; If you are experiencing similar issues, upgrade to the latest version of ddclient or change IP-check website to something other than dynamicdns.park-your-domain.com. See Discussion.
Backstory
On the morning of 22/3 I noticed that my website was down. My first thought was maybe the power went out and my server never rebooted, but no, it was running perfectly. The next thing I checked was my domain configuration, which I’ve had issues pop up randomly with before. When I pinged my domain I noticed a very strange IP address being resolved (an address in China) [1].
$ ping joelsiks.com
PING joelsiks.com (1.0.1.1) 56(84) bytes of data.
Checking my DNS configuration on Namecheap, my domain were pointing to 1.0.1.1. This is weird because I have Dynamic DNS configuration set up so that if my IP changes, the A record of my domain is updated to reflect that change. I need this becuase I have what is known as a Dynamic IP address [2], which practically means my ISP might change my assigned IP address in the future. This prompted me to check what IP address my Dynamic DNS configuration is reporting to Namecheap.
To update the A records of my domain when/if my IP changes, I use ddclient [3], with the configuration listed below. Much of the configuration is taken from Namecheap’s documentation [4].
daemon=300
verbose=no
# Configuration for joelsiks.com
ssl=yes
use=web, web=dynamicdns.park-your-domain.com/getip
protocol=namecheap
server=dynamicdns.park-your-domain.com
login=joelsiks.com
password=<redacted>
@
The culprit
When verifying the IP addresses ddclient is reporting to Namecheap, I notice most providers return my actual IP address, but dynamicdns.park-your-domain.com returns 1.0.1.1. I’ve found the culprit!
$ sudo ddclient --query
...
use=web, web=dyndns address is 123.123.123.123
use=web, web=loopia address is 123.123.123.123
use=web, web=dynamicdns.park-your-domain.com/getip address is 1.0.1.1
The easy fix for this is just changing the IP-check provider to something else in my ddclient configuration (which might not be the best solution, see Root cause). However, I wanted to get to the bottom of this. Is this an attack? bug in ddclient? bad-acting IP-check provider?
Issue analysis
By now I know that something weird is going on with dynamicdns.park-your-domain.com. Printing the HTTP headers when sending a request shows that that the result at the bottom is my actual IP address, which is weird. However, taking a closer look at the cookie, we see that it contains 1.0.1.1, which is the IP that ddclient is reporting!
$ curl -i dynamicdns.park-your-domain.com/getip
HTTP/1.1 200 OK
Date: Sat, 22 Mar 2025 12:46:57 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
cf-cache-status: DYNAMIC
Set-Cookie: __cf_bm=f8nMdwso5HDmz4PKANz.CByubjQt5UQlcAdq4o1.MgI-1742647617-1.0.1.1-0F2I0I8lxmIruO8FAFdzN1lucW7t7y8Gno9PHDecHdmAn_VY0EVJE8z2e83kIMv1ejOWqo1dmj3dRERwbAE_jlrM_ac8_HCnjaTw2U_YfZo; path=/; expires=Sat, 22-Mar-25 13:16:57 GMT; domain=.park-your-domain.com; HttpOnly
Server: cloudflare
CF-RAY: 9245cb788d9ea867-RIX
alt-svc: h3=":443"; ma=86400
123.123.123.123
Inspecting the source code of my version of ddclient (v3.9.1) shows that it’s using regex to find the first occurrence of what looks like an IP address. The query only matches the first occurrence by using ^.*? at the beginning, which is expanded as few times as possible. Under normal circumstances, the response would only contain a single IP address, but the regex query breaks when multiple strings looking like IP addresses are in the response, as I’m experiencing right now. It’s also a bit weird to look at the response headers in addition to the body.
if ($reply =~ /^.*?\b(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\b.*/is) {
$ip = $1;
$ip = un_zero_pad($ip);
$ip = filter_local($ip) if opt('fw-banlocal', $h);
} # ...
This issue is fixed in versions >=3.10.0 of ddclient, which reads the correct IP address from the response. Version 3.10.0 was released 22 October 2022 [5], which was some time ago. Out of 120 listed repositories on repology [6], only 53 repositories provide releases >=3.10.0, making 67 repositories affected by this issue.
Root cause
The __cf_bm cookie that causes the error in the first place is set by Cloudflare if a website enabled the “bot fight” mode [7]. Changing to another IP-check provider that also uses Cloudflare might cause the same problem to appear in the future if they also enable “bot fight” mode [ferrybig on reddit, 8]
Discussion
The best solution is to upgrade to a version of ddclient >=3.10.0, or just the latest [9]. Since most repositories containing ddclient does not provide a recent enough release, you might want to download the source code of ddclient and install it yourself [9]. Another possible solution is to change IP-check provider to something other than dynamicdns.park-your-domain.com, but beware that other providers might be affected by the same issue (either now or in the future).
There is an issue on GitHub tracking the issue in ddclient for visibility [10].