It does - but it will catch the address change only after the next time it's scheduled to run (once every 10 minutes).
The service I run isn't "sensitive to IP changes" - I just want to be able to reach my home network whenever and from wherever I want, without wondering whether the address changed recently without the DNS record being updated fast enough.
Just curious (because it matters), what is the public TTL on the A (or AAAA) Record in question (600 or less)?
Have you been testing the change by doing an nslookup directly to the provider's DNS server?
nslookup example.com <IPorHost_of_provider_DNS>
Wow, your IP must change a lot and quite often.
To be clear, yes - I do this quite often. Generally, DDNS providers suggest the public TTL be 300 (5 minutes) anyway. So lowering your check interval closer there could help. If you need your checking or updating to be faster than 5 minutes, you may want to consider other options, aside from lowering TTL below 300 (not suggested).
If you're concerned about 10 minutes, I'm not sure 5 is satisfactory?
Until I read this thread, I honestly considered 10 minutes excellent.
Maybe I'm overthinking it, but at my job I'm responsible for making systems as close to 100% available as possible, and the thought that the information about an address change is available to the system (a process has just configured the interface with it) and not passed down the chain to where it will be useful until some reparative task that checks every X minutes discovers it annoys me.
I’d avoid editing /etc/hotplug.d/iface/95-ddns directly, because a package upgrade can overwrite it. A small separate hotplug script for just your WAN interface is safer: on ifup/ifupdate, check $INTERFACE = wan, then call the documented manual update for your DDNS service. Add a simple lock/debounce too, because hotplug events can fire more than once. That keeps the normal 10 minute check as a fallback, but gives you the immediate update path when netifd actually reports a change.
This is my /etc/udhcpc.user script (called on DHCP events, like when your WAN gets an IP assigned) which then calls another script to update DDNS:
#!/bin/sh
# shellcheck disable=SC2154
if [ "$INTERFACE" = "wan" ]; then
ip="$J_T5_source"
if [ "$ip" != "$(cat /tmp/ddclient_ip 2>/dev/null)" ]; then
echo "$ip" > /tmp/ddclient_ip
/usr/bin/logger -t 'dyndns_cf' "$INTERFACE - $interface - $ip"
/usr/sbin/dyndns_cf "$ip"
fi
fi
exit 0
The ip address will be passed as "$1" into the script you use (instead of /usr/bin/dyndns_cf). As long as you dyndns update script is sound, this should work well.
Wiki currently suggests creating scripts inside of /etc/udhcpc.user.d/ but mine still gets called inside of /etc/ as well.
It will get triggered (even if your IP hadn't changed) on boot, because it stores previous IP in RAM, not persistent storage, you can change that if you're not concerned about flash wear.
Interesting. At my job, I tend to have to explain to stakeholders that don't have a technical background, that when doing changes like altering a public A record - to expect at least 5-10 minutes (or 9 mim 59 secs) of downtime or inaccessibility. This is after making sure the A record's TTL is already configured for 300 seconds.
Then they want to know why that change and waiting period is necessary before the former is undertaken. I definitely understand.
Then the best option would be to have a VPS and terminate all your incoming connections there and then via a tunnel to your other side.
You could even do dynamic routing via two different Internet uplinks.... Regarding to trying to do 100 % HA with a budget on a shoestring and bubble gum.
