Sounds like BitTorrent DHT, but for DNS. Is that the right take?
Close enough. I think its stored in a block chain though rather than just a p2p bittorrent network.
Decentralized DNS with the Handshake Naming System
41–50 of 75 posts
Re: Decentralized DNS with the Handshake Naming System
#42The article and Namebase faq go into some details, but just so I understand, what are the practical effects of this beyond decentralization? - If I buy a TLD, will I own it in perpetuity, even after I die? - If we're encouraging people to register their own TLDs, won't we run into the same limited-name/squatter problems as normal domains? I get that names are being released at a trickle, but that seems like it would…
I work at Namebase.The other comments address most of your questions, but just to add on: the 52 week rollout will help significantly with preventing squatters. Handshake has designed some other mechanisms that prevent squatting. The first is that the Alexa top 100k domains have been pre-registered (only facebook.com can register .facebook on Handshake). This ensures that existing domain stakeholders can transition t…
Hey! So, I thought this was cool and wanted to try it out.
Compiled hnsd and tried to run it on local machine and an ec2 spot instance but it keeps failing to connect to it's (hardcoded?) peers.
I keep seeing this,
peer 354 (172.104.177.177:13038): failed connecting: connection refused peer 354 (172.104.177.177:13038): closing peer peer 354 (172.104.177.177:13038): closed peer peer 355 (139.162.183.168:13038): failed connecting: connection refused peer 355 (139.162.183.168:13038): closing peer peer 355 (139.162.183.168:13038): closed peer peer 353 (172.104.214.189:13038): failed connecting: connection refused peer 353 (172.104.214.189:13038): closing peer peer 353 (172.104.214.189:13038): closed peer peer 352 (173.255.209.126:13038): failed connecting: connection refused peer 352 (173.255.209.126:13038): closing peer peer 352 (173.255.209.126:13038): closed peer peer 357 (172.104.177.177:13038): failed connecting: connection refused peer 357 (172.104.177.177:13038): closing peer peer 357 (172.104.177.177:13038): closed peer peer 359 (139.162.183.168:13038): failed connecting: connection refused peer 359 (139.162.183.168:13038): closing peer peer 359 (139.162.183.168:13038): closed peer peer 358 (172.104.214.189:13038): failed connecting: connection refused peer 358 (172.104.214.189:13038): closing peer peer 358 (172.104.214.189:13038): closed peer peer 356 (173.255.209.126:13038): failed connecting: connection refused peer 356 (173.255.209.126:13038): closing peer peer 356 (173.255.209.126:13038): closed peer peer 363 (172.104.177.177:13038): failed connecting: connection refused peer 363 (172.104.177.177:13038): closing peer peer 363 (172.104.177.177:13038): closed peer peer 361 (139.162.183.168:13038): failed connecting: connection refused peer 361 (139.162.183.168:13038): closing peer peer 361 (139.162.183.168:13038): closed peer peer 362 (172.104.214.189:13038): failed connecting: connection refused peer 362 (172.104.214.189:13038): closing peer peer 362 (172.104.214.189:13038): closed peer peer 360 (173.255.209.126:13038): failed connecting: connection refused peer 360 (173.255.209.126:13038): closing peer peer 360 (173.255.209.126:13038): closed peer
Also, These IP address are either blocking ICMP ping messages or outright unreachable because ping fails to talk to them.
Re: Decentralized DNS with the Handshake Naming System
#43Earlier quoted context omitted.
> The DNS ROOT becomes controlled by the people instead of ICANN - it’s the end of ceased and censored domains. Good luck with that. If there is no way to have a US court take ownership of a domain (or force someone to handover a bad faith registration), someone will either end up in jail for contempt, or it will just be banned. > Additionally, HNS also fixes the problems the CA system has today. CAs can generate cer…
But you first have to figure out who to put in jail for contempt and in order to ban it you'll have to take down the entire block chain. I'm not totally sure how this one works but with ENS there are key holders that theoretically have the ability to do operations on any entry but it takes a certain number of them to all coordinate and agree.
Right, so you threaten all of them with jail until they hand over the keys to a US Court to continue to do the takedowns for copyright enforcement / ISIS website / scam site pretending to be Amazon / the new Silk Road / $reason.
We have seen this before, where people who run these services are personally held in contempt until they comply with the order.
Re: Decentralized DNS with the Handshake Naming System
#44Earlier quoted context omitted.
I work at Namebase. Handshake is compatible with ENS actually because Handshake has reserved .eth for ENS names. Since Handshake decentralizes the top-level namespace, Handshake can serve as a gateway to other naming systems like ENS and Namecoin.
Um, please tell me more :) It can do that or it does do that? Also, ENS doesn't typically resolve to an IP but instead a swarm hash or a block address, what would end up resolving in those cases?
The way the the ENS integration would work is the DNS request for vitalik.eth would end up at a Handshake Authoritative Name Server and then there are certain blacklisted top level domains (.onion, .tor, .i2p, .bit and a few others) where a client for that protocol is instantiated and then a request is sent out to the appropriate system and then the response would be formatted into a DNS query by the Handshake Name Server and sent back to the client.
Not implemented yet, but this is where one would implement it https://github.com/handshake-org/hsd/blob/master/lib/dns/ser... https://github.com/handshake-org/hnsd/blob/master/src/ns.c#L...
Re: Decentralized DNS with the Handshake Naming System
#45Earlier quoted context omitted.
> The DNS ROOT becomes controlled by the people instead of ICANN - it’s the end of ceased and censored domains. Good luck with that. If there is no way to have a US court take ownership of a domain (or force someone to handover a bad faith registration), someone will either end up in jail for contempt, or it will just be banned. > Additionally, HNS also fixes the problems the CA system has today. CAs can generate cer…
> Good luck with that. If there is no way to have a US court take ownership of a domain (or force someone to handover a bad faith registration), someone will either end up in jail for contempt, or it will just be banned. This same argument applies to bitcoin and it has not (yet) been banned in much of the free world.
We don't see them trying to change anything on the chain with bitcoin - just trace people (and law enforcement has gotten pretty good at that to be fair). They seize wallets from people they arrest, like normal cash / assets, or get a court order to get companies holding the coin to hand them over, if the accused used a hosted wallet.
Re: Decentralized DNS with the Handshake Naming System
#46Earlier quoted context omitted.
I work at Namebase.The other comments address most of your questions, but just to add on: the 52 week rollout will help significantly with preventing squatters. Handshake has designed some other mechanisms that prevent squatting. The first is that the Alexa top 100k domains have been pre-registered (only facebook.com can register .facebook on Handshake). This ensures that existing domain stakeholders can transition t…
Hey! So, I thought this was cool and wanted to try it out. Compiled hnsd and tried to run it on local machine and an ec2 spot instance but it keeps failing to connect to it's (hardcoded?) peers. I keep seeing this, peer 354 (172.104.177.177:13038): failed connecting: connection refused peer 354 (172.104.177.177:13038): closing peer peer 354 (172.104.177.177:13038): closed peer peer 355 (139.162.183.168:13038): failed…
Unfortunately the seeder peers aren't up right now, see here for a fresh peers list
Re: Decentralized DNS with the Handshake Naming System
#47Yeah, because I want to have to mine a token every time I update my DNS settings. -_- I get the "global, transparent, append only log" appeal, but for the reality of most people, I don't want to rely on a blockchain converging, or processing my update in a certain amount of time. And that doesn't even cover companies (I don't agree with this, but it is a reality), that consider DNS entries private, and don't want to…
You don't do the mining, you pay a small fee to have others do the mining. By small I mean it costs me about $0.004 USD worth of eth to update my ENS domains. A pretty small price to pay for the superior features. For private info perhaps DNS will continue to work just fine for companies. Theoretically you can also host private block-chains and use that if you really wanted to.
> A pretty small price to pay for the superior features.
I am still trying to figure out what superior features these are, even for me as a small sites.
For certs, I can have Lets Encrypt, and set a CAA record of letsencypt.org. For DNS, I can host my own, or use one of the myriad of providers out there.
I am not likely to have my domain taken away from me (and neither are most people), so the DNS ROOT switch is not a draw.
Why would I move to a DNS ROOT with no one on it?
Re: Decentralized DNS with the Handshake Naming System
#48The article and Namebase faq go into some details, but just so I understand, what are the practical effects of this beyond decentralization? - If I buy a TLD, will I own it in perpetuity, even after I die? - If we're encouraging people to register their own TLDs, won't we run into the same limited-name/squatter problems as normal domains? I get that names are being released at a trickle, but that seems like it would…
I have only skimmed the whitepaper, but I did not notice any mention of handling of the loss of the private key. Sooner or later, any servers get hacked, and attackers can get the private data stored there. If this happens, is there any way to recover the TLD? Or are we going to end up with a network where many names point to ransomware pages?
To update DNS records, you need to submit a valid transaction to the network. People generally do not keep their keys connected to the internet to prevent this type of problem. It is possible to use Bitcoin Script to describe policies regarding updating the DNS records, ie a 2 of 3 multisig to update.
Re: Decentralized DNS with the Handshake Naming System
#49Earlier quoted context omitted.
If this gains traction, you will be able to pay a service provider a fee to update DNS entries for you. This is like the current system used by registrars. You don't need to care if it is powered by a blockchain in the background if you don't want to. I think it is great to have an alternative DNS system that is more censorship resistant.
> you will be able to pay a service provider a fee to update DNS entries for you. So every time I add a new LB, or cycle out an environment I have to pay someone? And then wait for them to process the chain to publish the result? Remind me, what did etherium get to for transactons to clear? 20 something hours? That is not something I want when I am trying to redirect traffic from either a set of NS records that are b…
Handshake is for top level domains. You can do quick updates using traditional DNS infrastructure at a domain underneath a Handshake top level domain. The benefit is that you have a cryptographic asset representing the top level domain, the root of trust comes from you, value can accrue in the asset itself, its tradable with non interactive atomic swaps and is censorship resistant.
Re: Decentralized DNS with the Handshake Naming System
#50Earlier quoted context omitted.
- Handshake TLDs need to be renewed every two years or the names go back up for auction. Renewals must include a recent block hash to prove that the name owner is still active and has _recently_ signed the renewal transaction. - Yes, names are rolled out over 52 weeks based on the hash of the name (modulo 52), which was designed to prevent squatting. The auction & renewals processes should help as well. - Yes, Handsh…
> Handshake TLDs need to be renewed every two years or the names go back up for auction. Renewals must include a recent block hash to prove that the name owner is still active and has _recently_ signed the renewal transaction. Can't this just be automated?
Yes but you risk keeping keys online