lsd0001

commit 3afa61c39befde67a2d8e9dc29d82d17f3f99034
parent a55b8e34a5a907cf2e87a81b81b6ed9fc06c74e6
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date:   Thu,  3 Feb 2022 10:49:29 +0100

more redirect records

Diffstat:
M
draft-schanzen-gns.xml
 | 
47
+++++++++++++++--------------------------------

1 file changed, 15 insertions(+), 32 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -1285,12 +1285,14 @@ NONCE := HKDF-Expand (PRK_n, label, 128 / 8)
        <name>REDIRECT</name>
        <t>
          A REDIRECT record is the GNS equivalent of a CNAME record in DNS.
-         A REDIRECT DATA entry is illustrated in <xref target="figure_redirectrecord"/>.</t>
+         Details on processing of this record is defined in <xref target="redirect_processing"/>.
+         A REDIRECT DATA entry is illustrated in <xref target="figure_redirectrecord"/>.
+       </t>
        <figure anchor="figure_redirectrecord">
          <artwork name="" type="" align="left" alt=""><![CDATA[
 0     8     16    24    32    40    48    56
 +-----+-----+-----+-----+-----+-----+-----+-----+
-|                    GNS NAME                   |
+|                   REDIRECT NAME               |
 /                                               /
 /                                               /
 |                                               |
@@ -1301,7 +1303,11 @@ NONCE := HKDF-Expand (PRK_n, label, 128 / 8)
        <dl>
          <dt>GNS NAME</dt>
          <dd>
-           The name to continue with in GNS. The value is UTF-8 encoded and
+           The name to continue with in GNS.
+           The value of a redirect record may be a regular GNS name, or a relative
+           name.
+           Relative names are indicated using the suffix ".+".
+           The string is UTF-8 encoded and
            0-terminated.
          </dd>
        </dl>
@@ -1703,15 +1709,6 @@ q := SHA-512 (ZKDF-Public(zk, label))
          The wire format of the RDATA is illustrated in
          <xref target="figure_rdata"/>.
        </t>
-       <!-- FIXME: I (CG) think we can do better here:
-            use the canonical TYPE-LENGTH-(FLAGS-EXPR)-VALUE
-            (as in TLV) instead of LENGTH-TYPE-(FLAGS-EXPR)-VALUE;
-            we should consider using 16 bit for DATA SIZE and
-            FLAGS (improves alignment, hardly a good use for 32-bit
-            flags or values);
-            We MAY also consider removing RRCOUNT, just bad
-            for alignment, and - strictly speaking - redundant,
-            just causes another error check for implementations.  -->
        <figure anchor="figure_rdata">
          <artwork name="" type="" align="left" alt=""><![CDATA[
 0     8     16    24    32    40    48    56
@@ -1949,32 +1946,18 @@ example.com = zk2
          <section anchor="redirect_processing" numbered="true" toc="default">
            <name>REDIRECT</name>
            <t>
-             If a REDIRECT record is encountered, the redirect name is
-             appended to the remaining name, except if the remaining name
-             is empty and the desired record type is REDIRECT, in which case
-             the resolution concludes with the REDIRECT record.
-               If the redirect name ends in ".+", <!-- FIXME Do we need this? -->
+             If the remaining name is empty and the desired record type is
+             REDIRECT, in which case the resolution concludes with the REDIRECT record.
+             If the redirect name ends in ".+",
              resolution continues in GNS with the new name in the
-             current zone. 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.
+             current zone. Otherwise, the redirect name treated as a GNS name
+             and resolution restarts.
              <!-- Note: this permits non-DNS resolvers to be triggered via NSS! -->
            </t>
            <t>
              In order to prevent infinite loops, the resolver MUST
              implement loop detections or limit the number of recursive
-             resolution steps.  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.
-           </t>
-           <t>
-             If the last REDIRECT encountered was a DNS name, the resolver
-             SHOULD return the DNS name
-             as a supplemental LEHO record (see <xref target="gnsrecords_leho" />)
-             with a relative expiration time of one hour.
-             <!-- Note: Martin: do we actually implement this in GNS today?
-                  Seems rather tricky to detect if we go via NSS... -->
+             resolution steps.
            </t>
          </section>
          <section anchor="gns2dns_processing" numbered="true" toc="default">