I wrote a little script to update the IPv4 and 6 addresses for multiple domains based on the IP addresses used by my myfritz subdomain. This script doesn’t run on your Fritz!Box, but it doesn’t have to run on your local network either.
Feel free to leave a comment here or on github.
Thanks for your great service!
All of this assumes that the FRITZ!Box (or the router in general) already has a mechanism to update
<your myfritz subdomain> A and AAAA records when its own public IPs change. And yes, the MyFRITZ service does provide a DDNS service so ok. Note that any other DDNS service configured on the FRITZ!Box will work as well, so you are not forced to use MyFRITZ for this.
For IPv4 this probably (I didn’t test) works to set the A records on the list of domains to the same public IPv4 that the FRITZ!Box has. But note that getting the current public IPv4 address can also be done by using one of several “what is my IP” services available on the Internet, e.g. https://checkipv4.dedyn.io/. So for this you don’t even need any DDNS service. Or you might be able to set a CNAME pointing to the MyFRITZ hostname.
For IPv6 your script works the same, but here this may not be what you want. Clients on the LAN will also have public IPv6 addresses — but allocated from the IPv6 LAN Prefix which is different from the public IPv6 of the FRITZ!Box itself. Normally these addresses are fairly temporary. They change often to mitigate privacy issues as well as when the IPv6 LAN prefix changes. So running an IPv6 service on a client in the LAN is not as simple as with IPv4.
Note that the IPv6 address your service is LISTENing on may be different than the IPv6 address used for new outgoing connections such as to https://checkipv6.dedyn.io/. Your LAN client usually has multiple public IPv6 addresses configured.
You have two challenges here:
- Make the service on the client LISTEN on a current valid public IPv6 address (as allocated from the IPv6 LAN prefix).
- Update DNS when the public IPv6 the service is LISTENing on changes.
If your LAN client uses SLAAC (see RFC 4862) with IPv6 SOII (see RFC 8981 and RFC 7217) addresses, which would be the common case, then it needs to monitor these to reconfigure the service and update DNS AAAA records.
If your LAN client uses stable Interface Identifiers (IIDs, the lower 64 bits of the IPv6 address), i.e. based on the interface MAC address, then it still needs to recognise when the IPv6 LAN prefix changes. This is not trivial to do.
I attempted to solve this here. But the solution still has some issues. And it is fairly specific to OpenBSD. It has been working for me most of the time though.