[lsd0001] branch master updated: misc clarifications

[gnunet]

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

grothoff pushed a commit to branch master
in repository lsd0001.

The following commit(s) were added to refs/heads/master by this push:
     new aa3e16a  misc clarifications
aa3e16a is described below

commit aa3e16a5c20727ef68946c1959181293831d33ef
Author: Christian Grothoff <address@hidden>
AuthorDate: Sun Nov 10 21:56:38 2019 +0100

    misc clarifications
---
 draft-schanzen-gns.xml | 114 ++++++++++++++++++++++++++++++-------------------
 1 file changed, 71 insertions(+), 43 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index d94334c..04ae9af 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -911,9 +911,14 @@
        <section anchor="record_retrieval" numbered="true" toc="default">
          <name>Record Retrieval</name>
          <t>
-           In order to resolve a name in GNS, a type MAY be given.
-           However, filtering of record results according to type is done after
-           the resource record set is retrieved.
+           When GNS name resolution is requested, a desired record type MAY be 
provided
+           by the client.
+           The GNS resolver will use the desired record type to guide 
processing, for
+           example by providing conversion of VPN records to A or AAAA 
records, if that
+           is desired.
+
+           However, filtering of record sets according to the required record 
types
+           MUST still be done by the client after the resource record set is 
retrieved.
          </t>
          <t>
            In each step of the recursive name resolution, there is an
@@ -931,84 +936,107 @@
            Upon receiving the RRBLOCK from the DHT, apart from verifying the
            provided signature, the resolver MUST check that the authoritative
            zone key was used to sign the record:
-           The derived zone key "h*zk" must match the public key provided in
-           the RRBLOCK.
+           The derived zone key "h*zk" MUST match the public key provided in
+           the RRBLOCK, otherwise the RRBLOCK MUST be ignored and the DHT 
lookup
+           GET(q) MUST continue.
          </t>
        </section>
        <section anchor="record_processing" numbered="true" toc="default">
          <name>Record Processing</name>
          <t>
            If the remainder of the name to resolve is not empty, the records
-           result MUST consist of a single PKEY record or one or more GNS2DNS 
records.
-           The recursion is then continued with the PKEY record value as new
-           authoritative zone or using the specified DNS server(s) as defined
-           int the following.
-         </t>
-         <t>
-           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
-           label "@" as remaining name. If the record type to be resolved is
-           PKEY, the PKEY record set is returned and the resolution is 
concluded.
+           result MUST consist of a single PKEY record, CNAME record,
+           or one or more GNS2DNS records. Otherwise, resolution fails
+           and GNS returns an empty record set.
          </t>
          <t>
            If the remainder of the name to resolve is empty and the records set
-           does not consist of a PKEY record, the record set is the result and
-           the resolution is concluded.
+           does not consist of a PKEY, CNAME or DNS2GNS record, the record set
+           is the result and the resolution is concluded.
          </t>
          <section anchor="pkey_processing" numbered="true" toc="default">
            <name>PKEY</name>
            <t>
-             When a resolver encounters a PKEY record, resolution continues
+             When a resolver encounters a PKEY record and the remainder of
+             the name is non-empty, resolution continues
              recursively with the remainder of the name in the newly discovered
              GNS zone as defined in <xref target="entry_zone" />.
            </t>
+           <t>
+             If the remainder of the name to resolve is empty and 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
+             label "@" as remaining name, except in the case where the desired
+             record type is PKEY, in which case the PKEY record is returned and
+             the resolution is concluded without resolving the empty apex 
label.
+           </t>
          </section>
          <section anchor="gns2dns_processing" numbered="true" toc="default">
            <name>GNS2DNS</name>
            <t>
-             When a resolver encounters a GNS2DNS record it is expected that 
it first
+             When a resolver encounters a GNS2DNS record and the remaining name
+             is empty and the desired record type is GNS2DNS, the GNS2DNS 
records
+             are returned.
+           </t>
+           <t>
+             Otherwise, it is expected that the resolver first
              resolves the IP(s) of the DNS specified name 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).
+             If the DNS server name ends in ".<Base32(zk)>", the DNS server 
name
+             is to be resolved against the GNS zone zk.
+           </t>
+           <t>
              Multiple
              GNS2DNS records may be stored under the same label, in which case 
the
-             resolver MUST try all of them.  However, if multiple GNS2DNS 
records
-             are present, the DNS name MUST be identical for all of them.
+             resolver MUST try all of them.  The resolver may try them in any
+             order or even in parallel.  If multiple GNS2DNS records
+             are present, the DNS name MUST be identical for all of them, if
+             not the resolution fails. <!-- FIXME: specify how to return the 
error? -->
+             The first successful recursive name resolution result
+             is returned to the client.
+           </t>
+           <t>
+             Once the IP addresses of the DNS servers have been determined,
+             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).  As the DNS servers
+             are likely authoritative DNS servers, the GNS resolver MUST
+             support recursive resolution and not delegate this to the
+             authoritative DNS servers.
            </t>
          </section>
          <section anchor="cname_processing" numbered="true" toc="default">
            <name>CNAME</name>
            <t>
-             Upon encountering a CNAME record, the resolver must continue the
-             resolution using the CNAME unless the queried record type is a
-             CNAME and we have reached the leftmost label of the name.
-             Resolution may continue either in GNS if GNS is authoritative of
-             the respective TLD or if the TLD is a relative zone indicator 
("+")
-             and we have found the CNAME in a GNS zone.
-             Otherwise, the resolver should continue the resolution recursively
-             through DNS.
+             If a CNAME record is encountered, the canonical name is
+             appended to the remaining name, except if the remaining name
+             is empty and the desired record type is CNAME, in which case
+             the resolution concludes with the CNAME record.
+             If the canonical 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.
+             <!-- Note: this permits non-DNS resolvers to be triggered via 
NSS! -->
            </t>
            <t>
              The recursive DNS resolution process may yield a CNAME as well
-             which in turn may either point into the DNS or GNS namespace.
-             In order to prevent infinite loops, the resolver should
-             implement loop detections or limit the recursive resolution of
-             CNAMEs using an upper bound.
+             which in turn may either point into the DNS or GNS namespace
+             (if it ends in a ".<Base32(zk)>").
+             In order to prevent infinite loops, the resolver MUST
+             implement loop detections or limit the number of recursive 
resolution
+             steps.
            </t>
          </section>
          <section anchor="box_processing" numbered="true" toc="default">
            <name>BOX</name>
            <t>
-              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)
+             When a BOX record is received, a GNS resolver
+             must unbox it if the name to be resolved continues with 
"_SERVICE._PROTO".
+             Otherwise, the BOX record 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.
            </t>
@@ -1017,11 +1045,11 @@
            <name>VPN</name>
            <t>
              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
+             record set contains at least one VPN record, the resolver SHOULD 
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.
+             The VPN record MUST be returned if the resolver implementation 
does not
+             support setting up a tunnnel.
            </t>
          </section>
        </section>

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