gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lsd0001] branch master updated: delegations and redirects


From: gnunet
Subject: [lsd0001] branch master updated: delegations and redirects
Date: Mon, 07 Feb 2022 12:32:54 +0100

This is an automated email from the git hooks/post-receive script.

martin-schanzenbach pushed a commit to branch master
in repository lsd0001.

The following commit(s) were added to refs/heads/master by this push:
     new 3881c3a  delegations and redirects
3881c3a is described below

commit 3881c3a94477a2ef242a3d166462716357c63436
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Mon Feb 7 12:32:50 2022 +0100

    delegations and redirects
---
 draft-schanzen-gns.xml | 32 +++++++++++++++++++++++---------
 1 file changed, 23 insertions(+), 9 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 52e9fd4..4287aca 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -918,9 +918,8 @@ zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
        Zone delegation records MUST have the CRTITICAL flag set.
        Not supporting some zone types MAY result in resolution failures. This
        MAY BE a valid choice if some zone delegation record types have been
-       determined to be cryptographically insecure, or if an application has
-       reasons to not support delegation to DNS for reasons such as complexity
-       or security. Zone delegation records MUST NOT be stored and published
+       determined to be cryptographically insecure.
+       Zone delegation records MUST NOT be stored and published
        under the apex label.
        A zone delegation record type value is the same as the respective ztype
        value.
@@ -1359,13 +1358,25 @@ S-Decrypt(zk,label,expiration,ciphertext):
    <section anchor="gnsrecords_redirect" numbered="true" toc="default">
      <name>Redirection Records</name>
      <t>
-       Redirection records MUST have the CRITICAL flag set.
+       Redirect records may be used to redirect resolution.
+       Any implementation SHOULD support all redirection record types defined 
here
+       and MAY support any number of additional redirection records defined in
+       the GNU Name System Record Types registry (see Section <xref 
target="gana"/>).
+       Redirection records MUST have the CRTITICAL flag set.
+       Not supporting some record types MAY result in resolution failures.
+       This MAY BE a valid choice if some redirection record types have been
+       determined to be insecure, or if an application has reasons to not
+       support redirection to DNS for reasons such as complexity or security.
+       Redirection records MUST NOT be stored and published under the apex 
label.
      </t>
      <section anchor="gnsrecords_rdr" numbered="true" toc="default">
        <name>REDIRECT</name>
        <t>
          A REDIRECT record is the GNS equivalent of a CNAME record in DNS.
+         A REDIRECT record MUST be the only record under a label.
+         No other records are allowed.
          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">
@@ -1381,23 +1392,26 @@ S-Decrypt(zk,label,expiration,ciphertext):
        </figure>
        <t> The REDIRECT DATA Wire Format</t>
        <dl>
-         <dt>GNS NAME</dt>
+         <dt>NAME</dt>
          <dd>
-           The name to continue with in GNS.
+           The name to continue with.
            The value of a redirect record may be a regular name, or a relative
            name.
-           Relative names are indicated using the suffix ".+".
+           Relative GNS names are indicated using the suffix ".+".
            The string is UTF-8 encoded and 0-terminated.
          </dd>
        </dl>
      </section>
      <section anchor="gnsrecords_gns2dns" numbered="true" toc="default">
        <name>GNS2DNS</name>
-       <t>It is possible to delegate a label back into DNS through a GNS2DNS 
record.
+       <t>
+         It is possible to delegate a label back into DNS through a GNS2DNS 
record.
          The resource record contains a DNS name for the resolver to continue 
with
          in DNS followed by a DNS server. Both names are in the format defined 
in
          <xref target="RFC1034" /> for DNS names.
-           A GNS2DNS DATA entry is illustrated in <xref 
target="figure_gns2dnsrecord"/>.</t>
+         There MAY be multiple GNS2DNS records under a label.
+         No other record types are allowed in the same record set.
+         A GNS2DNS DATA entry is illustrated in <xref 
target="figure_gns2dnsrecord"/>.</t>
        <figure anchor="figure_gns2dnsrecord">
          <artwork name="" type="" align="left" alt=""><![CDATA[
 0     8     16    24    32    40    48    56

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]