A DDNS service ties those IP addresses to a particular e-mail address and router, whilst indicating probable port forwarding. Though some of the same could be said of goolge or dropbox, to many people those are essential and would be used either way... Also not sure many free DDNS services have comparably robustness.
I'm not sure it does any of those things. It ties a domain name to an IP address, but (to a third party) it doesn't disclose any email or router details. Nor does it indicate port forwarding and, even if it did, it doesn't indicate what ports might be forwarded.
Anything with a public IP address is going to get scanned just by virtue of being connected to the internet. Having a domain name pointed at the IP address doesn't make this any more likely.
I'm not entirely sure what you mean by robustness here. Are you talking security? Uptime? Something else?
Anyway, I'm pretty sure the most popular DDNS services are on par with the likes of google and dropbox for security and uptime. I've certainly had no concerns while using cloudflare for my DDNS.
4 Likes
I’m not suggesting they would necessarily do that on purpose, just that murphy's law may apply if the data is there/collected.
Many people use a DDNS service in combination with port forwarding, so would assume concentration would be higher among DDNS users.
In regards to robustness, with respect to most free ddns services probably yes all of the above security/uptime... for instance I think it was google’s project zero that helped discover Cloudbleed, Heartbleed, Meltdown and Spectre etc.
Wasn’t aware of cloudflare’s free ddns service, will have to look into it.
Concentration would be higher than what? Users with static DNS? Users with no DNS? Also, I don't think people trying to find exploitable devices are trawling through DDNS records to find suitable targets. They'll just scan the address space and see what they find. The DNS record is irrelevant.
4 Likes
Concentration verses trying to find addresses in address space to exploit but you may be right. Either way generally prefer not making/managing another account and needing to trust another service, not really knowing how it maybe exploited (even if that only means my email leaks or something)... particularly if there were an alternative.
Doable, but not necessarily more secure.
Following all the discussion, both way on linking the remote devices have their advantage and disadvantage.
Disad. Private VOIP communication downtime in an issue with ddns compared to your illustration where it can be reduced.
Adv. ddns service are cheaply to freely available
the list is long, to cut short just evaluate your needs, plan and do accordingly.
With wireguard you dont need to have port forward.
2 Likes
fewer services, smaller attack surface (e.g. google account vs google account + DDNS account).
Seems like reason enough.
Fair point but would also be true of the “package” illustrated.
Fair point but seems like there would be a lot of reliable places to put a chunk of encrypted text.
Positives vs DDNS
- No outages because someone decided to stage a malware campaign via your DDNS service.
- Potential benefits for people who use services like VOIP.
- Fewer accounts to manage and to target.
I have done something similar with pastebin,Dropbox,Google drive. They all give you a dynamic link and you will need a static URL resolver. Maybe you can use ddns but obfuscate the octet
- Potential to route IP checks & updates through Tor.
@someeeguy, welcome to the community!
You can make a Tor service.
(there's a similar thread like this somewhere) - Tor acting like DynDNS replacement
1 Like
You overestimate illusory benefits and underestimate possible issues.
Nobody prevents you from using more than one DDNS service at the same time.
Meanwhile, cloud providers can change the API, restrict external access or block the account.
1 Like
It is in any case a lot of fun to build something like this.
May be worth ALSO playing with DDNS. I have quite enjoyed https://www.duckdns.org/why.jsp Super simple to use, with just single line in a regular cron job
1 Like
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.