commit aa69ed90dc6a186dbce6d9720e4682a31fd0f824
parent 2eb1996dc516e2e84edd7ffcb1f870c1c9745ab5
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Thu, 10 Mar 2022 11:17:33 +0100
more graphics
Diffstat:
1 file changed, 70 insertions(+), 8 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -1731,7 +1731,7 @@ GET(key) -> value
<t>
Resource records are grouped by their respective labels,
encrypted and published together in a single resource records block
- (RRBLOCK) in the storage under a key q: PUT(q, RRBLOCK).
+ (RRBLOCK) in the storage under a key q as illustrated in <xref target="figure_storage_publish"/>.
The key q is derived from the zone key and the respective
label of the contained records.
The required knowledge of both zone key and label in combination
@@ -1742,6 +1742,34 @@ GET(key) -> value
The implementation <bcp14>MUST</bcp14> use the PUT storage procedure in order to update
the zone contents accordingly.
</t>
+ <figure anchor="figure_storage_publish" title="Management and publication of local zones in the distributed storage.">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ Local Host | Distributed
+ | Storage
+ |
+ | +--------+
+ | / /|
+ | +--------+ |
++-----------+ +---------+ | | | |
+| | | |PUT(q, RRBLOCK) | | Public | |
+| User | | GNS |----------------|->| Zones | |
+| | | | | | |/
++-----------+ +---------+ | +--------+
+ | A |
+ | | Zone records |
+ | | grouped by label |
+ | | |
+ | +---------+ |
+ |Create / Delete / | /| |
+ |and Update +---------+ | |
+ |Local Zones | | | |
+ | | Local | | |
+ +-------------->| Zones | | |
+ | |/ |
+ +---------+ |
+ ]]></artwork>
+ </figure>
+
<section anchor="blinding" numbered="true" toc="default">
<name>The Storage Key</name>
<t>
@@ -1957,19 +1985,51 @@ q := SHA-512 (ZKDF-Public(zk, label))
Instead, it <bcp14>MUST</bcp14> respond to a resolution request with either the
requested resource record or an error message in case the resolution
fails.
- The following sections detail how resolution is initiated and each
- iteration in the resolution is processed.
- </t>
- <t>
+ <xref target="figure_resolution"/> illustrates how an application
+ requests the lookup of a GNS name (1).
The application <bcp14>MAY</bcp14> provide a desired record type to the resolver.
- The desired record type is used to guide processing.
+ Subsequently, the Start Zone is determined (2) and the recursive
+ resolution process started.
+ This is where the desired record type is used to guide processing.
For example, if a zone delegation record type is requested, the
resolution of the apex label in that zone must be skipped, as
the desired record is already found.
- The resolver implementation <bcp14>MUST NOT</bcp14> filter results according to the desired
- record type.
+ Details on how the resolution process is initiated and each iterative
+ result (3a,3b) in the resolution is processed are provided in the sections below.
+ The results of the lookup are eventually returned to the application (4).
+ The implementation <bcp14>MUST NOT</bcp14> filter results
+ according to the desired record type.
Filtering of record sets is typically done by the application.
</t>
+ <figure anchor="figure_resolution" title="The recursive GNS resolution process.">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ Local Host | Distributed
+ | Storage
+ |
+ | +--------+
+ | / /|
+ | +--------+ |
++-----------+ (1) Name +---------+ | | | |
+| | Lookup | | (3a) GET(q) | | Public | |
+|Application|----------| GNS |-------------------|->| Zones | |
+| |<---------| |<------------------|--| |/
++-----------+ (4) +---------+ (3b) RRBLOCK | +--------+
+ Records A |
+ | |
+ | |
+ (2) Determination of | |
+ Start Zone | |
+ | |
+ +---------+ |
+ / | /| |
+ +---------+ | |
+ | | | |
+ | Start | | |
+ | Zones | | |
+ | |/ |
+ +---------+ |
+ ]]></artwork>
+ </figure>
<section anchor="governance" numbered="true" toc="default">
<name>Start Zones</name>
<t>
@@ -2081,6 +2141,8 @@ example.com = zTLD2 := Base32GNS(ztype2||zk2)
record could not be processed <bcp14>SHOULD</bcp14> be returned in the error
description. The implementation <bcp14>MAY</bcp14> choose not to return the reason for the failure,
merely complicating troubleshooting for the user.
+ </t>
+ <t>
The next steps depend on the context of the name that is being
resolved:
</t>
