[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: add record types
|
From: |
gnunet |
|
Subject: |
[lsd0001] branch master updated: add record types |
|
Date: |
Sun, 10 Nov 2019 11:49: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 1cfb3c0 add record types
1cfb3c0 is described below
commit 1cfb3c00b74062a05515b076b2043ff787b0f33a
Author: Schanzenbach, Martin <address@hidden>
AuthorDate: Sun Nov 10 11:46:42 2019 +0100
add record types
---
draft-schanzen-gns.html | 184 ++++++++++++++++-----------
draft-schanzen-gns.txt | 332 ++++++++++++++++++++++++++++++++----------------
draft-schanzen-gns.xml | 23 ++++
3 files changed, 356 insertions(+), 183 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index ca2063d..29e7331 100644
--- a/draft-schanzen-gns.html
+++ b/draft-schanzen-gns.html
@@ -1081,22 +1081,25 @@ 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-pkey" class="xref">PKEY</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-record-types" class="xref">Record
Types</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-gns2dns" class="xref">GNS2DNS</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-pkey" class="xref">PKEY</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-leho" class="xref">LEHO</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-gns2dns" class="xref">GNS2DNS</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-nick" class="xref">NICK</a><a
href="#section-boilerplate.3-1.3.2.4.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-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.5.1"><a href="#section-3.5"
class="xref">3.5</a>. <a href="#name-nick" class="xref">NICK</a><a
href="#section-boilerplate.3-1.3.2.5.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.3.2.6">
- <p id="section-boilerplate.3-1.3.2.6.1"><a href="#section-3.6"
class="xref">3.6</a>. <a href="#name-vpn" class="xref">VPN</a><a
href="#section-boilerplate.3-1.3.2.6.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.3.2.6.1"><a href="#section-3.6"
class="xref">3.6</a>. <a href="#name-box" class="xref">BOX</a><a
href="#section-boilerplate.3-1.3.2.6.1" class="pilcrow">¶</a></p>
+</li>
+ <li class="toc ulEmpty" id="section-boilerplate.3-1.3.2.7">
+ <p id="section-boilerplate.3-1.3.2.7.1"><a href="#section-3.7"
class="xref">3.7</a>. <a href="#name-vpn" class="xref">VPN</a><a
href="#section-boilerplate.3-1.3.2.7.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
@@ -1368,18 +1371,47 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
regular records when resolving labels in local zones.<a
href="#section-3-9.6" class="pilcrow">¶</a>
</dd>
</dl>
-<div id="gnsrecords_pkey">
+<div id="gnsrecords_numbers">
<section id="section-3.1">
+ <h3 id="name-record-types">
+<a href="#section-3.1" class="section-number selfRef">3.1. </a><a
href="#name-record-types" class="section-name selfRef">Record Types</a>
+ </h3>
+<p id="section-3.1-1">
+ GNS-specific record type numbers start at 2^16, i.e. after the record
+ type numbers for DNS. The following is a list of defined and reserved
+ record types in GNS:<a href="#section-3.1-1" class="pilcrow">¶</a></p>
+<div id="figure_rrtypenums">
+<figure id="figure-3">
+ <div class="artwork art-text alignLeft" id="section-3.1-2.1">
+<pre>
+ Number | Type | Comment
+ ------------------------------------------------------------
+ 65536 | PKEY | GNS delegation
+ 65537 | NICK | GNS zone nickname
+ 65538 | LEHO | Legacy hostname
+ 65539 | VPN | Virtual private network
+ 65540 | GNS2DNS | DNS delegation
+ 65541 | BOX | Boxed record (for
TLSA/SRV)
+ 65542 up to 2^24 - 1 | - | Reserved
+ 2^24 up to 2^32 - 1 | - | Unassigned / For private
use
+ </pre>
+</div>
+<figcaption><a href="#figure-3" class="selfRef">Figure
3</a></figcaption></figure>
+</div>
+</section>
+</div>
+<div id="gnsrecords_pkey">
+<section id="section-3.2">
<h3 id="name-pkey">
-<a href="#section-3.1" class="section-number selfRef">3.1. </a><a
href="#name-pkey" class="section-name selfRef">PKEY</a>
+<a href="#section-3.2" class="section-number selfRef">3.2. </a><a
href="#name-pkey" class="section-name selfRef">PKEY</a>
</h3>
-<p id="section-3.1-1">In GNS, a delegation of a label to a zone is represented
through a PKEY
+<p id="section-3.2-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
- records are allowed. A PKEY DATA entry has the following format:<a
href="#section-3.1-1" class="pilcrow">¶</a></p>
+ records are allowed. A PKEY DATA entry has the following format:<a
href="#section-3.2-1" class="pilcrow">¶</a></p>
<div id="figure_pkeyrecord">
-<figure id="figure-3">
- <div class="artwork art-text alignLeft" id="section-3.1-2.1">
+<figure id="figure-4">
+ <div class="artwork art-text alignLeft" id="section-3.2-2.1">
<pre>
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1390,23 +1422,23 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-3" class="selfRef">Figure
3</a></figcaption></figure>
+<figcaption><a href="#figure-4" class="selfRef">Figure
4</a></figcaption></figure>
</div>
</section>
</div>
<div id="gnsrecords_gns2dns">
-<section id="section-3.2">
+<section id="section-3.3">
<h3 id="name-gns2dns">
-<a href="#section-3.2" class="section-number selfRef">3.2. </a><a
href="#name-gns2dns" class="section-name selfRef">GNS2DNS</a>
+<a href="#section-3.3" class="section-number selfRef">3.3. </a><a
href="#name-gns2dns" class="section-name selfRef">GNS2DNS</a>
</h3>
-<p id="section-3.2-1">It is possible to delegate a label back into DNS through
a GNS2DNS record.
+<p id="section-3.3-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.
- A GNS2DNS DATA entry has the following format:<a
href="#section-3.2-1" class="pilcrow">¶</a></p>
+ A GNS2DNS DATA entry has the following format:<a
href="#section-3.3-1" class="pilcrow">¶</a></p>
<div id="figure_gns2dnsrecord">
-<figure id="figure-4">
- <div class="artwork art-text alignLeft" id="section-3.2-2.1">
+<figure id="figure-5">
+ <div class="artwork art-text alignLeft" id="section-3.3-2.1">
<pre>
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1422,16 +1454,16 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
+-----------------------------------------------+
</pre>
</div>
-<figcaption><a href="#figure-4" class="selfRef">Figure
4</a></figcaption></figure>
+<figcaption><a href="#figure-5" class="selfRef">Figure
5</a></figcaption></figure>
</div>
</section>
</div>
<div id="gnsrecords_leho">
-<section id="section-3.3">
+<section id="section-3.4">
<h3 id="name-leho">
-<a href="#section-3.3" class="section-number selfRef">3.3. </a><a
href="#name-leho" class="section-name selfRef">LEHO</a>
+<a href="#section-3.4" class="section-number selfRef">3.4. </a><a
href="#name-leho" class="section-name selfRef">LEHO</a>
</h3>
-<p id="section-3.3-1">Legacy hostname records can be used by applications that
are expected
+<p id="section-3.4-1">Legacy hostname records can be used by applications that
are expected
to supply a DNS name on the application layer. The most common use
case
is HTTP virtual hosting, which as-is would not work with GNS names as
those may not be globally unique.
@@ -1440,10 +1472,10 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
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.3-1"
class="pilcrow">¶</a></p>
+ A LEHO DATA entry has the following format:<a href="#section-3.4-1"
class="pilcrow">¶</a></p>
<div id="figure_lehorecord">
-<figure id="figure-5">
- <div class="artwork art-text alignLeft" id="section-3.3-2.1">
+<figure id="figure-6">
+ <div class="artwork art-text alignLeft" id="section-3.4-2.1">
<pre>
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1454,32 +1486,32 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-5" class="selfRef">Figure
5</a></figcaption></figure>
+<figcaption><a href="#figure-6" class="selfRef">Figure
6</a></figcaption></figure>
</div>
-<p id="section-3.3-3">
+<p id="section-3.4-3">
NOTE: If an application uses a LEHO value in an HTTP request header
(e.g. "Host:" header) it must be converted to a punycode
representation
- <span>[<a href="#RFC5891" class="xref">RFC5891</a>]</span>.<a
href="#section-3.3-3" class="pilcrow">¶</a></p>
+ <span>[<a href="#RFC5891" class="xref">RFC5891</a>]</span>.<a
href="#section-3.4-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="gnsrecords_nick">
-<section id="section-3.4">
+<section id="section-3.5">
<h3 id="name-nick">
-<a href="#section-3.4" class="section-number selfRef">3.4. </a><a
href="#name-nick" class="section-name selfRef">NICK</a>
+<a href="#section-3.5" class="section-number selfRef">3.5. </a><a
href="#name-nick" class="section-name selfRef">NICK</a>
</h3>
-<p id="section-3.4-1">Nickname records can be used by zone administrators to
publish an
+<p id="section-3.5-1">Nickname records can be used by zone administrators to
publish an
indication on what label this zone prefers to be referred to.
This is a suggestion to other zones what label to use when creating a
- PKEY <a href="#gnsrecords_pkey" class="xref">Section 3.1</a> record
containing this zone's
+ PKEY <a href="#gnsrecords_pkey" class="xref">Section 3.2</a> record
containing this zone's
public zone key.
A NICK resource record contains an UTF-8 string
(not 0-terminated) representing the preferred label.
This string may NOT inlcude a ".".
This record SHOULD only be stored under the empty label "@".
- A NICK DATA entry has the following format:<a href="#section-3.4-1"
class="pilcrow">¶</a></p>
+ A NICK DATA entry has the following format:<a href="#section-3.5-1"
class="pilcrow">¶</a></p>
<div id="figure_nickrecord">
-<figure id="figure-6">
- <div class="artwork art-text alignLeft" id="section-3.4-2.1">
+<figure id="figure-7">
+ <div class="artwork art-text alignLeft" id="section-3.5-2.1">
<pre>
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1490,20 +1522,20 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-6" class="selfRef">Figure
6</a></figcaption></figure>
+<figcaption><a href="#figure-7" class="selfRef">Figure
7</a></figcaption></figure>
</div>
</section>
</div>
<div id="gnsrecords_box">
-<section id="section-3.5">
+<section id="section-3.6">
<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.6" class="section-number selfRef">3.6. </a><a
href="#name-box" class="section-name selfRef">BOX</a>
</h3>
-<p id="section-3.5-1">
- A BOX DATA entry has the following format:<a href="#section-3.5-1"
class="pilcrow">¶</a></p>
+<p id="section-3.6-1">
+ A BOX DATA entry has the following format:<a href="#section-3.6-1"
class="pilcrow">¶</a></p>
<div id="figure_boxrecord">
-<figure id="figure-7">
- <div class="artwork art-text alignLeft" id="section-3.5-2.1">
+<figure id="figure-8">
+ <div class="artwork art-text alignLeft" id="section-3.6-2.1">
<pre>
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1516,40 +1548,40 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-7" class="selfRef">Figure
7</a></figcaption></figure>
+<figcaption><a href="#figure-8" class="selfRef">Figure
8</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 16-bit 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.6-3">
+ <dt id="section-3.6-3.1">PROTO</dt>
+ <dd id="section-3.6-3.2">
+ the 16-bit protocol number, e.g. 6 for tcp. In network byte
order.<a href="#section-3.6-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.6-3.3">SVC</dt>
+ <dd id="section-3.6-3.4">
the 16-bit service value of the boxed record, i.e. the port number.
- In network byte order.<a href="#section-3.5-3.4"
class="pilcrow">¶</a>
+ In network byte order.<a href="#section-3.6-3.4"
class="pilcrow">¶</a>
</dd>
- <dt id="section-3.5-3.5">TYPE</dt>
- <dd id="section-3.5-3.6">
- is the 32-bit record type of the boxed record. In network byte
order.<a href="#section-3.5-3.6" class="pilcrow">¶</a>
+ <dt id="section-3.6-3.5">TYPE</dt>
+ <dd id="section-3.6-3.6">
+ is the 32-bit record type of the boxed record. In network byte
order.<a href="#section-3.6-3.6" class="pilcrow">¶</a>
</dd>
- <dt id="section-3.5-3.7">RECORD DATA</dt>
- <dd id="section-3.5-3.8">
+ <dt id="section-3.6-3.7">RECORD DATA</dt>
+ <dd id="section-3.6-3.8">
is a variable length field containing the "DATA" format of TYPE as
- defined for the respective TYPE in DNS.<a href="#section-3.5-3.8"
class="pilcrow">¶</a>
+ defined for the respective TYPE in DNS.<a href="#section-3.6-3.8"
class="pilcrow">¶</a>
</dd>
</dl>
</section>
</div>
<div id="gnsrecords_vpn">
-<section id="section-3.6">
+<section id="section-3.7">
<h3 id="name-vpn">
-<a href="#section-3.6" class="section-number selfRef">3.6. </a><a
href="#name-vpn" class="section-name selfRef">VPN</a>
+<a href="#section-3.7" class="section-number selfRef">3.7. </a><a
href="#name-vpn" class="section-name selfRef">VPN</a>
</h3>
-<p id="section-3.6-1">
- A VPN DATA entry has the following format:<a href="#section-3.6-1"
class="pilcrow">¶</a></p>
+<p id="section-3.7-1">
+ A VPN DATA entry has the following format:<a href="#section-3.7-1"
class="pilcrow">¶</a></p>
<div id="figure_vpnrecord">
-<figure id="figure-8">
- <div class="artwork art-text alignLeft" id="section-3.6-2.1">
+<figure id="figure-9">
+ <div class="artwork art-text alignLeft" id="section-3.7-2.1">
<pre>
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1565,7 +1597,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
+-----------------------------------------------+
</pre>
</div>
-<figcaption><a href="#figure-8" class="selfRef">Figure
8</a></figcaption></figure>
+<figcaption><a href="#figure-9" class="selfRef">Figure
9</a></figcaption></figure>
</div>
</section>
</div>
@@ -1666,7 +1698,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
DHT. This may include a periodic refresh publication.
A GNS RRBLOCK has the following format:<a href="#section-4.2-1"
class="pilcrow">¶</a></p>
<div id="figure_record_block">
-<figure id="figure-9">
+<figure id="figure-10">
<div class="artwork art-text alignLeft" id="section-4.2-2.1">
<pre>
0 8 16 24 32 40 48 56
@@ -1695,7 +1727,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-9" class="selfRef">Figure
9</a></figcaption></figure>
+<figcaption><a href="#figure-10" class="selfRef">Figure
10</a></figcaption></figure>
</div>
<p id="section-4.2-3">where:<a href="#section-4.2-3" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-4.2-4">
@@ -1758,7 +1790,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
set RDATA into the BDATA field of a GNS RRBLOCK.
The wire format of the RDATA looks as follows:<a
href="#section-4.3-1" class="pilcrow">¶</a></p>
<div id="figure_rdata">
-<figure id="figure-10">
+<figure id="figure-11">
<div class="artwork art-text alignLeft" id="section-4.3-2.1">
<pre>
0 8 16 24 32 40 48 56
@@ -1786,7 +1818,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
/ /
</pre>
</div>
-<figcaption><a href="#figure-10" class="selfRef">Figure
10</a></figcaption></figure>
+<figcaption><a href="#figure-11" class="selfRef">Figure
11</a></figcaption></figure>
</div>
<p id="section-4.3-3">where:<a href="#section-4.3-3" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-4.3-4">
@@ -1836,7 +1868,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
<span>[<a href="#RFC3826" class="xref">RFC3826</a>]</span> key
and a 256-bit TWOFISH <span>[<a href="#TWOFISH"
class="xref">TWOFISH</a>]</span> key:<a href="#section-4.3-7"
class="pilcrow">¶</a></p>
<div id="figure_hkdf_keys">
-<figure id="figure-11">
+<figure id="figure-12">
<div class="artwork art-text alignLeft" id="section-4.3-8.1">
<pre>
0 8 16 24 32 40 48 56
@@ -1853,13 +1885,13 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-11" class="selfRef">Figure
11</a></figcaption></figure>
+<figcaption><a href="#figure-12" class="selfRef">Figure
12</a></figcaption></figure>
</div>
<p id="section-4.3-9">
Similarly, we divide "IV" into a 128-bit initialization vector
and a 128-bit initialization vector:<a href="#section-4.3-9"
class="pilcrow">¶</a></p>
<div id="figure_hkdf_ivs">
-<figure id="figure-12">
+<figure id="figure-13">
<div class="artwork art-text alignLeft" id="section-4.3-10.1">
<pre>
0 8 16 24 32 40 48 56
@@ -1872,7 +1904,7 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-12" class="selfRef">Figure
12</a></figcaption></figure>
+<figcaption><a href="#figure-13" class="selfRef">Figure
13</a></figcaption></figure>
</div>
<p id="section-4.3-11">
The keys and IVs are used for a CFB128-AES-256 and
@@ -2126,7 +2158,13 @@ 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">
- TODO<a href="#section-7-1" class="pilcrow">¶</a></p>
+ In order to revoke a zone, a signed revocation object must be
published.
+ This object must be signed using the private zone key.
+ The revocation object is flooded in the overlay network. To prevent
+ flooding attacks, the revocation message must contain a proof-of-work.
+ The revocation message may be calculated ahead of time.<a
href="#section-7-1" class="pilcrow">¶</a></p>
+<p id="section-7-2">
+ A revocation message is defined as follows:<a href="#section-7-2"
class="pilcrow">¶</a></p>
</section>
</div>
<div id="security">
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
index e6e10db..495e6cf 100644
--- a/draft-schanzen-gns.txt
+++ b/draft-schanzen-gns.txt
@@ -63,32 +63,33 @@ Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Resource Records . . . . . . . . . . . . . . . . . . . . . . 4
- 3.1. PKEY . . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 3.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 3.3. LEHO . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 3.4. NICK . . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 3.5. BOX . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 3.6. VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 4. Publishing Records . . . . . . . . . . . . . . . . . . . . . 8
- 4.1. Key Derivations . . . . . . . . . . . . . . . . . . . . . 8
- 4.2. Resource Records Block . . . . . . . . . . . . . . . . . 9
- 4.3. Record Data Encryption and Decryption . . . . . . . . . . 11
- 5. Internationalization and Character Encoding . . . . . . . . . 13
- 6. Name Resolution . . . . . . . . . . . . . . . . . . . . . . . 13
- 6.1. Entry Zone . . . . . . . . . . . . . . . . . . . . . . . 13
- 6.2. Record Retrieval . . . . . . . . . . . . . . . . . . . . 14
- 6.3. Record Processing . . . . . . . . . . . . . . . . . . . . 15
- 6.3.1. PKEY . . . . . . . . . . . . . . . . . . . . . . . . 15
- 6.3.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . 15
- 6.3.3. CNAME . . . . . . . . . . . . . . . . . . . . . . . . 16
- 6.3.4. BOX . . . . . . . . . . . . . . . . . . . . . . . . . 16
- 6.3.5. VPN . . . . . . . . . . . . . . . . . . . . . . . . . 16
- 7. Zone Revocation . . . . . . . . . . . . . . . . . . . . . . . 16
- 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
- 10. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 17
- 11. Normative References . . . . . . . . . . . . . . . . . . . . 19
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
+ 3.1. Record Types . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.2. PKEY . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.3. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.4. LEHO . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.5. NICK . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.6. BOX . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 3.7. VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 4. Publishing Records . . . . . . . . . . . . . . . . . . . . . 9
+ 4.1. Key Derivations . . . . . . . . . . . . . . . . . . . . . 9
+ 4.2. Resource Records Block . . . . . . . . . . . . . . . . . 10
+ 4.3. Record Data Encryption and Decryption . . . . . . . . . . 12
+ 5. Internationalization and Character Encoding . . . . . . . . . 14
+ 6. Name Resolution . . . . . . . . . . . . . . . . . . . . . . . 14
+ 6.1. Entry Zone . . . . . . . . . . . . . . . . . . . . . . . 14
+ 6.2. Record Retrieval . . . . . . . . . . . . . . . . . . . . 15
+ 6.3. Record Processing . . . . . . . . . . . . . . . . . . . . 16
+ 6.3.1. PKEY . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 6.3.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . 16
+ 6.3.3. CNAME . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 6.3.4. BOX . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 6.3.5. VPN . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 7. Zone Revocation . . . . . . . . . . . . . . . . . . . . . . . 18
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
+ 10. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 11. Normative References . . . . . . . . . . . . . . . . . . . . 20
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
@@ -105,7 +106,6 @@ Table of Contents
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
@@ -114,6 +114,7 @@ Schanzenbach, et al. Expires 24 January 2020
[Page 2]
Internet-Draft The GNU Name System July 2019
+ 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
kind of cryptographically secured token, enabling it to double in
@@ -164,7 +165,6 @@ Internet-Draft The GNU Name System
July 2019
-
Schanzenbach, et al. Expires 24 January 2020 [Page 3]
Internet-Draft The GNU Name System July 2019
@@ -259,7 +259,43 @@ Internet-Draft The GNU Name System
July 2019
Private records should still be considered just like regular
records when resolving labels in local zones.
-3.1. PKEY
+3.1. Record Types
+
+ GNS-specific record type numbers start at 2^16, i.e. after the record
+ type numbers for DNS. The following is a list of defined and
+ reserved record types in GNS:
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 5]
+
+Internet-Draft The GNU Name System July 2019
+
+
+ Number | Type | Comment
+ ------------------------------------------------------------
+ 65536 | PKEY | GNS delegation
+ 65537 | NICK | GNS zone nickname
+ 65538 | LEHO | Legacy hostname
+ 65539 | VPN | Virtual private network
+ 65540 | GNS2DNS | DNS delegation
+ 65541 | BOX | Boxed record (for
TLSA/SRV)
+ 65542 up to 2^24 - 1 | - | Reserved
+ 2^24 up to 2^32 - 1 | - | Unassigned / For
private use
+
+ Figure 3
+
+3.2. PKEY
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
@@ -275,16 +311,9 @@ Internet-Draft The GNU Name System
July 2019
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
+ Figure 4
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 5]
-
-Internet-Draft The GNU Name System July 2019
-
-
- Figure 3
-
-3.2. GNS2DNS
+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
@@ -292,6 +321,23 @@ Internet-Draft The GNU Name System
July 2019
format defined in [RFC1034] for DNS names. A GNS2DNS DATA entry has
the following format:
+
+
+
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 6]
+
+Internet-Draft The GNU Name System July 2019
+
+
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| DNS NAME |
@@ -305,9 +351,9 @@ Internet-Draft The GNU Name System
July 2019
| |
+-----------------------------------------------+
- Figure 4
+ Figure 5
-3.3. LEHO
+3.4. LEHO
Legacy hostname records can be used by applications that are expected
to supply a DNS name on the application layer. The most common use
@@ -326,29 +372,28 @@ Internet-Draft The GNU Name System
July 2019
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 5
+ Figure 6
NOTE: If an application uses a LEHO value in an HTTP request header
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 6]
-
-Internet-Draft The GNU Name System July 2019
-
-
(e.g. "Host:" header) it must be converted to a punycode
representation [RFC5891].
-3.4. NICK
+3.5. NICK
Nickname records can be used by zone administrators to publish an
indication on what label this zone prefers to be referred to. This
is a suggestion to other zones what label to use when creating a PKEY
- Section 3.1 record containing this zone's public zone key. A NICK
+ Section 3.2 record containing this zone's public zone key. A NICK
resource record contains an UTF-8 string (not 0-terminated)
representing the preferred label. This string may NOT inlcude a ".".
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 7]
+
+Internet-Draft The GNU Name System July 2019
+
+
This record SHOULD only be stored under the empty label "@". A NICK
DATA entry has the following format:
@@ -360,9 +405,9 @@ Internet-Draft The GNU Name System
July 2019
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 6
+ Figure 7
-3.5. BOX
+3.6. BOX
A BOX DATA entry has the following format:
@@ -376,7 +421,7 @@ Internet-Draft The GNU Name System
July 2019
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 7
+ Figure 8
PROTO the 16-bit protocol number, e.g. 6 for tcp. In network byte
order.
@@ -387,19 +432,23 @@ Internet-Draft The GNU Name System
July 2019
TYPE is the 32-bit record type of the boxed record. In network byte
order.
+ RECORD DATA is a variable length field containing the "DATA" format
+ of TYPE as defined for the respective TYPE in DNS.
+3.7. VPN
-Schanzenbach, et al. Expires 24 January 2020 [Page 7]
-
-Internet-Draft The GNU Name System July 2019
+ A VPN DATA entry has the following format:
- RECORD DATA is a variable length field containing the "DATA" format
- of TYPE as defined for the respective TYPE in DNS.
-3.6. VPN
- A VPN DATA entry has the following format:
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 8]
+
+Internet-Draft The GNU Name System July 2019
+
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -414,7 +463,7 @@ Internet-Draft The GNU Name System
July 2019
| |
+-----------------------------------------------+
- Figure 8
+ Figure 9
4. Publishing Records
@@ -441,15 +490,6 @@ Internet-Draft The GNU Name System
July 2019
SHA256 for the expansion phase.
PRK_h is key material retrieved using an HKDF using the string "key-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 8]
-
-Internet-Draft The GNU Name System July 2019
-
-
derivation" as salt and the public zone key "zk" as initial keying
material.
@@ -458,6 +498,14 @@ Internet-Draft The GNU Name System
July 2019
d is the 256-bit private zone key as defined in Section 2.
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 9]
+
+Internet-Draft The GNU Name System July 2019
+
+
label is a UTF-8 string under which the resource records are
published.
@@ -501,7 +549,15 @@ Internet-Draft The GNU Name System
July 2019
-Schanzenbach, et al. Expires 24 January 2020 [Page 9]
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 10]
Internet-Draft The GNU Name System July 2019
@@ -531,7 +587,7 @@ Internet-Draft The GNU Name System
July 2019
/ |
+-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 9
+ Figure 10
where:
@@ -557,7 +613,7 @@ Internet-Draft The GNU Name System
July 2019
-Schanzenbach, et al. Expires 24 January 2020 [Page 10]
+Schanzenbach, et al. Expires 24 January 2020 [Page 11]
Internet-Draft The GNU Name System July 2019
@@ -606,14 +662,14 @@ Internet-Draft The GNU Name System
July 2019
/ PADDING /
/ /
- Figure 10
+ Figure 11
where:
-Schanzenbach, et al. Expires 24 January 2020 [Page 11]
+Schanzenbach, et al. Expires 24 January 2020 [Page 12]
Internet-Draft The GNU Name System July 2019
@@ -663,13 +719,13 @@ Internet-Draft The GNU Name System
July 2019
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 11
+ Figure 12
-Schanzenbach, et al. Expires 24 January 2020 [Page 12]
+Schanzenbach, et al. Expires 24 January 2020 [Page 13]
Internet-Draft The GNU Name System July 2019
@@ -686,7 +742,7 @@ Internet-Draft The GNU Name System
July 2019
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 12
+ Figure 13
The keys and IVs are used for a CFB128-AES-256 and CFB128-TWOFISH-256
chained symmetric cipher. Both ciphers are used in Cipher FeedBack
@@ -725,7 +781,7 @@ Internet-Draft The GNU Name System
July 2019
-Schanzenbach, et al. Expires 24 January 2020 [Page 13]
+Schanzenbach, et al. Expires 24 January 2020 [Page 14]
Internet-Draft The GNU Name System July 2019
@@ -781,7 +837,7 @@ Internet-Draft The GNU Name System
July 2019
-Schanzenbach, et al. Expires 24 January 2020 [Page 14]
+Schanzenbach, et al. Expires 24 January 2020 [Page 15]
Internet-Draft The GNU Name System July 2019
@@ -837,7 +893,7 @@ Internet-Draft The GNU Name System
July 2019
-Schanzenbach, et al. Expires 24 January 2020 [Page 15]
+Schanzenbach, et al. Expires 24 January 2020 [Page 16]
Internet-Draft The GNU Name System July 2019
@@ -886,18 +942,28 @@ Internet-Draft The GNU Name System
July 2019
result is returned if the resolver implementation does not support
any of the tunnnels provided in the VPN records.
-7. Zone Revocation
- TODO
-Schanzenbach, et al. Expires 24 January 2020 [Page 16]
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 17]
Internet-Draft The GNU Name System July 2019
+7. Zone Revocation
+
+ In order to revoke a zone, a signed revocation object must be
+ published. This object must be signed using the private zone key.
+ The revocation object is flooded in the overlay network. To prevent
+ flooding attacks, the revocation message must contain a proof-of-
+ work. The revocation message may be calculated ahead of time.
+
+ A revocation message is defined as follows:
+
8. Security Considerations
TODO
@@ -936,6 +1002,14 @@ Internet-Draft The GNU Name System
July 2019
6d656b27392b0fee
d_h :=
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 18]
+
+Internet-Draft The GNU Name System July 2019
+
+
01fb61f482c17633
77611c4c2509e0f3
81b0e7e4405c10bd
@@ -946,14 +1020,6 @@ Internet-Draft The GNU Name System
July 2019
f4e29a3310767e3b
8b38bc1b276ce2ba
9bf1b49df1e120a3
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 17]
-
-Internet-Draft The GNU Name System July 2019
-
-
20ecc9dffb68416f
11729ad878ad3bdf
d0b4db2626b620d7
@@ -992,6 +1058,14 @@ Internet-Draft The GNU Name System
July 2019
RRBLOCK :=
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 19]
+
+Internet-Draft The GNU Name System July 2019
+
+
055cb070e05fe6de SIGNATURE
ad694a50e5b4dedd
b9fdcbdbae004f65
@@ -1002,14 +1076,6 @@ Internet-Draft The GNU Name System
July 2019
10df4f39f5ba9f46____________
8cb514a56c0eaae0 zk_h
56745158a63ee4dd
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 18]
-
-Internet-Draft The GNU Name System July 2019
-
-
76853cb9545e326e
76d7fa920f818291____________
000000540000000f SIZE (=84) | PURPOSE (=15)
@@ -1049,6 +1115,13 @@ Internet-Draft The GNU Name System
July 2019
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>.
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 20]
+
+Internet-Draft The GNU Name System July 2019
+
+
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
@@ -1059,13 +1132,6 @@ Internet-Draft The GNU Name System
July 2019
DOI 10.17487/RFC5891, August 2010,
<https://www.rfc-editor.org/info/rfc5891>.
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 19]
-
-Internet-Draft The GNU Name System July 2019
-
-
[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
April 2013, <https://www.rfc-editor.org/info/rfc6895>.
@@ -1104,6 +1170,14 @@ Authors' Addresses
CH-2501 Biel/Bienne
Switzerland
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 21]
+
+Internet-Draft The GNU Name System July 2019
+
+
Email: address@hidden
@@ -1117,4 +1191,42 @@ Authors' Addresses
-Schanzenbach, et al. Expires 24 January 2020 [Page 20]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 22]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index d695e1a..5959ad8 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -255,6 +255,29 @@
regular records when resolving labels in local zones.
</dd>
</dl>
+ <section anchor="gnsrecords_numbers" numbered="true" toc="default">
+ <name>Record Types</name>
+ <t>
+ GNS-specific record type numbers start at 2^16, i.e. after the record
+ type numbers for DNS. The following is a list of defined and reserved
+ record types in GNS:
+ </t>
+ <figure anchor="figure_rrtypenums">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ Number | Type | Comment
+ ------------------------------------------------------------
+ 65536 | PKEY | GNS delegation
+ 65537 | NICK | GNS zone nickname
+ 65538 | LEHO | Legacy hostname
+ 65539 | VPN | Virtual private network
+ 65540 | GNS2DNS | DNS delegation
+ 65541 | BOX | Boxed record (for
TLSA/SRV)
+ 65542 up to 2^24 - 1 | - | Reserved
+ 2^24 up to 2^32 - 1 | - | Unassigned / For private
use
+ ]]></artwork>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+ </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
--
To stop receiving notification emails like this one, please contact
address@hidden.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0001] branch master updated: add record types,
gnunet <=