lsd0001

LSD0001: GNU Name System
Log | Files | Refs | README

commit 3ac66657c0b978ef6b4f538a2cd3b9200ec65097
parent 50248ef20609e793355f92cd76d25f381803a72e
Author: Schanzenbach, Martin <mschanzenbach@posteo.de>
Date:   Sat,  5 Oct 2019 10:52:54 +0200

add nick

Diffstat:
Mdraft-schanzen-gns.html | 92++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------------
Mdraft-schanzen-gns.txt | 266++++++++++++++++++++++++++++++++++++++++++++++++-------------------------------
Mdraft-schanzen-gns.xml | 26++++++++++++++++++++++++++
3 files changed, 250 insertions(+), 134 deletions(-)

diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html @@ -1090,7 +1090,10 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le <p id="section-boilerplate.3-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-leho" class="xref">LEHO</a><a href="#section-boilerplate.3-1.3.2.3.1" class="pilcrow">¶</a></p> </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-box" class="xref">BOX</a><a href="#section-boilerplate.3-1.3.2.4.1" class="pilcrow">¶</a></p> + <p id="section-boilerplate.3-1.3.2.4.1"><a href="#section-3.4" class="xref">3.4</a>.  <a href="#name-nick" class="xref">NICK</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> @@ -1451,12 +1454,43 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le <span>[<a href="#RFC3492" class="xref">RFC3492</a>]</span>.<a href="#section-3.3-3" class="pilcrow">¶</a></p> </section> </div> -<div id="gnsrecords_box"> +<div id="gnsrecords_nick"> <section id="section-3.4"> + <h3 id="name-nick"> +<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-nick" class="section-name selfRef">NICK</a> + </h3> +<p id="section-3.4-1">Nickname records can be used by zone administrators to publish an + indication on what label this zone prefers to be referred to. + This is a suggestion to other zones what label to use when creating a + PKEY <a href="#gnsrecords_pkey" class="xref">Section 3.1</a> record containing this zone's + public zone key. + A NICK resource record contains an UTF-8 string + (which is not 0-terminated) representing the preferred label. + This string may NOT inlcude a ".". + A NICK DATA entry has the following format:<a href="#section-3.4-1" class="pilcrow">¶</a></p> +<div id="figure_nickrecord"> +<figure id="figure-6"> + <div class="artwork art-text alignLeft" id="section-3.4-2.1"> +<pre> + 0 8 16 24 32 40 48 56 + +-----+-----+-----+-----+-----+-----+-----+-----+ + | NICKNAME | + / / + / / + | | + +-----+-----+-----+-----+-----+-----+-----+-----+ + </pre> +</div> +<figcaption><a href="#figure-6" class="selfRef">Figure 6</a></figcaption></figure> +</div> +</section> +</div> +<div id="gnsrecords_box"> +<section id="section-3.5"> <h3 id="name-box"> -<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-box" class="section-name selfRef">BOX</a> +<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.4-1"> +<p id="section-3.5-1"> 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 @@ -1471,10 +1505,10 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le 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:<a href="#section-3.4-1" class="pilcrow">¶</a></p> + 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.4-2.1"> +<figure id="figure-7"> + <div class="artwork art-text alignLeft" id="section-3.5-2.1"> <pre> 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ @@ -1487,26 +1521,26 @@ 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> -<dl class="dlParallel" id="section-3.4-3"> - <dt id="section-3.4-3.1">PROTO</dt> - <dd id="section-3.4-3.2"> - the 16-bit protocol number, e.g. 6 for tcp. In network byte order.<a href="#section-3.4-3.2" class="pilcrow">¶</a> +<dl class="dlParallel" id="section-3.5-3"> + <dt id="section-3.5-3.1">PROTO</dt> + <dd id="section-3.5-3.2"> + the 16-bit protocol number, e.g. 6 for tcp. In network byte order.<a href="#section-3.5-3.2" class="pilcrow">¶</a> </dd> - <dt id="section-3.4-3.3">SVC</dt> - <dd id="section-3.4-3.4"> + <dt id="section-3.5-3.3">SVC</dt> + <dd id="section-3.5-3.4"> the 16-bit service value of the boxed record, i.e. the port number. - In network byte order.<a href="#section-3.4-3.4" class="pilcrow">¶</a> + In network byte order.<a href="#section-3.5-3.4" class="pilcrow">¶</a> </dd> - <dt id="section-3.4-3.5">TYPE</dt> - <dd id="section-3.4-3.6"> - is the 32-bit record type of the boxed record. In network byte order.<a href="#section-3.4-3.6" class="pilcrow">¶</a> + <dt id="section-3.5-3.5">TYPE</dt> + <dd id="section-3.5-3.6"> + is the 32-bit record type of the boxed record. In network byte order.<a href="#section-3.5-3.6" class="pilcrow">¶</a> </dd> - <dt id="section-3.4-3.7">RECORD DATA</dt> - <dd id="section-3.4-3.8"> + <dt id="section-3.5-3.7">RECORD DATA</dt> + <dd id="section-3.5-3.8"> is a variable length field containing the "DATA" format of TYPE as - defined for the respective TYPE in DNS.<a href="#section-3.4-3.8" class="pilcrow">¶</a> + defined for the respective TYPE in DNS.<a href="#section-3.5-3.8" class="pilcrow">¶</a> </dd> </dl> </section> @@ -1606,7 +1640,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le include a periodic refresh publication. 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-7"> +<figure id="figure-8"> <div class="artwork art-text alignLeft" id="section-4.2-2.1"> <pre> 0 8 16 24 32 40 48 56 @@ -1635,7 +1669,7 @@ 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.2-3">where:<a href="#section-4.2-3" class="pilcrow">¶</a></p> <dl class="dlParallel" id="section-4.2-4"> @@ -1698,7 +1732,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le set RDATA into the BDATA field of a GNS record block. 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-8"> +<figure id="figure-9"> <div class="artwork art-text alignLeft" id="section-4.3-2.1"> <pre> 0 8 16 24 32 40 48 56 @@ -1726,7 +1760,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-3">where:<a href="#section-4.3-3" class="pilcrow">¶</a></p> <dl class="dlParallel" id="section-4.3-4"> @@ -1785,7 +1819,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-8" class="pilcrow">¶</a></p> <div id="figure_hkdf_keys"> -<figure id="figure-9"> +<figure id="figure-10"> <div class="artwork art-text alignLeft" id="section-4.3-9.1"> <pre> 0 8 16 24 32 40 48 56 @@ -1802,13 +1836,13 @@ 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-10"> Similarly, we divide "IV" into a 128-bit initialization vector and a 128-bit initialization vector:<a href="#section-4.3-10" class="pilcrow">¶</a></p> <div id="figure_hkdf_ivs"> -<figure id="figure-10"> +<figure id="figure-11"> <div class="artwork art-text alignLeft" id="section-4.3-11.1"> <pre> 0 8 16 24 32 40 48 56 @@ -1821,7 +1855,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le +-----+-----+-----+-----+-----+-----+-----+-----+ </pre> </div> -<figcaption><a href="#figure-10" class="selfRef">Figure 10</a></figcaption></figure> +<figcaption><a href="#figure-11" class="selfRef">Figure 11</a></figcaption></figure> </div> <p id="section-4.3-12"> The keys and IVs are used for a CFB128-AES-256 and diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt @@ -66,19 +66,20 @@ Table of Contents 3.1. PKEY . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. LEHO . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.4. BOX . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.4. NICK . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.5. BOX . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Publishing records . . . . . . . . . . . . . . . . . . . . . 8 4.1. Key derivations . . . . . . . . . . . . . . . . . . . . . 8 4.2. Resource records block . . . . . . . . . . . . . . . . . 9 - 4.3. Block data encryption and decryption . . . . . . . . . . 10 + 4.3. Block data encryption and decryption . . . . . . . . . . 11 5. Internationalization and Character Encoding . . . . . . . . . 13 6. Record Resolution . . . . . . . . . . . . . . . . . . . . . . 13 - 6.1. Entry Zone . . . . . . . . . . . . . . . . . . . . . . . 13 - 6.2. Recursive Resolution . . . . . . . . . . . . . . . . . . 13 - 7. Namespace Revocation . . . . . . . . . . . . . . . . . . . . 13 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 10. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 13 + 6.1. Entry Zone . . . . . . . . . . . . . . . . . . . . . . . 14 + 6.2. Recursive Resolution . . . . . . . . . . . . . . . . . . 14 + 7. Namespace Revocation . . . . . . . . . . . . . . . . . . . . 14 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 10. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 14 11. Normative References . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 @@ -104,8 +105,7 @@ Table of Contents 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 + @@ -114,6 +114,8 @@ Schanzenbach, et al. Expires 24 January 2020 [Page 2] Internet-Draft The GNU Name System July 2019 + 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 alternative to the Domain Name System (DNS). The design of GNS incorporates the capability to integrate and coexist with DNS. GNS @@ -163,8 +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 @@ -352,7 +352,27 @@ Internet-Draft The GNU Name System July 2019 (e.g. "Host:" header) it must be converted to a punycode representation [RFC3492]. -3.4. BOX +3.4. NICK + + Nickname records can be used by zone administrators to publish an + indication on what label this zone prefers to be referred to. This + is a suggestion to other zones what label to use when creating a PKEY + Section 3.1 record containing this zone's public zone key. A NICK + resource record contains an UTF-8 string (which is not 0-terminated) + representing the preferred label. This string may NOT inlcude a ".". + A NICK DATA entry has the following format: + + 0 8 16 24 32 40 48 56 + +-----+-----+-----+-----+-----+-----+-----+-----+ + | NICKNAME | + / / + / / + | | + +-----+-----+-----+-----+-----+-----+-----+-----+ + + Figure 6 + +3.5. BOX In GNS, every "." in a name delegates to another zone, and GNS lookups are expected to return all of the required useful information @@ -366,6 +386,14 @@ Internet-Draft The GNU Name System July 2019 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 + + + +Schanzenbach, et al. Expires 24 January 2020 [Page 7] + +Internet-Draft The GNU Name System July 2019 + + separate network request, and TLSA records become inseparable from the corresponding address records. A BOX DATA entry has the following format: @@ -380,20 +408,11 @@ Internet-Draft The GNU Name System July 2019 | | +-----+-----+-----+-----+-----+-----+-----+-----+ - Figure 6 + Figure 7 PROTO the 16-bit protocol number, e.g. 6 for tcp. In network byte order. - - - - -Schanzenbach, et al. Expires 24 January 2020 [Page 7] - -Internet-Draft The GNU Name System July 2019 - - SVC the 16-bit service value of the boxed record, i.e. the port number. In network byte order. @@ -422,6 +441,15 @@ Internet-Draft The GNU Name System July 2019 q := SHA512 (zk_h) We use a hash-based key derivation function (HKDF) as defined in + + + + +Schanzenbach, et al. Expires 24 January 2020 [Page 8] + +Internet-Draft The GNU Name System July 2019 + + [RFC5869]. We use HMAC-SHA512 for the extraction phase and HMAC- SHA256 for the expansion phase. @@ -443,13 +471,6 @@ Internet-Draft The GNU Name System July 2019 zk_h is a 256-bit public key derived from the zone key "zk" using the keying material "h". - - -Schanzenbach, et al. Expires 24 January 2020 [Page 8] - -Internet-Draft The GNU Name System July 2019 - - L is the prime-order subgroup as defined in Section 2. q Is the 512-bit DHT key under which the resource records block is @@ -470,6 +491,21 @@ Internet-Draft The GNU Name System July 2019 refresh publication. A GNS resource records block 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 | @@ -495,17 +531,10 @@ Internet-Draft The GNU Name System July 2019 / | +-----+-----+-----+-----+-----+-----+-----+-----+ - Figure 7 + Figure 8 where: - - -Schanzenbach, et al. Expires 24 January 2020 [Page 9] - -Internet-Draft The GNU Name System July 2019 - - SIGNATURE A 512-bit ECDSA deterministic signature compliant with [RFC6979]. The signature is computed over the data following the PUBLIC KEY field. The signature is created using the derived @@ -526,6 +555,13 @@ 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 resource records block 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- @@ -546,22 +582,6 @@ Internet-Draft The GNU Name System July 2019 set RDATA into the BDATA field of a GNS record block. The wire format of the RDATA looks as follows: - - - - - - - - - - - -Schanzenbach, et al. Expires 24 January 2020 [Page 10] - -Internet-Draft The GNU Name System July 2019 - - 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | RR COUNT | EXPIRA- / @@ -586,10 +606,18 @@ Internet-Draft The GNU Name System July 2019 / PADDING / / / - Figure 8 + Figure 9 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. @@ -609,15 +637,6 @@ Internet-Draft The GNU Name System July 2019 then use "zk_h" to compute "q" which is the query for the DHT. Upon receiving a block from the DHT, the receiver first checks that the PUBLIC KEY field matches "zk_h". Then, the client MUST verify the - - - - -Schanzenbach, et al. Expires 24 January 2020 [Page 11] - -Internet-Draft The GNU Name System July 2019 - - signature. These steps are mandatory to prevent record spoofing and MUST be performed before decryption. @@ -639,6 +658,22 @@ Internet-Draft The GNU Name System July 2019 "K" into a 256-bit AES [RFC3826] key and a 256-bit TWOFISH [TWOFISH] key: + + + + + + + + + + + +Schanzenbach, et al. Expires 24 January 2020 [Page 12] + +Internet-Draft The GNU Name System July 2019 + + 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | AES KEY | @@ -652,7 +687,7 @@ Internet-Draft The GNU Name System July 2019 | | +-----+-----+-----+-----+-----+-----+-----+-----+ - Figure 9 + Figure 10 Similarly, we divide "IV" into a 128-bit initialization vector and a 128-bit initialization vector: @@ -666,15 +701,7 @@ Internet-Draft The GNU Name System July 2019 | | +-----+-----+-----+-----+-----+-----+-----+-----+ - - - -Schanzenbach, et al. Expires 24 January 2020 [Page 12] - -Internet-Draft The GNU Name System July 2019 - - - Figure 10 + Figure 11 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 @@ -694,6 +721,15 @@ Internet-Draft The GNU Name System July 2019 TODO + + + + +Schanzenbach, et al. Expires 24 January 2020 [Page 13] + +Internet-Draft The GNU Name System July 2019 + + 6.1. Entry Zone There are three sources from which the entry zone can be determined: @@ -723,13 +759,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 13] - -Internet-Draft The GNU Name System July 2019 - - label := "mail" d := @@ -749,6 +778,14 @@ Internet-Draft The GNU Name System July 2019 f2dbf7930be76fb9 5e7c80b1416f8ca6 dc50ce8e1fb759b9 + + + +Schanzenbach, et al. Expires 24 January 2020 [Page 14] + +Internet-Draft The GNU Name System July 2019 + + fedcdcf546c17e9b 4c4f23632855c053 6668e9f684f4dc33 @@ -778,14 +815,6 @@ Internet-Draft The GNU Name System July 2019 AES_IV := a808b929bc9fad7a - - - -Schanzenbach, et al. Expires 24 January 2020 [Page 14] - -Internet-Draft The GNU Name System July 2019 - - 686bbe3432bed77a TWOFISH_KEY := @@ -805,6 +834,14 @@ Internet-Draft The GNU Name System July 2019 000a046d61696c07 Priority (10) |4 | mail | 7 6578616d706c6503 example | 3 636f6d0000000000 com | \0 | Followed by + + + +Schanzenbach, et al. Expires 24 January 2020 [Page 15] + +Internet-Draft The GNU Name System July 2019 + + 0000000000000000 24 bytes of padding to 2^6 0000000000000000 00000000 @@ -835,13 +872,6 @@ Internet-Draft The GNU Name System July 2019 001fd19a6406a721 713f0a0d - - -Schanzenbach, et al. Expires 24 January 2020 [Page 15] - -Internet-Draft The GNU Name System July 2019 - - 11. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", @@ -861,6 +891,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 16] + +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, @@ -890,14 +927,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 16] - -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, @@ -917,6 +946,14 @@ Authors' Addresses Email: schanzen@gnunet.org + + + +Schanzenbach, et al. Expires 24 January 2020 [Page 17] + +Internet-Draft The GNU Name System July 2019 + + Christian Grothoff Berner Fachhochschule Hoeheweg 80 @@ -949,4 +986,23 @@ Authors' Addresses -Schanzenbach, et al. Expires 24 January 2020 [Page 17] + + + + + + + + + + + + + + + + + + + +Schanzenbach, et al. Expires 24 January 2020 [Page 18] diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml @@ -345,6 +345,32 @@ <xref target="RFC3492" />. </t> </section> + <section anchor="gnsrecords_nick" numbered="true" toc="default"> + <name>NICK</name> + <t>Nickname records can be used by zone administrators to publish an + indication on what label this zone prefers to be referred to. + This is a suggestion to other zones what label to use when creating a + PKEY <xref target="gnsrecords_pkey" /> record containing this zone's + public zone key. + A NICK resource record contains an UTF-8 string + (which is not 0-terminated) representing the preferred label. + This string may NOT inlcude a ".". + A NICK DATA entry has the following format: + </t> + <figure anchor="figure_nickrecord"> + <artwork name="" type="" align="left" alt=""><![CDATA[ + 0 8 16 24 32 40 48 56 + +-----+-----+-----+-----+-----+-----+-----+-----+ + | NICKNAME | + / / + / / + | | + +-----+-----+-----+-----+-----+-----+-----+-----+ + ]]></artwork> + <!-- <postamble>which is a very simple example.</postamble>--> + </figure> + </section> + <section anchor="gnsrecords_box" numbered="true" toc="default"> <name>BOX</name> <t>