So what does an example name look like?
GNS is intended to replace DNS (in a backwards-compatible way) at the ICANN level so if it was ever adopted facebook.com would resolve (by following public key PKEY records, not IP/DNS NS records) using GNS.
In addition, a neat feature of GNS is the hyper-hyper local root. So if you add your friend alice's PKEY in your local root as "alice", then you could resolve whatever in her zone as whatever.alice. But can this not be achieved with DNS already, you may wonder? Two differences:
1) resolution is by public key, so you don't need to keep a mapping of all your friends' nameserver IPs
2) it's intended as a recursive mechanism where you can advertise your favorite domains on your own zone, so for example if i publish The Pirate Bay's public key in my zone in a tpb record, hypothetical tpb.tofu.net will still resolve properly
All in all, GNS is so far the only credible alternative to DNS i've read about, if only because both the protocol and the zonefile syntax are backwards-compatible with DNS.
The main reason would be lack of interest. It's developed by a handful of people who are undertaking one of the biggest tasks in the history of the Internet with very little resources.
Remember how much energy it took to switch everyone to IPv6? Right it still hasn't happened 20 years later: that's exactly the kind of change GNS is about, and that's why it's designed to be backwards-compatible with DNS so we don't end up in the same situation.
I'm open to the idea that the provided implementation could be bad (haven't read the code), and i believe there may be valid criticisms of some parts of the protocol. I just haven't read anything of the sort so far. In both cases, that could hinder adoption, but both could be fixed before GNS is standardized, which is why the authors have been pushing early drafts to the IETF (to gather feedback).
> Are the prevailing registries/registrars opposed to it?
In regards to the ICANN, registries and registrars i'm not aware of any opposition. GNS changes nothing significant to their politics/economics: it would require some time/resources to deploy but arguably nothing terrifying. Registr* specifically are probably entirely unaware of this effort and couldn't care less, especially since GNS is designed in a backwards-compatible manner where people can continue to use regular DNS and it will "just work".
> Would there be any authority that could mediate disputes over who "owns" a name?
This is registry policy and has nothing to do with the protocol. Every registry has a different policy on this matter, which may also be impacted by local regulations.
> Does it address the problem of name-squatting/hijacking?
Hijacking is made harder by GNS because we use public-key cryptography from the start to delegate zones to a third-party, not location (IP/domain). It's like DNSSEC but better because you don't have to mess with your zone to advertise the key (the key *is* your zone identifier in the DHT).
As for name-squatting, this is again entirely unrelated to GNS as it has to do with ICANN/registry policies. GNS is about better technical foundations for DNS in the 21st century, it's *not* about changing the politics of the ICANN root (although it's arguably an empowering technology for alternative roots to emerge).
Hope i answered your questions. (there may be some details i got wrong as i'm not involved with GNS project)
For a such long answer, you could just mention this at beginning and stop there. This is a reason it will never become a standard. There is no possibility that a central authority will endorse a tool that will potentially make them obsolete or create a competitor to them.
It's a GNU project.
Imagine for a moment this was a Microsoft project, and was called MSDNS. Would the name matter? I would argue that it does.
Granted that basically no non-techie has ever heard of GNU (or the FSF) - despite the insistence on calling it GNU/Linux - I don't think it'll be a deal breaker, but I think it's uncool to put a "company" name/trademark in a global standard protocol name.
So for me it's not the creators, but rather the name itself that warns a down vote.
I value the GNU project's ethical framework and feel like that's worth fighting for/with, although i personally am strongly opposed to the current internal politics of the FSF which are definitely not aligned with the base/masses of the libre-software movement.
Also GNU = small non-profit, Microsoft = giant corporation.
> So if you add your friend alice's PKEY in your local root as "alice", then you could resolve whatever in her zone as whatever.alice.
This sounds very undesirable to me. The same address resolving to the same website for everyone is a useful property of the current system.
This is a desirable property for many companies that filter employee internet access from their internal network right on the DNS level.
That's already only guaranteed under the public root, which GNS intends to preserve: the situation would not change in this regard. I can already map "hn" to a well known HN IP address in my /etc/hosts: the only hurdles would come from my web browser sending the "hn" Host header (easily fixed) and trying to validate the remote TLS certificate for "hn" (less easily fixed). In this regard, GNS would be different in that i could delegate "HN" to a public key and not be bound to the IP suddenly changing under my feet.
On a higher level, i would argue the difference is GNS by design empowers users to archive/publish records because they don't need to operate infrastructure for that. If you already have a domain name and are familiar with DNS, publishing records is not that hard: GNS would make it far easier because since the records live in the DHT you only need client UX to publish a zone, no need to configure a name server or to point your client configuration to a specific name server API.
Yes! Finally a protocol that does not discriminate against non-ASCII languages (like punycode does in my opinion).
Hello, my name is xn--jeprenj-rqb! </rant> (:
— Falsehoods Programmers Believe About Names https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...