commit 0ce248a0d1da352c99bdc032e6218bed13ada671
parent 334b69b02e5ac642ea4178d99125a00568452191
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Sun, 20 Feb 2022 09:56:45 +0100
finish start zone
Diffstat:
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -1899,18 +1899,28 @@ q := SHA-512 (ZKDF-Public(zk, label))
<section anchor="governance" numbered="true" toc="default">
<name>Start Zones</name>
<t>
- The resolution of a GNS name starts by identifying the start zone.
+ The resolution of a GNS name starts by identifying the start zone
+ suffix. Once the start zone suffix is identified, recursive resolution
+ of the remainder of the name is initiated (<xref target="recursion"/>).
+ There are two types of start zone suffixes: zTLDs and local
+ suffix-to-zone mappings.
+ The choice of available suffix-to-zone mappings is at the sole
+ discretion of the local system administrator or user.
+ This property addresses the issue of a single hierarchy with a
+ centrally controlled root and the related issue of distribution and
+ management of root servers in DNS (see <xref target="RFC8324"/>, Section 3.10 and 3.12).
+ </t>
+ <t>
For names ending with a zTLD the start zone is explicitly given in the
suffix of the name to resolve.
In order to ensure uniqueness of names with zTLDs any
implementation MUST use the given zone as start zone.
- </t>
- <t>
An implementation MUST first try to interpret the rightmost label of
the given name as the beginning of a zTLD (<xref target="zTLD"/>).
If the rightmost label cannot be (partially) decoded or if it does not
indicate a supported ztype, the name is treated as a normal name and
- start zone discovery MUST continue.
+ start zone discovery MUST continue with finding a local suffix-to-zone
+ mapping.
If a valid ztype can be found in the rightmost label, the
implementation MUST try to synthesize and decode the zTLD to retrieve
the start zone key according to <xref target="zTLD"/>.
@@ -1925,17 +1935,8 @@ Example name: www.example.<zTLD>
]]></artwork>
<t>
For names not ending with a zTLD the resolver MUST determine the start
- zone through other means.
- The choice of available start zone(s) is at the sole
- discretion of the local system administrator or user.
- This property addresses the issue of a single hierarchy with a
- centrally controlled root and the related issue of distribution and
- management of root servers in DNS (see <xref target="RFC8324"/>, Section 3.10 and 3.12).
- </t>
- <t>
- In order to discover the start zone from a name, an implementation MAY
- support the configuration of "suffix-to-zTLD" mappings.
- Suffix-to-zTLD mappings MUST be configurable through a local
+ zone through a local suffix-to-zone mapping.
+ Suffix-to-zone mappings MUST be configurable through a local
configuration file or database by the user or system administrator.
A suffix MAY consist of multiple GNS labels concatenated with a
label separator.
@@ -1945,7 +1946,7 @@ Example name: www.example.<zTLD>
implementation MUST return an error.
</t>
<t>
- If both a locally managed zone and a configuration entry for a
+ If both a configuration entry for a locally managed zone and a
non-local zone exist for the same suffix, the locally managed zone MUST
be given priority.
The following is a non-normative example mapping of start zones:
@@ -1961,9 +1962,8 @@ example.com = zTLD2 (ztype2||zk2)
=> Name to resolve from start zone: www
]]></artwork>
<t>
- The process given is not exhaustive and resolvers MAY supplement it
- with other mechanisms if the particular application
- requires a different process.
+ The process given above MAY be supplemented with other mechanisms if
+ the particular application requires a different process.
If no start zone can be discovered, resolution MUST fail and an
error MUST be returned to the application.
</t>
