commit e7df043d73f099756a27e16836e362662efd31fb
parent 77dd5c2d584225c8615489015c3c3a8299a21113
Author: Schanzenbach, Martin <mschanzenbach@posteo.de>
Date: Fri, 8 Nov 2019 14:22:50 -0500
add some box and vpn
Diffstat:
3 files changed, 334 insertions(+), 179 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
@@ -1095,6 +1095,9 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<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>
</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>
+</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.4">
@@ -1135,6 +1138,12 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<li class="toc ulEmpty" id="section-boilerplate.3-1.6.2.3.2.3">
<p id="section-boilerplate.3-1.6.2.3.2.3.1"><a href="#section-6.3.3" class="xref">6.3.3</a>. <a href="#name-cname" class="xref">CNAME</a><a href="#section-boilerplate.3-1.6.2.3.2.3.1" class="pilcrow">¶</a></p>
</li>
+ <li class="toc ulEmpty" id="section-boilerplate.3-1.6.2.3.2.4">
+ <p id="section-boilerplate.3-1.6.2.3.2.4.1"><a href="#section-6.3.4" class="xref">6.3.4</a>. <a href="#name-box-2" class="xref">BOX</a><a href="#section-boilerplate.3-1.6.2.3.2.4.1" class="pilcrow">¶</a></p>
+</li>
+ <li class="toc ulEmpty" id="section-boilerplate.3-1.6.2.3.2.5">
+ <p id="section-boilerplate.3-1.6.2.3.2.5.1"><a href="#section-6.3.5" class="xref">6.3.5</a>. <a href="#name-vpn-2" class="xref">VPN</a><a href="#section-boilerplate.3-1.6.2.3.2.5.1" class="pilcrow">¶</a></p>
+</li>
</ul>
</li>
</ul>
@@ -1545,6 +1554,35 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
</dl>
</section>
</div>
+<div id="gnsrecords_vpn">
+<section id="section-3.6">
+ <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>
+ </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>
+<div id="figure_vpnrecord">
+<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
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TODO DNS NAME |
+ / /
+ / /
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DNS SERVER NAME |
+ / TODO /
+ / /
+ | |
+ +-----------------------------------------------+
+ </pre>
+</div>
+<figcaption><a href="#figure-8" class="selfRef">Figure 8</a></figcaption></figure>
+</div>
+</section>
+</div>
</section>
</div>
<div id="publish">
@@ -1642,7 +1680,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-8">
+<figure id="figure-9">
<div class="artwork art-text alignLeft" id="section-4.2-2.1">
<pre>
0 8 16 24 32 40 48 56
@@ -1671,7 +1709,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>
<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">
@@ -1734,7 +1772,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-9">
+<figure id="figure-10">
<div class="artwork art-text alignLeft" id="section-4.3-2.1">
<pre>
0 8 16 24 32 40 48 56
@@ -1762,7 +1800,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.3-3">where:<a href="#section-4.3-3" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-4.3-4">
@@ -1812,7 +1850,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-10">
+<figure id="figure-11">
<div class="artwork art-text alignLeft" id="section-4.3-8.1">
<pre>
0 8 16 24 32 40 48 56
@@ -1829,13 +1867,13 @@ 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-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-11">
+<figure id="figure-12">
<div class="artwork art-text alignLeft" id="section-4.3-10.1">
<pre>
0 8 16 24 32 40 48 56
@@ -1848,7 +1886,7 @@ 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-11">
The keys and IVs are used for a CFB128-AES-256 and
@@ -2056,6 +2094,27 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
CNAMEs using an upper bound.<a href="#section-6.3.3-2" class="pilcrow">¶</a></p>
</section>
</div>
+<div id="box_processing">
+<section id="section-6.3.4">
+ <h4 id="name-box-2">
+<a href="#section-6.3.4" class="section-number selfRef">6.3.4. </a><a href="#name-box-2" class="section-name selfRef">BOX</a>
+ </h4>
+<p id="section-6.3.4-1">
+ TODO<a href="#section-6.3.4-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="vpn_processing">
+<section id="section-6.3.5">
+ <h4 id="name-vpn-2">
+<a href="#section-6.3.5" class="section-number selfRef">6.3.5. </a><a href="#name-vpn-2" class="section-name selfRef">VPN</a>
+ </h4>
+<p id="section-6.3.5-1">
+ If the queried record type is either A or AAAA and the retrieved
+ record set contains a VPN record, the resolver must open a VPN
+ tunnel (cite someplace? This is difficult to define!) and return
+ the IPv4 or IPv6 tunnel address, respectively.<a href="#section-6.3.5-1" class="pilcrow">¶</a></p>
+</section>
+</div>
</section>
</div>
</section>
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
@@ -68,24 +68,27 @@ Table of Contents
3.3. LEHO . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. NICK . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. BOX . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 4. Publishing Records . . . . . . . . . . . . . . . . . . . . . 8
- 4.1. Key Derivations . . . . . . . . . . . . . . . . . . . . . 8
- 4.2. Resource Records Block . . . . . . . . . . . . . . . . . 9
+ 3.6. VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 4. Publishing Records . . . . . . . . . . . . . . . . . . . . . 9
+ 4.1. Key Derivations . . . . . . . . . . . . . . . . . . . . . 9
+ 4.2. Resource Records Block . . . . . . . . . . . . . . . . . 10
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
+ 5. Internationalization and Character Encoding . . . . . . . . . 14
+ 6. Name Resolution . . . . . . . . . . . . . . . . . . . . . . . 14
+ 6.1. Entry Zone . . . . . . . . . . . . . . . . . . . . . . . 14
+ 6.2. Record Retrieval . . . . . . . . . . . . . . . . . . . . 15
6.3. Record Processing . . . . . . . . . . . . . . . . . . . . 15
- 6.3.1. PKEY . . . . . . . . . . . . . . . . . . . . . . . . 15
- 6.3.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . 15
+ 6.3.1. PKEY . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 6.3.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . 16
6.3.3. CNAME . . . . . . . . . . . . . . . . . . . . . . . . 16
- 7. Zone Revocation . . . . . . . . . . . . . . . . . . . . . . . 16
- 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
- 10. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 16
- 11. Normative References . . . . . . . . . . . . . . . . . . . . 18
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
+ 6.3.4. BOX . . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 6.3.5. VPN . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 7. Zone Revocation . . . . . . . . . . . . . . . . . . . . . . . 17
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
+ 10. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 11. Normative References . . . . . . . . . . . . . . . . . . . . 19
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
@@ -103,9 +106,6 @@ Table of Contents
capabilities of an entire nation state at their disposal. This
specification describes a censorship-resistant, privacy-preserving
and decentralized name system: The GNU Name System (GNS). It is
- designed to provide a secure alternative to DNS, especially when
- censorship or manipulation is encountered. GNS can bind names to any
- kind of cryptographically secured token, enabling it to double in
@@ -114,6 +114,9 @@ Schanzenbach, et al. Expires 24 January 2020 [Page 2]
Internet-Draft The GNU Name System July 2019
+ 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
some respects as even as an alternative to some of today's Public Key
Infrastructures, in particular X.509 for the Web.
@@ -158,9 +161,6 @@ Internet-Draft The GNU Name System July 2019
zk is the ECDSA public key corresponding to d. It is defined in
[RFC6979] as the curve point d*B where B is the group generator of
- the elliptic curve. The public key is used to uniquely identify a
- GNS zone and is referred to as the "zone key".
-
@@ -170,6 +170,9 @@ Schanzenbach, et al. Expires 24 January 2020 [Page 3]
Internet-Draft The GNU Name System July 2019
+ the elliptic curve. The public key is used to uniquely identify a
+ GNS zone and is referred to as the "zone key".
+
3. Resource Records
A GNS implementor MUST provide a mechanism to create and manage
@@ -216,9 +219,6 @@ Internet-Draft The GNU Name System July 2019
DATA the variable-length resource record data payload. The contents
are defined by the respective type of the resource record.
- Flags indicate metadata surrounding the resource record. A flag
- value of 0 indicates that all flags are unset. The following
-
Schanzenbach, et al. Expires 24 January 2020 [Page 4]
@@ -226,6 +226,8 @@ Schanzenbach, et al. Expires 24 January 2020 [Page 4]
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
resource record:
@@ -273,8 +275,6 @@ Internet-Draft The GNU Name System July 2019
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 3
-
Schanzenbach, et al. Expires 24 January 2020 [Page 5]
@@ -282,6 +282,8 @@ Schanzenbach, et al. Expires 24 January 2020 [Page 5]
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
@@ -327,8 +329,6 @@ Internet-Draft The GNU Name System July 2019
Figure 5
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 [RFC5891].
@@ -338,6 +338,9 @@ 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
Nickname records can be used by zone administrators to publish an
@@ -377,6 +380,20 @@ Internet-Draft The GNU Name System July 2019
the corresponding address records. A BOX DATA entry has the
following format:
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 7]
+
+Internet-Draft The GNU Name System July 2019
+
+
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| PROTO | SVC | TYPE |
@@ -387,13 +404,6 @@ 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
-
-
Figure 7
PROTO the 16-bit protocol number, e.g. 6 for tcp. In network byte
@@ -408,6 +418,38 @@ Internet-Draft The GNU Name System July 2019
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:
+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TODO DNS NAME |
+ / /
+ / /
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DNS SERVER NAME |
+ / TODO /
+ / /
+ | |
+ +-----------------------------------------------+
+
+ Figure 8
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 8]
+
+Internet-Draft The GNU Name System July 2019
+
+
4. Publishing Records
GNS resource records are published in a distributed hash table (DHT).
@@ -441,15 +483,6 @@ 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 8]
-
-Internet-Draft The GNU Name System July 2019
-
-
label is a UTF-8 string under which the resource records are
published.
@@ -465,6 +498,14 @@ Internet-Draft The GNU Name System July 2019
published. It is the SHA512 hash over the public key "zk_h"
corresponding to the derived private key "d_h".
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 9]
+
+Internet-Draft The GNU Name System July 2019
+
+
We point out that the multiplication of "zk" with "h" is a point
multiplication, while the multiplication of "d" with "h" is a scalar
multiplication.
@@ -478,34 +519,6 @@ Internet-Draft The GNU Name System July 2019
underlying DHT. This may include a periodic refresh publication. A
GNS RRBLOCK has the following format:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 9]
-
-Internet-Draft The GNU Name System July 2019
-
-
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| SIGNATURE |
@@ -531,7 +544,7 @@ Internet-Draft The GNU Name System July 2019
/ |
+-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 8
+ Figure 9
where:
@@ -540,6 +553,15 @@ Internet-Draft The GNU Name System July 2019
PUBLIC KEY field. The signature is created using the derived
private key "d_h" (see Section 4).
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 10]
+
+Internet-Draft The GNU Name System July 2019
+
+
PUBLIC KEY is the 256-bit public key "zk_h" to be used to verify
SIGNATURE. The wire format of this value is defined in [RFC8032],
Section 5.1.5.
@@ -555,13 +577,6 @@ Internet-Draft The GNU Name System July 2019
PURPOSE A 32-bit signature purpose flag. This field MUST be 15 (in
network byte order).
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 10]
-
-Internet-Draft The GNU Name System July 2019
-
-
EXPIRATION Specifies when the RRBLOCK expires and the encrypted
block SHOULD be removed from the DHT and caches as it is likely
stale. However, applications MAY continue to use non-expired
@@ -582,6 +597,27 @@ Internet-Draft The GNU Name System July 2019
set RDATA into the BDATA field of a GNS RRBLOCK. The wire format of
the RDATA looks as follows:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 11]
+
+Internet-Draft The GNU Name System July 2019
+
+
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| RR COUNT | EXPIRA- /
@@ -606,18 +642,10 @@ Internet-Draft The GNU Name System July 2019
/ PADDING /
/ /
- Figure 9
+ Figure 10
where:
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 11]
-
-Internet-Draft The GNU Name System July 2019
-
-
RR COUNT A 32-bit value containing the number of variable-length
resource records which are following after this field in network
byte order.
@@ -637,6 +665,15 @@ Internet-Draft The GNU Name System July 2019
records block payload, the key material "K" and initialization vector
"IV" for the symmetric cipher are derived as follows:
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 12]
+
+Internet-Draft The GNU Name System July 2019
+
+
PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk)
K := HKDF-Expand (PRK_k, label, 512 / 8);
@@ -663,16 +700,7 @@ Internet-Draft The GNU Name System July 2019
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 10
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 12]
-
-Internet-Draft The GNU Name System July 2019
-
+ Figure 11
Similarly, we divide "IV" into a 128-bit initialization vector and a
128-bit initialization vector:
@@ -686,7 +714,7 @@ Internet-Draft The GNU Name System July 2019
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 11
+ Figure 12
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
@@ -695,6 +723,13 @@ Internet-Draft The GNU Name System July 2019
RDATA := AES(AES KEY, AES IV, TWOFISH(TWOFISH KEY, TWOFISH IV, BDATA))
BDATA := TWOFISH(TWOFISH KEY, TWOFISH IV, AES(AES KEY, AES IV, RDATA))
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 13]
+
+Internet-Draft The GNU Name System July 2019
+
+
5. Internationalization and Character Encoding
All labels in GNS are encoded in UTF-8 [RFC3629]. This does not
@@ -721,15 +756,6 @@ Internet-Draft The GNU Name System July 2019
If the TLD is a Base32-encoded public zone key "zk", the entry zone
of the resolution process is implicitly given by the name.
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 13]
-
-Internet-Draft The GNU Name System July 2019
-
-
Example name: www.example.<Base32(zk)>
=> Entry zone: zk
=> Name to resolve from entry zone: www.example
@@ -752,6 +778,14 @@ Internet-Draft The GNU Name System July 2019
SHOULD be configurable through the GNS implementation. A mapping has
the form "prefix = public zone key". The prefix may consist of
multiple GNS labels concatenated with a ".". If multiple prefixes
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 14]
+
+Internet-Draft The GNU Name System July 2019
+
+
match the name to resolve, the longest prefix is chosen. The prefix
length of two results cannot be equal, as this would indicate a
misconfiguration.
@@ -778,14 +812,6 @@ Internet-Draft The GNU Name System July 2019
1. Extract the right-most label from the name to look up.
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 14]
-
-Internet-Draft The GNU Name System July 2019
-
-
2. Calculate q using the label and zk.
3. Perform a DHT query GET(q) to retrieve the RRBLOCK.
@@ -808,6 +834,14 @@ Internet-Draft The GNU Name System July 2019
If the remainder of the name to resolve is empty but we have received
a record set containing only a single PKEY record, the recursion is
continued with the PKEY as authoritative zone and the empty apex
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 15]
+
+Internet-Draft The GNU Name System July 2019
+
+
label "@" as remaining name. If the record type to be resolved is
PKEY, the PKEY record set is returned and the resolution is
concluded.
@@ -834,14 +868,6 @@ Internet-Draft The GNU Name System July 2019
appended to the remainder of the name to be resolved, and resolved by
querying the name server(s). Multiple GNS2DNS records may be stored
under the same label, in which case the resolver MUST try all of
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 15]
-
-Internet-Draft The GNU Name System July 2019
-
-
them. However, if multiple GNS2DNS records are present, the DNS name
MUST be identical for all of them.
@@ -860,6 +886,25 @@ Internet-Draft The GNU Name System July 2019
prevent infinite loops, the resolver should implement loop detections
or limit the recursive resolution of CNAMEs using an upper bound.
+6.3.4. BOX
+
+ TODO
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 16]
+
+Internet-Draft The GNU Name System July 2019
+
+
+6.3.5. VPN
+
+ If the queried record type is either A or AAAA and the retrieved
+ record set contains a VPN record, the resolver must open a VPN tunnel
+ (cite someplace? This is difficult to define!) and return the IPv4
+ or IPv6 tunnel address, respectively.
+
7. Zone Revocation
TODO
@@ -891,13 +936,6 @@ Internet-Draft The GNU Name System July 2019
4f213f23ea719eca
17fc32dc410e082e
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 16]
-
-Internet-Draft The GNU Name System July 2019
-
-
h :=
2af3275a9cf90e54
f2dbf7930be76fb9
@@ -908,6 +946,14 @@ Internet-Draft The GNU Name System July 2019
6668e9f684f4dc33
6d656b27392b0fee
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 17]
+
+Internet-Draft The GNU Name System July 2019
+
+
d_h :=
01fb61f482c17633
77611c4c2509e0f3
@@ -946,14 +992,6 @@ Internet-Draft The GNU Name System July 2019
RDATA :=
0000000100059412 RR COUNT | EXPIRA-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 17]
-
-Internet-Draft The GNU Name System July 2019
-
-
09ddea0f00000014 -TION | DATA SIZE (20)
0000000f00000000 TYPE (15=MX) | FLAGS (0)
000a046d61696c07 Priority (10) |4 | mail | 7
@@ -964,6 +1002,14 @@ Internet-Draft The GNU Name System July 2019
00000000
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 18]
+
+Internet-Draft The GNU Name System July 2019
+
+
RRBLOCK :=
055cb070e05fe6de SIGNATURE
ad694a50e5b4dedd
@@ -1003,13 +1049,6 @@ Internet-Draft The GNU Name System July 2019
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 18]
-
-Internet-Draft The GNU Name System July 2019
-
-
[RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The
Advanced Encryption Standard (AES) Cipher Algorithm in the
SNMP User-based Security Model", RFC 3826,
@@ -1018,6 +1057,15 @@ Internet-Draft The GNU Name System July 2019
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 19]
+
+Internet-Draft The GNU Name System July 2019
+
+
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>.
@@ -1058,14 +1106,6 @@ Authors' Addresses
GNUnet e.V.
Boltzmannstrasse 3
85748 Garching
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 19]
-
-Internet-Draft The GNU Name System July 2019
-
-
Germany
Email: schanzen@gnunet.org
@@ -1074,6 +1114,14 @@ Internet-Draft The GNU Name System July 2019
Christian Grothoff
Berner Fachhochschule
Hoeheweg 80
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 20]
+
+Internet-Draft The GNU Name System July 2019
+
+
CH-2501 Biel/Bienne
Switzerland
@@ -1117,4 +1165,12 @@ Internet-Draft The GNU Name System July 2019
-Schanzenbach, et al. Expires 24 January 2020 [Page 20]
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 21]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -360,21 +360,8 @@
<section anchor="gnsrecords_box" numbered="true" toc="default">
<name>BOX</name>
<t>
- In GNS, every "." in a name delegates to another zone, and
- GNS lookups are expected to return all of the required useful
- information in one record set. This is incompatible with the
- special labels used by DNS for SRV and TLSA records. Thus, GNS
- defines the BOX record format to box up SRV and TLSA records and
- include them in the record set of the label they are associated
- with. For example, a
- TLSA record for "_https._tcp.foo.gnu" will be stored in the record set of
- "foo.gnu" as a BOX record with service (SVC) 443 (https) and protocol (PROTO) 6
- (tcp) and record_type "TLSA". When a BOX record is received, a GNS resolver
- must unbox it if the name to be resolved continues with "_SERVICE._PROTO",
- otherwise it is to be left untouched. This way, TLSA (and SRV)
- records do not require a separate network request, and TLSA
- records become inseparable from the corresponding address records.
- A BOX DATA entry has the following format:</t>
+ A BOX DATA entry has the following format:
+ </t>
<figure anchor="figure_boxrecord">
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
@@ -410,6 +397,29 @@
</dd>
</dl>
</section>
+ <section anchor="gnsrecords_vpn" numbered="true" toc="default">
+ <name>VPN</name>
+ <t>
+ A VPN DATA entry has the following format:</t>
+ <figure anchor="figure_vpnrecord">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | TODO DNS NAME |
+ / /
+ / /
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | DNS SERVER NAME |
+ / TODO /
+ / /
+ | |
+ +-----------------------------------------------+
+ ]]></artwork>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+ </section>
+
</section>
<section anchor="publish" numbered="true" toc="default">
@@ -881,6 +891,36 @@
CNAMEs using an upper bound.
</t>
</section>
+ <section anchor="box_processing" numbered="true" toc="default">
+ <name>BOX</name>
+ <t>
+ In GNS, every "." in a name delegates to another zone, and
+ GNS lookups are expected to return all of the required useful
+ information in one record set. This is incompatible with the
+ special labels used by DNS for SRV and TLSA records. Thus, GNS
+ defines the BOX record format to box up SRV and TLSA records and
+ include them in the record set of the label they are associated
+ with. For example, a
+ TLSA record for "_https._tcp.foo.gnu" will be stored in the record set of
+ "foo.gnu" as a BOX record with service (SVC) 443 (https) and protocol (PROTO) 6
+ (tcp) and record_type "TLSA". When a BOX record is received, a GNS resolver
+ must unbox it if the name to be resolved continues with "_SERVICE._PROTO",
+ otherwise it is to be left untouched. This way, TLSA (and SRV)
+ records do not require a separate network request, and TLSA
+ records become inseparable from the corresponding address records.
+ </t>
+ </section>
+ <section anchor="vpn_processing" numbered="true" toc="default">
+ <name>VPN</name>
+ <t>
+ If the queried record type is either A or AAAA and the retrieved
+ record set contains at least one VPN record, the resolver must open a
+ tunnel and return the IPv4 or IPv6 tunnel address, respectively.
+ The type of tunnel depends on the contents of the VPN record data.
+ No result is returned if the resolver implementation does not
+ support any of the tunnnels provided in the VPN records.
+ </t>
+ </section>
</section>
</section>
<section anchor="revocation" numbered="true" toc="default">
