The following applies to a RED interface using DHCP.
Currently DDNS Updater polls once every five minutes (from fcrontab) for a change in public IP:
# Update dynamic DNS records every five minutes.
*/5 * * * * [ -f "/var/ipfire/red/active" ] && /usr/bin/ddns update-all
Currently I’m not using DDNS Updater; I’m using my own shell scripts.
Rather than polling I let dhcpcd do the work with the following dhcpcd.exit-hook script in /var/ipfire/dhcpc:
# dhcpcd.exit-hook -- included by dhcpcd-run-hooks
if [ \( "$reason" = "BOUND" \) -o \( "$reason" = "RENEW" \) -o \( "$reason" = "REBIND" \) ]; then
/usr/local/bin/ipcheck.sh $new_ip_address >/dev/null 2>&1
fi
NOTE: ipcheck.sh is one of my scripts, not a part of IPFire.
While I haven’t tried it I see no reason why the same can’t be done with DDNS Updater by changing the exit hook command to:
/usr/bin/ddns update-all
Coming from a dhcpcd BOUND or RENEW or REBIND it shouldn’t be necessary to check that the red interface is active.
NOTE: Ignore the dhcpcd-run-hooks documentation RE location of hook scripts; on IPFire they are in /var/ipfire/dhcpc and /var/ipfire/dhcpc/dhcpcd-hooks.
NOTE: If you do this be sure to comment out the “/usr/bin/ddns update-all” entry in fcrontab.
For RED being a DHCP connection, you’re right.
But for all other connection types, this isn’t true. “ddns update-all” must be called at all locations, where the IP of red0 is altered if this is possible at all.
I guess you are correct. I wasn’t thinking of PPP. I don’t know how RED gets its IP on PPP. Of course, if the connection type is ‘static’ we wouldn’t need DDNS Updater anyway.
I’ll edit my post to indicate that it applies only to RED being a DHCP connection.
The static case is even more complex. There are possibly several places where the IP can be changed.
Thus it is best to check the red IP periodically, this is done by fcron.
You may not realize it, but you are redefining the word ‘static’ and contradicting yourself here (“fixed”, “change at any time”).
A static IP is most definitely not subject to change at any time. A static IP does not require dynamic DNS. An IP that stays the same for years but is subject to change at any time is a dynamic IP: “almost static” is still dynamic.
In two of your three examples the IP change is initiated by the user. Dynamic DNS is not required there: the user simply updates his static DNS at the time he makes the change. In your third example any ISP that changes a customer’s static IP is in breach of contract.
There is no case for handling change of a static IP because “change of a static IP” is an oxymoron. By definition a static IP does not change. That is not to be confused with cases such as a user giving up a static IP (e.g., by changing ISP), losing a static IP if he stops paying for it, etc.
My examples are based on the common use of ‘static IPs’. These IPs are fixed because of reasons outside the IPFire system:
a device that requests a special IP
the choice of the IP(s) by the ISP for contracts with fixed IP(s), A change of this allocation can be within the contract, if it is announced early enough.
allocation of a certain IP in the system (modem/router, IPFire)
All this are topics in the system ( WAN, access device, IPFire, local network(s) ) which are not managed by IPFire. Therefore IPFire is forced to check this parameter periodically. A period of 5 minutes IMO is a good compromise between reaction just in time and system load.
Just to bring some light dark: even when the RED IP address is static, ddns needs to be called regularly.
There are two reasons:
IPFire could be behind a (CG)NAT. Then it won’t know it’s public IP address and it might change which needs to update the dynamic DNS entry.
Dynamic DNS providers need the entry to be refreshed about every 30 days. If that doesn’t happen, they will delete it. ddns keeps track if this and refreshed entries even when the public IP address hasn’t changed.
I hadn’t thought of that. I can further restrict the application of this to the case where RED uses DHCP and the RED IP is the public IP. I think this will cover the majority of IPFire users.
I think this can be taken care of by running ddns from fcron monthly, or perhaps semi-monthly (instead of every five minutes).
If you don’t see a problem with what I have just proposed I’d like to make these changes to my first post, but it seems that posts more than 24 hours old cannot be edited. Suggestion?
You can of course customise your own system as much as you want, but it won’t be sufficient to only check once a month, or once a fortnight. The reason behind that is that dynamic DNS providers are not very stable, they are offline for quite a bit. If an update was unsuccessful we will need to try again.
I do not even understand what the problem here is in the first place. Is it bothering you that there is a cronjob that is not doing anything useful on your system? You will have 20 more of those…
In the case where RED uses DHCP and the RED IP is the public IP, there is an opportunity to replace frequent (every five minutes) polling with an event driven solution facilitated by dhcpcd. Event driven software is preferable to polling software.
If ddns were relieved of the responsibility of detecting a change in public IP, how often do you think ddns should be run?
If you were able to know when the public IP address has changed, then you would only need to call it exactly that many times. Unfortunately that is not possible.
If you can be sure that this won’t affect you, and you can be sure that updates are always 100% successful, then you won’t need the cron job.
But how often do you think ddns should be run in order to 1) deal with failed updates and 2) refresh unchanged dynamic DNS every N (typically 30) days? Once a day? More often than that?
If something goes wrong, you want the update to succeed as soon as possible. VPN connections and other things depend on it. That is why it is running so often.
OK, you have convinced me that ddns should be run every 5 minutes in order to repeat a failed update promptly.
My shell script alternative to ddns sends an email notification that includes the update result(s). Currently I need to deal with a failed update manually, by rerunning one of the scripts. I’ll think about doing retries in the script.
I need the email notification anyway, as I need to update the authorized IP at a couple of VoIP providers. This requires logging in to their user portals and can’t be automated. Fortunately my public IP almost never changes, unless I do something (like changing a NIC) to change it.
The point of this thread was to prevent having to run ddns frequently (every five minutes). It turns out that there is a good reason to run ddns every five minutes.
I suggest that you NOT make the changes in the first post of this thread.
I am placing this notice here because the first post is no longer editable.