commit 84069e53addee337aedad320eb8c5d02b5a702c3
parent 079fcdcffe6e17af6a03f4f9a544b71700c133db
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Thu, 3 Feb 2022 18:57:27 +0100
more redirect
Diffstat:
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -1304,11 +1304,10 @@ NONCE := HKDF-Expand (PRK_n, label, 128 / 8)
<dt>GNS NAME</dt>
<dd>
The name to continue with in GNS.
- The value of a redirect record may be a regular GNS name, or a relative
+ The value of a redirect record may be a regular name, or a relative
name.
Relative names are indicated using the suffix ".+".
- The string is UTF-8 encoded and
- 0-terminated.
+ The string is UTF-8 encoded and 0-terminated.
</dd>
</dl>
</section>
@@ -1951,21 +1950,20 @@ example.com = zk2
If the redirect name ends in ".+",
resolution continues in GNS with the new name in the
current zone.
- Otherwise, the redirect name treated as a GNS name
- and resolution restarts.
- <!-- FIXME Otherwise, the resulting name is resolved via the
+ Otherwise, the resulting name is resolved via the
default operating system name resolution process.
This may in turn trigger a GNS name resolution process depending
- on the system configuration.-->
- <!-- Note: this permits non-DNS resolvers to be triggered via NSS! -->
+ on the system configuration.
+ In case resolution continues in DNS, the name MUST first be
+ converted to a punycode representation <xref target="RFC5890" />.
</t>
<t>
In order to prevent infinite loops, the resolver MUST
implement loop detections or limit the number of recursive
resolution steps.
- <!-- FIXME The loop detection MUST be effective even
+ The loop detection MUST be effective even
if a REDIRECT found in GNS triggers subsequent GNS lookups via
- the default operating system name resolution process.-->
+ the default operating system name resolution process.
</t>
</section>
<section anchor="gns2dns_processing" numbered="true" toc="default">
