[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: clarifications, edits
|
From: |
gnunet |
|
Subject: |
[lsd0001] branch master updated: clarifications, edits |
|
Date: |
Tue, 17 Dec 2019 21:21:42 +0100 |
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 4555151 clarifications, edits
4555151 is described below
commit 4555151956256fbc58f8a3f6d38aed4c8ccf12ac
Author: Christian Grothoff <address@hidden>
AuthorDate: Tue Dec 17 21:18:36 2019 +0100
clarifications, edits
---
draft-schanzen-gns.xml | 163 +++++++++++++++++++++++++++++++------------------
1 file changed, 102 insertions(+), 61 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 4fa7e35..86609a6 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -853,9 +853,9 @@
iteration in the resolution is processed.
</t>
<t>
- GNS resolution of a name must start in a given root zone indicated using
+ GNS resolution of a name must start in a given starting zone indicated
using
a zone public key.
- Details on how the root zone may be determined is discussed in
+ Details on how the starting zone may be determined is discussed in
<xref target="governance" />.
</t>
<t>
@@ -873,8 +873,8 @@
<name>Recursion</name>
<t>
In each step of the recursive name resolution, there is an
- authoritative zone zk and a name to resolve which may be empty.
- Initially, the authoritative zone is the root entry zone. If the
name
+ authoritative zone zk and a name to resolve. The name may be empty.
+ Initially, the authoritative zone is the start zone. If the name
is empty, it is interpreted as the apex label "@".
</t>
<t>
@@ -899,34 +899,55 @@
</section>
<section anchor="record_processing" numbered="true" toc="default">
<name>Record Processing</name>
- <t>
+ <t>
Record processing occurs at the end of a single recursion. We assume
that the RRBLOCK has been cryptographically verified and decrypted.
At this point, we must first determine if we have received a valid
record set in the context of the name we are trying to resolve:
</t>
- <t>
+ <ol>
+ <li>
Case 1:
- If the remainder of the name to resolve is empty and the records set
+ If the remainder of the name to resolve is empty and the record set
does not consist of a PKEY, CNAME or DNS2GNS record, the record set
- is the result and the resolution is concluded.
- </t>
- <t>
- Case 2:
- If the remainder of the name to resolve is not empty, the records
- result MUST consist of a single PKEY record, CNAME record,
- or one or more GNS2DNS records. Otherwise, resolution fails
+ is the result and the recursion is concluded.
+ </li>
+ <li>
+ Case 2:
+ If the name to be resolved is of the format
+ "_SERVICE._PROTO" and the record set contains one or more matching
BOX
+ records, the records in the BOX records are the result and the
recusion
+ is concluded (Section <xref target="box_processing" />).
+ </li>
+ <li>
+ Case 3:
+ If the remainder of the name to resolve is not empty and
+ does not match the "_SERVICE._PROTO" syntax, then the current record
set
+ MUST consist of a single PKEY record
+ (Section <xref target="pkey_processing" />),
+ a single CNAME record
+ (Section <xref target="cname_processing" />),
+ or one or more GNS2DNS records
+ (Section <xref target="gns2dns_processing" />),
+ which are processed
+ as described in the respective sections below.
+ Otherwise, resolution fails
and the resolver MUST return an empty record set.
- In the following, we describe how the special processing of the
above
- record types is performed.
- </t>
+
+ Finally, after the recursion terminates, the client preferences
+ for the record type SHOULD be considered. If a VPN record is found
+ and the client requests an A or AAAA record, the VPN record
+ SHOULD be converted (Section <xref target="vpn_processing" />)
+ if possible.
+ </li>
+ </ol>
<section anchor="pkey_processing" numbered="true" toc="default">
<name>PKEY</name>
<t>
When the resolver encounters a PKEY record and the remainder of
the name is not empty, resolution continues
- recursively with the remainder of the name in the newly discovered
- GNS zone.
+ recursively with the remainder of the name in the
+ GNS zone specified in the PKEY record.
</t>
<t>
If the remainder of the name to resolve is empty and we have
@@ -941,13 +962,13 @@
<section anchor="gns2dns_processing" numbered="true" toc="default">
<name>GNS2DNS</name>
<t>
- When a resolver encounters a GNS2DNS record and the remaining name
+ When a resolver encounters one or more GNS2DNS records and the
remaining name
is empty and the desired record type is GNS2DNS, the GNS2DNS
- records are returned.
+ 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
+ IP(s) of the specified DNS 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.
@@ -959,7 +980,7 @@
<t>
Multiple GNS2DNS records may be stored under the same label,
in which case the resolver MUST try all of them.
- The resolver may try them in any order or even in parallel.
+ 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 and an
emtpy record set is returned as the record set is invalid.
@@ -968,13 +989,24 @@
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
+ resolved by querying the DNS name server(s). As the DNS servers
+ specified are possibly authoritative DNS servers, the GNS
resolver MUST
+ support recursive resolution and MUST NOT delegate this to the
authoritative DNS servers.
The first successful recursive name resolution result
is returned to the client.
</t>
+ <t>
+ GNS resolvers SHOULD offer a configuration
+ option to disable DNS processing to avoid information leakage
+ and provide a consistent security profile for all name resolutions.
+ Such resolvers would return an empty record set upon encountering
+ a GNS2DNS record during the recursion. However, if GNS2DNS records
+ are encountered in the record set for the apex and a GNS2DNS record
+ is expicitly requested by the application, such records MUST
+ still be returned, even if DNS support is disabled by the
+ GNS resolver configuration.
+ </t>
</section>
<section anchor="cname_processing" numbered="true" toc="default">
<name>CNAME</name>
@@ -988,7 +1020,7 @@
current zone. Otherwise, the resulting name is resolved via the
default operating system name resolution process.
This may in turn again trigger a GNS resolution process depending
- on the system configuration.
+ on the system configuration.
<!-- Note: this permits non-DNS resolvers to be triggered via
NSS! -->
</t>
<t>
@@ -998,6 +1030,8 @@
In order to prevent infinite loops, the resolver MUST
implement loop detections or limit the number of recursive
resolution steps.
+ <!-- Note: Martin: do we actually implement this in GNS today?
+ Seems rather tricky to detect if we go via NSS... -->
</t>
</section>
<section anchor="box_processing" numbered="true" toc="default">
@@ -1014,7 +1048,8 @@
<section anchor="vpn_processing" numbered="true" toc="default">
<name>VPN</name>
<t>
- If the queried record type is either A or AAAA and the retrieved
+ At the end of the recursion,
+ if the queried record type is either A or AAAA and the retrieved
record set contains at least one VPN record, the resolver SHOULD
open a tunnel and return the IPv4 or IPv6 tunnel address,
respectively.
@@ -1028,7 +1063,13 @@
<section anchor="revocation" numbered="true" toc="default">
<name>Zone Revocation</name>
<t>
- In order to revoke a zone, a signed revocation object SHOULD be
+ Whenever a recursive resolver encounters a new GNS zone, it MUST
+ check against the local revocation list whether the respective
+ zone key has been revoked. If the zone key was revoked, the
+ resolution MUST fail with an empty result set.
+ </t>
+ <t>
+ In order to revoke a zone key, a signed revocation object SHOULD be
published.
This object MUST be signed using the private zone key.
The revocation object is flooded in the overlay network. To prevent
@@ -1043,38 +1084,33 @@
<section anchor="governance" numbered="true" toc="default">
<name>Determining the Root Zone and Zone Governance</name>
<t>
- The resolution of a GNS name must start in a given root zone
+ The resolution of a GNS name must start in a given start zone
indicated to the resolver using any public zone key.
- The local resolver may have a local root zone configured/hard-coded
- which points to a local or remote root zone authority.
- A resolver client may also determine the root zone from the
- name given for resolution or using information retrieved out of band.
- In general, the governance model of any zone is at the sole discretion
- of the zone owner. However, the choice of root zone(s) is at the sole
+ The local resolver may have a local start zone configured/hard-coded
+ which points to a local or remote start zone key.
+ A resolver client may also determine the start zone from the
+ suffix of the name given for resolution or using information
+ retrieved out of band.
+ The governance model of any zone is at the sole discretion
+ of the zone owner. However, the choice of start zone(s) is at the sole
discretion of the local system administrator or user.
+ </t>
+ <t>
This is an important distinguishing factor from the Domain Name System
where root zone governance is centralized at the Internet Corporation
for Assigned Names and Numbers (ICANN).
- In essence, GNS follows the idea of a hyper-hyper local root zone
- configuration.
+ In DNS terminology, GNS roughly follows the idea of a hyper-hyper
+ local root zone deployment, with the difference that it is not
+ expected that all deployments use the same local root zone.
</t>
<t>
- In the following, we give some examples how a local client resolver
may
- discover the root zone.
- Any of the examples below may be exchanged with other mechanisms
- and are not normative.
- Possible high-level mechanisms to discover the root zone for a given
- name are:
+ In the following, we give examples how a local client resolver SHOULD
+ discover the start zone. The process given is not exhaustive and
+ clients MAY suppliement it with other mechanisms or ignore it if the
+ particular application requires a different process.
</t>
- <ol>
- <li>The top-level domain is an encoded local zone key.</li>
- <li>A local configuration exists that allow to map a name suffix
- to a zone key.</li>
- <li>An out-of-band mechnism exists that allow to determine the
- authoritative root zone for a given name.</li>
- </ol>
<t>
- The resolver client may try to interpret the top-level domain of
+ GNS clients SHOULD first try to interpret the top-level domain of
a GNS name as a zone key.
For example. if the top-level domain is a Base32-encoded public zone
key "zk", the root zone of the resolution process is implicitly given
@@ -1086,10 +1122,13 @@
=> Name to resolve from root zone: www.example
]]></artwork>
<t>
- In GNS, users may own and manage their own zones.
- Each local zone may be associated with a single GNS label.
- If this label is the top-level domain of the name
- to resolve, resolution starts from the respective local zone:
+ In GNS, users MAY own and manage their own zones.
+ Each local zone SHOULD be associated with a single GNS label,
+ but users MAY choose to use longer names consisting of
+ multiple labels.
+ If the name of a locally managed zone matches the suffix
+ of the name to be resolved,
+ resolution SHOULD start from the respective local zone:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
Example name: www.example.gnu
@@ -1102,13 +1141,15 @@
=> Name to resolve from entry zone: www.example
]]></artwork>
<t>
- Finally, external "suffix to zone mappings" may exist.
- Suffix to zone key mappings may be configurable through a local
+ Finally, additional "suffix to zone" mappings MAY be configured.
+ Suffix to zone key mappings SHOULD be configurable through a local
configuration file or database by the user or system administrator.
- The suffix may consist of multiple GNS labels concatenated with a
+ The suffix MAY consist of multiple GNS labels concatenated with a
".". If multiple suffixes match the name to resolve, the longest
- matching suffix is used. The suffix length of two results
- cannot be equal, as this would indicate a misconfiguration:
+ matching suffix MUST BE used. The suffix length of two results
+ cannot be equal, as this would indicate a misconfiguration.
+ If both a locally managed zone and a configuration entry exist
+ for the same suffix, the locally managed zone MUST have priority.
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
Example name: www.example.gnu
--
To stop receiving notification emails like this one, please contact
address@hidden.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0001] branch master updated: clarifications, edits,
gnunet <=