[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: update files
|
From: |
gnunet |
|
Subject: |
[lsd0001] branch master updated: update files |
|
Date: |
Tue, 17 Dec 2019 21:27:48 +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 63b8257 update files
63b8257 is described below
commit 63b8257b4e6eb4dcd279a3d9f1b4cefcbea3226f
Author: Schanzenbach, Martin <address@hidden>
AuthorDate: Tue Dec 17 21:24:41 2019 +0100
update files
---
draft-schanzen-gns.html | 163 +++++++++++++++-----------
draft-schanzen-gns.txt | 298 ++++++++++++++++++++++++------------------------
2 files changed, 248 insertions(+), 213 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index fb5f808..aa50230 100644
--- a/draft-schanzen-gns.html
+++ b/draft-schanzen-gns.html
@@ -2017,9 +2017,9 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
In the following, we define how resolution is initiated and each
iteration in the resolution is processed.<a href="#section-6-1"
class="pilcrow">¶</a></p>
<p id="section-6-2">
- 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
<a href="#governance" class="xref">Section 8</a>.<a href="#section-6-2"
class="pilcrow">¶</a></p>
<p id="section-6-3">
When GNS name resolution is requested, a desired record type MAY be
@@ -2038,8 +2038,8 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
</h3>
<p id="section-6.1-1">
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 "@".<a
href="#section-6.1-1" class="pilcrow">¶</a></p>
<p id="section-6.1-2">
From here, the following steps are recursively executed, in
order:<a href="#section-6.1-2" class="pilcrow">¶</a></p>
@@ -2074,19 +2074,42 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
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:<a
href="#section-6.2-1" class="pilcrow">¶</a></p>
-<p id="section-6.2-2">
+<ol start="1" type="1" class="normal" id="section-6.2-2">
+ <li id="section-6.2-2.1">
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.<a
href="#section-6.2-2" class="pilcrow">¶</a></p>
-<p id="section-6.2-3">
- 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.<a
href="#section-6.2-2.1" class="pilcrow">¶</a>
+</li>
+ <li id="section-6.2-2.2">
+ 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 <a href="#box_processing" class="xref">Section
6.2.4</a>).<a href="#section-6.2-2.2" class="pilcrow">¶</a>
+</li>
+ <li id="section-6.2-2.3">
+ 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 <a href="#pkey_processing" class="xref">Section 6.2.1</a>),
+ a single CNAME record
+ (Section <a href="#cname_processing" class="xref">Section 6.2.3</a>),
+ or one or more GNS2DNS records
+ (Section <a href="#gns2dns_processing" class="xref">Section 6.2.2</a>),
+ 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.<a href="#section-6.2-3"
class="pilcrow">¶</a></p>
+
+ 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 <a href="#vpn_processing"
class="xref">Section 6.2.5</a>)
+ if possible.<a href="#section-6.2-2.3" class="pilcrow">¶</a>
+</li>
+ </ol>
<div id="pkey_processing">
<section id="section-6.2.1">
<h4 id="name-pkey-2">
@@ -2095,8 +2118,8 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<p id="section-6.2.1-1">
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.<a href="#section-6.2.1-1" class="pilcrow">¶</a></p>
+ recursively with the remainder of the name in the
+ GNS zone specified in the PKEY record.<a href="#section-6.2.1-1"
class="pilcrow">¶</a></p>
<p id="section-6.2.1-2">
If the remainder of the name to resolve is empty and we have
received a record set containing only a single PKEY record, the
@@ -2113,12 +2136,12 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<a href="#section-6.2.2" class="section-number selfRef">6.2.2. </a><a
href="#name-gns2dns-2" class="section-name selfRef">GNS2DNS</a>
</h4>
<p id="section-6.2.2-1">
- 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.<a href="#section-6.2.2-1"
class="pilcrow">¶</a></p>
<p id="section-6.2.2-2">
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.
@@ -2129,7 +2152,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<p id="section-6.2.2-3">
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.<a
href="#section-6.2.2-3" class="pilcrow">¶</a></p>
@@ -2137,12 +2160,22 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
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.<a href="#section-6.2.2-4"
class="pilcrow">¶</a></p>
+<p id="section-6.2.2-5">
+ 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.<a href="#section-6.2.2-5"
class="pilcrow">¶</a></p>
</section>
</div>
<div id="cname_processing">
@@ -2190,7 +2223,8 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<a href="#section-6.2.5" class="section-number selfRef">6.2.5. </a><a
href="#name-vpn-2" class="section-name selfRef">VPN</a>
</h4>
<p id="section-6.2.5-1">
- 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.
@@ -2209,15 +2243,20 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<a href="#section-7" class="section-number selfRef">7. </a><a
href="#name-zone-revocation" class="section-name selfRef">Zone Revocation</a>
</h2>
<p id="section-7-1">
- 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.<a href="#section-7-1"
class="pilcrow">¶</a></p>
+<p id="section-7-2">
+ 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
flooding attacks, the revocation message MUST contain a proof-of-work.
The revocation message including the proof-of-work MAY be calculated
- ahead of time to support timely revocation.<a href="#section-7-1"
class="pilcrow">¶</a></p>
-<p id="section-7-2">
- A revocation message is defined as follows:<a href="#section-7-2"
class="pilcrow">¶</a></p>
+ ahead of time to support timely revocation.<a href="#section-7-2"
class="pilcrow">¶</a></p>
+<p id="section-7-3">
+ A revocation message is defined as follows:<a href="#section-7-3"
class="pilcrow">¶</a></p>
</section>
</div>
<div id="governance">
@@ -2226,39 +2265,30 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<a href="#section-8" class="section-number selfRef">8. </a><a
href="#name-determining-the-root-zone-a" class="section-name
selfRef">Determining the Root Zone and Zone Governance</a>
</h2>
<p id="section-8-1">
- 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
- discretion of the local system administrator or user.
+ 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.<a
href="#section-8-1" class="pilcrow">¶</a></p>
+<p id="section-8-2">
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.<a href="#section-8-1" class="pilcrow">¶</a></p>
-<p id="section-8-2">
- 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:<a href="#section-8-2" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal" id="section-8-3">
- <li id="section-8-3.1">The top-level domain is an encoded local zone
key.<a href="#section-8-3.1" class="pilcrow">¶</a>
-</li>
- <li id="section-8-3.2">A local configuration exists that allow to map
a name suffix
- to a zone key.<a href="#section-8-3.2" class="pilcrow">¶</a>
-</li>
- <li id="section-8-3.3">An out-of-band mechnism exists that allow to
determine the
- authoritative root zone for a given name.<a href="#section-8-3.3"
class="pilcrow">¶</a>
-</li>
- </ol>
+ 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.<a
href="#section-8-2" class="pilcrow">¶</a></p>
+<p id="section-8-3">
+ 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.<a href="#section-8-3"
class="pilcrow">¶</a></p>
<p id="section-8-4">
- 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
@@ -2271,10 +2301,13 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
</pre><a href="#section-8-5" class="pilcrow">¶</a>
</div>
<p id="section-8-6">
- 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:<a
href="#section-8-6" class="pilcrow">¶</a></p>
+ 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:<a
href="#section-8-6" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-8-7">
<pre>
Example name: www.example.gnu
@@ -2288,13 +2321,15 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
</pre><a href="#section-8-7" class="pilcrow">¶</a>
</div>
<p id="section-8-8">
- 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:<a
href="#section-8-8" class="pilcrow">¶</a></p>
+ 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.<a
href="#section-8-8" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-8-9">
<pre>
Example name: www.example.gnu
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
index bb684c6..6433ffc 100644
--- a/draft-schanzen-gns.txt
+++ b/draft-schanzen-gns.txt
@@ -78,17 +78,17 @@ Table of Contents
6. Name Resolution . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Recursion . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Record Processing . . . . . . . . . . . . . . . . . . . . 16
- 6.2.1. PKEY . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 6.2.1. PKEY . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . 17
- 6.2.3. CNAME . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 6.2.3. CNAME . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2.4. BOX . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2.5. VPN . . . . . . . . . . . . . . . . . . . . . . . . . 18
- 7. Zone Revocation . . . . . . . . . . . . . . . . . . . . . . . 18
+ 7. Zone Revocation . . . . . . . . . . . . . . . . . . . . . . . 19
8. Determining the Root Zone and Zone Governance . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 20
- 12. Normative References . . . . . . . . . . . . . . . . . . . . 22
+ 12. Normative References . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction
@@ -820,9 +820,9 @@ Internet-Draft The GNU Name System
November 2019
storage. In the following, we define how resolution is initiated and
each iteration in the resolution is processed.
- GNS resolution of a name must start in a given root zone indicated
- using a zone public key. Details on how the root zone may be
- determined is discussed in Section 8.
+ GNS resolution of a name must start in a given starting zone
+ indicated using a zone public key. Details on how the starting zone
+ may be determined is discussed in Section 8.
When GNS name resolution is requested, a desired record type MAY be
provided by the client. The GNS resolver will use the desired record
@@ -845,9 +845,9 @@ Internet-Draft The GNU Name System
November 2019
6.1. Recursion
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 is empty, it is interpreted as the apex label "@".
+ 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 "@".
From here, the following steps are recursively executed, in order:
@@ -873,23 +873,23 @@ Internet-Draft The GNU Name System
November 2019
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:
- Case 1: If the remainder of the name to resolve is empty and the
- records set does not consist of a PKEY, CNAME or DNS2GNS record, the
- record set is the result and the resolution is concluded.
+ 1. Case 1: 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 recursion is concluded.
- 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 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.
-
-6.2.1. PKEY
-
- 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.
+ 2. 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 Section 6.2.4).
+ 3. 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 Section 6.2.1), a single CNAME record
+ (Section Section 6.2.3), or one or more GNS2DNS records
+ (Section Section 6.2.2), which are processed as described in the
+ respective sections below. Otherwise, resolution fails and the
+ resolver MUST return an empty record set. Finally, after the
@@ -898,6 +898,17 @@ Schanzenbach, et al. Expires 13 May 2020
[Page 16]
Internet-Draft The GNU Name System November 2019
+ 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 Section 6.2.5) if possible.
+
+6.2.1. PKEY
+
+ 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 GNS zone specified in the PKEY record.
+
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
@@ -907,12 +918,12 @@ Internet-Draft The GNU Name System
November 2019
6.2.2. GNS2DNS
- 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.
+ 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.
Otherwise, it is expected that the resolver first resolves the IP(s)
- of the DNS specified name server(s). GNS2DNS records MAY contain
+ 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.
If the DNS server name ends in ".+", the rest of the name is to be
@@ -921,7 +932,7 @@ Internet-Draft The GNU Name System
November 2019
resolved against the GNS zone zk.
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
+ case the 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 and an emtpy record set is returned as the record
@@ -929,11 +940,28 @@ Internet-Draft The GNU Name System
November 2019
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. The first successful recursive name
- resolution result is returned to the client.
+ name to be resolved, and 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.
+
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 17]
+
+Internet-Draft The GNU Name System November 2019
+
+
+ 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.
6.2.3. CNAME
@@ -946,14 +974,6 @@ Internet-Draft The GNU Name System
November 2019
system name resolution process. This may in turn again trigger a GNS
resolution process depending on the system configuration.
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 17]
-
-Internet-Draft The GNU Name System November 2019
-
-
The recursive DNS resolution process may yield a CNAME as well 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
@@ -970,32 +990,12 @@ Internet-Draft The GNU Name System
November 2019
6.2.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 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.
- The VPN record MUST be returned if the resolver implementation does
- not support setting up a tunnnel.
-
-7. Zone Revocation
-
- In order to revoke a zone, 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
- flooding attacks, the revocation message MUST contain a proof-of-
- work. The revocation message including the proof-of-work MAY be
- calculated ahead of time to support timely revocation.
-
- A revocation message is defined as follows:
-
-
-
-
-
-
-
-
-
+ 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. The type of tunnel depends on the
+ contents of the VPN record data. The VPN record MUST be returned if
+ the resolver implementation does not support setting up a tunnnel.
@@ -1010,36 +1010,47 @@ Schanzenbach, et al. Expires 13 May 2020
[Page 18]
Internet-Draft The GNU Name System November 2019
-8. Determining the Root Zone and Zone Governance
-
- The resolution of a GNS name must start in a given root 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 discretion
- of the local system administrator or user. 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.
+7. Zone Revocation
- 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:
+ 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.
- 1. The top-level domain is an encoded local zone key.
+ 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
+ flooding attacks, the revocation message MUST contain a proof-of-
+ work. The revocation message including the proof-of-work MAY be
+ calculated ahead of time to support timely revocation.
- 2. A local configuration exists that allow to map a name suffix to a
- zone key.
+ A revocation message is defined as follows:
- 3. An out-of-band mechnism exists that allow to determine the
- authoritative root zone for a given name.
+8. Determining the Root Zone and Zone Governance
- The resolver client may try to interpret the top-level domain of a
+ 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 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.
+
+ 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 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.
+
+ 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.
+
+ 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 by the name:
@@ -1048,17 +1059,6 @@ Internet-Draft The GNU Name System
November 2019
=> Root zone: zk
=> Name to resolve from root zone: www.example
- 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:
-
-
-
-
-
-
-
Schanzenbach, et al. Expires 13 May 2020 [Page 19]
@@ -1066,6 +1066,12 @@ Schanzenbach, et al. Expires 13 May 2020
[Page 19]
Internet-Draft The GNU Name System November 2019
+ 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:
+
Example name: www.example.gnu
Local zones:
fr = (d0,zk0)
@@ -1075,13 +1081,15 @@ Internet-Draft The GNU Name System
November 2019
=> Entry zone: zk1
=> Name to resolve from entry zone: www.example
- Finally, external "suffix to zone mappings" may exist. Suffix to
- zone key mappings may 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 ".". 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:
+ 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
+ ".". If multiple suffixes match the name to resolve, the longest
+ 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.
Example name: www.example.gnu
Local suffix mappings:
@@ -1105,15 +1113,7 @@ Internet-Draft The GNU Name System
November 2019
The following represents a test vector for a record of type MX with a
priority of 10 and the mail hostname mail.example.com.
- label := "mail"
- d :=
- 71199f7b287cc77a
- 0d21b5e40a77cb1d
- f89333903b284fe8
- 1878bf47f3b39da0
-
- zk (public zone key) :=
@@ -1122,6 +1122,15 @@ Schanzenbach, et al. Expires 13 May 2020
[Page 20]
Internet-Draft The GNU Name System November 2019
+ label := "mail"
+
+ d :=
+ 71199f7b287cc77a
+ 0d21b5e40a77cb1d
+ f89333903b284fe8
+ 1878bf47f3b39da0
+
+ zk (public zone key) :=
dff911496d025d7e
0885c03d19153e99
4f213f23ea719eca
@@ -1161,6 +1170,14 @@ Internet-Draft The GNU Name System
November 2019
AES_IV :=
a808b929bc9fad7a
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 21]
+
+Internet-Draft The GNU Name System November 2019
+
+
686bbe3432bed77a
TWOFISH_KEY :=
@@ -1170,14 +1187,6 @@ Internet-Draft The GNU Name System
November 2019
99e2747285d2a479
TWOFISH_IV :=
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 21]
-
-Internet-Draft The GNU Name System November 2019
-
-
071be189a9d236f9
b4a3654bb8c281d4
@@ -1218,15 +1227,6 @@ Internet-Draft The GNU Name System
November 2019
001fd19a6406a721
713f0a0d
-12. Normative References
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
- <https://www.rfc-editor.org/info/rfc1034>.
-
- [RFC1035] Mockapetris, P., "Domain names - implementation and
-
-
Schanzenbach, et al. Expires 13 May 2020 [Page 22]
@@ -1234,6 +1234,13 @@ Schanzenbach, et al. Expires 13 May 2020
[Page 22]
Internet-Draft The GNU Name System November 2019
+12. Normative References
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
+ <https://www.rfc-editor.org/info/rfc1034>.
+
+ [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>.
@@ -1276,13 +1283,6 @@ Internet-Draft The GNU Name System
November 2019
Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
April 2013, <https://www.rfc-editor.org/info/rfc6895>.
- [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
- Algorithm (DSA) and Elliptic Curve Digital Signature
- Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
- 2013, <https://www.rfc-editor.org/info/rfc6979>.
-
-
-
Schanzenbach, et al. Expires 13 May 2020 [Page 23]
@@ -1290,6 +1290,11 @@ Schanzenbach, et al. Expires 13 May 2020
[Page 23]
Internet-Draft The GNU Name System November 2019
+ [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
+ Algorithm (DSA) and Elliptic Curve Digital Signature
+ Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
+ 2013, <https://www.rfc-editor.org/info/rfc6979>.
+
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
@@ -1336,9 +1341,4 @@ Authors' Addresses
-
-
-
-
-
Schanzenbach, et al. Expires 13 May 2020 [Page 24]
--
To stop receiving notification emails like this one, please contact
address@hidden.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0001] branch master updated: update files,
gnunet <=