lsd0001

commit c2ab65f18db48574a10f984a2558f6e6b3a355dc
parent e588c60d71751faff51df1b725f2af359d1b535f
Author: Schanzenbach, Martin <mschanzenbach@posteo.de>
Date:   Fri,  4 Oct 2019 12:24:28 +0200

Merge branch 'master' of ssh://gnunet.org/lsd0001

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

1 file changed, 42 insertions(+), 24 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -30,13 +30,13 @@
    </address>
   </author>
   <author fullname="Christian Grothoff" initials="C." surname="Grothhoff">
-   <organization>GNUnet e.V.</organization>
+   <organization>Berner Fachhochschule</organization>
    <address>
     <postal>
-     <street>Boltzmannstrasse 3</street>
-     <city>Garching</city>
-     <code>85748</code>
-     <country>DE</country>
+     <street>Höheweg 80</street>
+     <city>Biel/Bienne</city>
+     <code>2501</code>
+     <country>CH</country>
     </postal>
     <email>schanzen@gnunet.org</email>
    </address>
@@ -192,7 +192,7 @@
   <t>In GNS, a delegation of a label to a zone is represented through a PKEY
     record. A PKEY resource record contains the public key of the zone to
     delegate to. A PKEY record MUST be the only record under a label. No other
-    records are allowed. The a PKEY DATA entry has the following format:</t>
+    records are allowed. A PKEY DATA entry has the following format:</t>
   <figure anchor="figure_pkeyrecord">
     <artwork name="" type="" align="left" alt=""><![CDATA[
       0     8     16    24    32    40    48    56
@@ -213,9 +213,19 @@
     in DNS followed by a DNS server. Both names are in the format defined in
     <xref target="RFC1034" /> for DNS names.
     If a resolver encounters a GNS2DNS record it is expected that it first
-    resolves the IP(s) of the DNS servers using DNS. Then, the encountered DNS
-    name is resolved by querying the name server(s).
-    The a GNS2DNS DATA entry has the following format:</t>
+    resolves the IP(s) of the DNS server(s).  GNS2DNS records MAY contain
+    numeric IPv4 or IPv6 addresses, allowing the resolver to skip this step.
+    The DNS server names may themselves be names in GNS or DNS.  If the
+    DNS server name ends in ".+", the rest of the name is to be interpreted
+    relative to the zone of the GNS2DNS record.
+    Then, the DNS name from the GNS2DNS record is 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
+    resolve MUST try all of them.  However, if multiple GNS2DNS records
+    are present, the DNS name MUST be identical for all of them.
+    A GNS2DNS DATA entry has the following format:</t>
   <figure anchor="figure_gns2dnsrecord">
     <artwork name="" type="" align="left" alt=""><![CDATA[
       0     8     16    24    32    40    48    56
@@ -237,14 +247,16 @@
 
 <section anchor="gnsrecords_leho" numbered="true" toc="default">
   <name>LEHO</name>
-  <t>As names in GNS are not globally unique, established practices such as
-    virtual hosting do not apply directly. In order to support such use cases,
-    GNS support a legacy hostname record which can be used by applications
-    (e.g. HTTP clients) in order to provide the necessary information.
-    The resource record contains a string which is not 0-terminated representing
-    the legacy hostname to use. It is expected to be found together in a single
-    resource record with an IPv4 or IPv6 address.
-    A LEHO DATA entry has the following format:</t>
+  <t>Legacy hostname records can be used by applications that are expected
+  to supply a DNS name on the application layer. The most common use case
+  is HTTP virtual hosting, which as-is would not work with GNS names as
+  those may not be globally unique.
+
+  A LEHO resource record contains a string (which is not 0-terminated) representing
+  the legacy hostname to use (FIXME: in UTF-8 or PUNY?).
+  It is expected to be found together in a single
+  resource record with an IPv4 or IPv6 address.
+   A LEHO DATA entry has the following format:</t>
   <figure anchor="figure_lehorecord">
     <artwork name="" type="" align="left" alt=""><![CDATA[
       0     8     16    24    32    40    48    56
@@ -261,14 +273,20 @@
 <section anchor="gnsrecords_box" numbered="true" toc="default">
   <name>BOX</name>
   <t>
-    Record type used to box up SRV and TLSA records.  For example, a
-    TLSA record for "_https._tcp.foo.gnu" will be stored under
-    "foo.gnu" as a BOX record with service 443 (https) and protocol 6
+    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 contained "_SERVICE._PROTO", otherwise it is
-    left untouched.  This is done to ensure that TLSA (and SRV)
-    records do not require a separate network request, thus making TLSA
-    records inseparable from the corresponding A/AAAA/VPN/etc. records.
+    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.
     A BOX DATA entry has the following format:</t>
   <figure anchor="figure_boxrecord">
     <artwork name="" type="" align="left" alt=""><![CDATA[