[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] [lsd0001] branch master updated (2cf8f54 -> d9c65a1)
|
From: |
gnunet |
|
Subject: |
[GNUnet-SVN] [lsd0001] branch master updated (2cf8f54 -> d9c65a1) |
|
Date: |
Fri, 04 Oct 2019 11:25:04 +0200 |
This is an automated email from the git hooks/post-receive script.
martin-schanzenbach pushed a change to branch master
in repository lsd0001.
from 2cf8f54 explain a bit more
new 93cb14c sectioning
new d9c65a1 Merge branch 'master' of ssh://gnunet.org/lsd0001
The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
draft-schanzen-gns.html | 193 ++++++++++++++++++-------------------
draft-schanzen-gns.txt | 248 ++++++++++++++++++++++++------------------------
draft-schanzen-gns.xml | 5 +-
3 files changed, 215 insertions(+), 231 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index 3d2232f..8f61d54 100644
--- 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>
@@ -1731,6 +1711,13 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<dd id="section-4.3-12.2">
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">
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
index d9a50fe..c976501 100644
--- 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].
@@ -385,6 +368,23 @@ 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: address@hidden
- 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: address@hidden
@@ -880,12 +886,6 @@ Internet-Draft The GNU Name System
July 2019
-
-
-
-
-
-
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index b8c5143..67136ea 100644
--- 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:
@@ -189,7 +187,6 @@
regular records when resolving labels in local zones.
</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
@@ -304,7 +301,7 @@
<dt>RECORD</dt>
<dd>
The boxed record in a format as defined in
- <xref target="rrecords_wire" />.
+ <xref target="rrecords" />.
</dd>
</dl>
</section>
--
To stop receiving notification emails like this one, please contact
address@hidden.
- [GNUnet-SVN] [lsd0001] branch master updated (2cf8f54 -> d9c65a1),
gnunet <=