Presentation given at IETF 118: https://datatracker.ietf.org/meeting/118/materials/slides-11...
98 karma · joined July 8, 2020
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.
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...
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.
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.
I have been a bit preoccupied with the RFC and other stuff recently, but its progressing.
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.
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...
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.
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.)
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.
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.
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)
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.
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.
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.
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
So, quite useful if you have a protocol specification with constants from which you want to generate code.
Is the namespace decentralized? That depends on how you use it. If you use GNS with an ICANN provided root zone configuration (this is an example, there is no such thing atm), then your names will have the same meaning as for other people using this configuratin. If you build your root zone from scratch, you will have modified the namespace in such a way that names are no longer unique. If you go full petname system (ie. names are basically treated as your personal address book), the names are no longer unique.
Think about DNS: If you are sufficiently technically literate, you can run your own root servers and use them. Is DNS at odds with Zookos triange? I would argue: Yes, depending on how you use it. It is just very common to use it with unique global names.
The reason why gnunet appears to be "redo-everything" is because that is exactly what is necessary if you take the issues seriously and think them through.
The reason why it takes so long is also because we are a small team and the goal does not provide instant gratification while at the same time being very hard to achieve.
It is a lot of systems programming and engineering. It is a lot more fun to reinvent the wheel in the newest shiny technology.