Good to know.
Don’t believe I listed any illusions.
Like the issues you put below much of it would be site/service/implementation dependent.
Struggling to accept one DDNS service account is necessary for this particular use case, let alone more.
Wouldn’t be restricted to only using cloud providers, would work anywhere one can save text really, but yes some of that could be true to varying degrees depending on the service/site and implementation. Obviously if someones interested in using their google account for this purpose tor would be off the table but other services/sites might work but be less reliable. Also one service might frequently change their api another may never etc.
As far as an account being blocked by a cloud provider (absent tor) for the occasionally modification/check of a text file (essentially using it as intended), seems pretty unlikely.
If something like Déjà Dup can send backups to google drives, seems like it should be doable.
Will look in to it.
1 Like
Cloud providers are not obligated to provide a stable API or notify you about the API changes.
You won't know about the change unless you are subscribed to their developer mailing list.
You'll find out about the problem only when the service stops working, but it will be too late.
Moreover, they can easily ban you for violating the terms of service due to incorrect API usage.
Other open source projects like Déjà Dup have been able to support google drive and I don’t believe their users are frequently banned or at least one would hope they’d remove support if that were the case. As mentioned though you basically only need a text box that can retain a value, so one could envision implementations that don't use traditional cloud storage services at all. That said, are there implementations that could result in a premium DDNS service being more appropriate when accessing ones home network is mission critical, sure lots of things are possible.
Keeping the services up-to-date is not very critical for their existing use cases.
You can simply update the package if it stops working.
On the other hand, the proposed use case breaks connectivity if the issue happens.
The remote host becomes unreachable, so you cannot update the package.
This is truly unreliable and compromises the original purpose.
Depends on implementation as the proposed “package” doesn't exist. But even if it were implemented as you describe, I would still choose it over a free DDNS service and if it were mission critical to maintain access I’d just have it failover to other services I already use (or e-mail), if that wasn’t an option I’d go with a premium DDNS service.
Anyways I’m coming to terms with the fact that having the router e-mail on IP change is the closest I’m going to get to this, which is fine the IP doesn't change that often.
I don't trust the free dynamic DNS services because it's never really free or even safe and secure.
Same thing with google and the others.
The cheaper solution for the endpoint(s) would be to use a true domain with a unlimited number of sub-domains.
.ovh = 2.39$/year --> .com = 9.99$ --> .adult = 97.99$ --> etc ...
Price also depend of the name you choose for example home-network.com is available for 6800$ the first year then 11.49$ the next year.
Sometimes new extension are even free the first year.
I have two .best like that than I don't plan to renewed so there will be an automatically cancelling at the end of the free period.
When you have your domain you can create the sub-domains.
Domain :
yourdomain.ovh
Sub-domains :
home.yourdomain.ovh
remote.yourdomain.ovh
Then use the DynHost (OVH ddns) and DDNS client (routers) for updating them :
With ddns client the minimum check is every 5 minutes with for example a script like :
curl https://www.cipherdyne.org/cgi-bin/myip
to verify if your IP has changed and need to be updated.
You can also add another layer of connectivity and use the Wireguard option "Persistent Keep Alive" (clients and/or servers) who is not in minutes but in seconds 
Voilà ! 
2 Likes
A quick and dirty, Plan C, way of always being able to look up the remote router's ip address is to create an hourly cron job that does
wget http://SomeDomainICanSeeHTTPLogsFor.com/ThisIsRemoteRouterReporting
You can then see the router IP address in your logs
2 Likes
Thanks for the ideas, lots of things to try when/if I get around to it.
Also was thinking it might be possible to use fdm to fetch/filter for emails from the other router and trigger a script to modify config on receipt accordingly. Seen a post suggest the use of fetchmail and procmail for a similar purpose, seems fdm is a substitute for both.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.