commit 77dd5c2d584225c8615489015c3c3a8299a21113
parent 13817cb561c7363cd75aa47c2a9c376b2c0c4183
Author: Schanzenbach, Martin <mschanzenbach@posteo.de>
Date: Fri, 8 Nov 2019 12:00:39 -0500
update resolution a bit
Diffstat:
3 files changed, 263 insertions(+), 117 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
@@ -1125,6 +1125,17 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.6.2.3">
<p id="section-boilerplate.3-1.6.2.3.1"><a href="#section-6.3" class="xref">6.3</a>. <a href="#name-record-processing" class="xref">Record Processing</a><a href="#section-boilerplate.3-1.6.2.3.1" class="pilcrow">¶</a></p>
+<ul class="toc ulEmpty">
+<li class="toc ulEmpty" id="section-boilerplate.3-1.6.2.3.2.1">
+ <p id="section-boilerplate.3-1.6.2.3.2.1.1"><a href="#section-6.3.1" class="xref">6.3.1</a>. <a href="#name-pkey-2" class="xref">PKEY</a><a href="#section-boilerplate.3-1.6.2.3.2.1.1" class="pilcrow">¶</a></p>
+</li>
+ <li class="toc ulEmpty" id="section-boilerplate.3-1.6.2.3.2.2">
+ <p id="section-boilerplate.3-1.6.2.3.2.2.1"><a href="#section-6.3.2" class="xref">6.3.2</a>. <a href="#name-gns2dns-2" class="xref">GNS2DNS</a><a href="#section-boilerplate.3-1.6.2.3.2.2.1" class="pilcrow">¶</a></p>
+</li>
+ <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>
+ </ul>
</li>
</ul>
</li>
@@ -1383,19 +1394,6 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
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 server(s). GNS2DNS records MAY contain
- numeric IPv4 or IPv6 addresses, allowing the resolver to skip this step.
- The DNS server names may themselves be names in GNS or DNS. If the
- DNS server name ends in ".+", the rest of the name is to be interpreted
- relative to the zone of the GNS2DNS record.
- Then, the DNS name from the GNS2DNS record is appended
- to the remainder of the name to be resolved, and
- resolved by querying the name server(s).
- Multiple
- GNS2DNS records may be stored under the same label, in which case the
- resolver MUST try all of them. However, if multiple GNS2DNS records
- are present, the DNS name MUST be identical for all of them.
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">
@@ -1989,8 +1987,10 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
</h3>
<p id="section-6.3-1">
If the remainder of the name to resolve is not empty, the records
- result MUST consist of a single PKEY record. The recursion is then
- continued with the PKEY record value as new authoritative zone.<a href="#section-6.3-1" class="pilcrow">¶</a></p>
+ result MUST consist of a single PKEY record or one or more GNS2DNS records.
+ The recursion is then continued with the PKEY record value as new
+ authoritative zone or using the specified DNS server(s) as defined
+ int the following.<a href="#section-6.3-1" class="pilcrow">¶</a></p>
<p id="section-6.3-2">
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
@@ -2001,6 +2001,61 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
If the remainder of the name to resolve is empty and the records set
does not consist of a PKEY record, the record set is the result and
the resolution is concluded.<a href="#section-6.3-3" class="pilcrow">¶</a></p>
+<div id="pkey_processing">
+<section id="section-6.3.1">
+ <h4 id="name-pkey-2">
+<a href="#section-6.3.1" class="section-number selfRef">6.3.1. </a><a href="#name-pkey-2" class="section-name selfRef">PKEY</a>
+ </h4>
+<p id="section-6.3.1-1">
+ When a resolver encounters a PKEY record, resolution continues
+ recursively with the remainder of the name in the newly discovered
+ GNS zone as defined in <a href="#entry_zone" class="xref">Section 6.1</a>.<a href="#section-6.3.1-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="gns2dns_processing">
+<section id="section-6.3.2">
+ <h4 id="name-gns2dns-2">
+<a href="#section-6.3.2" class="section-number selfRef">6.3.2. </a><a href="#name-gns2dns-2" class="section-name selfRef">GNS2DNS</a>
+ </h4>
+<p id="section-6.3.2-1">
+ When a resolver encounters a GNS2DNS record it is expected that it first
+ resolves the IP(s) of the DNS specified name server(s). GNS2DNS
+ records MAY contain numeric IPv4 or IPv6 addresses, allowing the
+ resolver to skip this step.
+ The DNS server names may themselves be names in GNS or DNS. If the
+ DNS server name ends in ".+", the rest of the name is to be interpreted
+ relative to the zone of the GNS2DNS record.
+ Then, the DNS name from the GNS2DNS record is appended
+ to the remainder of the name to be resolved, and
+ resolved by querying the name server(s).
+ Multiple
+ GNS2DNS records may be stored under the same label, in which case the
+ resolver MUST try all of them. However, if multiple GNS2DNS records
+ are present, the DNS name MUST be identical for all of them.<a href="#section-6.3.2-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="cname_processing">
+<section id="section-6.3.3">
+ <h4 id="name-cname">
+<a href="#section-6.3.3" class="section-number selfRef">6.3.3. </a><a href="#name-cname" class="section-name selfRef">CNAME</a>
+ </h4>
+<p id="section-6.3.3-1">
+ Upon encountering a CNAME record, the resolver must continue the
+ resolution using the CNAME unless the queried record type is a
+ CNAME and we have reached the leftmost label of the name.
+ Resolution may continue either in GNS if GNS is authoritative of
+ the respective TLD or if the TLD is a relative zone indicator ("+")
+ and we have found the CNAME in a GNS zone.
+ Otherwise, the resolver should continue the resolution recursively
+ through DNS.<a href="#section-6.3.3-1" class="pilcrow">¶</a></p>
+<p id="section-6.3.3-2">
+ The recursive DNS resolution process may yield a CNAME as well
+ which in turn may either point into the DNS or GNS namespace.
+ In order to prevent infinite loops, the resolver should
+ implement loop detections or limit the recursive resolution of
+ CNAMEs using an upper bound.<a href="#section-6.3.3-2" class="pilcrow">¶</a></p>
+</section>
+</div>
</section>
</div>
</section>
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
@@ -77,10 +77,13 @@ Table of Contents
6.1. Entry Zone . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Record Retrieval . . . . . . . . . . . . . . . . . . . . 14
6.3. Record Processing . . . . . . . . . . . . . . . . . . . . 15
- 7. Zone Revocation . . . . . . . . . . . . . . . . . . . . . . . 15
- 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
- 10. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 6.3.1. PKEY . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 6.3.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . 15
+ 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
@@ -103,9 +106,6 @@ Table of Contents
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.
-
@@ -114,6 +114,9 @@ Schanzenbach, et al. Expires 24 January 2020 [Page 2]
Internet-Draft The GNU Name System July 2019
+ some respects as even as an alternative to some of today's Public Key
+ Infrastructures, in particular X.509 for the Web.
+
This document contains the GNU Name System (GNS) technical
specification of the GNU Name System (GNS), a fully decentralized and
censorship-resistant name system. GNS provides a privacy-enhancing
@@ -162,9 +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
@@ -287,19 +287,8 @@ Internet-Draft The GNU Name System July 2019
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 server(s). GNS2DNS records MAY contain numeric IPv4 or IPv6
- addresses, allowing the resolver to skip this step. The DNS server
- names may themselves be names in GNS or DNS. If the DNS server name
- ends in ".+", the rest of the name is to be interpreted relative to
- the zone of the GNS2DNS record. Then, the DNS name from the GNS2DNS
- record is appended to the remainder of the name to be resolved, and
- resolved by querying the name server(s). Multiple GNS2DNS records
- may be stored under the same label, in which case the resolver MUST
- try all of them. However, if multiple GNS2DNS records are present,
- the DNS name MUST be identical for all of them. A GNS2DNS DATA entry
- has the following format:
+ format defined in [RFC1034] for DNS names. A GNS2DNS DATA entry has
+ the following format:
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -327,17 +316,6 @@ Internet-Draft The GNU Name System July 2019
single resource record with an IPv4 or IPv6 address. A LEHO 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
+-----+-----+-----+-----+-----+-----+-----+-----+
| LEGACY HOSTNAME |
@@ -352,6 +330,14 @@ Internet-Draft The GNU Name System July 2019
(e.g. "Host:" header) it must be converted to a punycode
representation [RFC5891].
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 6]
+
+Internet-Draft The GNU Name System July 2019
+
+
3.4. NICK
Nickname records can be used by zone administrators to publish an
@@ -386,14 +372,6 @@ Internet-Draft The GNU Name System July 2019
(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
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 7]
-
-Internet-Draft The GNU Name System July 2019
-
-
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
@@ -409,6 +387,13 @@ 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
@@ -443,13 +428,6 @@ Internet-Draft The GNU Name System July 2019
zk_h := h mod L * zk
q := SHA512 (zk_h)
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 8]
-
-Internet-Draft The GNU Name System July 2019
-
-
We use a hash-based key derivation function (HKDF) as defined in
[RFC5869]. We use HMAC-SHA512 for the extraction phase and HMAC-
SHA256 for the expansion phase.
@@ -463,6 +441,15 @@ 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.
@@ -501,6 +488,19 @@ Internet-Draft The GNU Name System July 2019
+
+
+
+
+
+
+
+
+
+
+
+
+
Schanzenbach, et al. Expires 24 January 2020 [Page 9]
Internet-Draft The GNU Name System July 2019
@@ -800,8 +800,10 @@ Internet-Draft The GNU Name System July 2019
6.3. Record Processing
If the remainder of the name to resolve is not empty, the records
- result MUST consist of a single PKEY record. The recursion is then
- continued with the PKEY record value as new authoritative zone.
+ result MUST consist of a single PKEY record or one or more GNS2DNS
+ records. The recursion is then continued with the PKEY record value
+ as new authoritative zone or using the specified DNS server(s) as
+ defined int the following.
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
@@ -814,6 +816,50 @@ Internet-Draft The GNU Name System July 2019
does not consist of a PKEY record, the record set is the result and
the resolution is concluded.
+6.3.1. PKEY
+
+ When a resolver encounters a PKEY record, resolution continues
+ recursively with the remainder of the name in the newly discovered
+ GNS zone as defined in Section 6.1.
+
+6.3.2. GNS2DNS
+
+ When a resolver encounters a GNS2DNS record it is expected that it
+ first resolves the IP(s) of the DNS specified name server(s).
+ GNS2DNS records MAY contain numeric IPv4 or IPv6 addresses, allowing
+ the resolver to skip this step. The DNS server names may themselves
+ be names in GNS or DNS. If the DNS server name ends in ".+", the
+ rest of the name is to be interpreted relative to the zone of the
+ GNS2DNS record. Then, the DNS name from the GNS2DNS record is
+ appended to the remainder of the name to be resolved, and resolved by
+ querying the name server(s). 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.
+
+6.3.3. CNAME
+
+ Upon encountering a CNAME record, the resolver must continue the
+ resolution using the CNAME unless the queried record type is a CNAME
+ and we have reached the leftmost label of the name. Resolution may
+ continue either in GNS if GNS is authoritative of the respective TLD
+ or if the TLD is a relative zone indicator ("+") and we have found
+ the CNAME in a GNS zone. Otherwise, the resolver should continue the
+ resolution recursively through DNS.
+
+ The recursive DNS resolution process may yield a CNAME as well which
+ in turn may either point into the DNS or GNS namespace. In order to
+ prevent infinite loops, the resolver should implement loop detections
+ or limit the recursive resolution of CNAMEs using an upper bound.
+
7. Zone Revocation
TODO
@@ -831,17 +877,6 @@ Internet-Draft The GNU Name System July 2019
The following represents a test vector for a record of type MX with a
priority of 10 and the mail hostname mail.example.com.
-
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 15]
-
-Internet-Draft The GNU Name System July 2019
-
-
label := "mail"
d :=
@@ -856,6 +891,13 @@ 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
@@ -890,14 +932,6 @@ Internet-Draft The GNU Name System July 2019
AES_IV :=
a808b929bc9fad7a
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 16]
-
-Internet-Draft The GNU Name System July 2019
-
-
686bbe3432bed77a
TWOFISH_KEY :=
@@ -912,6 +946,14 @@ 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
@@ -947,13 +989,6 @@ Internet-Draft The GNU Name System July 2019
001fd19a6406a721
713f0a0d
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 17]
-
-Internet-Draft The GNU Name System July 2019
-
-
11. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
@@ -968,6 +1003,13 @@ 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,
@@ -1002,14 +1044,6 @@ Internet-Draft The GNU Name System July 2019
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 18]
-
-Internet-Draft The GNU Name System July 2019
-
-
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
@@ -1024,6 +1058,14 @@ 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
@@ -1061,4 +1103,18 @@ Authors' Addresses
-Schanzenbach, et al. Expires 24 January 2020 [Page 19]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 20]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -280,19 +280,6 @@
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
<xref target="RFC1034" /> for DNS names.
- If a resolver encounters a GNS2DNS record it is expected that it first
- resolves the IP(s) of the DNS server(s). GNS2DNS records MAY contain
- numeric IPv4 or IPv6 addresses, allowing the resolver to skip this step.
- The DNS server names may themselves be names in GNS or DNS. If the
- DNS server name ends in ".+", the rest of the name is to be interpreted
- relative to the zone of the GNS2DNS record.
- Then, the DNS name from the GNS2DNS record is appended
- to the remainder of the name to be resolved, and
- resolved by querying the name server(s).
- Multiple
- GNS2DNS records may be stored under the same label, in which case the
- resolver MUST try all of them. However, if multiple GNS2DNS records
- are present, the DNS name MUST be identical for all of them.
A GNS2DNS DATA entry has the following format:</t>
<figure anchor="figure_gns2dnsrecord">
<artwork name="" type="" align="left" alt=""><