Does anyone have a good overview of how GNS works? I tried reading the docs, but it wasn’t clear to me how you avoid conflicts (does first to register win, or are GNS hierarchies in different namespaces for different root keys)?
Requiring key backup for recovery is going to be a problem for a lot of users. It also doesn’t look like there’s any mechanism for what to do if your key is stolen. With centralised DNS, you can use an out of band mechanism to convince your DNS provider (or SOA record owner) to fix it. For a decentralised system, you’d want something like a Shamir Secret Sharing system where a consortium of N of M designated people can force key rollover for your identity.
Every person controls their own root zone, and can map names to keys in it.
alice can publish their zone KeyA, and bob can map alice as keyA in their zone.
Now if bob publishes their zone KeyB to Caroline, and Caronline mapped bob to KeyB, she could resolve www.alice.bob to reach the www record in alice’s zone.
Additionally the lookup is kept confidential from the rest of the network.
There are no conflicts since every user manages their zone, and their preferred names for those zones.
By default the system ships with some zones preconfigured. But the way those zones assign records would be entirely up to each zone operator. Some may be first come first serve, others could operate similarly to how registrars operate today.
Many domains can point to the same service. And I expect users would pin services they use in their own zones kind of like bookmarks. And that communities would link to their own members zones.
This way a sort of social graph with contextual names gets built.
I have been thinking about graph name systems, though I haven’t studied the GNU name system.
Something interesting happens when I consider what mass adoption would look like. In particular, “By default the system ships with some zones preconfigured” — yes, that is necessary, especially if the ambition is to replace DNS. These built-in zones are doing effectively the same job as the DNS root zone.
So if operating systems ship with GNS support, the OS suppliers get to choose the built-in zones. They are now taking on the job of ICANN. I guess top-level GNS management would be a bit like the CA / Browser Forum — tho it would be impossible to avoid the infestation of trademark lawyers that ICANN labours with. As a result, a decentralized system becomes centralized.
I really like the peer-to-peer aspects of a GNS, but I don’t think it can eliminate the evils of the DNS.
For what it’s worth, GNS is aimed at solving protocol issues of DNS rather than organizational ones.
For what it’s worth, OS suppliers get to choose the built-in zones right now as well. There’s nothing stopping you from running alternative root zones with DNS as is, it’s just that vendors choose to default to ICANN’s one. The same could be done using GNS as well, with ICANN potentially pushing TLDs to transition into resolving using GNS instead of DNS, mirroring the zones during the transition period.
The protocol issues being solved are important issues. Organizational issues don’t particularly need a different protocol.
For a decentralised system, you’d want something like a Shamir Secret Sharing system where a consortium of N of M designated people can force key rollover for your identity.
I tried reading the docs, but it wasn’t clear to me how you avoid conflicts (does first to register win, or are GNS hierarchies in different namespaces for different root keys)?
If I understood you correctly, both. User resolving some name starts at the initial zone that’s been configured, and then looks up the information needed in it, recursing on delegation. Whoever controls the zone controls the naming, and for example the GANA registry that’s been setup for .alt goes by first to register policy. But if you wanted, you could set up your own .alt registry, but you’d need to convince users to set their configuration to point .alt requests into your zone.
Lots of custom binary blob formats like it’s the 80s. Very DNS. I wonder if something like CBOR or similar could do better here. Perhaps there is some DNS compatibility issue? If so, it doesn’t leap out at me.
I found the info on the project page to contain a decent summary of the project motivation. Of course there is a bit of marketing speak, but that can be safely ignored.
Does anyone have a good overview of how GNS works? I tried reading the docs, but it wasn’t clear to me how you avoid conflicts (does first to register win, or are GNS hierarchies in different namespaces for different root keys)?
Requiring key backup for recovery is going to be a problem for a lot of users. It also doesn’t look like there’s any mechanism for what to do if your key is stolen. With centralised DNS, you can use an out of band mechanism to convince your DNS provider (or SOA record owner) to fix it. For a decentralised system, you’d want something like a Shamir Secret Sharing system where a consortium of N of M designated people can force key rollover for your identity.
Every person controls their own root zone, and can map names to keys in it.
alice can publish their zone
KeyA, and bob can mapaliceaskeyAin their zone.Now if bob publishes their zone
KeyBto Caroline, and Caronline mappedbobtoKeyB, she could resolvewww.alice.bobto reach thewwwrecord in alice’s zone.Additionally the lookup is kept confidential from the rest of the network.
There are no conflicts since every user manages their zone, and their preferred names for those zones.
By default the system ships with some zones preconfigured. But the way those zones assign records would be entirely up to each zone operator. Some may be first come first serve, others could operate similarly to how registrars operate today.
Many domains can point to the same service. And I expect users would pin services they use in their own zones kind of like bookmarks. And that communities would link to their own members zones.
This way a sort of social graph with contextual names gets built.
I have been thinking about graph name systems, though I haven’t studied the GNU name system.
Something interesting happens when I consider what mass adoption would look like. In particular, “By default the system ships with some zones preconfigured” — yes, that is necessary, especially if the ambition is to replace DNS. These built-in zones are doing effectively the same job as the DNS root zone.
So if operating systems ship with GNS support, the OS suppliers get to choose the built-in zones. They are now taking on the job of ICANN. I guess top-level GNS management would be a bit like the CA / Browser Forum — tho it would be impossible to avoid the infestation of trademark lawyers that ICANN labours with. As a result, a decentralized system becomes centralized.
I really like the peer-to-peer aspects of a GNS, but I don’t think it can eliminate the evils of the DNS.
Not only trademarks but also phishing and putting up malicious fake versions of websites to dispense malware and harvest credentials.
For what it’s worth, GNS is aimed at solving protocol issues of DNS rather than organizational ones.
For what it’s worth, OS suppliers get to choose the built-in zones right now as well. There’s nothing stopping you from running alternative root zones with DNS as is, it’s just that vendors choose to default to ICANN’s one. The same could be done using GNS as well, with ICANN potentially pushing TLDs to transition into resolving using GNS instead of DNS, mirroring the zones during the transition period.
The protocol issues being solved are important issues. Organizational issues don’t particularly need a different protocol.
Recent talk from the project lead at GNU 40 event:
https://audio-video.gnu.org/video/gnu40/name-system-gnu40.pdf
https://audio-video.gnu.org/video/gnu40/namesystem-gnu40.webm
I believe that they have built exactly this: https://www.gnu.org/software/anastasis / https://anastasis.lu/papers/thesis-anastasis-2020.pdf …
If I understood you correctly, both. User resolving some name starts at the initial zone that’s been configured, and then looks up the information needed in it, recursing on delegation. Whoever controls the zone controls the naming, and for example the GANA registry that’s been setup for .alt goes by first to register policy. But if you wanted, you could set up your own .alt registry, but you’d need to convince users to set their configuration to point .alt requests into your zone.
Lots of custom binary blob formats like it’s the 80s. Very DNS. I wonder if something like CBOR or similar could do better here. Perhaps there is some DNS compatibility issue? If so, it doesn’t leap out at me.
I found the info on the project page to contain a decent summary of the project motivation. Of course there is a bit of marketing speak, but that can be safely ignored.
https://www.gnunet.org/en/news/2023-11-RFC9498.html