[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] [lsd0001] branch master updated: add box record
|
From: |
gnunet |
|
Subject: |
[GNUnet-SVN] [lsd0001] branch master updated: add box record |
|
Date: |
Fri, 04 Oct 2019 10:44:05 +0200 |
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 d65dab1 add box record
d65dab1 is described below
commit d65dab1c115fbe4bba036280222d9fa1045d2326
Author: Schanzenbach, Martin <address@hidden>
AuthorDate: Fri Oct 4 10:41:54 2019 +0200
add box record
---
draft-schanzen-gns.html | 88 +++++++++++++++++---
draft-schanzen-gns.txt | 208 ++++++++++++++++++++++++++++++------------------
draft-schanzen-gns.xml | 57 ++++++++++++-
3 files changed, 262 insertions(+), 91 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index 04c995d..7d9f651 100644
--- a/draft-schanzen-gns.html
+++ b/draft-schanzen-gns.html
@@ -1091,6 +1091,9 @@ async function addMetadata(){try{const
e=document.styleSheets[0].cssRules;for(le
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.3.2.4">
<p id="section-boilerplate.3-1.3.2.4.1"><a href="#section-3.4"
class="xref">3.4</a>. <a href="#name-leho" class="xref">LEHO</a><a
href="#section-boilerplate.3-1.3.2.4.1" class="pilcrow">¶</a></p>
+</li>
+ <li class="toc ulEmpty" id="section-boilerplate.3-1.3.2.5">
+ <p id="section-boilerplate.3-1.3.2.5.1"><a href="#section-3.5"
class="xref">3.5</a>. <a href="#name-box" class="xref">BOX</a><a
href="#section-boilerplate.3-1.3.2.5.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
@@ -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
index 592b229..2dcdb78 100644
--- 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: address@hidden
-
-
- 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: address@hidden
+ Bernd Fix
+ GNUnet e.V.
+ Boltzmannstrasse 3
+ 85748 Garching
+ Germany
+ Email: address@hidden
@@ -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
index 4d003dd..3330f54 100644
--- 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, erro
[...]
<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
forwardin [...]
<reference anchor="RFC1035"
target="https://www.rfc-editor.org/info/rfc1035";>
<front>
--
To stop receiving notification emails like this one, please contact
address@hidden.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [GNUnet-SVN] [lsd0001] branch master updated: add box record,
gnunet <=