[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated (77f52c8 -> dcb3ce7)
From: |
gnunet |
Subject: |
[lsd0001] branch master updated (77f52c8 -> dcb3ce7) |
Date: |
Wed, 09 Mar 2022 21:22:54 +0100 |
This is an automated email from the git hooks/post-receive script.
martin-schanzenbach pushed a change to branch master
in repository lsd0001.
from 77f52c8 fix
new f906fcf graphics
new dcb3ce7 typos
The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
draft-schanzen-gns.xml | 70 +++++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 64 insertions(+), 6 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 306064a..91abda4 100644
--- 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
@@ -509,8 +567,8 @@ ztype||zkey := Base32GNS-Decode(zTLD)
the least significant bytes in the leftmost label of the resulting
string. This allows the
resolver to determine the ztype and zTLD length from the rightmost
label and to subsequently determine how many labels the zTLD should
span.
- A GNS implementation <bcp14>MUST</bcp14> support the division of zTLD
in DNS compatible
- label lengths.
+ A GNS implementation <bcp14>MUST</bcp14> support the division of zTLDs
+ in DNS compatible label lengths.
For example, assuming a zTLD of 130 characters, the division is:
</t>
<!-- FIXME: Is this really really necessary? Really? -->
@@ -791,7 +849,7 @@ zTLD[126..129].zTLD[63..125].zTLD[0..62]
evict then from the local store at any time.
</t>
<t>
- Implementations <bcp14>MUST</bcp14> broadcast received revocations to
+ Implementations <bcp14>MUST</bcp14> broadcast received revocations
if they are valid and not stale.
Should the calculated validity period differ from the TTL field value,
the calculated value <bcp14>MUST</bcp14> be used as TTL field value
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
- [lsd0001] branch master updated (77f52c8 -> dcb3ce7),
gnunet <=