commit 93cb14cd2bb1fe1999ddd589a35d288411c211b3
parent fd37205cd8d3e270bda8b5f98a269e920eb7bd47
Author: Schanzenbach, Martin <mschanzenbach@posteo.de>
Date: Fri, 4 Oct 2019 11:22:45 +0200
sectioning
Diffstat:
3 files changed, 215 insertions(+), 231 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
@@ -1081,19 +1081,16 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<p id="section-boilerplate.3-1.3.1"><a href="#section-3" class="xref">3</a>. <a href="#name-resource-records" class="xref">Resource records</a><a href="#section-boilerplate.3-1.3.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-boilerplate.3-1.3.2.1">
- <p id="section-boilerplate.3-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>. <a href="#name-wire-format" class="xref">Wire format</a><a href="#section-boilerplate.3-1.3.2.1.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>. <a href="#name-pkey" class="xref">PKEY</a><a href="#section-boilerplate.3-1.3.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.3.2.2">
- <p id="section-boilerplate.3-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>. <a href="#name-pkey" class="xref">PKEY</a><a href="#section-boilerplate.3-1.3.2.2.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>. <a href="#name-gns2dns" class="xref">GNS2DNS</a><a href="#section-boilerplate.3-1.3.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.3.2.3">
- <p id="section-boilerplate.3-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>. <a href="#name-gns2dns" class="xref">GNS2DNS</a><a href="#section-boilerplate.3-1.3.2.3.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>. <a href="#name-leho" class="xref">LEHO</a><a href="#section-boilerplate.3-1.3.2.3.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.3.2.4">
- <p id="section-boilerplate.3-1.3.2.4.1"><a href="#section-3.4" class="xref">3.4</a>. <a href="#name-leho" class="xref">LEHO</a><a href="#section-boilerplate.3-1.3.2.4.1" class="pilcrow">¶</a></p>
-</li>
- <li class="toc ulEmpty" id="section-boilerplate.3-1.3.2.5">
- <p id="section-boilerplate.3-1.3.2.5.1"><a href="#section-3.5" class="xref">3.5</a>. <a href="#name-box" class="xref">BOX</a><a href="#section-boilerplate.3-1.3.2.5.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.3.2.4.1"><a href="#section-3.4" class="xref">3.4</a>. <a href="#name-box" class="xref">BOX</a><a href="#section-boilerplate.3-1.3.2.4.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
@@ -1160,8 +1157,8 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
</h2>
<p id="section-2-1">
A zone in GNS is defined by a public/private ECC key pair (d,zk),
- where B is the generator of a group or subgroup, d is the private key and
- zk the corresponding public key
+ where d is the private key and
+ zk the corresponding public key.
GNS uses the Ed25519 EC parameters as defined in <span>[<a href="#RFC8032" class="xref">RFC8032</a>]</span>.
GNS combines the EC parameters of Ed25519 with the ECDSA scheme
defined in <span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span> in order to achieve zone privacy.
@@ -1176,17 +1173,12 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<h2 id="name-resource-records">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-resource-records" class="section-name selfRef">Resource records</a>
</h2>
-<div id="rrecords_wire">
-<section id="section-3.1">
- <h3 id="name-wire-format">
-<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-wire-format" class="section-name selfRef">Wire format</a>
- </h3>
-<p id="section-3.1-1">
+<p id="section-3-1">
A GNS resource record holds the data of a specific record in a zone.
- The resource record format is defined as follows:<a href="#section-3.1-1" class="pilcrow">¶</a></p>
+ The resource record format is defined as follows:<a href="#section-3-1" class="pilcrow">¶</a></p>
<div id="figure_gnsrecord">
<figure id="figure-1">
- <div class="artwork art-text alignLeft" id="section-3.1-2.1">
+ <div class="artwork art-text alignLeft" id="section-3-2.1">
<pre>
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1197,62 +1189,50 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
| FLAGS | DATA /
+-----+-----+-----+-----+ /
/ /
- / +-----+-----+-----+-----+
- / | PADDING /
- +-----+-----+-----+-----+ /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+ / /
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a></figcaption></figure>
</div>
-<p id="section-3.1-3">where:<a href="#section-3.1-3" class="pilcrow">¶</a></p>
-<dl class="dlParallel" id="section-3.1-4">
- <dt id="section-3.1-4.1">EXPIRATION</dt>
- <dd id="section-3.1-4.2">
+<p id="section-3-3">where:<a href="#section-3-3" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-3-4">
+ <dt id="section-3-4.1">EXPIRATION</dt>
+ <dd id="section-3-4.2">
Denotes the absolute expiration date of the record.
In microseconds since midnight (0 hour), January 1, 1970 in network
- byte order.<a href="#section-3.1-4.2" class="pilcrow">¶</a>
+ byte order.<a href="#section-3-4.2" class="pilcrow">¶</a>
</dd>
- <dt id="section-3.1-4.3">DATA SIZE</dt>
- <dd id="section-3.1-4.4">
- The size of the DATA field in bytes and in network byte order including
- padding. The padding MUST ensure that the size of the resource record
- is a power of two. The only excption is the PKEY record type, which is
- never padded.<a href="#section-3.1-4.4" class="pilcrow">¶</a>
+ <dt id="section-3-4.3">DATA SIZE</dt>
+ <dd id="section-3-4.4">
+ The size of the DATA field in bytes and in network byte order.<a href="#section-3-4.4" class="pilcrow">¶</a>
</dd>
- <dt id="section-3.1-4.5">TYPE</dt>
- <dd id="section-3.1-4.6">
+ <dt id="section-3-4.5">TYPE</dt>
+ <dd id="section-3-4.6">
The resource record type. This type can be one of the GNS resource
records as defined in <a href="#rrecords" class="xref">Section 3</a> or a DNS record
type as defined in <span>[<a href="#RFC1035" class="xref">RFC1035</a>]</span> 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 (<span>[<a href="#RFC6895" class="xref">RFC6895</a>]</span>).<a href="#section-3.1-4.6" class="pilcrow">¶</a>
+ below 2^16 are reserved for allocation via IANA (<span>[<a href="#RFC6895" class="xref">RFC6895</a>]</span>).<a href="#section-3-4.6" class="pilcrow">¶</a>
</dd>
- <dt id="section-3.1-4.7">FLAGS</dt>
- <dd id="section-3.1-4.8">
- Resource record flags.<a href="#section-3.1-4.8" class="pilcrow">¶</a>
+ <dt id="section-3-4.7">FLAGS</dt>
+ <dd id="section-3-4.8">
+ Resource record flags.<a href="#section-3-4.8" class="pilcrow">¶</a>
</dd>
- <dt id="section-3.1-4.9">DATA</dt>
- <dd id="section-3.1-4.10">
+ <dt id="section-3-4.9">DATA</dt>
+ <dd id="section-3-4.10">
The resource record data payload. The contents are defined by the
- respective type of the resource record.<a href="#section-3.1-4.10" class="pilcrow">¶</a>
-</dd>
- <dt id="section-3.1-4.11">PADDING</dt>
- <dd id="section-3.1-4.12">
- The padding MUST contain the 0 value in all octets. Not applicable for
- PKEY records.<a href="#section-3.1-4.12" class="pilcrow">¶</a>
+ respective type of the resource record.<a href="#section-3-4.10" class="pilcrow">¶</a>
</dd>
- </dl>
-<p id="section-3.1-5">
+ </dl>
+<p id="section-3-5">
Flags indicate metadata surrounding the resource record. A flag
value of 0 indicates that all flags are unset. The following
illustrates the flag distribution in the 32-bit flag value of a
- resource record:<a href="#section-3.1-5" class="pilcrow">¶</a></p>
+ resource record:<a href="#section-3-5" class="pilcrow">¶</a></p>
<div id="figure_flag">
<figure id="figure-2">
- <div class="artwork art-text alignLeft" id="section-3.1-6.1">
+ <div class="artwork art-text alignLeft" id="section-3-6.1">
<pre>
... 5 4 3 2 1 0
------+--------+--------+--------+--------+--------+
@@ -1262,41 +1242,39 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a></figcaption></figure>
</div>
-<p id="section-3.1-7">
- where:<a href="#section-3.1-7" class="pilcrow">¶</a></p>
-<dl class="dlParallel" id="section-3.1-8">
- <dt id="section-3.1-8.1">SHADOW</dt>
- <dd id="section-3.1-8.2">
+<p id="section-3-7">
+ where:<a href="#section-3-7" class="pilcrow">¶</a></p>
+<dl class="dlParallel" id="section-3-8">
+ <dt id="section-3-8.1">SHADOW</dt>
+ <dd id="section-3-8.2">
If this flag is set, this record should not be used unless all (other)
- records with an absolute expiration time have expired.<a href="#section-3.1-8.2" class="pilcrow">¶</a>
+ records with an absolute expiration time have expired.<a href="#section-3-8.2" class="pilcrow">¶</a>
</dd>
- <dt id="section-3.1-8.3">EXPREL</dt>
- <dd id="section-3.1-8.4">
+ <dt id="section-3-8.3">EXPREL</dt>
+ <dd id="section-3-8.4">
The expiration time value of the record is a relative time and not
an absolute time. This flag should never be encountered by a resolver
- for records resolved from the DHT.<a href="#section-3.1-8.4" class="pilcrow">¶</a>
+ for records resolved from the DHT.<a href="#section-3-8.4" class="pilcrow">¶</a>
</dd>
- <dt id="section-3.1-8.5">PRIVATE</dt>
- <dd id="section-3.1-8.6">
+ <dt id="section-3-8.5">PRIVATE</dt>
+ <dd id="section-3-8.6">
This is a private record of this peer and it should thus not be
handed out to other peers. This flag should never be encountered by
- a resolver for records resolved from the DHT.<a href="#section-3.1-8.6" class="pilcrow">¶</a>
+ a resolver for records resolved from the DHT.<a href="#section-3-8.6" class="pilcrow">¶</a>
</dd>
- </dl>
-</section>
-</div>
+ </dl>
<div id="gnsrecords_pkey">
-<section id="section-3.2">
+<section id="section-3.1">
<h3 id="name-pkey">
-<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-pkey" class="section-name selfRef">PKEY</a>
+<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-pkey" class="section-name selfRef">PKEY</a>
</h3>
-<p id="section-3.2-1">In GNS, a delegation of a label to a zone is represented througha PKEY
+<p id="section-3.1-1">In GNS, a delegation of a label to a zone is represented through a PKEY
record. A PKEY resource record contains the public key of the zone to
delegate to. A PKEY record MUST be the only record under a label. No other
- labels are allows. The a PKEY DATA entry has the following format:<a href="#section-3.2-1" class="pilcrow">¶</a></p>
+ records are allowed. The a PKEY DATA entry has the following format:<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<div id="figure_pkeyrecord">
<figure id="figure-3">
- <div class="artwork art-text alignLeft" id="section-3.2-2.1">
+ <div class="artwork art-text alignLeft" id="section-3.1-2.1">
<pre>
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1312,21 +1290,21 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
</section>
</div>
<div id="gnsrecords_gns2dns">
-<section id="section-3.3">
+<section id="section-3.2">
<h3 id="name-gns2dns">
-<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-gns2dns" class="section-name selfRef">GNS2DNS</a>
+<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-gns2dns" class="section-name selfRef">GNS2DNS</a>
</h3>
-<p id="section-3.3-1">It is possible to delegate a label back into DNS through a GNS2DNS record.
+<p id="section-3.2-1">It is possible to delegate a label back into DNS through a GNS2DNS record.
The resource record contains a DNS name for the resolver to continue with
in DNS followed by a DNS server. Both names are in the format defined in
<span>[<a href="#RFC1034" class="xref">RFC1034</a>]</span> for DNS names.
If a resolver encounters a GNS2DNS record it is expected that it first
resolves the IP(s) of the DNS servers using DNS. Then, the encountered DNS
name is resolved by querying the name server(s).
- The a GNS2DNS DATA entry has the following format:<a href="#section-3.3-1" class="pilcrow">¶</a></p>
+ The a GNS2DNS DATA entry has the following format:<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<div id="figure_gns2dnsrecord">
<figure id="figure-4">
- <div class="artwork art-text alignLeft" id="section-3.3-2.1">
+ <div class="artwork art-text alignLeft" id="section-3.2-2.1">
<pre>
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1347,21 +1325,21 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
</section>
</div>
<div id="gnsrecords_leho">
-<section id="section-3.4">
+<section id="section-3.3">
<h3 id="name-leho">
-<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-leho" class="section-name selfRef">LEHO</a>
+<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-leho" class="section-name selfRef">LEHO</a>
</h3>
-<p id="section-3.4-1">As names in GNS are not globally unique, established practices such as
+<p id="section-3.3-1">As names in GNS are not globally unique, established practices such as
virtual hosting do not apply directly. In order to support such use cases,
GNS support a legacy hostname record which can be used by applications
(e.g. HTTP clients) in order to provide the necessary information.
The resource record contains a string which is not 0-terminated representing
the legacy hostname to use. It is expected to be found together in a single
resource record with an IPv4 or IPv6 address.
- A LEHO DATA entry has the following format:<a href="#section-3.4-1" class="pilcrow">¶</a></p>
+ A LEHO DATA entry has the following format:<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<div id="figure_lehorecord">
<figure id="figure-5">
- <div class="artwork art-text alignLeft" id="section-3.4-2.1">
+ <div class="artwork art-text alignLeft" id="section-3.3-2.1">
<pre>
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1377,11 +1355,11 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
</section>
</div>
<div id="gnsrecords_box">
-<section id="section-3.5">
+<section id="section-3.4">
<h3 id="name-box">
-<a href="#section-3.5" class="section-number selfRef">3.5. </a><a href="#name-box" class="section-name selfRef">BOX</a>
+<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-box" class="section-name selfRef">BOX</a>
</h3>
-<p id="section-3.5-1">
+<p id="section-3.4-1">
Record type used to box up SRV and TLSA records. For example, a
TLSA record for "_https._tcp.foo.gnu" will be stored under
"foo.gnu" as a BOX record with service 443 (https) and protocol 6
@@ -1390,10 +1368,10 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
left untouched. This is done to ensure that TLSA (and SRV)
records do not require a separate network request, thus making TLSA
records inseparable from the corresponding A/AAAA/VPN/etc. records.
- A BOX DATA entry has the following format:<a href="#section-3.5-1" class="pilcrow">¶</a></p>
+ A BOX DATA entry has the following format:<a href="#section-3.4-1" class="pilcrow">¶</a></p>
<div id="figure_boxrecord">
<figure id="figure-6">
- <div class="artwork art-text alignLeft" id="section-3.5-2.1">
+ <div class="artwork art-text alignLeft" id="section-3.4-2.1">
<pre>
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1408,24 +1386,24 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
</div>
<figcaption><a href="#figure-6" class="selfRef">Figure 6</a></figcaption></figure>
</div>
-<dl class="dlParallel" id="section-3.5-3">
- <dt id="section-3.5-3.1">PROTO</dt>
- <dd id="section-3.5-3.2">
- the protocol number, e.g. 6 for tcp. In network byte order.<a href="#section-3.5-3.2" class="pilcrow">¶</a>
+<dl class="dlParallel" id="section-3.4-3">
+ <dt id="section-3.4-3.1">PROTO</dt>
+ <dd id="section-3.4-3.2">
+ the protocol number, e.g. 6 for tcp. In network byte order.<a href="#section-3.4-3.2" class="pilcrow">¶</a>
</dd>
- <dt id="section-3.5-3.3">SVC</dt>
- <dd id="section-3.5-3.4">
+ <dt id="section-3.4-3.3">SVC</dt>
+ <dd id="section-3.4-3.4">
the service of the boxed record, i.e. the port number. In network
- byte order.<a href="#section-3.5-3.4" class="pilcrow">¶</a>
+ byte order.<a href="#section-3.4-3.4" class="pilcrow">¶</a>
</dd>
- <dt id="section-3.5-3.5">TYPE</dt>
- <dd id="section-3.5-3.6">
- Record type of the boxed record. In network byte order.<a href="#section-3.5-3.6" class="pilcrow">¶</a>
+ <dt id="section-3.4-3.5">TYPE</dt>
+ <dd id="section-3.4-3.6">
+ Record type of the boxed record. In network byte order.<a href="#section-3.4-3.6" class="pilcrow">¶</a>
</dd>
- <dt id="section-3.5-3.7">RECORD</dt>
- <dd id="section-3.5-3.8">
- The boxed record in a format as defined in
- <a href="#rrecords_wire" class="xref">Section 3.1</a>.<a href="#section-3.5-3.8" class="pilcrow">¶</a>
+ <dt id="section-3.4-3.7">RECORD</dt>
+ <dd id="section-3.4-3.8">
+ The boxed record in a format as defined in
+ <a href="#rrecords" class="xref">Section 3</a>.<a href="#section-3.4-3.8" class="pilcrow">¶</a>
</dd>
</dl>
</section>
@@ -1583,7 +1561,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<dd id="section-4.2-4.10">
The resource records block expiration time. This is the expiration
time of the resource record contained within this block with the
- smallest expiration time.
+ smallest expiration time.
If a records block includes shadow records, then the *maximum*
expiration time of all shadow records with matching type and the
expiration times of the non-shadow records is considered.
@@ -1718,8 +1696,10 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
+-----+-----+-----+-----+-----+-----+-----+-----+
| FLAGS | DATA /
+-----+-----+-----+-----+ /
- / /
- / /
+ / +-----------------------/
+ / | /
+ +-----------------------+ /
+ / PADDING /
/ /
</pre>
</div>
@@ -1732,6 +1712,13 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
A 32-bit value containing the number of resource records which are
following in network byte order.<a href="#section-4.3-12.2" class="pilcrow">¶</a>
</dd>
+ <dt id="section-4.3-12.3">PADDING</dt>
+ <dd id="section-4.3-12.4">
+ The padding MUST contain the 0 value in all octets. Not applicable for
+ PKEY records.
+ The padding MUST ensure that the size of the RDATA is a power of two.
+ The only excption is the PKEY record type, which is never padded.<a href="#section-4.3-12.4" class="pilcrow">¶</a>
+</dd>
</dl>
<p id="section-4.3-13">
is followed by a set of resource records with the respective
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
@@ -63,22 +63,21 @@ Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Resource records . . . . . . . . . . . . . . . . . . . . . . 2
- 3.1. Wire format . . . . . . . . . . . . . . . . . . . . . . . 3
- 3.2. PKEY . . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 3.3. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 3.4. LEHO . . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 3.5. BOX . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.1. PKEY . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3.3. LEHO . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.4. BOX . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Publishing records . . . . . . . . . . . . . . . . . . . . . 6
4.1. Key derivations . . . . . . . . . . . . . . . . . . . . . 6
4.2. Resource records block . . . . . . . . . . . . . . . . . 7
4.3. Block data encryption and decryption . . . . . . . . . . 9
5. Internationalization and Character Encoding . . . . . . . . . 11
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
- 7. Record Resolution . . . . . . . . . . . . . . . . . . . . . . 11
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
+ 7. Record Resolution . . . . . . . . . . . . . . . . . . . . . . 12
8. Namespace Revocation . . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 12
- 11. Normative References . . . . . . . . . . . . . . . . . . . . 14
+ 11. Normative References . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
@@ -95,17 +94,18 @@ Table of Contents
2. Zones
A zone in GNS is defined by a public/private ECC key pair (d,zk),
- where B is the generator of a group or subgroup, d is the private key
- and zk the corresponding public key GNS uses the Ed25519 EC
- parameters as defined in [RFC8032]. GNS combines the EC parameters
- of Ed25519 with the ECDSA scheme defined in [RFC6979] in order to
- achieve zone privacy. The public key "zk" is used to uniquely
- identify and refer to the zone and is thus called "zone key".
- Records published in the zone are signed using a private key derived
- from "d" as described in Section 4.
+ where d is the private key and zk the corresponding public key. GNS
+ uses the Ed25519 EC parameters as defined in [RFC8032]. GNS combines
+ the EC parameters of Ed25519 with the ECDSA scheme defined in
+ [RFC6979] in order to achieve zone privacy. The public key "zk" is
+ used to uniquely identify and refer to the zone and is thus called
+ "zone key". Records published in the zone are signed using a private
+ key derived from "d" as described in Section 4.
3. Resource records
+ A GNS resource record holds the data of a specific record in a zone.
+ The resource record format is defined as follows:
@@ -114,11 +114,6 @@ Schanzenbach, et al. Expires 24 January 2020 [Page 2]
Internet-Draft The GNU Name System July 2019
-3.1. Wire format
-
- A GNS resource record holds the data of a specific record in a zone.
- The resource record format is defined as follows:
-
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| EXPIRATION |
@@ -128,11 +123,7 @@ Internet-Draft The GNU Name System July 2019
| FLAGS | DATA /
+-----+-----+-----+-----+ /
/ /
- / +-----+-----+-----+-----+
- / | PADDING /
- +-----+-----+-----+-----+ /
- | |
- +-----+-----+-----+-----+-----+-----+-----+-----+
+ / /
Figure 1
@@ -143,9 +134,7 @@ Internet-Draft The GNU Name System July 2019
byte order.
DATA SIZE The size of the DATA field in bytes and in network byte
- order including padding. The padding MUST ensure that the size of
- the resource record is a power of two. The only excption is the
- PKEY record type, which is never padded.
+ order.
TYPE The resource record type. This type can be one of the GNS
resource records as defined in Section 3 or a DNS record type as
@@ -159,17 +148,6 @@ Internet-Draft The GNU Name System July 2019
DATA The resource record data payload. The contents are defined by
the respective type of the resource record.
- PADDING The padding MUST contain the 0 value in all octets. Not
- applicable for PKEY records.
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 3]
-
-Internet-Draft The GNU Name System July 2019
-
-
Flags indicate metadata surrounding the resource record. A flag
value of 0 indicates that all flags are unset. The following
illustrates the flag distribution in the 32-bit flag value of a
@@ -184,6 +162,14 @@ Internet-Draft The GNU Name System July 2019
where:
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 3]
+
+Internet-Draft The GNU Name System July 2019
+
+
SHADOW If this flag is set, this record should not be used unless
all (other) records with an absolute expiration time have expired.
@@ -195,12 +181,12 @@ Internet-Draft The GNU Name System July 2019
be handed out to other peers. This flag should never be
encountered by a resolver for records resolved from the DHT.
-3.2. PKEY
+3.1. PKEY
- In GNS, a delegation of a label to a zone is represented througha
+ In GNS, a delegation of a label to a zone is represented through a
PKEY record. A PKEY resource record contains the public key of the
zone to delegate to. A PKEY record MUST be the only record under a
- label. No other labels are allows. The a PKEY DATA entry has the
+ label. No other records are allowed. The a PKEY DATA entry has the
following format:
0 8 16 24 32 40 48 56
@@ -213,6 +199,20 @@ Internet-Draft The GNU Name System July 2019
Figure 3
+3.2. GNS2DNS
+
+ It is possible to delegate a label back into DNS through a GNS2DNS
+ record. The resource record contains a DNS name for the resolver to
+ continue with in DNS followed by a DNS server. Both names are in the
+ format defined in [RFC1034] for DNS names. If a resolver encounters
+ a GNS2DNS record it is expected that it first resolves the IP(s) of
+ the DNS servers using DNS. Then, the encountered DNS name is
+ resolved by querying the name server(s). The a GNS2DNS DATA entry
+ has the following format:
+
+
+
+
@@ -226,17 +226,6 @@ Schanzenbach, et al. Expires 24 January 2020 [Page 4]
Internet-Draft The GNU Name System July 2019
-3.3. GNS2DNS
-
- It is possible to delegate a label back into DNS through a GNS2DNS
- record. The resource record contains a DNS name for the resolver to
- continue with in DNS followed by a DNS server. Both names are in the
- format defined in [RFC1034] for DNS names. If a resolver encounters
- a GNS2DNS record it is expected that it first resolves the IP(s) of
- the DNS servers using DNS. Then, the encountered DNS name is
- resolved by querying the name server(s). The a GNS2DNS DATA entry
- has the following format:
-
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| DNS NAME |
@@ -252,7 +241,7 @@ Internet-Draft The GNU Name System July 2019
Figure 4
-3.4. LEHO
+3.3. LEHO
As names in GNS are not globally unique, established practices such
as virtual hosting do not apply directly. In order to support such
@@ -273,16 +262,7 @@ Internet-Draft The GNU Name System July 2019
Figure 5
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 5]
-
-Internet-Draft The GNU Name System July 2019
-
-
-3.5. BOX
+3.4. BOX
Record type used to box up SRV and TLSA records. For example, a TLSA
record for "_https._tcp.foo.gnu" will be stored under "foo.gnu" as a
@@ -294,6 +274,14 @@ Internet-Draft The GNU Name System July 2019
records inseparable from the corresponding A/AAAA/VPN/etc. records.
A BOX DATA entry has the following format:
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 5]
+
+Internet-Draft The GNU Name System July 2019
+
+
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| PROTO | SVC | TYPE |
@@ -313,7 +301,7 @@ Internet-Draft The GNU Name System July 2019
TYPE Record type of the boxed record. In network byte order.
- RECORD The boxed record in a format as defined in Section 3.1.
+ RECORD The boxed record in a format as defined in Section 3.
4. Publishing records
@@ -326,18 +314,6 @@ Internet-Draft The GNU Name System July 2019
4.1. Key derivations
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 6]
-
-Internet-Draft The GNU Name System July 2019
-
-
PRK_h := HKDF-Extract ("key-derivation", zk)
h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
d_h := h*d mod p
@@ -355,6 +331,13 @@ Internet-Draft The GNU Name System July 2019
h is the HKDF expansion result. The expansion info is a
concatenation of the label and string "gns".
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 6]
+
+Internet-Draft The GNU Name System July 2019
+
+
d is the private zone key as defined in [RFC8032].
P is the base point of the curve Ed25519 as defined in [RFC8032].
@@ -389,6 +372,23 @@ Internet-Draft The GNU Name System July 2019
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Schanzenbach, et al. Expires 24 January 2020 [Page 7]
Internet-Draft The GNU Name System July 2019
@@ -580,8 +580,10 @@ Internet-Draft The GNU Name System July 2019
+-----+-----+-----+-----+-----+-----+-----+-----+
| FLAGS | DATA /
+-----+-----+-----+-----+ /
- / /
- / /
+ / +-----------------------/
+ / | /
+ +-----------------------+ /
+ / PADDING /
/ /
Figure 10
@@ -591,6 +593,11 @@ Internet-Draft The GNU Name System July 2019
RR COUNT A 32-bit value containing the number of resource records
which are following in network byte order.
+ PADDING The padding MUST contain the 0 value in all octets. Not
+ applicable for PKEY records. The padding MUST ensure that the
+ size of the RDATA is a power of two. The only excption is the
+ PKEY record type, which is never padded.
+
is followed by a set of resource records with the respective formats
defined in Section 3.
@@ -601,13 +608,6 @@ Internet-Draft The GNU Name System July 2019
which are internationalized through the IDNA specifications
[RFC5890].
-6. Security Considerations
-
- TODO
-
-7. Record Resolution
-
- TODO
@@ -618,6 +618,14 @@ Schanzenbach, et al. Expires 24 January 2020 [Page 11]
Internet-Draft The GNU Name System July 2019
+6. Security Considerations
+
+ TODO
+
+7. Record Resolution
+
+ TODO
+
8. Namespace Revocation
TODO
@@ -658,6 +666,14 @@ Internet-Draft The GNU Name System July 2019
d_h :=
3376c182f461fb01
f3e009254c1c6177
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 12]
+
+Internet-Draft The GNU Name System July 2019
+
+
bd105c40e4e7b081
182ed3f702c81700
@@ -667,13 +683,6 @@ Internet-Draft The GNU Name System July 2019
6e325e54b93c8576
9182810f92fad776
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 12]
-
-Internet-Draft The GNU Name System July 2019
-
-
q (query key) :=
81d65adced4dce6f
3b7e7610339ae2f4
@@ -713,6 +722,14 @@ Internet-Draft The GNU Name System July 2019
636f6d0000000000 com | \0 | Followed by
0000000000000000 24 bytes of padding to 2^6
0000000000000000
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 13]
+
+Internet-Draft The GNU Name System July 2019
+
+
00000000
@@ -722,14 +739,6 @@ Internet-Draft The GNU Name System July 2019
e80818d0a84059a8
5eee901a66459e5e
3d1a10b29a5b8354
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 13]
-
-Internet-Draft The GNU Name System July 2019
-
-
1b58636781166b9a
642920eee8e7a65a
001fd19a6406a721
@@ -770,15 +779,6 @@ Internet-Draft The GNU Name System July 2019
001fd19a6406a721
713f0a0d
-11. 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 24 January 2020 [Page 14]
@@ -786,6 +786,13 @@ Schanzenbach, et al. Expires 24 January 2020 [Page 14]
Internet-Draft The GNU Name System July 2019
+11. 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>.
@@ -828,13 +835,6 @@ Authors' Addresses
Email: schanzen@gnunet.org
- Christian Grothoff
- GNUnet e.V.
- Boltzmannstrasse 3
- 85748 Garching
- Germany
-
-
Schanzenbach, et al. Expires 24 January 2020 [Page 15]
@@ -842,6 +842,12 @@ Schanzenbach, et al. Expires 24 January 2020 [Page 15]
Internet-Draft The GNU Name System July 2019
+ Christian Grothoff
+ GNUnet e.V.
+ Boltzmannstrasse 3
+ 85748 Garching
+ Germany
+
Email: schanzen@gnunet.org
@@ -887,10 +893,4 @@ Internet-Draft The GNU Name System July 2019
-
-
-
-
-
-
Schanzenbach, et al. Expires 24 January 2020 [Page 16]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -95,8 +95,6 @@
</section>
<section anchor="rrecords" numbered="true" toc="default">
<name>Resource records</name>
- <section anchor="rrecords_wire" numbered="true" toc="default">
- <name>Wire format</name>
<t>
A GNS resource record holds the data of a specific record in a zone.
The resource record format is defined as follows:
@@ -183,7 +181,6 @@
a resolver for records resolved from the DHT.
</dd>
</dl>
-</section>
<section anchor="gnsrecords_pkey" numbered="true" toc="default">
<name>PKEY</name>
<t>In GNS, a delegation of a label to a zone is represented through a PKEY
@@ -298,7 +295,7 @@
<dt>RECORD</dt>
<dd>
The boxed record in a format as defined in
- <xref target="rrecords_wire" />.
+ <xref target="rrecords" />.
</dd>
</dl>
</section>
