Was reading a article how dns affect the availability of resources thus checked on which nameservers [tardigrade.io] is interestingly on Google Cloud DNS probably. My question is what if google cloud dns goes down will it affect the availability of data ?
For Storj to be pure dencentralized can’t we use all nodes as a dns resolver or any other opensource decentralized dns server
DNS is definitely a problem for the Internet…
It’s a universal problem. And there are numerous pathways being developed in various corners of the decentralized development groups to either augment or replace DNS.
DNS is hierarchical, and can continue to properly resolve names to IP addresses even if the designated nameservers for a domain drop out of “The Cloud” for awhile. A much bigger issue for DNS is spoofing… and DNSSEC is generally used to combat that problem.
If the domain is registered on NameCheap per the screenshot on the first post, DNSSEC can be enabled easily there. I have enabled that for my domains.
See https://www.namecheap.com/support/knowledgebase/subcategory/2232/dnssec/ for more information.
The key thing to be aware of is that while only 4 name servers are listed any large DNS provider will have a vast number of nodes supporting DNS resolution using simple solutions such as load balancing and more advance systems such as Anycast. The result is that the 4 published addresses will be serviced by 100’s of nodes distributed across many data centres.
DNS information is also cached as hierarchical at your machine, your ISP, their DNS provider and so on.
The real issue for Tardigrade.io is not their choice of DNS provider, by the choices made by the node providers to the storj platform. As many node providers (including myself) do not have static IP addresses provided by their ISPs they depend on DDNS (Dynamic Domain Name System) services that maintain a map between the public IP address they are using and a DNS name. If one of these providers was to fail storj could lose access to a large number of nodes for a while.
Ha, this indeed looks like a big risk to me!
yeah sounds a bit risky to me too. but they didn’t like my suggestion: Remove DynamicDNS requirement
Adds some additional programming to the node and satellites.
It’s just another business risk that storj has to manage. In part, it will be managed via holding more blocks in the system than the minimum possible and from a quick look at the source code from the fact that the resolved IP address seems to be held in the database as well as any provided DNS name. This would allow many nodes to still be accessed even if the DDNS server they use failed as there would only be an issue if the assigned IP address was to change and the satellite had to rediscover the IP address while the DDNS service used was down.
a ddns provider would have to be offline for more than a day, then all nodes in countries that change the IP daily will be gone, e.g. germany.
Short downtimes would of course hardly affect the network because the DNS will be cached by all other dns nodes.
So maybe the risk isn’t big, I don’t know how many countries/providers change their IPs daily.
I think Storj cold implement function that wold every 10 min send ip to sattelite and sattelite will hold and renew this ip during the time. This function cold be turn on/off in config, then sattelite dont need to realize domain names of nodes before sending, there always will be IP only. Also something like this will help to monitor downtime of node very fast, in 10-20 min and more posible send live node ip to client, not 4h like now.
From a quick look at the source code a satellite may not do a domain name resolution every time a node is contacted for some form of task. Without spending a lot more time reading the code which has rather limited documentation I can not be sure, I would guess a name resolution is only done if a node does not respond when the recorded IP address is used. Such a process would greatly reduce the number of DNS requests not just for the satellite, but far more importantly for Tardigrade.io client nodes.
as i know, sattelite make dns resolution when sending to client ip list to upload data, and when clien need download data. so this part will work faster.
The Storj whitepaper’s computations on the necessary availability of the nodes to achieve customer-friendly SLA do not take it into account, yet as far as I know the current practice is to follow the requirements as computed by the whitepaper. The whitepaper puts huge assumptions on the independence of node failures, and a failure of a third-party DDNS service is exactly the opposite.
