commit 1c38d4c2534e3237806218fcc4ba5183d338991f
parent 987afd02f37bf5f09e01351091e41cda2663167a
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Mon, 20 Dec 2021 11:57:38 +0100
reorder
Diffstat:
1 file changed, 82 insertions(+), 81 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -1348,6 +1348,88 @@ q := SHA512 (HDKD-Public(zk, label))
types MUST still be done by the client after the resource record set
is retrieved.
</t>
+ <section anchor="governance" numbered="true" toc="default">
+ <name>Root Zone</name>
+ <t>
+ The resolution of a GNS name must start in a given start zone
+ indicated to the resolver using any public zone key.
+ The local resolver may have a local start zone configured/hard-coded
+ which points to a local or remote start zone key.
+ A resolver client may also determine the start zone from the
+ suffix of the name given for resolution or using information
+ retrieved out of band.
+ The governance model of any zone is at the sole discretion
+ of the zone owner. However, the choice of start zone(s) is at the sole
+ discretion of the local system administrator or user.
+ </t>
+ <t>
+ This is an important distinguishing factor from the Domain Name System
+ where root zone governance is centralized at the Internet Corporation
+ for Assigned Names and Numbers (ICANN).
+ In DNS terminology, GNS roughly follows the idea of a hyper-hyper
+ local root zone deployment, with the difference that it is not
+ expected that all deployments use the same local root zone.
+ </t>
+ <t>
+ In the following, we give examples how a local client resolver SHOULD
+ discover the start zone. The process given is not exhaustive and
+ clients MAY suppliement it with other mechanisms or ignore it if the
+ particular application requires a different process.
+ </t>
+ <t>
+ GNS clients MUST first try to interpret the top-level domain of
+ a GNS name as a zone key representation ("zTLD").
+ If the top-level domain is indicated to be a label representation of
+ a public zone key with a well-defined "ztype" value, the root zone of
+ the resolution process is implicitly given by the suffic of the name:
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+Example name: www.example.<zTLD>
+=> Root zone: zk of type ztype
+=> Name to resolve from root zone: www.example
+ ]]></artwork>
+ <t>
+ In GNS, users MAY own and manage their own zones.
+ Each local zone SHOULD be associated with a single GNS label,
+ but users MAY choose to use longer names consisting of
+ multiple labels.
+ If the name of a locally managed zone matches the suffix
+ of the name to be resolved,
+ resolution SHOULD start from the respective local zone:
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+Example name: www.example.org
+Local zones:
+fr = (d0,zk0)
+gnu = (d1,zk1)
+com = (d2,zk2)
+...
+=> Entry zone: zk1
+=> Name to resolve from entry zone: www.example
+ ]]></artwork>
+ <t>
+ Finally, additional "suffix to zone" mappings MAY be configured.
+ Suffix to zone key mappings SHOULD be configurable through a local
+ configuration file or database by the user or system administrator.
+ The suffix MAY consist of multiple GNS labels concatenated with a
+ ".". If multiple suffixes match the name to resolve, the longest
+ matching suffix MUST BE used. The suffix length of two results
+ cannot be equal, as this would indicate a misconfiguration.
+ If both a locally managed zone and a configuration entry exist
+ for the same suffix, the locally managed zone MUST have priority.
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+Example name: www.example.org
+Local suffix mappings:
+gnu = zk0
+example.org = zk1
+example.com = zk2
+...
+=> Entry zone: zk1
+=> Name to resolve from entry zone: www
+ ]]></artwork>
+ </section>
+
<section anchor="recursion" numbered="true" toc="default">
<name>Recursion</name>
<t>
@@ -1845,87 +1927,6 @@ NICK: john (Supplemental)
expiration date.</li>
</ol>
</section>
- <section anchor="governance" numbered="true" toc="default">
- <name>Determining the Root Zone and Zone Governance</name>
- <t>
- The resolution of a GNS name must start in a given start zone
- indicated to the resolver using any public zone key.
- The local resolver may have a local start zone configured/hard-coded
- which points to a local or remote start zone key.
- A resolver client may also determine the start zone from the
- suffix of the name given for resolution or using information
- retrieved out of band.
- The governance model of any zone is at the sole discretion
- of the zone owner. However, the choice of start zone(s) is at the sole
- discretion of the local system administrator or user.
- </t>
- <t>
- This is an important distinguishing factor from the Domain Name System
- where root zone governance is centralized at the Internet Corporation
- for Assigned Names and Numbers (ICANN).
- In DNS terminology, GNS roughly follows the idea of a hyper-hyper
- local root zone deployment, with the difference that it is not
- expected that all deployments use the same local root zone.
- </t>
- <t>
- In the following, we give examples how a local client resolver SHOULD
- discover the start zone. The process given is not exhaustive and
- clients MAY suppliement it with other mechanisms or ignore it if the
- particular application requires a different process.
- </t>
- <t>
- GNS clients MUST first try to interpret the top-level domain of
- a GNS name as a zone key representation ("zTLD").
- If the top-level domain is indicated to be a label representation of
- a public zone key with a well-defined "ztype" value, the root zone of
- the resolution process is implicitly given by the suffic of the name:
- </t>
- <artwork name="" type="" align="left" alt=""><![CDATA[
-Example name: www.example.<zTLD>
-=> Root zone: zk of type ztype
-=> Name to resolve from root zone: www.example
- ]]></artwork>
- <t>
- In GNS, users MAY own and manage their own zones.
- Each local zone SHOULD be associated with a single GNS label,
- but users MAY choose to use longer names consisting of
- multiple labels.
- If the name of a locally managed zone matches the suffix
- of the name to be resolved,
- resolution SHOULD start from the respective local zone:
- </t>
- <artwork name="" type="" align="left" alt=""><![CDATA[
-Example name: www.example.org
-Local zones:
-fr = (d0,zk0)
-gnu = (d1,zk1)
-com = (d2,zk2)
-...
-=> Entry zone: zk1
-=> Name to resolve from entry zone: www.example
- ]]></artwork>
- <t>
- Finally, additional "suffix to zone" mappings MAY be configured.
- Suffix to zone key mappings SHOULD be configurable through a local
- configuration file or database by the user or system administrator.
- The suffix MAY consist of multiple GNS labels concatenated with a
- ".". If multiple suffixes match the name to resolve, the longest
- matching suffix MUST BE used. The suffix length of two results
- cannot be equal, as this would indicate a misconfiguration.
- If both a locally managed zone and a configuration entry exist
- for the same suffix, the locally managed zone MUST have priority.
- </t>
- <artwork name="" type="" align="left" alt=""><![CDATA[
-Example name: www.example.org
-Local suffix mappings:
-gnu = zk0
-example.org = zk1
-example.com = zk2
-...
-=> Entry zone: zk1
-=> Name to resolve from entry zone: www
- ]]></artwork>
- </section>
<section anchor="encoding" numbered="true" toc="default">
<name>Internationalization and Character Encoding</name>
<t>
