commit f906fcff9d8ff6a3b475096d06295ae22d745cf5
parent 77f52c822c45b0827145a112ac3ddfd96df2e0da
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Wed, 9 Mar 2022 21:21:33 +0100
graphics
Diffstat:
1 file changed, 61 insertions(+), 3 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -191,6 +191,12 @@
An application refers to a component which uses a GNS implementation
to resolve names into records and processes its contents.
</dd>
+ <dt>Resolver</dt>
+ <dd>
+ The resolver is the part of the GNS implementation which implements
+ the recursive name resolution logic defined in
+ <xref target="resolution"/>.
+ </dd>
<dt>Name</dt>
<dd>
A name in GNS is a domain name as defined in <xref target="RFC8499"/>
@@ -326,8 +332,8 @@
</t>
<t>
Zone contents are encrypted and signed
- before being published in a distributed key-value storage
- (<xref target="publish"/>).
+ before being published in a distributed key-value storage (<xref target="publish"/>)
+ as illustrated in <xref target="figure_arch_publish"/>.
In this process, unique zone identification is hidden from the network
through the use of key blinding.
Key blinding allows the creation of signatures for zone contents
@@ -347,9 +353,35 @@
based on <xref target="RFC7363" />, <xref target="Kademlia" /> or
<xref target="R5N" />.
</t>
+ <figure anchor="figure_arch_publish" title="An example diagram of two hosts publishing GNS zones.">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ Local Host | Distributed | Remote Host
+ | Storage |
+ | |
+ | +--------+ |
+ | / /| |
+ +---------+ Publish | +--------+ | | Publish +---------+
+ | | Zones | | | | | Zones | |
+ | GNS |----------|->| Public | |<-|----------| GNS |
+ | | | | Zones | | | | |
+ +---------+ | | |/ | +---------+
+ A | +--------+ | A
+ | | | |
+ +---------+ | | +---------+
+ / | /| | | / | /|
+ +---------+ | | | +---------+ |
+ | | | | | | | |
+ | Local | | | | | Local | |
+ | Zones | | | | | Zones | |
+ | |/ | | | |/
+ +---------+ | | +---------+
+ ]]></artwork>
+ </figure>
<t>
+ Applications use the GNS implementation to lookup GNS names.
Starting from a configurable start zone, names are resolved by following zone
- delegations. For each label in a name, the recursive GNS resolver
+ delegations recursively as illustrated in <xref target="figure_arch_resolv"/>.
+ For each label in a name, the recursive GNS resolver
fetches the respective record from the storage layer (<xref target="resolution"/>).
Without knowledge of the label values and the zone keys, the
different derived keys are unlinkable both to the original zone key and to each
@@ -363,6 +395,32 @@
with the ability to verify the integrity of the published information
without disclosing the originating zone.
</t>
+ <figure anchor="figure_arch_resolv" title="High-level view of the GNS resolution process.">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ Local Host | Distributed
+ | Storage
+ |
+ | +--------+
+ | / /|
+ | +--------+ |
++-----------+ Name +---------+ Recursive | | | |
+| | Lookup | | Resolution | | Public | |
+|Application|----------| GNS |-------------|->| Zones | |
+| |<---------| |<------------|--| |/
++-----------+ Results +---------+ Intermediate| +--------+
+ A Results |
+ | |
+ +---------+ |
+ / | /| |
+ +---------+ | |
+ | | | |
+ | Start | | |
+ | Zones | | |
+ | |/ |
+ +---------+ |
+ ]]></artwork>
+ </figure>
+
<t>
In the remainder of this document, the "implementer" refers to the developer building
a GNS implementation including, for example, zone management tools and
