DuckDNS is down for me, causing my nodes to be offline. Is anyone else experiencing issues?
Hi, it’s true. But i confirm you that the node it’s not down. When Duckdns not resolve the dns only the port UDP/QUIC is misconfigured but the node is online ever
Now that I think about it - why does the node even need a DDNS? The satellite knows the IP address of the node already and I’m sure the node periodically checks in with the satellite so the satellite can update it. The satellite needs to know the port, but I think that the situations when the external IP of outgoing connections is different from the external IP for incoming connections are extremely rare (or maybe if the IP changes while the node is running it may be a bit better)
3 Likes
It really would be awesome not to need a DynDNS service!
3 Likes
Needs a DDNS to update a non static IP and the sats cache the old public IP till the ddns has updated it. At least ive seen it from experience when changing my public IP it would still see the old IP until it has updated.
3 Likes
Wait, so if DuckDNS goes down, my node will continue running just fine?
The system will rely on the most recently cached IP if it can’t resolve the DNS.
You could, in theory, write some kind of script that checked your external IP and then restarted your node and changed the external address setting. That would avoid the need for a dynamic DNS provider. But, with file walker checking the node after every restart, it is likely not ideal unless your IP changes are few and far between.
3 Likes
It works correctly, and as other users have written in other posts, the node sees the external ip and not the dns. Also because the dns has only ip cached that communicates to whom it serves, but within it the Storj data flow does not pass but it happens directly from the customers to your node.
1 Like
Doesn’t sound great because of the file walker indeed…
Unless it would be built-in in the node software itself so it doesn’t have to restart I guess!
… I know what you’re gonna tell me: Pull requests welcome! 
2 Likes
I guess i’m gonna ask the 1302 day question why doesn’t the node check what it’s ip is an update it accordingly without having to restart the node to change it? We got an auto updater now why not an auto ip updater? That’s really what everyone needs these days right? One less thing a SNO has to worry about when maintaining his/hers storagenode makes sense more now then ever since we’re really in production mode now.
Especially now since we depend on ddns to rely our ips to be stable enough for the network i see more an more people complaining about it.
Just need an option to enable it since some have static ips an some don’t. We need a stable network not people getting suspended cause of a bad ddns provider’s.
2 Likes
I believe you know the answer. If not
However, it don’t so simple to acomplish as it may look. Not all nodes uses the same IP for outgoing and incoming connections. The storagenode itself should not act as a DDNS service, it’s not its purpose. However, I have to agree, that the satellite could cache the contacted IP as an external address of the node which is checked-in right now. In most cases it should be the same as a contact address (not all of course, but I guess 90%).
1 Like
Maybe Storj should offer their own DDNS, built into the storagenode Docker container?
I’m against inserting any system tools to the storagenode binary, it’s not its purpose. Storagenode should store and provide data on request, not trying to replace OS or DDNS, or whatever. It should do only one function and do it well - serve storage.
Regarding DDNS client you can only update the DDNS hostname with a new IP address, but you also need a DNS server somewhere, which will handle your DDNS domain. I think no-ip is good for that, no need to reinvent a wheel.
You may also containerize the DDNS client and run storagenode and DDNS client as containers with docker compose.
2 Likes
My view is that the connection between nodes and satellites is a core functionality that should not rely on some 3rd party. It should work wether or not some DDNS provider goes down.
1 Like
Yes, I think so
The only problem I see here, is for nodes uses different IP for incoming connections than IP for outgoing.
And I think it could be solved by providing an exact contact address with port, but by default it could be 0.0.0.0:node_port or :node_port (we still need to provide a contact port to the satellites).
I see it from my personal situation where my ISP force-disconnects the internet every 24 hours and re-assigns a new IP. This is really common in Germany and not some unique edge case here. This should be fully handled by the storagenode software without the need of any 3rd party.
It’s a server part, not a client part. But it handles - you may update your contact address with a new IP and restart the node, which is less convenient than updating a cache on the satellite during check-in.
However, my suggestion actually is not better too. The check-in is happening every hour, but your ISP may update IP right after the check-in, so your node would be considered as offline for the next hour…
So right now the independent globally available address and its updater looks better.
The node could keep tab of the average time between each interaction with clients, as they are very frequent (for instance: a request every 10s in average). And as soon as activity stops (e.g. 100s without activity), it should look suspicious and the Node could contact satellites to check whether its IP address changed.
This would probably be better than checking it on a regular timer (like once per hour).
Just my 2 cts ^^
2 Likes
This sounds like a good idea. Removing the need for DDNS would be huge.
It can be both: the satellite can keep last known address for a node to send to customers, from last check-in. Each node can monitor its external IP and check-in with the satellite as soon as it changes.
Satellite will just need to keep database of nodeID to IP mappings, unless it does already, and node software will need to allow to override the IP auto-detection to support nontrivial routing scenarios.
Seems easy to add, albeit it will replicate the existing functionality of third party DDNS services, which is bad. On the other hand, since we know users will keep using crappy DDNS providers, there really are two choices:
- one is to educate users and have them rationally pick good solution, preserving good design of separating storage and networking at the expense of reliability, because we know users will keep using free solutions because “ddns is ddns, why should I pay for it when free one works just fine (most of the time, and with 2sec latency).
- and the other: sigh, and reimplement “DDNS” inside the satellite. It will be uglier, but will improve reliability by removing a whole realm of potential screwups
The latter option also may help with ipv6 transition, as the satellite will be made aware of nodes networking situation directly and can optimize a bunch of stuff. Maybe implementing something like a mesh network between “unreachable” geographically close nodes, etc.
3 Likes