Decentralized DNS with the Handshake Naming System
privateinternetaccess.com
privateinternetaccess.com
- 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 just put off the problem a bit.
- Is this going to have the same environmental problems as Bitcoin, or will having fewer transactions mean that's less of an issue?
- Is Brave the only browser looking into this, or are we also seeing buy-in from browsers like Firefox and Chrome?
I'll read through whitepaper and learn the details, but if possible I'd like to know if it's worth my time to do so.
I'm not necessarily feeling great about the idea of having separate TLDs for every site, but I'll admit there is something attractive about being able to register 1 TLD as a namespace, one time, and then using subdomains for every other site I ever make. It's just not clear to me how that system would scale.
No, if you don't send a renewal transaction, the name goes up for auction again.
> - Is this going to have the same environmental problems as Bitcoin, or will having fewer transactions mean that's less of an issue?
Yes, it's proof of work
> I'm not necessarily feeling great about the idea of having separate TLDs for every site
TLD owners manage the namespace as they see fit. that includes issuing/selling/giving away sub-domains. <subdomain>.<TLD namespace>
- 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, Handshake uses proof-of-work. It's a different algorithm (Blake2b keyed with KMAC256) than Bitcoin but still essentially relies on energy consumption for security.
- I'm not aware of any other major integrations. But it is easy for users to run their OWN local light client and use it as the DNS resolver for their OS: https://github.com/handshake-org/hnsd
Can't this just be automated?
Second, Handshake is airdropping 70% of the mainnet coins to open-source developers. If you have over 15 followers on GitHub, you can claim around $400-800 of Handshake coins (HNS) with no strings attached. Not only will this give developers an incentive to check Handshake out, but also this ensures that the bidding power is spread out at launch. Without this mechanism, a whale could spend $10mm on HNS at launch and outbid everyone.
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.
Try this command, It contains a list of peers that were working few hours back. Maybe they are still online.
./hnsd -r 127.0.0.1:53 -s ajgkxfe47u6wwyvyh7qixbdddvjxcqbs2oxwr5attq45yj72s5pcs@54.201.46.33:13038,akudgzg2wntfjucsodyvz44h76qae7xrtuix6wc6fc22cx5jll6fe@165.227.52.206:13038,ajaqq7jwqrwixmvl64tzi3qfi7ynj3hmmtzmkyubtrljh4mwmh7ie@165.22.151.242:13038,ap77bve4acntajehkvqc33bvlsi27ka6l2xte4fhn2ghuwx44fsxc@18.236.58.201:13038How will one go about this? I'm interested, if only for the purpose of claiming a few domains that I have a personal interest in.
If you want an easier way to claim and use your coins I can also add you to our private beta for Namebase.io. Just ping me at tieshun at namebase.io.
Do you know if these users will still receive the tokens they signed up for? Should these tokens show up on testnet?
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?
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 expose an easily scannable list of DNS entries .
Additionally, HNS also fixes the problems the CA system has today. CAs can generate certificates for any domain - even if the domain owner didn’t request it. This has led to countless occurrences of abuse.
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 certificates for any domain - even if the domain owner didn’t request it. This has led to countless occurrences of abuse.
It fixes the non EV cert situation (kind of - CAA records also help this, and work on the standard internet), but doesn't fix EV certs (i.e. amzon.tld is actually Amazon LLC and not Scammers R Us Ltd.)
It also ignores the reality of most major companies in the world MITM'ing all outbound traffic from offices to ensure sensitive content is not exfilled from the company - there is 0 chance of them allowing traffic out that they could not MITM.
This same argument applies to bitcoin and it has not (yet) been banned in much of the free world.
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.
We have seen this before, where people who run these services are personally held in contempt until they comply with the order.
* I say "usually" because more complex permissions schemes are possible with Bitcoin Script. m-of-n in particular I could see being very useful; it could allow individuals to update some parts of the record but not all - for instance, make it mathematically impossible to abandon the domain or move where it's pointed, but still possible to update contact information.
I think it is great to have an alternative DNS system that is more censorship resistant.
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 broken, or if I host the full zone in the chain, a broken AWS / Azure region.
Combine the time to wait for caches to refresh on the internets (better these days, but still longer than people would like), with waiting for a blockchain to publish my new records, and you have ops people in pain.
DNS is already one of the largest fault tolerant, eventually consistent, cachable, federated, and globally distributed key value databases ever to exist - we don't need to add blockchain to the mix.
I don't see how this follows at all.
The slowing transaction incorporation times for major cryptocurrencies is related to transaction volume, not to the total size of the chain to date. Presumably a system restricted to updated HNS entries would not encounter anywhere near the same transaction volume.
From what I've heard, the "Layer 2" networks for even the most venerable of blockchains have the potential to reduce transaction times a couple of orders of magnitude.
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.
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?
ENS domain names can mainly be used for payment for now, so I'd be sending crypto to [domain].eth where the advantage is having a readable address instead of a random-looking string.
You can also host web pages on it (which I believe is helped by their IPFS) but that has seen limited use as of yet.
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?
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...
No more rogue SSL certificates!
(Incidentally, cement with such long lifespans were widely used during the Roman Empire)
The existing TLDs will continue to be held by the existing TLD holders. So, as an example, news.ycombinator.com will still work!
This is truly a drop-in replacement of the DNS ROOT giving power back to the people.
Then you wouldn't have to convince people to spin up a new node for a separate chain. This seems like an obvious choice to take advantage of Bitcoin's network effects and inherent chain security.
You could even lock up some bitcoin and issue bitcoin-backed Handshake tokens and continue operations as normal.
Also ENS (Ethereum Name Service) on the ethereum block chain is really cool, though its more for resolving to swarm hashes or block addresses... which are for decentralized documents and apps.
> The Domain Name System (DNS) is a hierarchical and decentralized naming system for computers, services, or other resources connected to the Internet or a private network.
> While DNS is already fairly decentralized, the centralization exists because of ICANN’s gatekeeper control .... ICANN ultimately has control over what internet names are acceptable – and serves as a singular point of failure.
That is what this is doing.
> Handshake is a decentralized, permissionless naming protocol compatible with DNS where every peer is validating and in charge of managing the root zone with the goal of creating an alternative to existing Certificate Authorities. Its purpose is not to replace the DNS protocol, but to replace the root zone file and the root servers with a public commons.