[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: update
|
From: |
gnunet |
|
Subject: |
[lsd0001] branch master updated: update |
|
Date: |
Mon, 16 Dec 2019 10:52:21 +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 17ba525 update
17ba525 is described below
commit 17ba525ce58aff29fb67debce7411e8c29324ced
Author: Schanzenbach, Martin <address@hidden>
AuthorDate: Mon Dec 16 10:49:16 2019 +0100
update
---
draft-schanzen-gns.html | 297 ++++++++++++++++++++++---------------------
draft-schanzen-gns.txt | 330 ++++++++++++++++++++++++++++--------------------
draft-schanzen-gns.xml | 240 ++++++++++++++++++++---------------
3 files changed, 481 insertions(+), 386 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index 7c91e91..425cf38 100644
--- a/draft-schanzen-gns.html
+++ b/draft-schanzen-gns.html
@@ -1124,7 +1124,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<p id="section-boilerplate.3-1.6.1"><a href="#section-6"
class="xref">6</a>. <a href="#name-name-resolution" class="xref">Name
Resolution</a><a href="#section-boilerplate.3-1.6.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-boilerplate.3-1.6.2.1">
- <p id="section-boilerplate.3-1.6.2.1.1"><a href="#section-6.1"
class="xref">6.1</a>. <a href="#name-record-retrieval" class="xref">Record
Retrieval</a><a href="#section-boilerplate.3-1.6.2.1.1"
class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.6.2.1.1"><a href="#section-6.1"
class="xref">6.1</a>. <a href="#name-recursion" class="xref">Recursion</a><a
href="#section-boilerplate.3-1.6.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.6.2.2">
<p id="section-boilerplate.3-1.6.2.2.1"><a href="#section-6.2"
class="xref">6.2</a>. <a href="#name-record-processing" class="xref">Record
Processing</a><a href="#section-boilerplate.3-1.6.2.2.1"
class="pilcrow">¶</a></p>
@@ -1153,17 +1153,6 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.8">
<p id="section-boilerplate.3-1.8.1"><a href="#section-8"
class="xref">8</a>. <a href="#name-root-zone-governance" class="xref">Root
Zone Governance</a><a href="#section-boilerplate.3-1.8.1"
class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-boilerplate.3-1.8.2.1">
- <p id="section-boilerplate.3-1.8.2.1.1"><a href="#section-8.1"
class="xref">8.1</a>. <a href="#name-top-level-domain-as-local-z"
class="xref">Top-level domain as local zone key</a><a
href="#section-boilerplate.3-1.8.2.1.1" class="pilcrow">¶</a></p>
-</li>
- <li class="toc ulEmpty" id="section-boilerplate.3-1.8.2.2">
- <p id="section-boilerplate.3-1.8.2.2.1"><a href="#section-8.2"
class="xref">8.2</a>. <a href="#name-top-level-domain-maps-to-a-"
class="xref">Top-level domain maps to a local zone name</a><a
href="#section-boilerplate.3-1.8.2.2.1" class="pilcrow">¶</a></p>
-</li>
- <li class="toc ulEmpty" id="section-boilerplate.3-1.8.2.3">
- <p id="section-boilerplate.3-1.8.2.3.1"><a href="#section-8.3"
class="xref">8.3</a>. <a href="#name-name-suffix-mapped-to-an-ex"
class="xref">Name suffix mapped to an external zone key</a><a
href="#section-boilerplate.3-1.8.2.3.1" class="pilcrow">¶</a></p>
-</li>
- </ul>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.9">
<p id="section-boilerplate.3-1.9.1"><a href="#section-9"
class="xref">9</a>. <a href="#name-security-considerations"
class="xref">Security Considerations</a><a href="#section-boilerplate.3-1.9.1"
class="pilcrow">¶</a></p>
@@ -2028,49 +2017,51 @@ 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 entry zone.
- Details on how the root zone is determined is discussed in
+ 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
<a href="#governance" class="xref">Section 8</a>.<a href="#section-6-2"
class="pilcrow">¶</a></p>
-<div id="record_retrieval">
+<p id="section-6-3">
+ 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.<a href="#section-6-3" class="pilcrow">¶</a></p>
+<div id="recursion">
<section id="section-6.1">
- <h3 id="name-record-retrieval">
-<a href="#section-6.1" class="section-number selfRef">6.1. </a><a
href="#name-record-retrieval" class="section-name selfRef">Record Retrieval</a>
+ <h3 id="name-recursion">
+<a href="#section-6.1" class="section-number selfRef">6.1. </a><a
href="#name-recursion" class="section-name selfRef">Recursion</a>
</h3>
<p id="section-6.1-1">
- 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.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
-<p id="section-6.1-2">
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 "@".<a
href="#section-6.1-2" class="pilcrow">¶</a></p>
-<p id="section-6.1-3">
- From here, the following steps are recursively executed, in
order:<a href="#section-6.1-3" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal" id="section-6.1-4">
- <li id="section-6.1-4.1">Extract the right-most label from the name
to look up.<a href="#section-6.1-4.1" class="pilcrow">¶</a>
+ 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>
+<ol start="1" type="1" class="normal" id="section-6.1-3">
+ <li id="section-6.1-3.1">Extract the right-most label from the name
to look up.<a href="#section-6.1-3.1" class="pilcrow">¶</a>
</li>
- <li id="section-6.1-4.2">Calculate q using the label and zk as
defined in
- <a href="#blinding" class="xref">Section 4.1</a>.<a
href="#section-6.1-4.2" class="pilcrow">¶</a>
+ <li id="section-6.1-3.2">Calculate q using the label and zk as
defined in
+ <a href="#blinding" class="xref">Section 4.1</a>.<a
href="#section-6.1-3.2" class="pilcrow">¶</a>
</li>
- <li id="section-6.1-4.3">Perform a DHT query GET(q) to retrieve the
RRBLOCK.<a href="#section-6.1-4.3" class="pilcrow">¶</a>
+ <li id="section-6.1-3.3">Perform a DHT query GET(q) to retrieve the
RRBLOCK.<a href="#section-6.1-3.3" class="pilcrow">¶</a>
</li>
- <li id="section-6.1-4.4">Verify and process the RRBLOCK and decrypt
the BDATA contained
- in it as defined in <a href="#recordencryption"
class="xref">Section 4.3</a>.<a href="#section-6.1-4.4" class="pilcrow">¶</a>
+ <li id="section-6.1-3.4">Verify and process the RRBLOCK and decrypt
the BDATA contained
+ in it as defined in <a href="#recordencryption"
class="xref">Section 4.3</a>.<a href="#section-6.1-3.4" class="pilcrow">¶</a>
</li>
</ol>
-<p id="section-6.1-5">
+<p id="section-6.1-4">
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, otherwise the RRBLOCK MUST be ignored and the DHT
lookup
- GET(q) MUST continue.<a href="#section-6.1-5"
class="pilcrow">¶</a></p>
+ GET(q) MUST continue.<a href="#section-6.1-4"
class="pilcrow">¶</a></p>
</section>
</div>
<div id="record_processing">
@@ -2079,22 +2070,31 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a
href="#name-record-processing" class="section-name selfRef">Record
Processing</a>
</h3>
<p id="section-6.2-1">
- 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.<a
href="#section-6.2-1" class="pilcrow">¶</a></p>
+ 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:<a
href="#section-6.2-1" class="pilcrow">¶</a></p>
<p id="section-6.2-2">
+ 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.<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
+ 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>
<div id="pkey_processing">
<section id="section-6.2.1">
<h4 id="name-pkey-2">
<a href="#section-6.2.1" class="section-number selfRef">6.2.1. </a><a
href="#name-pkey-2" class="section-name selfRef">PKEY</a>
</h4>
<p id="section-6.2.1-1">
- When a resolver encounters a PKEY record and the remainder of
- the name is non-empty, resolution continues
+ 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>
<p id="section-6.2.1-2">
@@ -2114,27 +2114,25 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
</h4>
<p id="section-6.2.2-1">
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.<a href="#section-6.2.2-1" class="pilcrow">¶</a></p>
+ 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 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.
- If the DNS server name ends in ".<Base32(zk)>", the DNS
server name
- is to be resolved against the GNS zone zk.<a
href="#section-6.2.2-2" class="pilcrow">¶</a></p>
+ 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.
+ If the DNS server name ends in ".<Base32(zk)>", the DNS
+ server name is to be resolved against the GNS zone zk.<a
href="#section-6.2.2-2" class="pilcrow">¶</a></p>
<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. If multiple GNS2DNS records
- are present, the DNS name MUST be identical for all of them, if
- not the resolution fails.
- The first successful recursive name resolution result
- is returned to the client.<a href="#section-6.2.2-3"
class="pilcrow">¶</a></p>
+ 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>
<p id="section-6.2.2-4">
Once the IP addresses of the DNS servers have been determined,
the DNS name from the GNS2DNS record is appended
@@ -2142,7 +2140,9 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
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.<a href="#section-6.2.2-4"
class="pilcrow">¶</a></p>
+ 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>
</section>
</div>
<div id="cname_processing">
@@ -2158,14 +2158,16 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
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.<a
href="#section-6.2.3-1" class="pilcrow">¶</a></p>
+ default operating system name resolution process.
+ This may in turn again trigger a GNS resolution process depending
+ on the system configuration.<a href="#section-6.2.3-1"
class="pilcrow">¶</a></p>
<p id="section-6.2.3-2">
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 MUST
- implement loop detections or limit the number of recursive
resolution
- steps.<a href="#section-6.2.3-2" class="pilcrow">¶</a></p>
+ implement loop detections or limit the number of recursive
+ resolution steps.<a href="#section-6.2.3-2"
class="pilcrow">¶</a></p>
</section>
</div>
<div id="box_processing">
@@ -2174,11 +2176,12 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<a href="#section-6.2.4" class="section-number selfRef">6.2.4. </a><a
href="#name-box-2" class="section-name selfRef">BOX</a>
</h4>
<p id="section-6.2.4-1">
- 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.<a href="#section-6.2.4-1" class="pilcrow">¶</a></p>
+ 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.<a href="#section-6.2.4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="vpn_processing">
@@ -2188,11 +2191,12 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
</h4>
<p id="section-6.2.5-1">
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.
+ 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.<a href="#section-6.2.5-1"
class="pilcrow">¶</a></p>
+ The VPN record MUST be returned if the resolver implementation
+ does not support setting up a tunnnel.<a href="#section-6.2.5-1"
class="pilcrow">¶</a></p>
</section>
</div>
</section>
@@ -2205,7 +2209,8 @@ 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
published.
+ 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.
@@ -2223,80 +2228,84 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<p id="section-8-1">
The resolution of a GNS name must start in a given root zone
indicated to the resolver using any public zone key.
- A resolver client may determine the root zone public from the
- name given for resolution using information retrieved out of band.
- In the following, we illustrate how prior to recursive resolution, the
- root zone can be determined.<a href="#section-8-1"
class="pilcrow">¶</a></p>
+ 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.<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
- an are not normative.<a href="#section-8-2" class="pilcrow">¶</a></p>
-<div id="rootiskey">
-<section id="section-8.1">
- <h3 id="name-top-level-domain-as-local-z">
-<a href="#section-8.1" class="section-number selfRef">8.1. </a><a
href="#name-top-level-domain-as-local-z" class="section-name selfRef">Top-level
domain as local zone key</a>
- </h3>
-<p id="section-8.1-1">
- If the TLD is a Base32-encoded public zone key "zk", the entry
- zone of the resolution process is implicitly given by the name.<a
href="#section-8.1-1" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-8.1-2">
+ an 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">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">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">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>
+<p id="section-8-4">
+ The resolver client may 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:<a href="#section-8-4" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-8-5">
<pre>
- Example name: www.example.<Base32(zk)>
- => Root zone: zk
- => Name to resolve from root zone: www.example
- </pre><a href="#section-8.1-2" class="pilcrow">¶</a>
-</div>
-</section>
-</div>
-<div id="rootislocal">
-<section id="section-8.2">
- <h3 id="name-top-level-domain-maps-to-a-">
-<a href="#section-8.2" class="section-number selfRef">8.2. </a><a
href="#name-top-level-domain-maps-to-a-" class="section-name selfRef">Top-level
domain maps to a local zone name</a>
- </h3>
-<p id="section-8.2-1">
- Each local zone of the user may be associated with a single GNS
- label. If this label is the top-level domain (TLD) of the name
- to resolve, resolution can from the local zone.<a
href="#section-8.2-1" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-8.2-2">
+ Example name: www.example.<Base32(zk)>
+ => Root zone: zk
+ => Name to resolve from root zone: www.example
+ </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 can from the 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
- Local zones:
- fr = (d0,zk0)
- gnu = (d1,zk1)
- com = (d2,zk2)
- ...
- => Entry zone: zk1
- => Name to resolve from entry zone: www.example
- </pre><a href="#section-8.2-2" class="pilcrow">¶</a>
-</div>
-</section>
-</div>
-<div id="rootisoob">
-<section id="section-8.3">
- <h3 id="name-name-suffix-mapped-to-an-ex">
-<a href="#section-8.3" class="section-number selfRef">8.3. </a><a
href="#name-name-suffix-mapped-to-an-ex" class="section-name selfRef">Name
suffix mapped to an external zone key</a>
- </h3>
-<p id="section-8.3-1">
- If no matching local zone for the TLD is found, external suffix to
- zone mappings may exist. External suffix to zone key mapping
- may be configurable through the GNS client implementation.
- A mapping has the form "suffix = public zone key".
- 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.<a
href="#section-8.3-1" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-8.3-2">
+ Example name: www.example.gnu
+ Local zones:
+ fr = (d0,zk0)
+ gnu = (d1,zk1)
+ com = (d2,zk2)
+ ...
+ => Entry zone: zk1
+ => Name to resolve from entry zone: www.example
+ </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
+ 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:<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
- Local suffix mappings:
- gnu = zk0
- example.gnu = zk1
- example.com = zk2
- ...
- => Entry zone: zk1
- => Name to resolve from entry zone: www
- </pre><a href="#section-8.3-2" class="pilcrow">¶</a>
-</div>
-</section>
+ Example name: www.example.gnu
+ Local suffix mappings:
+ gnu = zk0
+ example.gnu = zk1
+ example.com = zk2
+ ...
+ => Entry zone: zk1
+ => Name to resolve from entry zone: www
+ </pre><a href="#section-8-9" class="pilcrow">¶</a>
</div>
</section>
</div>
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
index ec0789b..7e04c44 100644
--- a/draft-schanzen-gns.txt
+++ b/draft-schanzen-gns.txt
@@ -76,7 +76,7 @@ Table of Contents
4.3. Record Data Encryption and Decryption . . . . . . . . . . 13
5. Internationalization and Character Encoding . . . . . . . . . 15
6. Name Resolution . . . . . . . . . . . . . . . . . . . . . . . 15
- 6.1. Record Retrieval . . . . . . . . . . . . . . . . . . . . 15
+ 6.1. Recursion . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Record Processing . . . . . . . . . . . . . . . . . . . . 16
6.2.1. PKEY . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . 17
@@ -84,15 +84,12 @@ Table of Contents
6.2.4. BOX . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2.5. VPN . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Zone Revocation . . . . . . . . . . . . . . . . . . . . . . . 18
- 8. Root Zone Governance . . . . . . . . . . . . . . . . . . . . 18
- 8.1. Top-level domain as local zone key . . . . . . . . . . . 18
- 8.2. Top-level domain maps to a local zone name . . . . . . . 19
- 8.3. Name suffix mapped to an external zone key . . . . . . . 19
- 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
- 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
- 11. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 8. Root Zone Governance . . . . . . . . . . . . . . . . . . . . 19
+ 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
+ 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
+ 11. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 20
12. Normative References . . . . . . . . . . . . . . . . . . . . 22
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction
@@ -105,7 +102,10 @@ Table of Contents
threatening the global availability and integrity of information on
the Internet.
-
+ DNS was not designed with security as a goal. This makes it very
+ vulnerable, especially to attackers that have the technical
+ capabilities of an entire nation state at their disposal. This
+ specification describes a censorship-resistant, privacy-preserving
@@ -114,10 +114,6 @@ Schanzenbach, et al. Expires 13 May 2020
[Page 2]
Internet-Draft The GNU Name System November 2019
- DNS was not designed with security as a goal. This makes it very
- vulnerable, especially to attackers that have the technical
- capabilities of an entire nation state at their disposal. This
- specification describes a censorship-resistant, privacy-preserving
and decentralized name system: The GNU Name System (GNS). It is
designed to provide a secure alternative to DNS, especially when
censorship or manipulation is encountered. GNS can bind names to any
@@ -163,6 +159,10 @@ Internet-Draft The GNU Name System
November 2019
p is the prime of edwards25519 as defined in [RFC7748], i.e. 2^255
- 19.
+ B is the group generator (X(P),Y(P)) of edwards25519 as defined in
+ [RFC7748].
+
+
Schanzenbach, et al. Expires 13 May 2020 [Page 3]
@@ -170,9 +170,6 @@ Schanzenbach, et al. Expires 13 May 2020
[Page 3]
Internet-Draft The GNU Name System November 2019
- B is the group generator (X(P),Y(P)) of edwards25519 as defined in
- [RFC7748].
-
L is the prime-order subgroup of edwards25519 in [RFC7748].
zk is the ECDSA public key corresponding to d. It is defined in
@@ -218,6 +215,9 @@ Internet-Draft The GNU Name System
November 2019
the GNS resource records as defined in Section 3 or a DNS record
type as defined in [RFC1035] or any of the complementary
standardized DNS resource record types. This value must be stored
+ in network byte order. Note that values below 2^16 are reserved
+ for allocation via IANA ([RFC6895]).
+
@@ -226,9 +226,6 @@ Schanzenbach, et al. Expires 13 May 2020
[Page 4]
Internet-Draft The GNU Name System November 2019
- in network byte order. Note that values below 2^16 are reserved
- for allocation via IANA ([RFC6895]).
-
FLAGS is a 32-bit resource record flags field (see below).
DATA the variable-length resource record data payload. The contents
@@ -277,6 +274,9 @@ Internet-Draft The GNU Name System
November 2019
+
+
+
Schanzenbach, et al. Expires 13 May 2020 [Page 5]
Internet-Draft The GNU Name System November 2019
@@ -820,10 +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 entry zone.
- Details on how the root zone is determined is discussed in Section 8.
-
-6.1. Record Retrieval
+ 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.
When GNS name resolution is requested, a desired record type MAY be
provided by the client. The GNS resolver will use the desired record
@@ -832,8 +831,9 @@ Internet-Draft The GNU Name System
November 2019
of record sets according to the required record types MUST still be
done by the client after the resource record set is retrieved.
- In each step of the recursive name resolution, there is an
- authoritative zone zk and a name to resolve which may be empty.
+
+
+
@@ -842,6 +842,10 @@ Schanzenbach, et al. Expires 13 May 2020
[Page 15]
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 "@".
@@ -864,32 +868,28 @@ Internet-Draft The GNU Name System
November 2019
6.2. Record Processing
- 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.
+ 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:
+
+ 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.
- 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.
+ 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 a resolver encounters a PKEY record and the remainder of the
- name is non-empty, resolution continues recursively with the
+ 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.
- 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.
-
-
-
-
-
@@ -898,6 +898,13 @@ Schanzenbach, et al. Expires 13 May 2020
[Page 16]
Internet-Draft The GNU Name System November 2019
+ 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.
+
6.2.2. GNS2DNS
When a resolver encounters a GNS2DNS record and the remaining name is
@@ -917,15 +924,16 @@ Internet-Draft The GNU Name System
November 2019
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. The first successful recursive name resolution
- result is returned to the client.
+ resolution fails and an emtpy record set is returned as the record
+ set is invalid.
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 authoritative DNS servers. The first successful recursive name
+ resolution result is returned to the client.
6.2.3. CNAME
@@ -935,16 +943,8 @@ Internet-Draft The GNU Name System
November 2019
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.
-
- 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
- MUST implement loop detections or limit the number of recursive
- resolution steps.
-
-
-
+ system name resolution process. This may in turn again trigger a GNS
+ resolution process depending on the system configuration.
@@ -954,6 +954,12 @@ 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
+ MUST implement loop detections or limit the number of recursive
+ resolution steps.
+
6.2.4. BOX
When a BOX record is received, a GNS resolver must unbox it if the
@@ -982,26 +988,20 @@ Internet-Draft The GNU Name System
November 2019
A revocation message is defined as follows:
-8. Root Zone Governance
- The resolution of a GNS name must start in a given root zone
- indicated to the resolver using any public zone key. A resolver
- client may determine the root zone public from the name given for
- resolution using information retrieved out of band. In the
- following, we illustrate how prior to recursive resolution, the root
- zone can be determined.
- Any of the examples below may be exchanged with other mechanisms an
- are not normative.
-8.1. Top-level domain as local zone key
- If the TLD is a Base32-encoded public zone key "zk", the entry zone
- of the resolution process is implicitly given by the name.
- Example name: www.example.<Base32(zk)>
- => Root zone: zk
- => Name to resolve from root zone: www.example
+
+
+
+
+
+
+
+
+
@@ -1010,53 +1010,53 @@ Schanzenbach, et al. Expires 13 May 2020
[Page 18]
Internet-Draft The GNU Name System November 2019
-8.2. Top-level domain maps to a local zone name
-
- Each local zone of the user may be associated with a single GNS
- label. If this label is the top-level domain (TLD) of the name to
- resolve, resolution can from the local zone.
-
- Example name: www.example.gnu
- Local zones:
- fr = (d0,zk0)
- gnu = (d1,zk1)
- com = (d2,zk2)
- ...
- => Entry zone: zk1
- => Name to resolve from entry zone: www.example
-
-8.3. Name suffix mapped to an external zone key
-
- If no matching local zone for the TLD is found, external suffix to
- zone mappings may exist. External suffix to zone key mapping may be
- configurable through the GNS client implementation. A mapping has
- the form "suffix = public zone key". 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.
-
- Example name: www.example.gnu
- Local suffix mappings:
- gnu = zk0
- example.gnu = zk1
- example.com = zk2
- ...
- => Entry zone: zk1
- => Name to resolve from entry zone: www
+8. Root Zone Governance
-9. Security Considerations
+ 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.
+
+ 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 an are not normative. Possible high-
+ level mechanisms to discover the root zone for a given name are:
+
+ 1. Top-level domain is an encoded local zone key.
+
+ 2. Local configuration exists that allow to map a name suffix to a
+ zone key.
+
+ 3. Out-of-band mechnism exists that allow to determine the
+ authoritative root zone for a given name.
+
+ The resolver client may 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:
+
+ Example name: www.example.<Base32(zk)>
+ => 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 can from the local
+ zone:
- TODO
-10. IANA Considerations
- This will be fun
-11. Test Vectors
- The following represents a test vector for a record of type MX with a
- priority of 10 and the mail hostname mail.example.com.
@@ -1066,6 +1066,45 @@ Schanzenbach, et al. Expires 13 May 2020
[Page 19]
Internet-Draft The GNU Name System November 2019
+ Example name: www.example.gnu
+ Local zones:
+ fr = (d0,zk0)
+ gnu = (d1,zk1)
+ com = (d2,zk2)
+ ...
+ => 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:
+
+ Example name: www.example.gnu
+ Local suffix mappings:
+ gnu = zk0
+ example.gnu = zk1
+ example.com = zk2
+ ...
+ => Entry zone: zk1
+ => Name to resolve from entry zone: www
+
+9. Security Considerations
+
+ TODO
+
+10. IANA Considerations
+
+ This will be fun
+
+11. Test Vectors
+
+ 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 :=
@@ -1075,6 +1114,14 @@ Internet-Draft The GNU Name System
November 2019
1878bf47f3b39da0
zk (public zone key) :=
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 20]
+
+Internet-Draft The GNU Name System November 2019
+
+
dff911496d025d7e
0885c03d19153e99
4f213f23ea719eca
@@ -1114,14 +1161,6 @@ Internet-Draft The GNU Name System
November 2019
AES_IV :=
a808b929bc9fad7a
-
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 20]
-
-Internet-Draft The GNU Name System November 2019
-
-
686bbe3432bed77a
TWOFISH_KEY :=
@@ -1131,6 +1170,14 @@ 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
@@ -1171,13 +1218,6 @@ Internet-Draft The GNU Name System
November 2019
001fd19a6406a721
713f0a0d
-
-
-Schanzenbach, et al. Expires 13 May 2020 [Page 21]
-
-Internet-Draft The GNU Name System November 2019
-
-
12. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
@@ -1185,6 +1225,15 @@ Internet-Draft The GNU Name System
November 2019
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
+
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 22]
+
+Internet-Draft The GNU Name System November 2019
+
+
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
@@ -1227,18 +1276,20 @@ 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 22]
+
+
+
+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>.
@@ -1285,4 +1336,9 @@ Authors' Addresses
-Schanzenbach, et al. Expires 13 May 2020 [Page 23]
+
+
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 24]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 209e43b..02ae129 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -853,22 +853,24 @@
iteration in the resolution is processed.
</t>
<t>
- GNS resolution of a name must start in a given root entry zone.
- Details on how the root zone is determined is discussed in
+ 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
<xref target="governance" />.
</t>
- <section anchor="record_retrieval" numbered="true" toc="default">
- <name>Record Retrieval</name>
- <t>
- 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.
+ <t>
+ 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>
+ 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>
+ <section anchor="recursion" numbered="true" toc="default">
+ <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.
@@ -898,21 +900,31 @@
<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, CNAME record,
- or one or more GNS2DNS records. Otherwise, resolution fails
- and the resolver MUST return an empty record set.
+ 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>
+ 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.
</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
+ 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>
<section anchor="pkey_processing" numbered="true" toc="default">
<name>PKEY</name>
<t>
- When a resolver encounters a PKEY record and the remainder of
- the name is non-empty, resolution continues
+ 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.
</t>
@@ -930,29 +942,27 @@
<name>GNS2DNS</name>
<t>
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.
+ 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.
- If the DNS server name ends in ".<Base32(zk)>", the DNS
server name
- is to be resolved against the GNS zone zk.
+ 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.
+ 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.
- 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.
+ 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.
</t>
<t>
Once the IP addresses of the DNS servers have been determined,
@@ -962,6 +972,8 @@
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.
</t>
</section>
<section anchor="cname_processing" numbered="true" toc="default">
@@ -975,6 +987,8 @@
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.
+ This may in turn again trigger a GNS resolution process depending
+ on the system configuration.
<!-- Note: this permits non-DNS resolvers to be triggered via
NSS! -->
</t>
<t>
@@ -982,29 +996,31 @@
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.
+ 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, 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.
+ 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>
</section>
<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
- record set contains at least one VPN record, the resolver SHOULD
open a
- tunnel and return the IPv4 or IPv6 tunnel address, respectively.
+ 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.
+ The VPN record MUST be returned if the resolver implementation
+ does not support setting up a tunnnel.
</t>
</section>
</section>
@@ -1012,7 +1028,8 @@
<section anchor="revocation" numbered="true" toc="default">
<name>Zone Revocation</name>
<t>
- In order to revoke a zone, a signed revocation object SHOULD be
published.
+ 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.
@@ -1028,68 +1045,81 @@
<t>
The resolution of a GNS name must start in a given root zone
indicated to the resolver using any public zone key.
- A resolver client may determine the root zone public from the
- name given for resolution using information retrieved out of band.
- In the following, we illustrate how prior to recursive resolution, the
- root zone can be determined.
+ 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.
</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
an are not normative.
+ Possible high-level mechanisms to discover the root zone for a given
+ name are:
</t>
- <section anchor="rootiskey" numbered="true" toc="default">
- <name>Top-level domain as local zone key</name>
- <t>
- If the TLD is a Base32-encoded public zone key "zk", the entry
- zone of the resolution process is implicitly given by the name.
- </t>
- <artwork name="" type="" align="left" alt=""><![CDATA[
- Example name: www.example.<Base32(zk)>
- => Root zone: zk
- => Name to resolve from root zone: www.example
- ]]></artwork>
- </section>
- <section anchor="rootislocal" numbered="true" toc="default">
- <name>Top-level domain maps to a local zone name</name>
- <t>
- Each local zone of the user may be associated with a single GNS
- label. If this label is the top-level domain (TLD) of the name
- to resolve, resolution can from the local zone.
- </t>
- <artwork name="" type="" align="left" alt=""><![CDATA[
- Example name: www.example.gnu
- Local zones:
- fr = (d0,zk0)
- gnu = (d1,zk1)
- com = (d2,zk2)
- ...
- => Entry zone: zk1
- => Name to resolve from entry zone: www.example
- ]]></artwork>
- </section>
- <section anchor="rootisoob" numbered="true" toc="default">
- <name>Name suffix mapped to an external zone key</name>
- <t>
- If no matching local zone for the TLD is found, external suffix to
- zone mappings may exist. External suffix to zone key mapping
- may be configurable through the GNS client implementation.
- A mapping has the form "suffix = public zone key".
- 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.
- </t>
- <artwork name="" type="" align="left" alt=""><![CDATA[
- Example name: www.example.gnu
- Local suffix mappings:
- gnu = zk0
- example.gnu = zk1
- example.com = zk2
- ...
- => Entry zone: zk1
- => Name to resolve from entry zone: www
- ]]></artwork>
- </section>
+ <ol>
+ <li>Top-level domain is an encoded local zone key.</li>
+ <li>Local configuration exists that allow to map a name suffix
+ to a zone key.</li>
+ <li>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
+ 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:
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ Example name: www.example.<Base32(zk)>
+ => Root zone: zk
+ => 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 can from the local zone:
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ Example name: www.example.gnu
+ Local zones:
+ fr = (d0,zk0)
+ gnu = (d1,zk1)
+ com = (d2,zk2)
+ ...
+ => Entry zone: zk1
+ => 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
+ 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:
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ Example name: www.example.gnu
+ Local suffix mappings:
+ gnu = zk0
+ example.gnu = zk1
+ example.com = zk2
+ ...
+ => Entry zone: zk1
+ => Name to resolve from entry zone: www
+ ]]></artwork>
</section>
<section anchor="security" numbered="true" toc="default">
<name>Security Considerations</name>
--
To stop receiving notification emails like this one, please contact
address@hidden.