The GNU Name System(gnunet.org)
gnunet.org
The GNU Name System
https://www.gnunet.org/en/gns.html
146 comments
I couldn’t find any contact info for you, but if you’d like to do a paid write up on GNS for nslookup.io, please contact me :)
Ha, thanks, however I do not think I know enough about GNS to be able to do a good writeup on it. I tried figuring GNS out few months ago (in an attempt to use Handshake for the bootstrapping root zone), but had trouble running their tooling and promptly gave up, and that's where the research stopped.
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 :)
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 :)
I was under the impression that DNSSEC is vulnerable to downgrade attacks. Is this still the case?
DNSSEC has support for denial of existence (NSEC/NSEC3) proofs, which means resolvers may require the resolver to provide them. This means you can't just MITM a DS record away. However practically most people dont use locally DNSSEC verifying resolvers, instead relying on upstream resolvers to do the job for them, which can be easily manipulated by your ISP.
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]
1. https://blog.cloudflare.com/black-lies/
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]
1. https://blog.cloudflare.com/black-lies/
To put this in a bit of context, a regular NSEC3 is 1kb of data. Black lies are 350b. The average website is 1600kb. Cloudflare's black lies seems more to target the computational work on cloudflare's part, since a unique lookup at cloudflare require both an expensive database search and a computational expensive signing of the answer.
Cloudflare also outlines the following reason in the linked blog post:
> "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."
> "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."
This might be an unpopular opinion, but I think that decentralized DNS, and decentralized naming in general, is one of the few use cases that can be neatly solved by a blockchain, but is extremely hard to solve any other way.
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.
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.
I don't have a lot of faith in the namecoin or namecoin-derivative solutions. Just because an agent has a lot of cryptocurrency or hash power doesn't mean they should be able to steal or squat a domain. There are security consequences for domain ownership.
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.
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.
Yeah, namecoin was a pretty dramatic failure — every interesting domain on it was squatted early on, when it was cheaper to do so.
Differing itself from ICANN in what way, exactly?
>This might be an unpopular opinion, but I think that decentralized DNS, and decentralized naming in general, is one of the few use cases that can be neatly solved by a blockchain, but is extremely hard to solve any other way.
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.
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.
> 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.
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.
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.
Or you can simply trust the organization bootstrapping the naming system by other means and not use a blockchain to defend against this hypothetical scenario at a high energy/compute cost.
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.
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.
That only works if the users trust their government(s), where geopolitics are stable, and where freedom from censorship is a cultural norm. All of those things are increasingly rare, and centralized domain names are an easy way for states or competing governments to block access to undesirable materials.
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.
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.
> 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.
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.
> 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.
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
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
What do you mean? Blockchains are already heavily lopsided. Throwing state resources into the mix would only make that worse.
You think the government would have more than 51% of the compute power of the entire world? If that were true they could easily break TOR
Yes, quite trivially? Compute power is more a function of dollars than population. Don't they already surveil most Tor exit nodes?
> Yes, quite trivially? Compute power is more a function of dollars than 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
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
Correct.
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.
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.
voila, it isn't any different than the current system.
While far from perfect the existing system has many properties that are good enough.
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.
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.
- they are nowhere nearly good enough. the current system satisfies only one criteria of the 'security, user-chosen names, and decentralization' trifecta, and even that just barely.
- 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
- 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
See: namecoin
https://www.namecoin.org/
Namecoin is a notable failure: https://www.cs.princeton.edu/~arvindn/publications/namespace...
Which Blockchain? If you use, for example, .eth on one chain - there's literally nothing stopping me from instigating a new chain which also uses .eth
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?
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?
See: Ethereum Name System (https://ens.domains/)
ENS is a good example of a working concept of blockchain domains and is the only type of NFT that cannot be 'right-click saved', unlike the JPEG ones.
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:
[0] https://twitter.com/matt_willemsen/status/154901782285598310...
[1] https://handshake.org
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...
[1] https://handshake.org
There's also the matter that ENS "solves" the problem by reintroducing a central point of failure: the smart contract itself. Anything blockchain-adjacent really can't conceivably be called "decentralized".
ENS leads by far in the blockchain space. Almost 2 million names registered.
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
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
How many of those names are not squatted, and have non-trivial content?
Theoretically, you could combine a blockchain-based root zone governance (e.g. Handshake) with GNS. This would give you globally unique names and efficient and private delegated names.
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.
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.
or you can go the Secure Scuttlebutt route where the user resolves a name based on some simple function of how your peers (which you explicitly choose) resolve it.
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.
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.
[deleted]
As long as you don't mind the astronomical operating cost once such a system reaches the scale of DNS, sure.
You could solve decentralized naming with a blockchain. But blockchains have negative externalities (yes, even proof of work), and decentralized DNS can be solved without one (with a DHT being an obvious part of the solution).
Why does this not exist?
It does, but has tradeoffs we don't want. Like having no way to curb abuse.
on the contrary, that's the thing we want the most. having no way to curb abuse is what gave Tor a few orders of magnitude more adoption than the other alternative internets. having no way to curb abuse is what made crypto market what it is.
it's really not. not I or anyone I know wants a web filled with malware, CSAM or spam that is difficult to remove. Onion links already being the Russian roulette they are, the tendency is rather clear, nobody* really wants that.
You should decouple existing from experiencing it. Me too, like you, don't want to experience what I consider malware, spam, etc.
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
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
In theory that's a reasonable approach, in reality we've tried that on the web with all the restrictions we have. Antiviruses, real-time spam blocklists, adblockers all perpetually try to catch and block malicious actors, so far they haven't succeeded. On the local level as well, registrars have to follow local laws.
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.
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.
Most of those methods will still work under a decentralized DNS, because although it's decentralized at the global layer, there will still be centralized clusters
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
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
it's not the name servers' job to deal with any of that, especially on the clearnet
It's the host of those name servers' job, yes.
you're arguing that its yellow pages job to remove the entry for businesses that violate laws. not only is that not the case, that's profoundly absurd.
It is! If a doctor listed on yellow pages is not really a doctor then they shouldn't be there to mislead people. This analogy extends wonderfully, really. If that fake doctor is also infecting people with illnesses or takes pictures secretly, then it's not only a legal mandate, it's also an ethical one.
and that's the authority you choose to report such a transgression to - not the police, not the oversight agencies, but the yellow pages? that's who you expect to investigate your report a make a judgement about its validity?
Reporting to the law enforcement and removing a "number" are not mutually exclusive. But law enforcement has got their hands full with the more illegal stuff already. So leaving the not too difficult to detect - simple spam, scam and malware to the registrars and hosts to deal with - is not ridiculous.
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?
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?
it is an observation. the two systems without punitive measures I have provided as an example in my original comment - crypto and tor - have been doing alright for more than a decade.
It exists, many times over
> How can a legitimate domain owner tell other people to not use his name in GNS?
> 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?
> 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?
This is a complex question. In order to use GNS "like" DNS, you need a similar Root Zone governance. See also https://www.ietf.org/archive/id/draft-schanzen-gns-19.html#n... and https://www.ietf.org/archive/id/draft-schanzen-gns-19.html#n...
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
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
I mean, DNS also doesn't care at a protocol level about governance, right?
It's just the actual, practical DNS system that everybody actually uses which does.
It's just the actual, practical DNS system that everybody actually uses which does.
Yes. And it is totally possible that a "common" and default use case with GNS looks just like DNS.
The spec just does not mandate the governance. In fact, it mandates implementations to honor user-chosen configurations for petname overrides.
(See my other comments)
From the doc, it appears that the name isn't the name. ;)
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.
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.
The whole point of DNS is for a human readable name to be globally recognized.
I have configured my browser to go to news.ycombinator.com when I type "hn" in its URL bar. The domain name could be anything even a b32 hash I wouldn't mind, I would still just type "hn".
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 :).
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 :).
Although almost all users just use a search engine. Actually typing in domains is dying (very slowly). I still do it occasionally for things written "in the real world" but this is slowly getting replaced with QR codes.
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).
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).
The apparent dichotomy of either using a search engine or typing out the full domain is confusing. What I do 99% of the time is type two or three letters into the address bar and let the rest of the address complete from my browser history. Giving those two or three letters to google to doesn't seem like it would do anything to improve the process, it's just a default that browsers foist on users because Google pays the browser developer for it.
That is how people use domain names, but people are a very small subset of the DNS "customers" - all applications and websites hit DNS quite often.
I stopped using qr codes when I realized how easy it is for someone to put a sticker over an existing code and send me to a phishing site. Certainly, I can do it super cautiously, but it definitely seems like an easy attack vector.
> Although almost all users just use a search engine.
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.
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.
Then why do you need a new name system? Just use the IPv6 address.
Discovery, ease of use, vanity, tradition.
I thought we just established that the names in the GNU Name System are not meant to be human readable, and that the human readable names are not "owned" by anyone.
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?
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?
It is important to distinguish the technical procedure of resolving a name with the namespace governance.
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.
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.
Why wouldn't they be able to discover your site through the human readable name? They just wouldn't go to a centralized source of truth to find that name, but ask trusted peers for it. IIUC, it's not a huge difference in practice from how things already work, but the technical side allows greater resiliency to attacks from malicious parties.
Yes, and you could apply the DNS governance model to GNS.
For example:
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.
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.
DNS is just a system whereby you can translate any name to any IP address. Global has nothing to do with it. In fact, by nature DNS is almost always local (you go to your chosen DNS server's IP to get the data). Your DNS server is free to lie to you about the real IP for www.google.com.
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.
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.
So it's basically useless without adding governance which eliminates the entire point of this project.
No, you get to choose your governance rather than it being chosen for you. That seems like an really important thing when we normally talk about governance.
> No, you get to choose your governance rather than it being chosen for you.
For instance, if you live in China.
For instance, if you live in China.
That’s not always how DNS is used in practice. There are lots of different configurations where there’s a local portion that represents a non-global name. This isn’t necessarily best practice, mind you, because it can have security implications if the name doesn’t resolve locally but does remotely.
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.
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.
Think about how the hosts.txt file was originally used before the DNS. It's closer to that (with a lot of extra sophistication and 40+ year learning)
The only thing that needs to be globally recognized are public keys. The distribution of those public-key/identity pairs is a social problem that the existing DNS/PKI does not solve but rather makes worse.
Users anonymously subscribe to root zones that they trust, or act as their own authority.
Users anonymously subscribe to root zones that they trust, or act as their own authority.
All decentralized domain systems by definition do not address universality and thus require a change in user behavior. The core idea is a return to pre-internet naming where "Sal's Pizza" refers to a different establishment in different cities.
There are pros and cons to this approach but the point is not to exactly replicate DNS.
There are pros and cons to this approach but the point is not to exactly replicate DNS.
Yes, that is the point of DNS, but that is not the point of GNS.
Unlike DNS, GNS doesn't require that only one nick be bound to a domain to be resolved. [0] There's a series of preferences for the order of resolution, which means that you can prioritise your friend over someone else.
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.
[0] https://lsd.gnunet.org/lsd0001/#name-nick-2
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.
[0] https://lsd.gnunet.org/lsd0001/#name-nick-2
This is how it is in I2P too, and it works okay there :).
Zooko's Triangle might be a factor here. Sounds like they chose 'distributed' over 'human-meaningful.'
https://en.wikipedia.org/wiki/Zooko%27s_triangle
https://en.wikipedia.org/wiki/Zooko%27s_triangle
No, we chose the petname/SDSI solution to the problem: https://www.ietf.org/archive/id/draft-schanzen-gns-19.html#n...
Seems like "X Window" system: the right solution to the wrong problem.
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".
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".
> 5) Privacy is already solved using "DNS over https".
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.
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.
I imagine the GNU answer would be that you shouldn't run hostile / nonfree software on your machines, and you should simply be able to tell your software not to contact undesired servers (via configuration or, worst case scenario, recompilation).
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).
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).
> Having recently fully de-Big-Teched all my devices, I have the luxury of agreeing with that philosophy.
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'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 was inaccurate, sorry. My devices only run either Linux or rooted LineageOS, but I do run some hostile Big Tech apps on them like WhatsApp or Tinder. However, I use tools like TrackerControl and Insular to prevent them from calling hosts other than those I have explicitly whitelisted, or from accessing data they shouldn't.
I still avoid installing them when possible. Facebook, Airbnb, and many others work just fine via their websites.
I still avoid installing them when possible. Facebook, Airbnb, and many others work just fine via their websites.
Is anything wrong with Matrix?
Honestly just never explored it much, but my whole family and friend circle is on Facebook Messenger. Does this work through Matrix in some way?
It solves the problem of your ISP's DNS resolver being hostile in one way or another. But you still have to have complete trust in the resolver you choose. Which is not great if most people choose $BIGCORP's resolver.
In my opinion, most of DoH's protocol problems (and implicated problems) have been solved by oblivious DoH.
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.
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.
> but at the same time it hides application requests from the user, renders user's own DNS-based filtering (pihole and such) useless
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?
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 cannot trust non-free software to use OS DNS settings (Chrome taught me that).
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.
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.
You can simply run your own DoH endpoint, or use the endpoint of someone you trust.
What about software that could query another endpoint without my knowledge?
Even early Google Chrome shat on OS DNS settings and was querying 8.8.8.8 but that could be filtered.
Even early Google Chrome shat on OS DNS settings and was querying 8.8.8.8 but that could be filtered.
What about it? If you can't trust it, you can't trust it. You either control it, don't control it and don't care, or don't control and it's a moot point. Nothing you deploy even needs to use "real DNS" to look things up; it could just set up a TLS channel with an IPv4 rendezvous.
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.
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.
There's no reason that DoH couldn't be a shared OS service.
6) In the spec we clarify:
"While DNS is distributed, in practice it relies on centralized, trusted registrars to provide globally unique names. As the awareness of the central role DNS plays on the Internet rises, various institutions are using their power (including legal means) to engage in attacks on the DNS, thus threatening the global availability and integrity of information on the Internet."
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.
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.
I hate that I had to double check when you said "GNS uses crypto" and realised you meant crypto as in cryptography, not the other meaning commonly associated with blockchain coins.
> Real problem: domain squatters. Can't see GNS solves this.
What's the point of squatting random identifiers? Seriously, what damage does it do to you if I "squat" on ´www.000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884´ ?
What's the point of squatting random identifiers? Seriously, what damage does it do to you if I "squat" on ´www.000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884´ ?
Actually, GNS does solve this partially:
If there is a squatter for, e.g. example.com, and this is a troll preventing Example Co from claiming their "name", they could just lobby/advertise for this mapping configuration in start zone configurations:
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.
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.
I would consider this to "unsolve it".
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.
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.
Well compelling the TLD owner (in this case .com) through the courts to change the delegation to your zone also works in GNS. (You would not force some kind of "hand over" of the example.com domain. Because that is not how it works).
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)
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)
1) Censorship is a very real problem on the clearnet.
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.
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.
Censorship is a big problem. The Daily Stormer is a canary in the coal mine for how controversial clearnet websites can be censored in countries that have not yet gone the China route.
I mean, fuck the Daily Stormer, but the sites that have been most subject to state-mandated DNS blocking are primarily torrent search engines, which most people would agree are a good thing. I'm willing to accept the loss of DNS blocking as an avenue to attack the Daily Stormer in order to preserve the Pirate Bay.
TPB is still alive on Tor BTW:
http://piratebayo3klnzokct3wt5yyxb2vpebbuyjl7m623iaxmqhsd52c...
http://piratebayo3klnzokct3wt5yyxb2vpebbuyjl7m623iaxmqhsd52c...
1) is a much smaller problem than 2) indeed, but it does still happen.
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.)
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.)
Seems interesting.
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.
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.
It actually takes quite a bit of work to operate a registrar.
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.
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.
I have no doubt that there is hard work running a registrar, but it is ultimately just meaningless bureaucracy if the system it is servicing (DNS) is not actually useful to society at large. It is in essence, a "Bullshit Job"[0]:
>[...] 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...
>[...] 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...
It doesn't seem like bullshit to me to make sure that people claiming to be someone are actually them, and others who claim otherwise are not. With the anonymity the Internet brings, I find comfort in knowing that the URL I type in my browser is actually the endpoint I wish to receive. If that takes humans to deal with, so be it.
If that brings you comfort, then you should not be comforted as registrars will not do what you're describing.
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.
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.
> If that brings you comfort, then you should not be comforted as registrars will not do what you're describing.
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.
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.
RFC-style spec is at https://lsd.gnunet.org/lsd0001/
It is also currently in the "final" phases of a RFC publication (Indepdendent Stream, Informational): https://datatracker.ietf.org/doc/draft-schanzen-gns/
Just came here with the same link in my clipboard and a question: What would be the reason for using "lsd" instead of popular IETF RFCs? The fact that RFC is supposed to open a dialogue/discussion and "lsd" is something final? (edit: it isn't; it's a IETF-style Internet-Draft). Other LSDs on that site link to RFCs.
And, um, second question: what does "lsd" stand for in this case?
And, um, second question: what does "lsd" stand for in this case?
It stands for "Living Standards Document": https://www.gnunet.org/en/livingstandards.html
I can't find much on what "LSD" means here. The root of the subdomain has no index, just a file listing.
>What would be the reason for using "lsd" instead of popular IETF RFCs?
Maybe due to the following?
>This specification was developed outside the IETF and does not have IETF consensus.
Maybe due to the following?
>This specification was developed outside the IETF and does not have IETF consensus.
Most RFCs start without consensus as well, that's why they are Request For Comments, to reconcile about the idea/specification
This sentence is usually added for specifications which are submitted independently to the Independent Stream Editor, as opposed to drafts which are discussed in a WG at IETF.
I tried to use the gns system last year & got stuck, I blogged my progress here
https://russell.ballestrini.net/gnunet-gns-nameserver-operat...
https://russell.ballestrini.net/gnunet-gns-nameserver-operat...
To answer the last question in your blog post:
gnunet-config --diagnostics tells you where the configuration file(s) are.
Hey check 'tis paper [1] by Christian Grothoff (the creator of GNU Taler) on NSA program MORECOWBELL that is mentioned in the GNS landing page.
[1]: http://goodtimesweb.org/surveillance/2015/MORECOWBELL-Analys...
[1]: http://goodtimesweb.org/surveillance/2015/MORECOWBELL-Analys...
This is completely off topic but i was interested in an old answer of yours. Why is Sasha an appropriate nickname for Alexander in all speech but reserved for informalities with Alexandra?
From a non-expert: is there any reason (other than consumer packaging and polish) that a system like this couldn't be rolled out immediately, with ICANN as the default provider?
There are a lot of stakeholders involved and a lot of applications relying on DNS may have problems (browsers).
So the migration path is long and winded I guess.
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.)
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.)
You can't shim GNS into looking like DNS to the OS?
You can. Either using nsswitch plugins or a local DNS service that resolved the names in GNS.
But, browsers are delicate when it comes to TLS certificates, for example.
See also https://www.ietf.org/archive/id/draft-schanzen-gns-19.html#n...
There's no technical reason it couldn't, but a big non-technical one: it doesn't allow for the rent-seeking behavior that supports ICANN and the internet name industry.
But would it be necessary for ICANN to participate in or consent to someone else (trustworthy) making their registry available over GNS?
Am I right to conclude you can have multiple pet names pointing to a single global name? If so, might this lead to something like brand confusion? For instance, let's say I have a place called 4rergdes0903004059 as a global identifier for my company, Xerox. I would then make a pet name of something like Xerox.com to point to said global. However, Staples.com also points as a pet name to my Xerox global identifier...
From a technical perspective this is possible, I think. But it would mean one of two things:
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.
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.
Ah, so the answer is basically no, since the key to the zone would not allow this mapping so long as everything was configured correctly. I did not see the key part but I did skim the article. Thanks!
Related:
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)
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)
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.