schanzen

Presentation given at IETF 118: https://datatracker.ietf.org/meeting/118/materials/slides-11...

Co-author here. If you look into the R5N paper (link in draft), you can find this term. If you assume a routing performance of O(log n) and O(sqrt (n)) number of lookups to find the value, you get O (sqrt (n) * log n) as overall complexity (last section in paper).

For the argument of the sqrt (n) itself, see the paper.

Edit 1: Quote: "Assuming that T [random path length] is chosen large enough to achieve perfect mixing, sqrt (n / (c−1)) replicas would need to be created in order for a GET request to succeed with about 50% probability according to the birthday paradox."

Edit 2: In a world without local minima the term itself will be 1 (you only need a single lookup and will find the value with 100% probability. In the restricted route scenario you will have to so O(sqrt(n)) lookups.

Our recent webinar shows the state of GNS, and addresses some recurring questions regarding governance, how name registration is supposed to work and the RFC.

This is correct. I would like to add that the ISE also had us engage with a variety of stakeholders within the IETF (dnsop, for example, as part of discussions on RFC 9476) and also expected some third party reviews.

This is probably the time to thank and give credit to all reviewers and the ISE in particular, again :) https://www.rfc-editor.org/rfc/rfc9498.html#name-acknowledge...

These are all valid deployment questions, which we tried to address in Appendix A.

In a nutshell, we expect that resolvers would ship with a (large) set of default "suffix-to-zone" mappings, that can be overridden by the user to provide a usable and convenient out-of-the box experience. Not that "we expect" means that this would be the ideal scenario, not something to expect when installing our reference implementation right now.

Indeed that would work. In theory. Especially since we thought of that use case (delegation into DNS) with the GNS2DNS record type.

There is a BUT: You need an initial label for ICANN zone to resolve the names. Unless you have a resolver implementation that "hides" the zkey of ICANN in the UI. But technically, under the hood, a name for this ICANN zone would look like:

www.example.com.THEICANNZKEY...

ICANN could also publish the TLDs individually as zones, however, and you could have an "ICANN Start Zone" (see Start Zone in the RFC) consisting of the TLD/zone key mappings.

We are currently working on mirroring some DNS TLDs: https://www.gnunet.org/en/news/2022-11-NGI-Entrust-GNS-TLDs....

I have been a bit preoccupied with the RFC and other stuff recently, but its progressing.

Basically that means you have an issue with https://www.rfc-editor.org/rfc/rfc9476.html, not GNS.

GNS, in theory, could replace DNS (the technology) and reuse its current root governance model as default.

From the point of view of GNS namespace governance is separate from name resolution protocols. Of course, from the point of view of a lot of DNS folks, DNS is both: The governance (ICANN) and the technology (RFC 1035 et al) and indivisible.

We use this SU-TLD in our GNS draft which is also already in the editor queue: https://datatracker.ietf.org/doc/draft-schanzen-gns/

This is really nice information. Thank you!

FWIW we have recently acquired funding to demonstrate that GNS can handle large size zones by migrating TLD zones (available through AXFR for now, the number of zones supporting hat is, eh, marginal [1]) to GNS which delegate back into DNS (using [2]).

This allows GNS users to (partially) circumvent the root and manually manage their local root namespace as envisioned for GNS [3].

We think that shipping default configurations and allowing users to modify/enhance that locally is how governance should look like from the user's perspective. If you want ICANN as default -> use the ICANN default configuration... if you need to override a censored/censoring registry, you can do that too... etc

[1] https://jpmens.net/2021/05/18/dns-open-zone-data/ [2] https://www.ietf.org/archive/id/draft-schanzen-gns-21.html#n... [3] https://www.ietf.org/archive/id/draft-schanzen-gns-21.html#n...

For our transitive use of petnames in name systems see also https://datatracker.ietf.org/doc/draft-schanzen-gns/ and https://www.gnunet.org/en/gns.html

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)

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 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 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.)

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.

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.

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)

No, we chose the petname/SDSI solution to the problem: https://www.ietf.org/archive/id/draft-schanzen-gns-19.html#n...

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.

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.

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.

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.

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

It is also currently in the "final" phases of a RFC publication (Indepdendent Stream, Informational): https://datatracker.ietf.org/doc/draft-schanzen-gns/

It stands for "Living Standards Document": https://www.gnunet.org/en/livingstandards.html

We use recutils for the GNUnet and GNU Taler names and numbers registry: https://gana.gnunet.org Using the recsel and recfmt tools that come with it you can autogenerate header/source files of constants from such a format into whatever language you need. For example, we do that for the GNU Name System record types: https://datatracker.ietf.org/doc/draft-schanzen-gns/ https://git.gnunet.org/gana.git/tree/gnu-name-system-record-...

So, quite useful if you have a protocol specification with constants from which you want to generate code.

To be honest: I would prefer our mailing list for discussions (see top post). Our email addresses are also in the draft. A lot of discussions happen via the IETF Datatracker infrastructure and internal email discussions/meetings. We have a monthly gnunet jour fixe and we do post news entries (https://www.gnunet.org) We dropped our IRC channel when the freenode apocalypse happened.