commit d65dab1c115fbe4bba036280222d9fa1045d2326
parent 841d7e4a855e6223d9d41ed7743b8b8d51fa07b9
Author: Schanzenbach, Martin <mschanzenbach@posteo.de>
Date: Fri, 4 Oct 2019 10:41:54 +0200
add box record
Diffstat:
3 files changed, 262 insertions(+), 91 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
@@ -1092,6 +1092,9 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<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>
+</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.4">
@@ -1225,8 +1228,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
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 and link to the DNS
- record type registry.<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.1-4.6" class="pilcrow">¶</a>
</dd>
<dt id="section-3.1-4.7">FLAGS</dt>
<dd id="section-3.1-4.8">
@@ -1374,6 +1376,60 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
</div>
</section>
</div>
+<div id="gnsrecords_box">
+<section id="section-3.5">
+ <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>
+ </h3>
+<p id="section-3.5-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
+ (tcp) and record_type "TLSA". When a BOX record is received, a GNS resolver
+ must unbox it if the name contained "_SERVICE._PROTO", otherwise it is
+ 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>
+<div id="figure_boxrecord">
+<figure id="figure-6">
+ <div class="artwork art-text alignLeft" id="section-3.5-2.1">
+<pre>
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ |PROTO| SVC | TYPE |
+ +-----------+-----------------------------------+
+ | RECORD |
+ / /
+ / /
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ </pre>
+</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>
+</dd>
+ <dt id="section-3.5-3.3">SVC</dt>
+ <dd id="section-3.5-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>
+</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>
+</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>
+</dd>
+ </dl>
+</section>
+</div>
</section>
</div>
<div id="publish">
@@ -1464,7 +1520,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
encryption scheme.
A GNS resource records block has the following format:<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<div id="figure_record_block">
-<figure id="figure-6">
+<figure id="figure-7">
<div class="artwork art-text alignLeft" id="section-4.2-2.1">
<pre>
0 8 16 24 32 40 48 56
@@ -1493,7 +1549,7 @@ 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>
<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">
@@ -1527,7 +1583,10 @@ 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.
This is a 64-bit absolute date in microseconds since midnight
(0 hour), January 1, 1970 in network byte order.<a href="#section-4.2-4.10" class="pilcrow">¶</a>
</dd>
@@ -1588,7 +1647,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
We divide the resulting keying material "K" into a 256-bit AES key
"Kaes" and a 256-bit TWOFISH key "Ktwo":<a href="#section-4.3-3" class="pilcrow">¶</a></p>
<div id="figure_hkdf_keys">
-<figure id="figure-7">
+<figure id="figure-8">
<div class="artwork art-text alignLeft" id="section-4.3-4.1">
<pre>
0 8 16 24 32 40 48 56
@@ -1605,13 +1664,13 @@ 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>
<p id="section-4.3-5">
Similarly, we divide "IV" into a 128-bit initialization vector IVaes
and a 128-bit initialization vector IVtwo:<a href="#section-4.3-5" class="pilcrow">¶</a></p>
<div id="figure_hkdf_ivs">
-<figure id="figure-8">
+<figure id="figure-9">
<div class="artwork art-text alignLeft" id="section-4.3-6.1">
<pre>
0 8 16 24 32 40 48 56
@@ -1624,7 +1683,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.3-7">
The symmetric keys and IVs are used for a AES+TWOFISH combined
@@ -1638,7 +1697,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<p id="section-4.3-9">
The decrypted RDATA has the following format:<a href="#section-4.3-9" 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-10.1">
<pre>
0 8 16 24 32 40 48 56
@@ -1664,7 +1723,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-11">where:<a href="#section-4.3-11" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-4.3-12">
@@ -1732,7 +1791,9 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<h2 id="name-test-vectors">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-test-vectors" class="section-name selfRef">Test Vectors</a>
</h2>
-<p id="section-10-1"><a href="#section-10-1" class="pilcrow">¶</a></p>
+<p id="section-10-1">
+ The following represents a test vector for a record of type MX with
+ a priority of 10 and the mail hostname mail.example.com.<a href="#section-10-1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-10-2">
<pre>
label := "mail"
@@ -1883,6 +1944,9 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<dt id="RFC5890">[RFC5890]</dt>
<dd>
<span class="refAuthor">Klensin, J.</span>, <span class="refTitle">"Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework"</span>, <span class="seriesInfo">RFC 5890</span>, <span class="seriesInfo">DOI 10.17487/RFC5890</span>, <time datetime="2010-08">August 2010</time>, <span><<a href="https://www.rfc-editor.org/info/rfc5890">https://www.rfc-editor.org/info/rfc5890</a>></span>. </dd>
+<dt id="RFC6895">[RFC6895]</dt>
+ <dd>
+<span class="refAuthor">Eastlake 3rd, D.</span>, <span class="refTitle">"Domain Name System (DNS) IANA Considerations"</span>, <span class="seriesInfo">BCP 42</span>, <span class="seriesInfo">RFC 6895</span>, <span class="seriesInfo">DOI 10.17487/RFC6895</span>, <time datetime="2013-04">April 2013</time>, <span><<a href="https://www.rfc-editor.org/info/rfc6895">https://www.rfc-editor.org/info/rfc6895</a>></span>. </dd>
<dt id="RFC6979">[RFC6979]</dt>
<dd>
<span class="refAuthor">Pornin, T.</span>, <span class="refTitle">"
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
@@ -62,23 +62,24 @@ Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
- 3. Resource records . . . . . . . . . . . . . . . . . . . . . . 3
+ 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
4. Publishing records . . . . . . . . . . . . . . . . . . . . . 6
4.1. Key derivations . . . . . . . . . . . . . . . . . . . . . 6
4.2. Resource records block . . . . . . . . . . . . . . . . . 7
- 4.3. Block data encryption and decryption . . . . . . . . . . 8
- 5. Internationalization and Character Encoding . . . . . . . . . 10
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
- 7. Record Resolution . . . . . . . . . . . . . . . . . . . . . . 10
- 8. Namespace Revocation . . . . . . . . . . . . . . . . . . . . 11
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
- 10. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 11
- 11. Normative References . . . . . . . . . . . . . . . . . . . . 13
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
+ 4.3. Block data encryption and decryption . . . . . . . . . . 9
+ 5. Internationalization and Character Encoding . . . . . . . . . 11
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
+ 7. Record Resolution . . . . . . . . . . . . . . . . . . . . . . 11
+ 8. Namespace Revocation . . . . . . . . . . . . . . . . . . . . 12
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
+ 10. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 11. Normative References . . . . . . . . . . . . . . . . . . . . 14
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
@@ -103,8 +104,7 @@ Table of Contents
Records published in the zone are signed using a private key derived
from "d" as described in Section 4.
-
-
+3. Resource records
@@ -114,8 +114,6 @@ Schanzenbach, et al. Expires 24 January 2020 [Page 2]
Internet-Draft The GNU Name System July 2019
-3. Resource records
-
3.1. Wire format
A GNS resource record holds the data of a specific record in a zone.
@@ -154,13 +152,15 @@ Internet-Draft The GNU Name System July 2019
defined in [RFC1035] 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 and link to the DNS record type registry.
+ via IANA ([RFC6895]).
FLAGS Resource record flags.
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.
@@ -170,9 +170,6 @@ Schanzenbach, et al. Expires 24 January 2020 [Page 3]
Internet-Draft The GNU Name System July 2019
- PADDING The padding MUST contain the 0 value in all octets. Not
- applicable for PKEY records.
-
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
@@ -221,6 +218,9 @@ Internet-Draft The GNU Name System July 2019
+
+
+
Schanzenbach, et al. Expires 24 January 2020 [Page 4]
Internet-Draft The GNU Name System July 2019
@@ -282,6 +282,39 @@ Schanzenbach, et al. Expires 24 January 2020 [Page 5]
Internet-Draft The GNU Name System July 2019
+3.5. 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
+ BOX record with service 443 (https) and protocol 6 (tcp) and
+ record_type "TLSA". When a BOX record is received, a GNS resolver
+ must unbox it if the name contained "_SERVICE._PROTO", otherwise it
+ is 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:
+
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ |PROTO| SVC | TYPE |
+ +-----------+-----------------------------------+
+ | RECORD |
+ / /
+ / /
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+
+ Figure 6
+
+ PROTO the protocol number, e.g. 6 for tcp. In network byte order.
+
+ SVC the service of the boxed record, i.e. the port number. In
+ network byte order.
+
+ TYPE Record type of the boxed record. In network byte order.
+
+ RECORD The boxed record in a format as defined in Section 3.1.
+
4. Publishing records
GNS resource records are published in a distributed hash table (DHT).
@@ -293,6 +326,18 @@ 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
@@ -328,22 +373,26 @@ 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".
+4.2. Resource records block
+ GNS records are grouped by their labels and published as a single
+ block in the DHT. The contained resource records are encrypted using
+ a symmetric encryption scheme. A GNS resource records block has the
+ following format:
-Schanzenbach, et al. Expires 24 January 2020 [Page 6]
-
-Internet-Draft The GNU Name System July 2019
-4.2. Resource records block
- GNS records are grouped by their labels and published as a single
- block in the DHT. The contained resource records are encrypted using
- a symmetric encryption scheme. A GNS resource records block 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
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -370,7 +419,7 @@ Internet-Draft The GNU Name System July 2019
/ |
+-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 6
+ Figure 7
where:
@@ -385,15 +434,6 @@ Internet-Draft The GNU Name System July 2019
SIZE A 32-bit value containing the length of the signed data
following the PUBLIC KEY field in network byte order. This value
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 7]
-
-Internet-Draft The GNU Name System July 2019
-
-
always includes the length of the fields SIZE (4), PURPOSE (4) and
EXPIRATION (8) in addition to the length of the BDATA.
@@ -402,9 +442,20 @@ Internet-Draft The GNU Name System July 2019
EXPIRATION The resource records block expiration time. This is the
expiration time of the resource record contained within this block
- with the smallest expiration time. This is a 64-bit absolute date
- in microseconds since midnight (0 hour), January 1, 1970 in
- network byte order.
+
+
+
+Schanzenbach, et al. Expires 24 January 2020 [Page 8]
+
+Internet-Draft The GNU Name System July 2019
+
+
+ with the 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. This is a 64-bit absolute date in
+ microseconds since midnight (0 hour), January 1, 1970 in network
+ byte order.
BDATA The encrypted resource records with a total size of SIZE - 16.
@@ -441,15 +492,6 @@ Internet-Draft The GNU Name System July 2019
K := HKDF-Expand (PRK_k, label, 512 / 8);
IV := HKDF-Expand (PRK_iv, label, 256 / 8)
-
-
-
-
-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. The output keying material is 64
@@ -457,6 +499,13 @@ Internet-Draft The GNU Name System July 2019
the initialization vector. We divide the resulting keying material
"K" into a 256-bit AES key "Kaes" and a 256-bit TWOFISH key "Ktwo":
+
+
+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
+-----+-----+-----+-----+-----+-----+-----+-----+
| AES KEY (Kaes) |
@@ -470,7 +519,7 @@ Internet-Draft The GNU Name System July 2019
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 7
+ Figure 8
Similarly, we divide "IV" into a 128-bit initialization vector IVaes
and a 128-bit initialization vector IVtwo:
@@ -484,7 +533,7 @@ Internet-Draft The GNU Name System July 2019
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
- Figure 8
+ Figure 9
The symmetric keys and IVs are used for a AES+TWOFISH combined
cipher. Both ciphers are used in Cipher FeedBack (CFB) mode.
@@ -501,7 +550,14 @@ 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
@@ -528,7 +584,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
@@ -572,6 +628,8 @@ Internet-Draft The GNU Name System July 2019
10. Test Vectors
+ The following represents a test vector for a record of type MX with a
+ priority of 10 and the mail hostname mail.example.com.
label := "mail"
@@ -609,15 +667,14 @@ Internet-Draft The GNU Name System July 2019
6e325e54b93c8576
9182810f92fad776
- q (query key) :=
-
-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
+ q (query key) :=
81d65adced4dce6f
3b7e7610339ae2f4
bae26c271bbc388b
@@ -665,15 +722,15 @@ Internet-Draft The GNU Name System July 2019
e80818d0a84059a8
5eee901a66459e5e
3d1a10b29a5b8354
- 1b58636781166b9a
-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
+ 1b58636781166b9a
642920eee8e7a65a
001fd19a6406a721
713f0a0d
@@ -720,16 +777,18 @@ Internet-Draft The GNU Name System July 2019
<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>.
-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
+ specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
+ November 1987, <https://www.rfc-editor.org/info/rfc1035>.
+
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
@@ -744,6 +803,10 @@ Internet-Draft The GNU Name System July 2019
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>.
+ [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>.
+
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
Algorithm (DSA) and Elliptic Curve Digital Signature
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
@@ -771,27 +834,24 @@ Authors' Addresses
85748 Garching
Germany
- Email: schanzen@gnunet.org
-
-
- Bernd Fix
- GNUnet e.V.
- Boltzmannstrasse 3
- 85748 Garching
-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
- Germany
-
Email: schanzen@gnunet.org
+ Bernd Fix
+ GNUnet e.V.
+ Boltzmannstrasse 3
+ 85748 Garching
+ Germany
+ Email: schanzen@gnunet.org
@@ -833,8 +893,4 @@ 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]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -142,8 +142,7 @@
type as defined in <xref target="RFC1035" /> 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 and link to the DNS
- record type registry.
+ below 2^16 are reserved for allocation via IANA (<xref target="RFC6895" />).
</dd>
<dt>FLAGS</dt>
<dd>
@@ -268,6 +267,54 @@
<!-- <postamble>which is a very simple example.</postamble>-->
</figure>
</section>
+<section anchor="gnsrecords_box" numbered="true" toc="default">
+ <name>BOX</name>
+ <t>
+ 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
+ (tcp) and record_type "TLSA". When a BOX record is received, a GNS resolver
+ must unbox it if the name contained "_SERVICE._PROTO", otherwise it is
+ 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:</t>
+ <figure anchor="figure_boxrecord">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ 0 8 16 24 32 40 48 56
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ | PROTO | SVC | TYPE |
+ +-----------+-----------------------------------+
+ | RECORD |
+ / /
+ / /
+ | |
+ +-----+-----+-----+-----+-----+-----+-----+-----+
+ ]]></artwork>
+ <!-- <postamble>which is a very simple example.</postamble>-->
+ </figure>
+ <dl>
+ <dt>PROTO</dt>
+ <dd>
+ the protocol number, e.g. 6 for tcp. In network byte order.
+ </dd>
+ <dt>SVC</dt>
+ <dd>
+ the service of the boxed record, i.e. the port number. In network
+ byte order.
+ </dd>
+ <dt>TYPE</dt>
+ <dd>
+ Record type of the boxed record. In network byte order.
+ </dd>
+ <dt>RECORD</dt>
+ <dd>
+ The boxed record in a format as defined in
+ <xref target="rrecords_wire" />.
+ </dd>
+ </dl>
+</section>
+
</section>
@@ -409,7 +456,10 @@
<dd>
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.
This is a 64-bit absolute date in microseconds since midnight
(0 hour), January 1, 1970 in network byte order.
</dd>
@@ -770,6 +820,7 @@
<seriesInfo name="RFC" value="8032"/>
<seriesInfo name="DOI" value="10.17487/RFC8032"/>
</reference>
+ <reference anchor="RFC6895" target="https://www.rfc-editor.org/info/rfc6895"><front><title>Domain Name System (DNS) IANA Considerations</title><author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3rd"><organization/></author><date year="2013" month="April"/><abstract><t>This document specifies Internet Assigned Numbers Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597.</t></abstract></front><seriesInfo name="BCP" value="42"/><seriesInfo name="RFC" value="6895"/><seriesInfo name="DOI" value="10.17487/RFC6895"/></reference>
<reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc1034"><front><title>Domain names - concepts and facilities</title><author initials="P.V." surname="Mockapetris" fullname="P.V. Mockapetris"><organization/></author><date year="1987" month="November"/><abstract><t>This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them.</t></abstract></front><seriesInfo name="STD" value="13"/><seriesInfo name="RFC" value="1034"/><seriesInfo name="DOI" value="10.17487/RFC1034"/></reference>
<reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1035">
<front>
