gnunet-svn
[Top][All Lists]
Advanced

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

[lsd0001] branch master updated: update box with ref


From: gnunet
Subject: [lsd0001] branch master updated: update box with ref
Date: Sun, 10 Nov 2019 12:44:23 +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 3e7622c  update box with ref
3e7622c is described below

commit 3e7622c5905ba4c680d6379943e54640d234ade1
Author: Schanzenbach, Martin <address@hidden>
AuthorDate: Sun Nov 10 12:41:44 2019 +0100

    update box with ref
---
 draft-schanzen-gns.html |  27 ++--
 draft-schanzen-gns.txt  | 344 ++++++++++++++++++++++++------------------------
 draft-schanzen-gns.xml  |  65 ++++++---
 3 files changed, 235 insertions(+), 201 deletions(-)

diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index b4ec456..efe4949 100644
--- a/draft-schanzen-gns.html
+++ b/draft-schanzen-gns.html
@@ -1565,6 +1565,17 @@ async function addMetadata(){try{const 
e=document.styleSheets[0].cssRules;for(le
 <a href="#section-3.6" class="section-number selfRef">3.6. </a><a 
href="#name-box" class="section-name selfRef">BOX</a>
         </h3>
 <p id="section-3.6-1">
+         In GNS, every "." in a name delegates to another zone, and
+         GNS lookups are expected to return all of the required useful
+         information in one record set.  This is incompatible with the
+         special labels used by DNS for SRV and TLSA records.  Thus, GNS
+         defines the BOX record format to box up SRV and TLSA records and
+         include them in the record set of the label they are associated
+         with.  For example, a
+         TLSA record for "_https._tcp.foo.gnu" will be stored in the record 
set of
+         "foo.gnu" as a BOX record with service (SVC) 443 (https) and protocol 
(PROTO) 6
+         (tcp) and record_type "TLSA".
+         For reference, see also <span>[<a href="#RFC2782" 
class="xref">RFC2782</a>]</span>
          A BOX DATA entry has the following format:<a href="#section-3.6-1" 
class="pilcrow">¶</a></p>
 <div id="figure_boxrecord">
 <figure id="figure-8">
@@ -2153,16 +2164,7 @@ async function addMetadata(){try{const 
e=document.styleSheets[0].cssRules;for(le
 <a href="#section-6.3.4" class="section-number selfRef">6.3.4. </a><a 
href="#name-box-2" class="section-name selfRef">BOX</a>
           </h4>
 <p id="section-6.3.4-1">
-             In GNS, every "." in a name delegates to another zone, and
-             GNS lookups are expected to return all of the required useful
-             information in one record set.  This is incompatible with the
-             special labels used by DNS for SRV and TLSA records.  Thus, GNS
-             defines the BOX record format to box up SRV and TLSA records and
-             include them in the record set of the label they are associated
-             with.  For example, a
-             TLSA record for "_https._tcp.foo.gnu" will be stored in the 
record set of
-             "foo.gnu" as a BOX record with service (SVC) 443 (https) and 
protocol (PROTO) 6
-             (tcp) and record_type "TLSA".  When a BOX record is received, a 
GNS resolver
+              When a BOX record is received, a GNS resolver
              must unbox it if the name to be resolved continues with 
"_SERVICE._PROTO",
              otherwise it is to be left untouched.  This way, TLSA (and SRV)
              records do not require a separate network request, and TLSA
@@ -2339,6 +2341,11 @@ async function addMetadata(){try{const 
e=document.styleSheets[0].cssRules;for(le
 <dt id="RFC1035">[RFC1035]</dt>
       <dd>
 <span class="refAuthor">Mockapetris, P.</span>, <span class="refTitle">"Domain 
names - implementation and specification"</span>, <span class="seriesInfo">STD 
13</span>, <span class="seriesInfo">RFC 1035</span>, <span 
class="seriesInfo">DOI 10.17487/RFC1035</span>, <time 
datetime="1987-11">November 1987</time>, <span>&lt;<a 
href="https://www.rfc-editor.org/info/rfc1035";>https://www.rfc-editor.org/info/rfc1035</a>&gt;</span>.
 </dd>
+<dt id="RFC2782">[RFC2782]</dt>
+      <dd>
+<span class="refAuthor">Gulbrandsen, A.</span><span class="refAuthor">, Vixie, 
P.</span><span class="refAuthor">, and L. Esibov</span>, <span 
class="refTitle">"
+             A DNS RR for specifying the location of services (DNS SRV)
+          "</span>, <span class="seriesInfo">RFC 2782</span>, <span 
class="seriesInfo">DOI 10.17487/RFC2782</span>, <time 
datetime="2000-02">February 2000</time>, <span>&lt;<a 
href="https://www.rfc-editor.org/info/rfc2782";>https://www.rfc-editor.org/info/rfc2782</a>&gt;</span>.
 </dd>
 <dt id="RFC3629">[RFC3629]</dt>
       <dd>
 <span class="refAuthor">Yergeau, F.</span>, <span class="refTitle">"UTF-8, a 
transformation format of ISO 10646"</span>, <span class="seriesInfo">STD 
63</span>, <span class="seriesInfo">RFC 3629</span>, <span 
class="seriesInfo">DOI 10.17487/RFC3629</span>, <time 
datetime="2003-11">November 2003</time>, <span>&lt;<a 
href="https://www.rfc-editor.org/info/rfc3629";>https://www.rfc-editor.org/info/rfc3629</a>&gt;</span>.
 </dd>
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
index 7a81796..46aa1e9 100644
--- a/draft-schanzen-gns.txt
+++ b/draft-schanzen-gns.txt
@@ -70,26 +70,26 @@ Table of Contents
      3.5.  NICK  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
      3.6.  BOX . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
      3.7.  VPN . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
-   4.  Publishing Records  . . . . . . . . . . . . . . . . . . . . .   9
-     4.1.  Key Derivations . . . . . . . . . . . . . . . . . . . . .   9
-     4.2.  Resource Records Block  . . . . . . . . . . . . . . . . .  10
+   4.  Publishing Records  . . . . . . . . . . . . . . . . . . . . .  10
+     4.1.  Key Derivations . . . . . . . . . . . . . . . . . . . . .  10
+     4.2.  Resource Records Block  . . . . . . . . . . . . . . . . .  11
      4.3.  Record Data Encryption and Decryption . . . . . . . . . .  12
-   5.  Internationalization and Character Encoding . . . . . . . . .  14
-   6.  Name Resolution . . . . . . . . . . . . . . . . . . . . . . .  14
-     6.1.  Entry Zone  . . . . . . . . . . . . . . . . . . . . . . .  14
-     6.2.  Record Retrieval  . . . . . . . . . . . . . . . . . . . .  15
+   5.  Internationalization and Character Encoding . . . . . . . . .  15
+   6.  Name Resolution . . . . . . . . . . . . . . . . . . . . . . .  15
+     6.1.  Entry Zone  . . . . . . . . . . . . . . . . . . . . . . .  15
+     6.2.  Record Retrieval  . . . . . . . . . . . . . . . . . . . .  16
      6.3.  Record Processing . . . . . . . . . . . . . . . . . . . .  16
-       6.3.1.  PKEY  . . . . . . . . . . . . . . . . . . . . . . . .  16
-       6.3.2.  GNS2DNS . . . . . . . . . . . . . . . . . . . . . . .  16
+       6.3.1.  PKEY  . . . . . . . . . . . . . . . . . . . . . . . .  17
+       6.3.2.  GNS2DNS . . . . . . . . . . . . . . . . . . . . . . .  17
        6.3.3.  CNAME . . . . . . . . . . . . . . . . . . . . . . . .  17
-       6.3.4.  BOX . . . . . . . . . . . . . . . . . . . . . . . . .  17
-       6.3.5.  VPN . . . . . . . . . . . . . . . . . . . . . . . . .  17
+       6.3.4.  BOX . . . . . . . . . . . . . . . . . . . . . . . . .  18
+       6.3.5.  VPN . . . . . . . . . . . . . . . . . . . . . . . . .  18
    7.  Zone Revocation . . . . . . . . . . . . . . . . . . . . . . .  18
    8.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
    9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
    10. Test Vectors  . . . . . . . . . . . . . . . . . . . . . . . .  18
    11. Normative References  . . . . . . . . . . . . . . . . . . . .  20
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22
 
 1.  Introduction
 
@@ -425,7 +425,30 @@ Internet-Draft             The GNU Name System             
    July 2019
 
 3.6.  BOX
 
-   A BOX DATA entry has the following format:
+   In GNS, every "." in a name delegates to another zone, and GNS
+   lookups are expected to return all of the required useful information
+   in one record set.  This is incompatible with the special labels used
+   by DNS for SRV and TLSA records.  Thus, GNS defines the BOX record
+   format to box up SRV and TLSA records and include them in the record
+   set of the label they are associated with.  For example, a TLSA
+   record for "_https._tcp.foo.gnu" will be stored in the record set of
+   "foo.gnu" as a BOX record with service (SVC) 443 (https) and protocol
+   (PROTO) 6 (tcp) and record_type "TLSA".  For reference, see also
+   [RFC2782] A BOX DATA entry has the following format:
+
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al.     Expires 24 January 2020                [Page 8]
+
+Internet-Draft             The GNU Name System                 July 2019
+
 
               0     8     16    24    32    40    48    56
               +-----+-----+-----+-----+-----+-----+-----+-----+
@@ -441,15 +464,6 @@ Internet-Draft             The GNU Name System             
    July 2019
 
    where:
 
-
-
-
-
-Schanzenbach, et al.     Expires 24 January 2020                [Page 8]
-
-Internet-Draft             The GNU Name System                 July 2019
-
-
    PROTO  the 16-bit protocol number, e.g. 6 for tcp.  In network byte
       order.
 
@@ -481,6 +495,17 @@ Internet-Draft             The GNU Name System             
    July 2019
 
                                   Figure 9
 
+
+
+
+
+
+
+Schanzenbach, et al.     Expires 24 January 2020                [Page 9]
+
+Internet-Draft             The GNU Name System                 July 2019
+
+
 4.  Publishing Records
 
    GNS resource records are published in a distributed hash table (DHT).
@@ -495,17 +520,6 @@ Internet-Draft             The GNU Name System             
    July 2019
 
    Given a label, the DHT key "q" is derived as follows:
 
-
-
-
-
-
-
-Schanzenbach, et al.     Expires 24 January 2020                [Page 9]
-
-Internet-Draft             The GNU Name System                 July 2019
-
-
             PRK_h := HKDF-Extract ("key-derivation", zk)
             h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
             d_h := h * d mod L
@@ -540,6 +554,14 @@ Internet-Draft             The GNU Name System             
    July 2019
       published.  It is the SHA512 hash over the public key "zk_h"
       corresponding to the derived private key "d_h".
 
+
+
+
+Schanzenbach, et al.     Expires 24 January 2020               [Page 10]
+
+Internet-Draft             The GNU Name System                 July 2019
+
+
    We point out that the multiplication of "zk" with "h" is a point
    multiplication, while the multiplication of "d" with "h" is a scalar
    multiplication.
@@ -553,15 +575,6 @@ Internet-Draft             The GNU Name System             
    July 2019
    underlying DHT.  This may include a periodic refresh publication.  A
    GNS RRBLOCK has the following format:
 
-
-
-
-
-Schanzenbach, et al.     Expires 24 January 2020               [Page 10]
-
-Internet-Draft             The GNU Name System                 July 2019
-
-
               0     8     16    24    32    40    48    56
               +-----+-----+-----+-----+-----+-----+-----+-----+
               |                   SIGNATURE                   |
@@ -596,6 +609,15 @@ Internet-Draft             The GNU Name System             
    July 2019
       PUBLIC KEY field.  The signature is created using the derived
       private key "d_h" (see Section 4).
 
+
+
+
+
+Schanzenbach, et al.     Expires 24 January 2020               [Page 11]
+
+Internet-Draft             The GNU Name System                 July 2019
+
+
    PUBLIC KEY  is the 256-bit public key "zk_h" to be used to verify
       SIGNATURE.  The wire format of this value is defined in [RFC8032],
       Section 5.1.5.
@@ -611,13 +633,6 @@ Internet-Draft             The GNU Name System             
    July 2019
    PURPOSE  A 32-bit signature purpose flag.  This field MUST be 15 (in
       network byte order).
 
-
-
-Schanzenbach, et al.     Expires 24 January 2020               [Page 11]
-
-Internet-Draft             The GNU Name System                 July 2019
-
-
    EXPIRATION  Specifies when the RRBLOCK expires and the encrypted
       block SHOULD be removed from the DHT and caches as it is likely
       stale.  However, applications MAY continue to use non-expired
@@ -638,6 +653,27 @@ Internet-Draft             The GNU Name System             
    July 2019
    set RDATA into the BDATA field of a GNS RRBLOCK.  The wire format of
    the RDATA looks as follows:
 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al.     Expires 24 January 2020               [Page 12]
+
+Internet-Draft             The GNU Name System                 July 2019
+
+
               0     8     16    24    32    40    48    56
               +-----+-----+-----+-----+-----+-----+-----+-----+
               |     RR COUNT          |        EXPIRA-        /
@@ -666,14 +702,6 @@ Internet-Draft             The GNU Name System             
    July 2019
 
    where:
 
-
-
-
-Schanzenbach, et al.     Expires 24 January 2020               [Page 12]
-
-Internet-Draft             The GNU Name System                 July 2019
-
-
    RR COUNT  A 32-bit value containing the number of variable-length
       resource records which are following after this field in network
       byte order.
@@ -693,6 +721,15 @@ Internet-Draft             The GNU Name System             
    July 2019
    records block payload, the key material "K" and initialization vector
    "IV" for the symmetric cipher are derived as follows:
 
+
+
+
+
+Schanzenbach, et al.     Expires 24 January 2020               [Page 13]
+
+Internet-Draft             The GNU Name System                 July 2019
+
+
             PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
             PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk)
             K := HKDF-Expand (PRK_k, label, 512 / 8);
@@ -721,15 +758,6 @@ Internet-Draft             The GNU Name System             
    July 2019
 
                                  Figure 12
 
-
-
-
-
-Schanzenbach, et al.     Expires 24 January 2020               [Page 13]
-
-Internet-Draft             The GNU Name System                 July 2019
-
-
    Similarly, we divide "IV" into a 128-bit initialization vector and a
    128-bit initialization vector:
 
@@ -751,6 +779,13 @@ Internet-Draft             The GNU Name System             
    July 2019
             RDATA := AES(AES KEY, AES IV, TWOFISH(TWOFISH KEY, TWOFISH IV, 
BDATA))
             BDATA := TWOFISH(TWOFISH KEY, TWOFISH IV, AES(AES KEY, AES IV, 
RDATA))
 
+
+
+Schanzenbach, et al.     Expires 24 January 2020               [Page 14]
+
+Internet-Draft             The GNU Name System                 July 2019
+
+
 5.  Internationalization and Character Encoding
 
    All labels in GNS are encoded in UTF-8 [RFC3629].  This does not
@@ -777,15 +812,6 @@ Internet-Draft             The GNU Name System             
    July 2019
    If the TLD is a Base32-encoded public zone key "zk", the entry zone
    of the resolution process is implicitly given by the name.
 
-
-
-
-
-Schanzenbach, et al.     Expires 24 January 2020               [Page 14]
-
-Internet-Draft             The GNU Name System                 July 2019
-
-
             Example name: www.example.<Base32(zk)>
             => Entry zone: zk
             => Name to resolve from entry zone: www.example
@@ -808,6 +834,14 @@ Internet-Draft             The GNU Name System             
    July 2019
    SHOULD be configurable through the GNS implementation.  A mapping has
    the form "prefix = public zone key".  The prefix may consist of
    multiple GNS labels concatenated with a ".".  If multiple prefixes
+
+
+
+Schanzenbach, et al.     Expires 24 January 2020               [Page 15]
+
+Internet-Draft             The GNU Name System                 July 2019
+
+
    match the name to resolve, the longest prefix is chosen.  The prefix
    length of two results cannot be equal, as this would indicate a
    misconfiguration.
@@ -834,14 +868,6 @@ Internet-Draft             The GNU Name System             
    July 2019
 
    1.  Extract the right-most label from the name to look up.
 
-
-
-
-Schanzenbach, et al.     Expires 24 January 2020               [Page 15]
-
-Internet-Draft             The GNU Name System                 July 2019
-
-
    2.  Calculate q using the label and zk.
 
    3.  Perform a DHT query GET(q) to retrieve the RRBLOCK.
@@ -864,6 +890,14 @@ Internet-Draft             The GNU Name System             
    July 2019
    If the remainder of the name to resolve is empty but we have received
    a record set containing only a single PKEY record, the recursion is
    continued with the PKEY as authoritative zone and the empty apex
+
+
+
+Schanzenbach, et al.     Expires 24 January 2020               [Page 16]
+
+Internet-Draft             The GNU Name System                 July 2019
+
+
    label "@" as remaining name.  If the record type to be resolved is
    PKEY, the PKEY record set is returned and the resolution is
    concluded.
@@ -890,14 +924,6 @@ Internet-Draft             The GNU Name System             
    July 2019
    appended to the remainder of the name to be resolved, and resolved by
    querying the name server(s).  Multiple GNS2DNS records may be stored
    under the same label, in which case the resolver MUST try all of
-
-
-
-Schanzenbach, et al.     Expires 24 January 2020               [Page 16]
-
-Internet-Draft             The GNU Name System                 July 2019
-
-
    them.  However, if multiple GNS2DNS records are present, the DNS name
    MUST be identical for all of them.
 
@@ -916,43 +942,34 @@ Internet-Draft             The GNU Name System            
     July 2019
    prevent infinite loops, the resolver should implement loop detections
    or limit the recursive resolution of CNAMEs using an upper bound.
 
-6.3.4.  BOX
 
-   In GNS, every "." in a name delegates to another zone, and GNS
-   lookups are expected to return all of the required useful information
-   in one record set.  This is incompatible with the special labels used
-   by DNS for SRV and TLSA records.  Thus, GNS defines the BOX record
-   format to box up SRV and TLSA records and include them in the record
-   set of the label they are associated with.  For example, a TLSA
-   record for "_https._tcp.foo.gnu" will be stored in the record set of
-   "foo.gnu" as a BOX record with service (SVC) 443 (https) and protocol
-   (PROTO) 6 (tcp) and record_type "TLSA".  When a BOX record is
-   received, a GNS resolver must unbox it if the name to be resolved
-   continues with "_SERVICE._PROTO", otherwise it is to be left
-   untouched.  This way, TLSA (and SRV) records do not require a
-   separate network request, and TLSA records become inseparable from
-   the corresponding address records.
 
-6.3.5.  VPN
 
-   If the queried record type is either A or AAAA and the retrieved
-   record set contains at least one VPN record, the resolver must open a
-   tunnel and return the IPv4 or IPv6 tunnel address, respectively.  The
-   type of tunnel depends on the contents of the VPN record data.  No
-   result is returned if the resolver implementation does not support
-   any of the tunnnels provided in the VPN records.
 
 
 
 
+Schanzenbach, et al.     Expires 24 January 2020               [Page 17]
+
+Internet-Draft             The GNU Name System                 July 2019
 
 
+6.3.4.  BOX
 
+   When a BOX record is received, a GNS resolver must unbox it if the
+   name to be resolved continues with "_SERVICE._PROTO", otherwise it is
+   to be left untouched.  This way, TLSA (and SRV) records do not
+   require a separate network request, and TLSA records become
+   inseparable from the corresponding address records.
 
-Schanzenbach, et al.     Expires 24 January 2020               [Page 17]
-
-Internet-Draft             The GNU Name System                 July 2019
+6.3.5.  VPN
 
+   If the queried record type is either A or AAAA and the retrieved
+   record set contains at least one VPN record, the resolver must open a
+   tunnel and return the IPv4 or IPv6 tunnel address, respectively.  The
+   type of tunnel depends on the contents of the VPN record data.  No
+   result is returned if the resolver implementation does not support
+   any of the tunnnels provided in the VPN records.
 
 7.  Zone Revocation
 
@@ -985,6 +1002,14 @@ Internet-Draft             The GNU Name System            
     July 2019
             f89333903b284fe8
             1878bf47f3b39da0
 
+
+
+
+Schanzenbach, et al.     Expires 24 January 2020               [Page 18]
+
+Internet-Draft             The GNU Name System                 July 2019
+
+
             zk (public zone key) :=
             dff911496d025d7e
             0885c03d19153e99
@@ -1002,14 +1027,6 @@ Internet-Draft             The GNU Name System           
      July 2019
             6d656b27392b0fee
 
             d_h :=
-
-
-
-Schanzenbach, et al.     Expires 24 January 2020               [Page 18]
-
-Internet-Draft             The GNU Name System                 July 2019
-
-
             01fb61f482c17633
             77611c4c2509e0f3
             81b0e7e4405c10bd
@@ -1041,6 +1058,14 @@ Internet-Draft             The GNU Name System           
      July 2019
             3425e8a811ae59d2
             99e2747285d2a479
 
+
+
+
+Schanzenbach, et al.     Expires 24 January 2020               [Page 19]
+
+Internet-Draft             The GNU Name System                 July 2019
+
+
             TWOFISH_IV :=
             071be189a9d236f9
             b4a3654bb8c281d4
@@ -1058,14 +1083,6 @@ Internet-Draft             The GNU Name System           
      July 2019
 
 
             RRBLOCK :=
-
-
-
-Schanzenbach, et al.     Expires 24 January 2020               [Page 19]
-
-Internet-Draft             The GNU Name System                 July 2019
-
-
             055cb070e05fe6de SIGNATURE
             ad694a50e5b4dedd
             b9fdcbdbae004f65
@@ -1096,10 +1113,24 @@ Internet-Draft             The GNU Name System          
       July 2019
               STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
               <https://www.rfc-editor.org/info/rfc1034>.
 
+
+
+
+
+Schanzenbach, et al.     Expires 24 January 2020               [Page 20]
+
+Internet-Draft             The GNU Name System                 July 2019
+
+
    [RFC1035]  Mockapetris, P., "Domain names - implementation and
               specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
               November 1987, <https://www.rfc-editor.org/info/rfc1035>.
 
+   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+              specifying the location of services (DNS SRV)", RFC 2782,
+              DOI 10.17487/RFC2782, February 2000,
+              <https://www.rfc-editor.org/info/rfc2782>.
+
    [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
               10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
               2003, <https://www.rfc-editor.org/info/rfc3629>.
@@ -1115,13 +1146,6 @@ Internet-Draft             The GNU Name System           
      July 2019
               DOI 10.17487/RFC5869, May 2010,
               <https://www.rfc-editor.org/info/rfc5869>.
 
-
-
-Schanzenbach, et al.     Expires 24 January 2020               [Page 20]
-
-Internet-Draft             The GNU Name System                 July 2019
-
-
    [RFC5890]  Klensin, J., "Internationalized Domain Names for
               Applications (IDNA): Definitions and Document Framework",
               RFC 5890, DOI 10.17487/RFC5890, August 2010,
@@ -1145,6 +1169,15 @@ Internet-Draft             The GNU Name System           
      July 2019
               for Security", RFC 7748, DOI 10.17487/RFC7748, January
               2016, <https://www.rfc-editor.org/info/rfc7748>.
 
+
+
+
+
+Schanzenbach, et al.     Expires 24 January 2020               [Page 21]
+
+Internet-Draft             The GNU Name System                 July 2019
+
+
    [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
               Signature Algorithm (EdDSA)", RFC 8032,
               DOI 10.17487/RFC8032, January 2017,
@@ -1170,14 +1203,6 @@ Authors' Addresses
    CH-2501 Biel/Bienne
    Switzerland
 
-
-
-
-Schanzenbach, et al.     Expires 24 January 2020               [Page 21]
-
-Internet-Draft             The GNU Name System                 July 2019
-
-
    Email: address@hidden
 
 
@@ -1204,29 +1229,4 @@ Internet-Draft             The GNU Name System           
      July 2019
 
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
 Schanzenbach, et al.     Expires 24 January 2020               [Page 22]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index e6de72e..317f367 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -419,6 +419,17 @@
      <section anchor="gnsrecords_box" numbered="true" toc="default">
        <name>BOX</name>
        <t>
+         In GNS, every "." in a name delegates to another zone, and
+         GNS lookups are expected to return all of the required useful
+         information in one record set.  This is incompatible with the
+         special labels used by DNS for SRV and TLSA records.  Thus, GNS
+         defines the BOX record format to box up SRV and TLSA records and
+         include them in the record set of the label they are associated
+         with.  For example, a
+         TLSA record for "_https._tcp.foo.gnu" will be stored in the record 
set of
+         "foo.gnu" as a BOX record with service (SVC) 443 (https) and protocol 
(PROTO) 6
+         (tcp) and record_type "TLSA".
+         For reference, see also <xref target="RFC2782" />
          A BOX DATA entry has the following format:
        </t>
        <figure anchor="figure_boxrecord">
@@ -956,16 +967,7 @@
          <section anchor="box_processing" numbered="true" toc="default">
            <name>BOX</name>
            <t>
-             In GNS, every "." in a name delegates to another zone, and
-             GNS lookups are expected to return all of the required useful
-             information in one record set.  This is incompatible with the
-             special labels used by DNS for SRV and TLSA records.  Thus, GNS
-             defines the BOX record format to box up SRV and TLSA records and
-             include them in the record set of the label they are associated
-             with.  For example, a
-             TLSA record for "_https._tcp.foo.gnu" will be stored in the 
record set of
-             "foo.gnu" as a BOX record with service (SVC) 443 (https) and 
protocol (PROTO) 6
-             (tcp) and record_type "TLSA".  When a BOX record is received, a 
GNS resolver
+              When a BOX record is received, a GNS resolver
              must unbox it if the name to be resolved continues with 
"_SERVICE._PROTO",
              otherwise it is to be left untouched.  This way, TLSA (and SRV)
              records do not require a separate network request, and TLSA
@@ -1215,22 +1217,47 @@
            <date year="1999" month="March"/>
          </front>
        </reference>
+       <reference anchor="RFC2782" 
target="https://www.rfc-editor.org/info/rfc2782";>
+         <front>
+           <title>
+             A DNS RR for specifying the location of services (DNS SRV)
+           </title>
+           <author initials="A." surname="Gulbrandsen" fullname="A. 
Gulbrandsen">
+             <organization/>
+           </author>
+           <author initials="P." surname="Vixie" fullname="P. Vixie">
+             <organization/>
+           </author>
+           <author initials="L." surname="Esibov" fullname="L. Esibov">
+             <organization/>
+           </author>
+           <date year="2000" month="February"/>
+           <abstract>
+             <t>
+               This document describes a DNS RR which specifies the location 
of the server(s) for a specific protocol and domain. [STANDARDS-TRACK]
+             </t>
+           </abstract>
+         </front>
+         <seriesInfo name="RFC" value="2782"/>
+         <seriesInfo name="DOI" value="10.17487/RFC2782"/>
+       </reference>
+
 
        <!--    <reference anchor="ISO20022">
          <front>
-           <title>ISO 20022 Financial Services - Universal financial industry 
message scheme</title>
-           <author>
-             <organization>International Organization for 
Standardization</organization>
-             <address>
-               <uri>http://www.iso.ch</uri>
-             </address>
-           </author>
-           <date month="May" year="2013"/>
+         <title>ISO 20022 Financial Services - Universal financial industry 
message scheme</title>
+         <author>
+         <organization>International Organization for 
Standardization</organization>
+         <address>
+         <uri>http://www.iso.ch</uri>
+         </address>
+         </author>
+         <date month="May" year="2013"/>
          </front>
        </reference>-->
      </references>
      <!-- Change Log
-     v00 2017-07-23  MS   Initial version
+       v00 2017-07-23  MS   Initial version
      -->
    </back>
  </rfc>

-- 
To stop receiving notification emails like this one, please contact
address@hidden.



reply via email to

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