The GNU Name System
lsd.gnunet.org
lsd.gnunet.org
happy hacking
A few questions:
- are you people open to the idea of an IRC/XMPP chan or a weblog/gemlog? following from afar (without being on the ML) looks like there's not a lot of activity, although i can see with my bare eyes the draft spec has evolved a lot
- how confident are you in your DHT spec/implementation for scalability and security? are other people working on different implementations? is there a testbed one can run scalability checks with?
- are you actively cooperating with other non-profit projects such as Tor? GNS sounds like it could be the missing piece in such crypto-secure routing schemes without memorable names ; i understand that GNS is part of GNUNet, but i'm asking about other ties/cooperations
- why is it called "hyper hyper" local root? maybe i'm missing some context (despite reading about RFC7706 and froot), but "local root" or "user-editable root" sounds clearer to me
- did i faithfully represent the technics/politics of GNS in those posts? if not please let me know so i can avoid to repeat the same mistakes: https://news.ycombinator.com/item?id=30155773 https://news.ycombinator.com/item?id=30156097 https://news.ycombinator.com/item?id=30156175
- how can we support GNS and help make it a reality?
Yes, the only reason why there are no posts on the ML and very little posts on the GNUnet news archive is that I do this in my spare time. Now, the draft is mostly(TM) finished. So I do not see a reason for blogging anymore.
> how confident are you in your DHT spec/implementation for scalability and security? are other people working on different implementations? is there a testbed one can run scalability checks with?
That is a good question. GNUnet is still figuring out the transport layer. Until that is in a state that we are satisfied with, we will conduct performance tests. That being said, looking at other DHT proposals out there we think that R5N (and especially the improvements we have planned) are far superior. It still has strong roots in Kademlia though.
> are you actively cooperating with other non-profit projects such as Tor? GNS sounds like it could be the missing piece in such crypto-secure routing schemes without memorable names ; i understand that GNS is part of GNUNet, but i'm asking about other ties/cooperations
Yes. I think there was some collaboration here: https://datatracker.ietf.org/doc/html/draft-grothoff-iesg-sp... But we are not in regular contact and tor seems to go their own route. There are, however, similarities: https://gitweb.torproject.org/torspec.git/tree/proposals/224...
> - why is it called "hyper hyper" local root? maybe i'm missing some context (despite reading about RFC7706 and froot), but "local root" or "user-editable root" sounds clearer to me
As this was confusing, it is removed from the draft. I think you can still find it on some slides when you look for it. In general, what is currently explained in the draft should be correct and there is no need to think about this too hard ;)
> - did i faithfully represent the technics/politics of GNS in those posts? if not please let me know so i can avoid to repeat the same mistakes: https://news.ycombinator.com/item?id=30155773 https://news.ycombinator.com/item?id=30156097 https://news.ycombinator.com/item?id=30156175
I think so. There seems to be an understandable conflation of the technical means of name resolution (the draft) and the governance issues related to zones and names. Governance of zones (but especially root zone governance) is out of scope of the draft. But it is of major importance for any real world use.
> - how can we support GNS and help make it a reality?
My usual response would be: Install GNUnet and run a zone. But, we are currently in the process of fixing some major bugs in GNUnet and it is just not yet ready. As you correctly assessed, we are a very small team at the moment.
The labels in a name are separated using the character "." (dot).
Any mention of what happens with other dot-like codepoints?
Abuse through name confusion is possible, of course. I do not think this can be solved while at the same time supporting i18n. The real question is: What is the attack vector and how can it be mitigated. A GNS deployment and the selection of root zones should eventually converge towards a trusted namespace (for each individual user). There is not really any incentive having a TLD zone in your configuration that would allow such odd labels as there is not much use beyond fraud in using them. The governance policies ("rules") of the zone are expected to "trickle down" the delegation chains or alternatively damage reputation of the parent zone.
That said, as systems problems go, it is a really juicy one and brings a lot of understanding to all those who undertake it!
https://icann.zoom.us/recording/share/M8N-Duq935XheIZoBedIwm...
If you know nothing of these two protocols or the different problems they try to address, that's a good start!
Handshake is even worse because it claims to assert control over top-level domains. Most other systems just claim one top-level domain (e.g. .bit) and assert control over that one.
Handshake is focused on fixing something that isn't broken to introduce auctions instead of first-come-first-served in the DNS world. I personally don't see any interest in that, but i also don't see much wrong, except of course my clever names are going to be outbid by people with more money :'(.
Algorithmic auctions for names simply don't work. There are bots trying to register basically every conceivable name for the lowest possible fee. Once sold, the name is permanently taken, unless the bot owner decides not to renew it every 2 years. That's why they don't work.
It's the same problem that most cryptocurrencies face: by the time you want something, it's almost guaranteed that someone else already took it. Real-life capitalism also suffers this problem with regards to land.
Wait, they didn't hand out real money?! Was it even possible for the projects to convert those tokens to real money?!
> That's why they don't work.
Strongly agree!
> Real-life capitalism also suffers this problem with regards to land
The two problems are related but different: land property titles are not auction-based. They're far more expensive than a domain name (and that's a problem that land can even be sold), but it's still a first-come-first-served system. If you had auctions for land, you can be sure only the richest people would own land at all (which is already the case to some extent, but the situation would arguably be worse).
The problem with land titles is very similar to the problems with domain auctions. The problem is unchecked first-come-first-served. Whoever happened to put a fence around that bit of land 300 years ago got to own it. Now 300 years later, we don't get the same privilege because all land in existence was already fenced around. Instead we have to beg someone who got some land from someone who got some land from someone who got some land from someone who got some land from someone who got some land from someone who got some land from someone who fenced it off back at the beginning. And it is the same with most cryptocurrencies, and it will be the same with Handshake names.
More like: Whose henchmen ran off the farmers working that land at the beginning, or alternatively declared it their own and started demanding taxes at swordpoint from those farmers.
https://en.m.wikipedia.org/wiki/Zooko%27s_triangle
I searched around the GNS site quite a bit and couldn't find an answer. It is pretty well understood today that the main obstacle to decentralized naming is Zooko's Trilemma, much as it was well understood pre-2009 that the main obstacle to decentralized cryptocurrencies was the double-spend problem.
I'm a bit surprised that "here's how we solve Zooko's Trilemma" isn't front-and center on the GNS website.
That might be part of the answer
I agree that it's probably the least-bad compromise available at the moment.
After that initial non-human friendly+secure part, the ideal result is that it is secure+human friendly. The reality is that this is just as vulnerable to eventual implicit centralization like DNS has been. That just means things need to be hijacked by regulatory capture instead of hacking.
I was going to say: Gnunet pet names aren't globally unique, therefore Gnunet gives up on having the human-meaningful addresses be globally unique. However, from your link it appears that there is no requirement in Zooko's Triangle for those human-meaningful addresses to be globally unique. So it doesn't actually give up anything:
1. Pet names are human meaningful (though not globally unique). Check.
2. Public keys are secure (and in the typical cases globally unique, btw). Check.
3. Gnunet zones are decentralized. Check.
There you go. Triangle drawn.
AFAICT Gnunet punts the names down to the user in a similar way to how Convergence punted CA choice down to the user. In both cases the user chooses which entity or entities to trust, being more or less strict in what to do if those entities disagree based on some predetermined criteria.
In reality, however, I remember that Google balked at adopting Convergence because it seemed likely that most would have eventually just standardized on delegating their own choice of "decentralized" CA to Google. Then you'd end up with an ostensible decentralized set of authorities where that set is simply { Google } for the vast majority of users.
I don't see any mechanism in Gnunet that would avoid a similar fate. Especially given that the examples given in the current docs are so goddamned confusing and convoluted that a tempting workaround would be "Step 1. Just set Google as your thingy." I offer into evidence exhibit one: Gmail.
If they aren't globally unique they aren't really names anymore.
If I send you a link involving news.ycombinator.com, and you think that news.ycombinator.com is really furrypr0n.com, I would say that we are not using the same naming system.
That isn't distributed; it's merely incoherent.
Is the namespace decentralized? That depends on how you use it. If you use GNS with an ICANN provided root zone configuration (this is an example, there is no such thing atm), then your names will have the same meaning as for other people using this configuratin. If you build your root zone from scratch, you will have modified the namespace in such a way that names are no longer unique. If you go full petname system (ie. names are basically treated as your personal address book), the names are no longer unique.
Think about DNS: If you are sufficiently technically literate, you can run your own root servers and use them. Is DNS at odds with Zookos triange? I would argue: Yes, depending on how you use it. It is just very common to use it with unique global names.
The issue is going to be how to communicate a domain name that resolves identically between sender and receiver. Some sort of relative domain naming will have to be implemented. Perhaps sub domains may have to be resolved against the zone used to access the original information. Or, the address may also specifies the zone pkey against which names have to be resolved. If this could be resolved, the Zooko's triangle may finally be completed, without the need for globally unique names.
edit: these slides are a start: https://git.gnunet.org/presentations.git/plain/icann66/20191...
> Query privacy: Queries do not reveal domain name
> Record confidentiality: Values in DHT are signed and encrypted by zone owner.
> Zone privacy: Zones cannot be enumerated
> Censorship and DDoS resistance
That's the key security properties compared to DNS.
i'm left with a few big questions:
1) how can you have query privacy and zone privacy in the same system? seems like query privacy would open the system up to dictionary attacks at least; with a possibility that depending on how the dht is implemented, perhaps even high performance locally distributed dictionary attacks could be executed?
2) the issues of economics and property rights (as well as invested parties in the economy of name sales and registration) seem like they could collide with the technical goals with something like this gaining traction, has there been any thought given as how these political/economic concerns could be addressed?
To 2) This is a governance issue. Theoretically, you could deploy GNS with an ICANN root zone. BUT, the system is designed to give users the freedom to override defaults if necessary (see the root zone section in the draft). GNS clients will likely ship with a default zone configuration.
If you operate a zone and are a considered trustworthy third party, nobody can prevent you from taking coin for adding delegations to your zone or offering a platform on which you can trade the labels.
Like maybe there's this super cool blog about guitars my friend akhmad follows but i can't remember the URL right now and of course Google is giving me the worst SEO-induced results. But i know my friend akhmad published it as "guitar" in his zone because he also forgets the name every now and then, so now i can just go to "guitar.akhmad" in my browser (assuming i already have akhmad in my hyper-hyper local root).
Yes this does have some consequences for some things such as TLS validation, but if you want we could get into the details of why that's OK (TLDR: CAs are only good because DNS is bad security for key distribution, DANE over GNS would be arguably more secure).
The GNU Name System IETF Draft - https://news.ycombinator.com/item?id=23766947 - July 2020 (32 comments)
GNU name system - https://news.ycombinator.com/item?id=11641626 - May 2016 (58 comments)
But joking aside, it's good to have a censor-resistant resolution protocol. This is a more radical idea than the EU's recent proposal to have parallel name servers that obey Europe's GDPR rules.
Still, a lot of power is given to those that control the cables and satellites, and of course the electricity that powers the Internet's hardware. The commercialisation of the Internet has led to more centralization since the 2000s.
A true state of freedom and safety from repression, censorship and dictatorships can perhaps be only achieved with more ad-hoc mesh networks.
I've recently started playing with mesh networks. Yggdrasil is excellent. They haven't solved naming, they're focused on mesh routing with e2e encryption. There's a public network. It's very experimental. But it works and its just so cool!
Also worth mentioning is Nebula (made by the Slack devs). Nebula is great for building private mesh networks.
Its a very exciting space right now! I'm hopeful; an open internet is possible.
Yes! Finally a protocol that does not discriminate against non-ASCII languages (like punycode does in my opinion).
Hello, my name is xn--jeprenj-rqb! </rant> (:
— Falsehoods Programmers Believe About Names https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...
GNS is intended to replace DNS (in a backwards-compatible way) at the ICANN level so if it was ever adopted facebook.com would resolve (by following public key PKEY records, not IP/DNS NS records) using GNS.
In addition, a neat feature of GNS is the hyper-hyper local root. So if you add your friend alice's PKEY in your local root as "alice", then you could resolve whatever in her zone as whatever.alice. But can this not be achieved with DNS already, you may wonder? Two differences:
1) resolution is by public key, so you don't need to keep a mapping of all your friends' nameserver IPs
2) it's intended as a recursive mechanism where you can advertise your favorite domains on your own zone, so for example if i publish The Pirate Bay's public key in my zone in a tpb record, hypothetical tpb.tofu.net will still resolve properly
All in all, GNS is so far the only credible alternative to DNS i've read about, if only because both the protocol and the zonefile syntax are backwards-compatible with DNS.
The main reason would be lack of interest. It's developed by a handful of people who are undertaking one of the biggest tasks in the history of the Internet with very little resources.
Remember how much energy it took to switch everyone to IPv6? Right it still hasn't happened 20 years later: that's exactly the kind of change GNS is about, and that's why it's designed to be backwards-compatible with DNS so we don't end up in the same situation.
I'm open to the idea that the provided implementation could be bad (haven't read the code), and i believe there may be valid criticisms of some parts of the protocol. I just haven't read anything of the sort so far. In both cases, that could hinder adoption, but both could be fixed before GNS is standardized, which is why the authors have been pushing early drafts to the IETF (to gather feedback).
> Are the prevailing registries/registrars opposed to it?
In regards to the ICANN, registries and registrars i'm not aware of any opposition. GNS changes nothing significant to their politics/economics: it would require some time/resources to deploy but arguably nothing terrifying. Registr* specifically are probably entirely unaware of this effort and couldn't care less, especially since GNS is designed in a backwards-compatible manner where people can continue to use regular DNS and it will "just work".
> Would there be any authority that could mediate disputes over who "owns" a name?
This is registry policy and has nothing to do with the protocol. Every registry has a different policy on this matter, which may also be impacted by local regulations.
> Does it address the problem of name-squatting/hijacking?
Hijacking is made harder by GNS because we use public-key cryptography from the start to delegate zones to a third-party, not location (IP/domain). It's like DNSSEC but better because you don't have to mess with your zone to advertise the key (the key *is* your zone identifier in the DHT).
As for name-squatting, this is again entirely unrelated to GNS as it has to do with ICANN/registry policies. GNS is about better technical foundations for DNS in the 21st century, it's *not* about changing the politics of the ICANN root (although it's arguably an empowering technology for alternative roots to emerge).
Hope i answered your questions. (there may be some details i got wrong as i'm not involved with GNS project)
For a such long answer, you could just mention this at beginning and stop there. This is a reason it will never become a standard. There is no possibility that a central authority will endorse a tool that will potentially make them obsolete or create a competitor to them.
It's a GNU project.
Imagine for a moment this was a Microsoft project, and was called MSDNS. Would the name matter? I would argue that it does.
Granted that basically no non-techie has ever heard of GNU (or the FSF) - despite the insistence on calling it GNU/Linux - I don't think it'll be a deal breaker, but I think it's uncool to put a "company" name/trademark in a global standard protocol name.
So for me it's not the creators, but rather the name itself that warns a down vote.
I value the GNU project's ethical framework and feel like that's worth fighting for/with, although i personally am strongly opposed to the current internal politics of the FSF which are definitely not aligned with the base/masses of the libre-software movement.
Also GNU = small non-profit, Microsoft = giant corporation.
> So if you add your friend alice's PKEY in your local root as "alice", then you could resolve whatever in her zone as whatever.alice.
This sounds very undesirable to me. The same address resolving to the same website for everyone is a useful property of the current system.
This is a desirable property for many companies that filter employee internet access from their internal network right on the DNS level.
That's already only guaranteed under the public root, which GNS intends to preserve: the situation would not change in this regard. I can already map "hn" to a well known HN IP address in my /etc/hosts: the only hurdles would come from my web browser sending the "hn" Host header (easily fixed) and trying to validate the remote TLS certificate for "hn" (less easily fixed). In this regard, GNS would be different in that i could delegate "HN" to a public key and not be bound to the IP suddenly changing under my feet.
On a higher level, i would argue the difference is GNS by design empowers users to archive/publish records because they don't need to operate infrastructure for that. If you already have a domain name and are familiar with DNS, publishing records is not that hard: GNS would make it far easier because since the records live in the DHT you only need client UX to publish a zone, no need to configure a name server or to point your client configuration to a specific name server API.
I did not look at any details, just were at some talks of its proponents (now almost 10 years ago!).
But maybe some small parts will work and survive. Let’s see.
The reason why gnunet appears to be "redo-everything" is because that is exactly what is necessary if you take the issues seriously and think them through.
The reason why it takes so long is also because we are a small team and the goal does not provide instant gratification while at the same time being very hard to achieve.
It is a lot of systems programming and engineering. It is a lot more fun to reinvent the wheel in the newest shiny technology.
So it seems like more of a software project than a running service at this point?
It's supposedly a decentralized naming system, so running a node/client yourself should be enough to get started, otherwise I don't see how they can call it decentralized. But I'm not finding any links to any source code from this specification, which is to be expected, but my searches are not helping me either.
There is endless free porn with regular DNS so you can't use that. Pirate music and video has been done to death, don't think you can use that to roll out your own DNS. If facebook wanted to have their own DNS and rolled out their software with their clients then they could probably pull it off. China will do it at some point but only for their citizens in their territories.
Examples:
• if a site is banned from ICANN DNS, then there is no other choice,
• if I want to keep bots, spammers, search systems, providers, and government out of the door,
• if I want to welcome technical elite but hide from everybody else, like it was in old Internet.
• if I don't want to pay X$ every year for every domain.
• if I want to have a cool name for my site.
• if I want to create overlays for popular sites, to fight ads, spam, promotions, PR, and unwanted content.
Yet it is absoutely true, all it takes is changing some settings so that computers point elsewhere. ICANN derives its "authority" from voluntary behaviour of network admins.
Not to mention, X.509 is not centralized to begin with.