The GNU Name System
gnunet.org
gnunet.org
1. I runs on top of GNUnet, which is a huge DHT that can be used for any purpose you like.
2. So GNS aims to replace DNS with a newer "modern" protocol, it is not a alternative root zone (like Handshake or such), nor does it decentralize the root zone, it just decentralizes "DNS".
3. How it is supposed to work is, instead of OS bootstrapping using root servers, they are preloaded with a root zone public key (possibly belonging to ICANN) or a list of TLDs (with corresponding owner public keys). Then the key owner can publish zones signed with the corresponding keys on the DHT, which recursively contains keys for child subdomains. It's like if torrent and DNSSEC had a baby.
4. To lookup a domain, you do a request with (tld, pubkey) and verify the response, do this recursively for each label until you have the record you want.
5. The problems with DNS it solves is: censorship (DNS is very easy to intercept and censor), query privacy (I don't know how this works, they don't seem to use onion routing or something), and secure resolution.
One thing to note here is development on GNS started in the 2001s, this was before DNSSEC and DoT/DoH were a thing, and most of the DNS was unsecured (which albeit even is today), and this could have been a completely viable approach.
However there are a lot of great people on their mailing list which I'd say probably qualify a lot hetter than me.
I do plan to play around with soon however, and would probably make a public writeup, I'll send a link if I do :)
Aside from that they bloat the size of responses a lot. However if you can sign DNSSEC on the go, you can use Cloudflare's black lies approach and have small enough DNS responses. [1]
> "The reason this matters so much is that the maximum size of an unsigned UDP packet is typically 512 octets. DNSSEC requires support for at least 1220 octets long messages over UDP, but above that limit, the client may need to upgrade to DNS over TCP. A good practice is to keep enough headroom in order to keep response sizes below fragmentation threshold during zone signing key rollover periods."
A major problem when designing a decentralized naming system, or any naming system at all really, is preventing malicious users from grabbing all the cool names for themselves. The only way to do this is to make acquiring domains costly, and blockchains are a perfect way to enforce that in a decentralized manner. Other problems include accurately tracking domain ownership and letting the owners transfer domains to others, which cryptocurrencies have solved long ago. As an added benefit, because all domains in such a system are owned by a public key, we suddenly no longer need a root of trust for TLS, instead, we accept any TLS certificate signed by that public key.
Users should get to explicitly decide for themselves who owns what domain, or delegate that power to a trusted authority to decide for them. GNS enables this behavior.
I think namespacing is a rather poor use-case of this type of consensus.
It's an unpopular opinion because it doesn't hold up to scrutiny. Here, let's go through it piece by piece:
>A major problem when designing a decentralized naming system, or any naming system at all really, is preventing malicious users from grabbing all the cool names for themselves.
This has nothing to do with malicious users. Any system that allows users to exclusively claim names permanently (or semi-permanently) will have this problem. Even if you invented a way to define and eject all malicious users out of DNS, domain names like facebook.com and youtube.com would still be highly contended and expensive, because of the inherent demand of those names in the current market.
>The only way to do this is to make acquiring domains costly
No, that wouldn't exclude malicious customers, it would only exclude customers who don't have a lot of money. You'd just select for the customers who are both malicious and wealthy.
>and blockchains are a perfect way to enforce that in a decentralized manner.
In practice, blockchains aren't decentralized at all. This much was obvious to anyone involved, since the first bitcoin mining pool formed in 2010. By making the system costly to join, you're only accelerating the process of centralization.
>Other problems include accurately tracking domain ownership and letting the owners transfer domains to others, which cryptocurrencies have solved long ago.
Cryptocurrencies didn't solve this and never will. A blockchain isn't legally binding, so tracking ownership just can't be done there. At best, you can have something that's an approximation of ownership, but still requires a trusted authority (i.e. an oracle) to make the final say on what the ownership actually is.
>As an added benefit, because all domains in such a system are owned by a public key, we suddenly no longer need a root of trust for TLS, instead, we accept any TLS certificate signed by that public key.
This is just shifting the problem. Now instead of worrying about trusting the root, you have to worry about trusting every single key out there, and make an individual decision for each of them.
If domains cost $0, claiming all potentially useful names for yourself costs x*0=$0. Someone will inevitably do that, making them the exclusive owner of almost all domains you could ever want to buy. As a consequence, 99% of potential future domains would be owned by malicious actors, who could charge astronomical prices for them. In other words, if you make domains free, somebody will snatch them all up and sell them for a lot of money.
If you need to make a payment to get or renew a domain, such an attack becomes far more costly. Getting the first 100 English words is probably worth it, getting a combination of all possible names and surnames probably isn't, unlike in the free version. That way, you can still find interesting domains that you actually need for low dollar amounts.
> In practice, blockchains aren't decentralized at all. This much was obvious to anyone involved, since the first bitcoin mining pool formed in 2010. By making the system costly to join, you're only accelerating the process of centralization.
Even if you can make a 51% attack, the security of the system isn't compromised. Sure, you can prevent domain registrations, transfers and updates for a while, maybe even reverse transactions done in the last few blocks, but you still can't take over anybody's domain without having their private key.
> Cryptocurrencies didn't solve this and never will. A blockchain isn't legally binding, so tracking ownership just can't be done there. At best, you can have something that's an approximation of ownership, but still requires a trusted authority (i.e. an oracle) to make the final say on what the ownership actually is.
You don't care about ownership in the legal sense, all you care about is that if Mark Zuckerberg owns the private key for Facebook.com today, nobody can do anything to Facebook.com tomorrow without his consent.
> This is just shifting the problem. Now instead of worrying about trusting the root, you have to worry about trusting every single key out there, and make an individual decision for each of them.
All TLS really guarantees is that the server you're contacting is trusted by the owner of the domain you typed in. In the current system, you need a root of trust to accomplish that, blockchains give you that property for free.
Some reasonable measures:
1. the organization could be a non-profit co-operative owned individually by its investors 2. the organization could establish a contract that enforces desired behaviour of participants by the judicial system
Voila, no blockchain needed.
The allure of a supranational DHT network is that it is more censorship-resistant, requiring deep packet inspection or attacks to block certain lookups.
I think this hypothetical consensus-based DNS blockchain sounds nice at first glance, but really, it just means that DNS is changed from an authority-based model to a consensus-based one. But consensus of what? It's not of people, but of resources -- compute power -- which states will always have more of, anyway. Like TOR, it just means the state has to control/surveil more "trusted" nodes. So it doesn't really solve anything.
You can't "web of trust" a global network of 8 billion people who don't have any interest in this stuff, don't want to peg their individual identities to some online system, and don't agree on what truth is to begin with. You can't techno-topia your way out of the cultural differences inherent in geopolitical disagreements.
Too true.
Computers won't "solve" social/political/cultural issues. They're reflections of the creators' politics. Even blockchains that purport to be egalitarian reflect the political ideology of their creators -- often naive at best or tyrannical themselves at worst.
If a blockchain became the norm, there would be no way for the state to have more compute power than the rest of the population
There is no way the government has enough servers and computers to come even close to 51% of the world's compute. And if they tried to print money and buy it all, it would be seen as ridiculous and the government would be sacked.
Also, surveilling TOR exit nodes is very different from owning over 51% of all TOR relays. The former won't help you deanonymize users, the latter most definitely will
And as and user who does not understand, nor have the resources to meaningfully inspect, all the king's software and all the king's bugs, the end result is exactly the same: Good, old-fashioned analogue trust (GOFAT? to coin a phrase?) in the elves that make my computer run.
Protecting against malicious users grabbing all of the good names first using zero-trust blockchain networks requires the protections we all know against Sybil attacks. These protections are problematic for numerous reasons I don't think I need to enumerate here.
The point is that not solving that problem results in a system that is far less complicated and resource efficient. Some times the better solution is to rely on social/political/judicial systems instead of protecting against hypothetical malicious actors.
- all the good dotcoms have been squatted on since the 90s (that's why half the startups have gibberish names). particularly desirable domains are being squatted on even on all the random dotbullshit nu-tlds.
- the social/political/judicial systems are the very reason why there are so many attempts to build an alternative to registrars and DNS
I will readily agree that so far all attempts have failed though, being either too complex/clunky, or tainted with a crypto grift - I'm actually happy that namecoin/ens/handshake/etc got virtually no adoption. but it has to be done eventually. the entire industry is a scam and rent-seeking with unlimited profit margins
So you either have to disambiguate names at a protocol level (miki://whatever.eth vs edent://whatever.eth) or at a name level (whatever.eth.miki vs whatever.eth.edent)
Or, you convince everyone in the world to standardise on one chain. In which case, how's that difference from what we have already?
However, Coinbase (part of the 7 admin keyholders of ENS) had a closer look at .eth addresses and their use in their wallet and decided to remove support for it and instead use .id for their Coinbase wallet. [0]
Why did they do this? It turns out that:
"New crypto users with no previous exposure to ENS would make the false assumption that the ".eth” domain only works" for sending and receiving $ETH."
[0] https://twitter.com/matt_willemsen/status/154901782285598310...
Stats: https://dune.com/makoto/ens
Note that ENS is not only ETH, it supports multiple coins, and it's also compatible with the legacy DNS namespace, so it's possible to import & use tlds such as .com
In general, not a fan of BNS beyond that, through, as upkeep is too resource intensive. It is just not a sustainable and efficient thing to do for names.
Blockchain DNS will probably happen first, but i think name resolution which doesn’t require global consensus is under-appreciated. it’s like if i ask wikipedia (or a non-localized Google) for the page on “i3”, v.s. asking a random selection of my friends for the page on “i3”: i’m just always going to get a better result by more heavily weighting the response of my peers than the responses of people far-removed from me.
The problem is that malware and spam have gray areas where some people are ok with it, but others don't.
We should allow all of those existing, and instead limit what we experience by filtering/censoring
In other words, instead of censoring globally, we should censor locally at a community level
I don't think it would be any easier if you can't take any recourse besides blacklisting a pubkey there could be billion billions of. Even things that have no gray area would be nearly impossible to curtail in large volumes.
What you won't be able to do is remove at the root, and instead you blacklist
My claim is that under a decentralized DNS, "removing" or "blacklisting" have the same effect on what you consume because you are always in control.
The BIG difference is that, under a decentralized DNS, no one controls anymore what OTHER people consume/trust. And I am strongly against of any group of people limiting how other groups communicate between themselves, even if these "other groups" are sharing child pornography. I'm open to some data about this, meanwhile I have a strong bias into thinking the cure is much worse than the disease
I'm really sorry, but this infrastructure has functioned for more than two decades. It takes a massive amount of manhours daily to deal with abuse. How can you unironically defend and claim that a system that removes most punitive measures will be good or usable? Is it delusion or naivety?
> A: Names have no owners in GNS, so there cannot be a "legitimate" domain owner. Any user can claim any name (as his preferred name or "pseudonym") in his NICK record. Similarly, all other users can choose to ignore this preference and use a name of their choice (or even assign no name) for this user.
This is confusing me. How is it not a problem that randoms can just claim other people's domains?
However, the protocol does not really care what kind of governance is chosen or present. In order to understand this a bit better I invite anyone to read section 1-3 of https://www.ietf.org/archive/id/draft-schanzen-gns-19.html
It's just the actual, practical DNS system that everybody actually uses which does.
There is a global name, which is a long non-human readable unique identifier. And there is a nickname, which is only really locally significant, although the zone can publish a preferred name, the local side doesn't have to respect it.
Granted, most people do not bother using this feature, but it is also true that most non-technical people don't even bother with typing a URL, they use a search engine as a proxy anyway.
In fact it would be a good idea, ecologically, to have a system that educate its users to give their own nickname to website they visit often and use them rather than performing a search query. Especially if it is as simple as clicking a "bookmark as 'xxxxx'" with xxxxx being the default name of the service/website in your browser, with a TOFU principle :).
The last main thing that I use domains for is verification (is this really "google.com"?) but even that is 1. Not effective (yes, I am definitely "goog1e.com") and 2. Mostly replaced by my browser doing the check for me (for example via my password manager which only fills in credentials for the correct domain).
This is literally what I'm saying and the main point I'm addressing in the second and third paragraph of the comment you are replying to.
However, you make a very good point with QR code: this is another argument for why the actual domain name is not that important.
So what is the point?
How does this system facilitate "discovery" when no one can discover your website by the human readable name you would like to assign to it?
You could imagine a system where you manage your DNS root zone locally ("hyperlocal") and there is NO consensus on what it contains. The DNS resolution mechanism could support such a concept. It is only the de-facto rule of ICANN over the root zone what makes DNS names globally unique. And IETF/Standards do not allow to diverge from this.
The GNS specification explicitly allows it. That is it. It does not mandate that users must bootstrap their root using fancy hand-picked petnames. In practice, a common set of root zone entries will very likely exists. The specification does not mandate the governance.
There could be a world in which DNS names as we know them today are resolved using the GNS resolution mechanism with no tangible difference to the user.
Let's say GNS gets traction. Users and implementation could provide a list of start zone mappings which are managed by ICANN and use this as a default. Effectively, this will give users global names. Just like now. .de will be managed by DENIC, .fr will be managed by AFNIC etc.
BUT: GNS is designed to allow to override such a setting. The ICANN root zone may be delegated by the user into the .icann namespace. So, locally, example.com in DNS would become example.com.icann in GNS. Alternatively, the user may also override ANY TLD mapping provided by the ICANN configuration - or individual domains - if needed. For example, if a domain is seized or otherwise censored in DNS.
The thing that protects you here is TLS and PKI and our agreed-upon global trust system of registrars and certificate authorities that have been built up. DNS itself is just one (very abuse-able) cog in that wheel.
For instance, if you live in China.
To make this practice work consistently, the .local TLD is specifically reserved for such use cases in mDNS.
Now I should mention, all TLDs should be reserved even if only used locally because of above security implications, but there’s nothing preventing people from abusing DNS in a local setting to resolve names differently than they do remotely.
Users anonymously subscribe to root zones that they trust, or act as their own authority.
There are pros and cons to this approach but the point is not to exactly replicate DNS.
The domain itself can have a preference, but the user is free to ignore it. Which does mean that a domain is not as definitive as it is, in the case of DNS.
1) Non-problem: censorship. You can register domains in many different countries. Companies have no problem registering their domain.
2) Real problem: domain squatters. Can't see GNS solves this.
3) Real problem: sometimes people need to type (or verify) domain names. If there is no global ownership of "google.com", how do I know I'm at the right site and not a phishing site?
4) Real problem: DNS records are very limited in what they can contain (so TXT is abused for many things). GNS does not improve on this and is still a binary protocol, adding more complexity.
5) Privacy is already solved using "DNS over https". No need for reinventing the wheel completely.
6) Non problem: DNS is centralized. DNS is working very reliable and the central structure makes it easy to figure out why stuff does not work. A decentralized network is a nightmare for "why does DNS resolver fail".
Both yes and no. It shields the user from ISP's DNS-based invigilation but at the same time it hides application requests from the user, renders user's own DNS-based filtering (pihole and such) useless and can just transfer spying ability from local ISP to big corp.
Probably an unpopular opinion but personally, I don't consider DoH as an upgrade but a deprivation of user's control.
I see its theoretical benefits for less technical users who haven't heard of pihole or even problems that it solves. Just theoretical, because what benefits the user is often in opposition to what benefits the corporation.
Having recently fully de-Big-Teched all my devices, I have the luxury of agreeing with that philosophy.
As a slightly less harsh compromise, even if you run hostile apps you should be able to install a personal root certificate on your devices and MITM their traffic. Still, I imagine most IoT devices don't give you any way to do so, so you should avoid them or keep them disconnected from the wider Internet if they're still useful otherwise.
Either way, the pihole corner case is not a very good argument against DoH, which is far more often a security improvement.
A better argument is the big corp one, since DoH indirectly boosts their power (because a self-hosted site becomes less anonymous than one hosted on a shared AWS IP).
I'm curious as to what this entailed for you. To me this sounds like I'd cut off contact with over half my family. The social media I could get around/ignore altogether, but I never figured out how I'd manage the messaging situation.
I still avoid installing them when possible. Facebook, Airbnb, and many others work just fine via their websites.
We still need more ODoH proxies for me to completely trust the system, but any ISP could set those up if they wanted to. There's probably some information that can be extracted from the encrypted DoH request, but I don't think it's anywhere close to the problem DoH posed when it was first introduced (and more importantly, the problems caused by the way it was introduced in Firefox). I think the benefits massively outweigh the disadvantages.
Leveraging alternative protocols for DNS has always been an option and always will be. Apps and IoT have been doing this for years. Any application that cares about being blocked can trivially work around DNS problems with their own HTTPS-derived protocol and some do. What's left to block are the companies that won't deal with DoH problems anyway.
The control DNS interception provides is mostly an illusion. Kids at high school know how to bypass DNS blocks; application developers can be even harder to block. The only solution is to not run untrusted software in your network, or work with a traffic whitelist for hardware and software you can't control.
Can't you proxy it over a local DNS-over-https server that will provide filtering/caching and then have it query the upstream server?
I wouldn't want to proxy all HTTPS traffic (may not be possible if software ignores system-wide TLS CAs and uses bundled trust chain).
DoH introduces bunch new problems without solving any that I had.
Even early Google Chrome shat on OS DNS settings and was querying 8.8.8.8 but that could be filtered.
The idea that everyone else should have to use a DNS transport that ISPs can filter to downgrade back to being snoopable just so you can feel better about what your Chromecast or Amazon Stick or whatever does on your network doesn't make a whole lot of sense. I don't mean to put a bunch of stuff on you that you didn't say, but this is a very common pushback to DoH, and it makes no sense.
You're imagining things.
The problem is that the current implementation and deployment of DNS is the issue. GNS has built-in security privacy using crypto and p2p on the one hand with enough user-centric flexibility for trust and zone governance on the other to mitigate power grabs.
What's the point of squatting random identifiers? Seriously, what damage does it do to you if I "squat" on ´www.000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884´ ?
example.com = <theirZonePublicKey>
to be shipped with implementations. The squatter of "example" at the "com" registrar can be circumvented. If users/implementations choose to do so. The secure and unique names under the authority of Example Co will always be reachable in their zone.
Today Example Co can go to the courts and say "we own the name 'example', so we should have example.com". This works in many countries today. (Or they can offer current owner a sum of money).
With GNS they would have to lobby all sorts of GNS providers. That's a worse situation.
Similarly "buying the domain" simply means having this party yield the registration at the domain registrar to you.
Anyway, both also works in GNS. My example addresses the case where the legal claim is not possible and the other party uncooperative while "consensus" is that it is a squatter with no claim. (Or, by extension, a censorious circumstance, think TPB)
2) Users ultimately decide what root zones to trust or directly what nicks map to what public keys.
3) This is fundamentally the same class of attack as MITM/Evil Maid, it is impossible to completely defend against this. Existing DNS/PKI does not fix this either, It merely put everyone's eggs in one basked and hands the problem off to rent-seeking intermediaries (CA's, Registrars, etc.) which serve no purpose other than racketeering.
The purpose is not to make MITM impossible, just harder. Users will familiarize themselves with the risks of the system just as they do with Tor/I2P addresses.
Most users already receive phishing messages telling them to "Go to microsoft.signin.net to reset your password!" so they already know not to trust domains unless they trust the entity giving them the domain - that should be a sign that the existing DNS isn't socially expected to authenticate identities before letting them own a domain.
When you want to go to a company's website, do you use a search engine or just go to <company_name>.com and hope for the best? If so, do you expect every company to squat every TLD with their name?
5) LOL! Yeah... encrypts your DNS request directly to cloudflare or <intermediary>'s servers. GNS fixes this.
6) The centralization of the existing internet infrastructure in general is something that should be avoided. I for one, do not mind if it makes your job more difficult. It is not just critical for global security but also for personal liberty on the internet.
The centralization of crap like DNS serves as a major hurdle for average users and affects the use of the internet as a free-speech tool, even if you might not realize it. How do you get a domain? You have to pay a registrar, which means you need a credit card. How does a user host their own blog/email/whatever without jumping through all these hoops? They don't, they just use twitter or gmail or something and accept corporate censorship. DNS is a wedge towards "web 2.0" social media and thus censorship.
I wonder what Arab Spring would look like if everyone had easy access to a secure, private, decentralized internet instead of the what we have today where users are funneled into a handful of monopolies for corporate gain and social control.
A functional internet probably makes your job harder because the majority of the software industry is built on rent-seeking business that offers (service-based) solutions to systematic artificial problems like that of DNS, PKI, IP.
http://piratebayo3klnzokct3wt5yyxb2vpebbuyjl7m623iaxmqhsd52c...
5) This hides your queries from middle boxes, but your DNS server can still see the domains you are looking up. (There are some proposals to address this that involve a proxy who can't decrypt your request, so the DNS server can't see who sent the query.)
I've long held the view that DNS is no longer fit for purpose. It made sense back in the day, but what is the real point of TLDs these days? It means many folk have to register their name multiple times and there's problems with domain-name squatting. It's just a money-making ploy now.
In addition to the technical side, which there is plenty of, there's the human aspect. Imagine the amount of trademark disputes and abuse .com/Verisign has to deal with. Trademark or local law can rarely be automated.
>[...] 3. duct tapers, who temporarily fix problems that could be fixed permanently, e.g., programmers repairing bloated code, airline desk staff who calm passengers whose bags do not arrive [...]
[0] https://en.wikipedia.org/wiki/Bullshit_Jobs
In any case I can only assume it is pretty profitable because I pay them several dollars a month to basically manage a single entry in a database and manage some paperwork. And considering that major businesses will pay big $$$ for (several!) domains...
Domain squatters, bitsquatters, impersonators etc. create shell companies and run rampant without consequences, and the most companies can try to do is buy up all the TLDs with their name and hope some don't fall through the cracks. It is literally just racketeering.
They can file a legal/beurocratic action, but by time it goes through the damage has already been done to their customers in the form of phishing and MITM attacks.
Not to mention that DNS (excluding finnicky DNSSEC) just maps a domain to an IP address. It's not a public key. You could have your connection middlemanned by your ISP or some 3-letter agency and you would be none the wiser. All the actual security is provided by the PKI.
That's not true, just depends on the TLD.
> Not to mention that DNS (excluding finnicky DNSSEC) just maps a domain to an IP address. It's not a public key. You could have your connection middlemanned by your ISP or some 3-letter agency and you would be none the wiser. All the actual security is provided by the PKI.
PKI you can't trust if nobody can trust the DNS.
And, um, second question: what does "lsd" stand for in this case?
Maybe due to the following?
>This specification was developed outside the IETF and does not have IETF consensus.
https://russell.ballestrini.net/gnunet-gns-nameserver-operat...
[1]: http://goodtimesweb.org/surveillance/2015/MORECOWBELL-Analys...
Other than that, no. GNS itself could also be realised on top of other DHTs, such as libp2p/IPFS (before anyone mentioned the, eh, maturity issues of the reference implementation in GNUnet.)
1. Your implementation/OSes default configuration is messed up. 2. You accidentally messed up your local configuration yourself.
If 4rergdes0903004059 is a zone owned by Xerox (i.e. the zone public key), there is not reason why staples.com would point there unless 1. or 2.
The GNU Name System - https://news.ycombinator.com/item?id=30154830 - Jan 2022 (124 comments)
The GNU Name System IETF Draft - https://news.ycombinator.com/item?id=23766947 - July 2020 (32 comments)