[HN Gopher] The GNU Name System
___________________________________________________________________
The GNU Name System
Author : p4bl0
Score : 311 points
Date : 2022-07-25 09:49 UTC (13 hours ago)
(HTM) web link (www.gnunet.org)
(TXT) w3m dump (www.gnunet.org)
| silvestrov wrote:
| 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".
| Dracophoenix wrote:
| 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.
| NoGravitas wrote:
| 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.
| cowtools wrote:
| TPB is still alive on Tor BTW:
|
| http://piratebayo3klnzokct3wt5yyxb2vpebbuyjl7m623iaxmqhsd52
| c...
| schanzen wrote:
| 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.
| rntksi wrote:
| 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.
| ruuda wrote:
| 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.)
| hericium wrote:
| > 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.
| kevin_thibedeau wrote:
| There's no reason that DoH couldn't be a shared OS service.
| NoGravitas wrote:
| 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.
| tptacek wrote:
| You can simply run your own DoH endpoint, or use the endpoint
| of someone you trust.
| piaste wrote:
| 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).
| folkrav wrote:
| > 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.
| NullPrefix wrote:
| Is anything wrong with Matrix?
| jeroenhd wrote:
| 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.
| raverbashing wrote:
| > 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?
| hypertele-Xii wrote:
| > 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.000G006K2TJN
| MD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884' ?
| schanzen wrote:
| 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.
| silvestrov wrote:
| 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.
| schanzen wrote:
| 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)
| cowtools wrote:
| 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.
| prognu wrote:
| RFC-style spec is at https://lsd.gnunet.org/lsd0001/
| hericium wrote:
| 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?
| forgotpwd16 wrote:
| >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.
| schanzen wrote:
| 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.
| capableweb wrote:
| Most RFCs start without consensus as well, that's why they
| are _R_ equest _F_ or _C_ omments, to reconcile about the
| idea/specification
| junon wrote:
| I can't find much on what "LSD" means here. The root of the
| subdomain has no index, just a file listing.
| schanzen wrote:
| It stands for "Living Standards Document":
| https://www.gnunet.org/en/livingstandards.html
| schanzen wrote:
| It is also currently in the "final" phases of a RFC publication
| (Indepdendent Stream, Informational):
| https://datatracker.ietf.org/doc/draft-schanzen-gns/
| dang wrote:
| 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)
| foxhop wrote:
| I tried to use the gns system last year & got stuck, I blogged my
| progress here
|
| https://russell.ballestrini.net/gnunet-gns-nameserver-operat...
| prognu wrote:
| To answer the last question in your blog post: gnunet-config
| --diagnostics tells you where the configuration file(s) are.
| blippage wrote:
| 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.
| Avamander wrote:
| 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.
| cowtools wrote:
| 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...
| eddieroger wrote:
| 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.
| cowtools wrote:
| 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.
| kelthuzad wrote:
| > 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?
| shakna wrote:
| 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
| schanzen wrote:
| 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
| zerocrates wrote:
| 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.
| schanzen wrote:
| 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)
| p4bl0 wrote:
| This is how it is in I2P too, and it works okay there :).
| smackmybishop wrote:
| Zooko's Triangle might be a factor here. Sounds like they chose
| 'distributed' over 'human-meaningful.'
|
| https://en.wikipedia.org/wiki/Zooko%27s_triangle
| schanzen wrote:
| No, we chose the petname/SDSI solution to the problem:
| https://www.ietf.org/archive/id/draft-schanzen-
| gns-19.html#n...
| gertrunde wrote:
| 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.
| hsn915 wrote:
| The whole point of DNS is for a human readable name to be
| globally recognized.
| cowtools wrote:
| 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.
| notRobot wrote:
| Yes, that is the point of DNS, but that is not the point of
| GNS.
| hansword wrote:
| 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)
| p4bl0 wrote:
| 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 :).
| hsn915 wrote:
| Then why do you need a new name system? Just use the IPv6
| address.
| t-3 wrote:
| Discovery, ease of use, vanity, tradition.
| hsn915 wrote:
| 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?
| schanzen wrote:
| 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.
| t-3 wrote:
| 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.
| kevincox wrote:
| 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).
| bombcar wrote:
| 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.
| MichaelCollins wrote:
| 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.
| latchkey wrote:
| 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.
| ryukafalz wrote:
| They can also put a sticker over the domain name, and
| it's not necessarily going to be clear in the moment if
| mylocalrestaurant.co is invalid and it should be
| mylocalrestaurant.com instead.
| kevincox wrote:
| Nearly all of my QR usage is untrusted links anyways so
| it doesn't make any difference to me.
| p4bl0 wrote:
| > 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.
| PhineasRex wrote:
| 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.
| schanzen wrote:
| 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.
| BeefWellington wrote:
| 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.
| walls wrote:
| So it's basically useless without adding governance which
| eliminates the entire point of this project.
| pessimizer wrote:
| 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.
| naasking wrote:
| > No, you get to choose your governance rather than it
| being chosen for you.
|
| For instance, if you live in China.
| bluejekyll wrote:
| 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.
| balentio wrote:
| 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...
| schanzen wrote:
| 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.
| balentio wrote:
| 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!
| Anunayj wrote:
| I looked into GNS a little while ago and what I understood about
| how it works is:
|
| 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.
| cowtools wrote:
| I was under the impression that DNSSEC is vulnerable to
| downgrade attacks. Is this still the case?
| Anunayj wrote:
| 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/
| belorn wrote:
| 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.
| enzanki_ars wrote:
| 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."
| pul wrote:
| 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 :)
| tucnak wrote:
| 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...
| miki123211 wrote:
| 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.
| PhineasRex wrote:
| As long as you don't mind the astronomical operating cost once
| such a system reaches the scale of DNS, sure.
| cowtools wrote:
| 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.
| NoGravitas wrote:
| Yeah, namecoin was a pretty dramatic failure -- every
| interesting domain on it was squatted early on, when it was
| cheaper to do so.
| aaaaaaaaata wrote:
| Differing itself from ICANN in _what_ way, exactly?
| tptacek wrote:
| In exactly the way stated.
| User23 wrote:
| I think the point being made was that all the
| identifiably good DNS names got squatted back in the 90s
| when they were free.
| hnthrow1010 wrote:
| >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.
| miki123211 wrote:
| > 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.
| tsujp wrote:
| See: Ethereum Name System (https://ens.domains/)
| bouncycastle wrote:
| 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
| NoGravitas wrote:
| How many of those names are not squatted, and have non-
| trivial content?
| rvz wrote:
| 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:
| "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."
|
| I guess it really does make sense to anchor both .eth, .id,
| etc on Handshake [1] after all. The concept of ENS is fine
| for .eth, but it doesn't seem to be enough to prevent this
| sort of basic confusion.
|
| [0] https://twitter.com/matt_willemsen/status/154901782285598
| 310...
|
| [1] https://handshake.org
| hnthrow1010 wrote:
| 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".
| edent wrote:
| _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?
| schanzen wrote:
| 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.
| the_gipsy wrote:
| Why does this not exist?
| panick21_ wrote:
| It exists, many times over
| Avamander wrote:
| It does, but has tradeoffs we don't want. Like having no way
| to curb abuse.
| [deleted]
| NoGravitas wrote:
| 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).
| agentultra wrote:
| 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.
| solardev wrote:
| 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.
| agentultra wrote:
| > 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.
| rvense wrote:
| 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.
| timetraveller26 wrote:
| See: namecoin https://www.namecoin.org/
| NoGravitas wrote:
| Namecoin is a notable failure: https://www.cs.princeton.edu/~
| arvindn/publications/namespace...
| colinsane wrote:
| 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.
| pessimizer wrote:
| 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?
| t-3 wrote:
| 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.
| pessimizer wrote:
| But would it be necessary for ICANN to participate in or
| consent to someone else (trustworthy) making their registry
| available over GNS?
| schanzen wrote:
| 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.)
| pessimizer wrote:
| You can't shim GNS into looking like DNS to the OS?
| schanzen wrote:
| 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...
___________________________________________________________________
(page generated 2022-07-25 23:01 UTC)