I use dietpi-ddns, but it bothers me, that it unnecessarily updates the IP address, although it hasn’t changed. Some DynDNS providers even limit the allowed updates per day.
I suggest to make a checkup before, whether the IP has changed since last update.
Below is an extended version of /var/lib/dietpi/dietpi-ddns/update.sh which uses upnpc from http://miniupnp.free.fr/ (apt install miniupnpc). To check for external ip you can use the command external-ip, which should be quite universal for all upnp routers. However, I use a fritz.box-specific command in line 2 to make the script faster. Another way without upnpc would be to use an external provider to check for the current external IP. But I wanted to limit the internet access and need for external services to a minimum.
So, here’s my productive script. Maybe it can be taken as an inspiration to extent dietpi-ddns.
#!/bin/bash
lastipfile="/var/tmp/extip"
extip=$(upnpc -u http://fritz.box:49000/igddesc.xml -s | sed -n -e 's/^ExternalIPAddress = \([0-9.]*\)$/\1/p')
lastip=$(cat "$lastipfile" 2>/dev/null) || lastip="0.0.0.0"
[ "$lastip" == "$extip" ] || \
curl -4 -sSfL -u 'user:pass' 'host' 2>&1 > /dev/null | logger -t dietpi-ddns -p 3 && \
echo "$extip" > "$lastipfile"
Yes, our DDNS is updating the IP regardless of IP has been changed. A limitation we are aware of.
@MichaIng FYI
That’s why I put it into requests, not into troubleshooting. 
I’d appreciate if it would be considered to be refined, I have hoped to make it easier with my workaround / local solution.
Since IMO UPnP is a security issue, I have and recommend to everyone to disable it in router settings, we’d go with an external provider. Luckily we have our own + a function for it:
declare -F G_GET_WAN_IP
G_GET_WAN_IP
We didn’t implement it yet since from client perspective the IP check and the DDNS update are both simple tiny HTTPS requests. So doing the update itself does not cause more load then doing the check, i.e. the check actually adds additional load if the IP does differ.
DDNS providers limiting requests to something lower than 1 per minute is rare I think? At least none of the ones we implemented as hardcoded options has a limited anywhere near that strict.
But if it is more common, we can add the check as option of course.
Ah, and UPnP could be theoretically added as well as an option for the check. I remember we thought once to allow entering a custom command to retrieve the public IP, since there may be other options depending on network/router.
There are provider who limit daily updates down to 50 or 60 like ddnss.de
Best would be to verify current DDNS IP using a DNS request and to option actual external IP using G_GET_WAN_IP. Challange might be so check for IPv4/6 individually.
In my home i have using bash script by comparing old ip (saved in file) address with new ip address from cloudflare with if condition
dig +short txt ch whoami.cloudflare @1.0.0.1 | awk -F'"' '{ print $2}'
so as per Michalng advice
the local command give same result as this time cloudflare give to me.
G_GET_WAN_IP | awk '{print $1}'
this variable (G_GET_WAN_IP) always give me present WAN address at the time of event fire.
is this bash file based on above given bash file, good for dietpi & duckdns specific DDNS provider
#!/bin/bash
lastipfile="/var/tmp/extip"
extip=G_GET_WAN_IP | awk '{print $1}'
lastip=$(cat "$lastipfile" 2>/dev/null) || lastip="0.0.0.0"
[ "$lastip" == "$extip" ] || \
echo url="https://www.duckdns.org/update?domains=XXX&token=AAABBBCCCDDDip=" | curl -k -o ~/duckdns/duck.log -K - \
echo "$extip" > "$lastipfile"
please suggest me if i am somewhere wrong in this regard. thanks
I see the point that requesting external DNS ist not much more than updating regardless. Still there’s the problem of limits by some providers, and the unnecessaryty, see below.
That’s why I’d like to encourage implementing the upnp option too. Maybe to choose from, external DNS or upnp. You CAN make upnp safe, so there’s no need to discriminate this in general. People are responsible for their own systems, and if they use upnp for any specific reason, let them. Me, I see questing external providers for my own IP an issue too. Security-wise, reliability-wise and data-protection-wise. In general, I don’t want to use external stuff when not principally necessary. And one provider (dyndns) to connect to is better than two (DNS + dyndns). So, there is pari-pari between “we recommend not using upnp” or “we recommend not using unnecessary external connections”. Let the system administrator choose, that’s HIS responsibility and the decision is strongly bound to his side conditions, skills and use case. Nothing that a developer can decide on his side.
Another idea: use any existing service that has the external IP already for it’s own purpose? Pihole comes to my mind. Problem: not everyone has it installed. Any other?
Pi-hole has the public IP stored? I never new that, how to access it?
I don’t know, was just a blind guess, i’d think he needs it for it’s function? Maybe there’s something else already on the system? But anyway, we couldn’t make sure that it is up to date. So, maybe it was a bad idea.
PiHole don’t have such a feature. And we should not depend on such a service or a router functionality as we don’t know what has been installed and what is available inside network. We have quite a lot of user who even don’t know what features their router even have.
Therefore I would suggest to do a DNS request to verify current IP stored upstream and compare it with the actual external IP. If the are different, update DDNS.
No PiHole don’t need such information.
@Joulinar there’s no either-or in my suggestion. Usage of upnp has advantages and should be an option for the user. Btw. the upnp scheme tells what services the router provides and how to access them. And that’s all already implemented in the command external-ip: figuring out the features of the router and access them. If it fails, fall back to external service or vice versa, but let the user choose.