commit 1f02080c7484d60f6a28dc33de2adc73bd48195f
parent 72903eb519eb1bed3e5ea53978b8abd7fe655a92
Author: Christian Grothoff <christian@grothoff.org>
Date: Sun, 10 Nov 2019 21:02:55 +0100
cite rfc 2119
Diffstat:
3 files changed, 524 insertions(+), 850 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
@@ -2,35 +2,20 @@
<html lang="en" class="Internet-Draft">
<head>
<meta charset="utf-8">
-<meta content="Common,Latin" name="scripts">
-<meta content="initial-scale=1.0" name="viewport">
<title>
The GNU Name System Specification
</title>
-<meta content="Martin Schanzenbach" name="author">
-<meta content="Christian Grothoff" name="author">
-<meta content="Bernd Fix" name="author">
-<meta content="
+ <meta name="author" content="Martin Schanzenbach">
+<meta name="author" content="Christian Grothoff">
+<meta name="author" content="Bernd Fix">
+<meta name="description" content="
This document contains the GNU Name System (GNS) technical specification.
- " name="description">
-<meta content="xml2rfc 2.26.0" name="generator">
-<meta content="name systems" name="keyword">
-<link href="draft-schanzen-gns.xml" type="application/rfc+xml" rel="alternate">
-<link href="#copyright" rel="license">
-<style type="text/css">/*
-
- NOTE: Changes at the bottom of this file overrides some earlier settings.
-
- Once the style has stabilized and has been adopted as an official RFC style,
- this can be consolidated so that style settings occur only in one place, but
- for now the contents of this file consists first of the initial CSS work as
- provided to the RFC Formatter (xml2rfc) work, followed by itemized and
- commented changes found necssary during the development of the v3
- formatters.
-
-*/
-
-/* fonts */
+ ">
+<meta name="generator" content="xml2rfc 2.15.5">
+<meta name="keyword" content="name systems">
+<link rel="alternate" type="application/rfc+xml" href="draft-schanzen-gns.xml">
+<link rel="license" href="#copyright">
+<style type="text/css">/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */
@@ -196,16 +181,11 @@ dl > dt {
float: left;
margin-right: 1em;
}
-/*
-dl.nohang > dt {
- float: none;
-}
-*/
dl > dd {
margin-bottom: .8em;
min-height: 1.3em;
}
-dl.compact > dd, .dlCompact > dd {
+dl.compact > dd, dlCompact > dd {
margin-bottom: 0em;
}
dl > dd > dl {
@@ -218,7 +198,7 @@ a {
text-decoration: none;
}
a[href] {
- color: #22e; /* Arlen: WCAG 2019 */
+ color: #3E8EDE;
}
a[href]:hover {
background-color: #f2f2f2;
@@ -271,7 +251,6 @@ aside, blockquote {
}
blockquote {
background-color: #f9f9f9;
- color: #111; /* Arlen: WCAG 2019 */
border: 1px solid #ddd;
border-radius: 3px;
margin: 1em 0;
@@ -315,7 +294,7 @@ table p {
/* pilcrow */
a.pilcrow {
- color: #666; /* Arlen: AHDJ 2019 */
+ color: #777;
text-decoration: none;
visibility: hidden;
user-select: none;
@@ -376,7 +355,7 @@ hr {
/* The prepared/rendered info at the very bottom of the page */
.docInfo {
- color: #666; /* Arlen: WCAG 2019 */
+ color: #999;
font-size: 0.9em;
font-style: italic;
margin-top: 2em;
@@ -490,17 +469,17 @@ hr.addr {
right: 0.2em;
padding: 0.2em;
content: "The RFC Editor will remove this note";
- color: #9e2a00; /* Arlen: WCAG 2019 */
- background-color: #ffd; /* Arlen: WCAG 2019 */
+ color: #b76427;
+ background-color: rgba(249, 232, 105, 0.3);
}
.rfcEditorRemove {
position: relative;
padding-top: 1.8em;
- background-color: #ffd; /* Arlen: WCAG 2019 */
+ background-color: rgba(249, 232, 105, 0.3);
border-radius: 3px;
}
.cref {
- background-color: #ffd; /* Arlen: WCAG 2019 */
+ background-color: rgba(249, 232, 105, 0.3);
padding: 2px 4px;
}
.crefSource {
@@ -607,7 +586,7 @@ hr.addr {
/* pagination */
@media print {
body {
-
+ font-family: 'Noto Serif', "Times New Roman", Times, serif;
width: 100%;
}
p {
@@ -649,9 +628,6 @@ hr.addr {
}
}
-/* This is commented out here, as the string-set: doesn't
- pass W3C validation currently */
-/*
.ears thead .left {
string-set: ears-top-left content();
}
@@ -675,7 +651,6 @@ hr.addr {
.ears tfoot .right {
string-set: ears-bottom-right content();
}
-*/
@page :first {
padding-top: 0;
@@ -697,9 +672,6 @@ hr.addr {
size: A4;
margin-bottom: 45mm;
padding-top: 20px;
- /* The follwing is commented out here, but set appropriately by in code, as
- the content depends on the document */
- /*
@top-left {
content: 'Internet-Draft';
vertical-align: bottom;
@@ -735,15 +707,10 @@ hr.addr {
vertical-align: top;
border-top: solid 1px #ccc;
}
- */
-
}
/* Changes introduced to fix issues found during implementation */
-/* Make sure links are clickable even if overlapped by following H* */
-a {
- z-index: 2;
-}
+
/* Separate body from document info even without intervening H1 */
section {
clear: both;
@@ -802,12 +769,10 @@ tt, code, pre, code {
}
/* Fix the height/width aspect for ascii art*/
-pre.sourcecode,
.art-text pre {
line-height: 1.12;
}
-
/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
float: right;
@@ -868,18 +833,10 @@ caption {
script don't end up on the other side of the page. */
address.vcard {
- max-width: 30em;
+ max-width: 20em;
margin-right: auto;
}
-/* For address alignment dependent on LTR or RTL scripts */
-address div.left {
- text-align: left;
-}
-address div.right {
- text-align: right;
-}
-
/* Provide table alignment support. We can't use the alignX classes above
since they do unwanted things with caption and other styling. */
table.right {
@@ -899,89 +856,19 @@ table.left {
caption a[href] {
color: #222;
}
-
-@media print {
- .toplink {
- display: none;
- }
-
- /* avoid overwriting the top border line with the ToC header */
- #toc {
- padding-top: 1px;
- }
-
- /* Avoid page breaks inside dl and author address entries */
- dd {
- page-break-before: avoid;
- }
- .vcard {
- page-break-inside: avoid;
- }
-
-}
-/* Avoid wrapping of URLs in references */
-.references a {
- white-space: nowrap;
-}
-/* Tweak the bcp14 keyword presentation */
-.bcp14 {
- font-variant: small-caps;
- font-weight: bold;
- font-size: 0.9em;
-}
-/* Tweak the invisible space above H* in order not to overlay links in text above */
- h2 {
- margin-top: -18px; /* provide offset for in-page anchors */
- padding-top: 31px;
- }
- h3 {
- margin-top: -18px; /* provide offset for in-page anchors */
- padding-top: 24px;
- }
- h4 {
- margin-top: -18px; /* provide offset for in-page anchors */
- padding-top: 24px;
- }
-/* Float artwork pilcrow to the right */
-.artwork a.pilcrow {
- display: block;
- line-height: 0.7;
- margin-top: 0.15em;
-}
-/* Make pilcrows on dd visible */
-@media screen {
- dd:hover > a.pilcrow {
- visibility: visible;
- }
-}
-/* Make the placement of figcaption match that of a table's caption
- by removing the figure's added bottom margin */
-.alignLeft.art-text,
-.alignCenter.art-text,
-.alignRight.art-text {
- margin-bottom: 0;
-}
-.alignLeft,
-.alignCenter,
-.alignRight {
- margin: 1em 0 0 0;
-}
</style>
-<link href="rfc-local.css" type="text/css" rel="stylesheet">
+<link rel="stylesheet" href="rfc-local.css" type="text/css">
</head>
<body>
-<script>
-async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(let t=0;t<e.length;t++)if(/#identifiers/.exec(e[t].selectorText)){const a=e[t].cssText.replace("#identifiers","#metadata");document.styleSheets[0].insertRule(a,document.styleSheets[0].cssRules.length)}}catch(e){console.log(e)}const e=document.getElementById("metadata");if(e){e.style.background="#eee";try{var t;t=document.URL.indexOf("html")>=0?document.URL.replace(/html$/,"json"):document.URL+".json";const o=await fetch(t),s=(await o.json())[0],r="",d="https://datatracker.ietf.org/doc",l="https://datatracker.ietf.org/ipr/search",c="https://www.rfc-editor.org/info",n=s.doc_id.toLowerCase(),i=s.doc_id.slice(0,3).toLowerCase(),f=s.doc_id.slice(3).replace(/^0+/,""),h={status:"Status",obsoletes:"Obsoletes",obsoleted_by:"Obsoleted By",updates:"Updates",updated_by:"Updated By",see_also:"See Also",errata_url:"Errata"};let u="<dl style='overflow:hidden'>";["status","obsoletes","obsoleted_by","updates","updated_by","see_also","errata_url"].forEach(e=>{if("status"==e){s[e]=s[e].toLowerCase();var t=s[e].split(" ");sLen=t.length;var o="",p=1;for(let e=0;e<sLen;e++)p<sLen?o=o+a(t[e])+" ":o+=a(t[e]),p++;s[e]=o}else if("obsoletes"==e||"obsoleted_by"==e||"updates"==e||"updated_by"==e){var b,g="",y=1;b=s[e].length;for(let t=0;t<b;t++)s[e][t]&&(s[e][t]=String(s[e][t]).toLowerCase(),g=y<b?g+"<a href='"+r+"/rfc/".concat(s[e][t])+"'>"+s[e][t].slice(3)+"</a>, ":g+"<a href='"+r+"/rfc/".concat(s[e][t])+"'>"+s[e][t].slice(3)+"</a>",y++);s[e]=g}else if("see_also"==e){var m,w="",L=1;m=s[e].length;for(let t=0;t<m;t++)if(s[e][t]){s[e][t]=String(s[e][t]);var _=s[e][t].slice(0,3),v=s[e][t].slice(3).replace(/^0+/,"");w=L<m?w+"<a href='"+r+"/"+_.toLowerCase()+"/".concat(v.toLowierCase())+"'>"+_+" "+v+"</a>, ":w+"<a href='"+r+"/"+_.toLowerCase()+"/".concat(v.toLowerCase())+"'>"+_+" "+v+"</a>",L++}s[e]=w}else if("errata_url"==e){var C="";C=s[e]?C+"<a href='"+s[e]+"'>Errata exist</a>, <a href='"+d+"/"+n+"'>Datatracker</a>, <a href='"+l+"/?"+i+"="+f+"&submit="+i+"'>IPR</a>, <a href='"+c+"/"+n+"'>Info page</a>":"<a href='"+d+"/"+n+"'>Datatracker</a>, <a href='"+l+"/?"+i+"="+f+"&submit="+i+"'>IPR</a>, <a href='"+c+"/"+n+"'>Info page</a>",s[e]=C}""!=s[e]?"Errata"==h[e]?u+=`<dt>More info:</dt><dd>${s[e]}</dd>`:u+=`<dt>${h[e]}:</dt><dd>${s[e]}</dd>`:"Errata"==h[e]&&(u+=`<dt>More info:</dt><dd>${s[e]}</dd>`)}),u+="</dl>",e.innerHTML=u}catch(e){console.log(e)}}else console.log("Could not locate metadata <div> element");function a(e){return e.charAt(0).toUpperCase()+e.slice(1)}}window.addEventListener("load",addMetadata);</script>
-<script src="metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">Internet-Draft</td>
<td class="center">The GNU Name System</td>
-<td class="right">July 2019</td>
+<td class="right">November 2019</td>
</tr></thead>
<tfoot><tr>
<td class="left">Schanzenbach, et al.</td>
-<td class="center">Expires 24 January 2020</td>
+<td class="center">Expires 13 May 2020</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
@@ -993,12 +880,12 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<dd class="internet-draft">draft-schanzen-gns-00</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
-<time datetime="2019-07-23" class="published">23 July 2019</time>
+<time datetime="2019-11-10" class="published">10 November 2019</time>
</dd>
<dt class="label-intended-status">Intended Status:</dt>
<dd class="intended-status">Informational</dd>
<dt class="label-expires">Expires:</dt>
-<dd class="expires"><time datetime="2020-01-24">24 January 2020</time></dd>
+<dd class="expires"><time datetime="2020-05-13">13 May 2020</time></dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
@@ -1028,21 +915,17 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
</h2>
-<p id="section-boilerplate.1-1">
- This Internet-Draft is submitted in full conformance with the
+<p id="section-boilerplate.1-1">This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
-<p id="section-boilerplate.1-2">
- Internet-Drafts are working documents of the Internet Engineering Task
+<p id="section-boilerplate.1-2">Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF). Note that other groups may also distribute working
documents as Internet-Drafts. The list of current Internet-Drafts is
- at <span><a href="https://datatracker.ietf.org/drafts/current/">https://datatracker.ietf.org/drafts/current/</a></span>.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
-<p id="section-boilerplate.1-3">
- Internet-Drafts are draft documents valid for a maximum of six months
+ at https://datatracker.ietf.org/drafts/current/.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
+<p id="section-boilerplate.1-3">Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
-<p id="section-boilerplate.1-4">
- This Internet-Draft will expire on 24 January 2020.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
+<p id="section-boilerplate.1-4">This Internet-Draft will expire on 13 May 2020.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
@@ -1050,19 +933,17 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
</h2>
-<p id="section-boilerplate.2-1">
- Copyright (c) 2019 IETF Trust and the persons identified as the
- document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
-<p id="section-boilerplate.2-2">
- This document is subject to BCP 78 and the IETF Trust's Legal
+<p id="section-boilerplate.2-1">Copyright (c) 2019 IETF Trust and the persons identified as the document
+ authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
+<p id="section-boilerplate.2-2">This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
- (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
- publication of this document. Please review these documents
- carefully, as they describe your rights and restrictions with
- respect to this document. Code Components extracted from this
- document must include Simplified BSD License text as described in
- Section 4.e of the Trust Legal Provisions and are provided without
- warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents carefully,
+ as they describe your rights and restrictions with respect to this
+ document. Code Components extracted from this document must include
+ Simplified BSD License text as described in Section 4.e of the Trust
+ Legal Provisions and are provided without warranty as described in the
+ Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
@@ -1072,102 +953,102 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
</h2>
<nav class="toc"><ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-boilerplate.3-1.1">
- <p id="section-boilerplate.3-1.1.1"><a href="#section-1" class="xref">1</a>. <a href="#name-introduction" class="xref">Introduction</a><a href="#section-boilerplate.3-1.1.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.1.1"><a href="#section-1" class="xref">1</a>. <a href="#name-introduction" class="xref">Introduction</a><a href="#section-boilerplate.3-1.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.2">
- <p id="section-boilerplate.3-1.2.1"><a href="#section-2" class="xref">2</a>. <a href="#name-zones" class="xref">Zones</a><a href="#section-boilerplate.3-1.2.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.2.1"><a href="#section-2" class="xref">2</a>. <a href="#name-zones" class="xref">Zones</a><a href="#section-boilerplate.3-1.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.3">
- <p id="section-boilerplate.3-1.3.1"><a href="#section-3" class="xref">3</a>. <a href="#name-resource-records" class="xref">Resource Records</a><a href="#section-boilerplate.3-1.3.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.3.1"><a href="#section-3" class="xref">3</a>. <a href="#name-resource-records" class="xref">Resource Records</a><a href="#section-boilerplate.3-1.3.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-boilerplate.3-1.3.2.1">
- <p id="section-boilerplate.3-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>. <a href="#name-record-types" class="xref">Record Types</a><a href="#section-boilerplate.3-1.3.2.1.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>. <a href="#name-record-types" class="xref">Record Types</a><a href="#section-boilerplate.3-1.3.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.3.2.2">
- <p id="section-boilerplate.3-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>. <a href="#name-pkey" class="xref">PKEY</a><a href="#section-boilerplate.3-1.3.2.2.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>. <a href="#name-pkey" class="xref">PKEY</a><a href="#section-boilerplate.3-1.3.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.3.2.3">
- <p id="section-boilerplate.3-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>. <a href="#name-gns2dns" class="xref">GNS2DNS</a><a href="#section-boilerplate.3-1.3.2.3.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>. <a href="#name-gns2dns" class="xref">GNS2DNS</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-leho" class="xref">LEHO</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-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-nick" class="xref">NICK</a><a href="#section-boilerplate.3-1.3.2.5.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.3.2.5.1"><a href="#section-3.5" class="xref">3.5</a>. <a href="#name-nick" class="xref">NICK</a><a href="#section-boilerplate.3-1.3.2.5.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.3.2.6">
- <p id="section-boilerplate.3-1.3.2.6.1"><a href="#section-3.6" class="xref">3.6</a>. <a href="#name-box" class="xref">BOX</a><a href="#section-boilerplate.3-1.3.2.6.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.3.2.6.1"><a href="#section-3.6" class="xref">3.6</a>. <a href="#name-box" class="xref">BOX</a><a href="#section-boilerplate.3-1.3.2.6.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.3.2.7">
- <p id="section-boilerplate.3-1.3.2.7.1"><a href="#section-3.7" class="xref">3.7</a>. <a href="#name-vpn" class="xref">VPN</a><a href="#section-boilerplate.3-1.3.2.7.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.3.2.7.1"><a href="#section-3.7" class="xref">3.7</a>. <a href="#name-vpn" class="xref">VPN</a><a href="#section-boilerplate.3-1.3.2.7.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.4">
- <p id="section-boilerplate.3-1.4.1"><a href="#section-4" class="xref">4</a>. <a href="#name-publishing-records" class="xref">Publishing Records</a><a href="#section-boilerplate.3-1.4.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.4.1"><a href="#section-4" class="xref">4</a>. <a href="#name-publishing-records" class="xref">Publishing Records</a><a href="#section-boilerplate.3-1.4.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-boilerplate.3-1.4.2.1">
- <p id="section-boilerplate.3-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>. <a href="#name-key-derivations" class="xref">Key Derivations</a><a href="#section-boilerplate.3-1.4.2.1.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>. <a href="#name-key-derivations" class="xref">Key Derivations</a><a href="#section-boilerplate.3-1.4.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.4.2.2">
- <p id="section-boilerplate.3-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>. <a href="#name-resource-records-block" class="xref">Resource Records Block</a><a href="#section-boilerplate.3-1.4.2.2.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>. <a href="#name-resource-records-block" class="xref">Resource Records Block</a><a href="#section-boilerplate.3-1.4.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.4.2.3">
- <p id="section-boilerplate.3-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>. <a href="#name-record-data-encryption-and-" class="xref">Record Data Encryption and Decryption</a><a href="#section-boilerplate.3-1.4.2.3.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>. <a href="#name-record-data-encryption-and-" class="xref">Record Data Encryption and Decryption</a><a href="#section-boilerplate.3-1.4.2.3.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.5">
- <p id="section-boilerplate.3-1.5.1"><a href="#section-5" class="xref">5</a>. <a href="#name-internationalization-and-ch" class="xref">Internationalization and Character Encoding</a><a href="#section-boilerplate.3-1.5.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.5.1"><a href="#section-5" class="xref">5</a>. <a href="#name-internationalization-and-ch" class="xref">Internationalization and Character Encoding</a><a href="#section-boilerplate.3-1.5.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.6">
- <p id="section-boilerplate.3-1.6.1"><a href="#section-6" class="xref">6</a>. <a href="#name-name-resolution" class="xref">Name Resolution</a><a href="#section-boilerplate.3-1.6.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.6.1"><a href="#section-6" class="xref">6</a>. <a href="#name-name-resolution" class="xref">Name Resolution</a><a href="#section-boilerplate.3-1.6.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-boilerplate.3-1.6.2.1">
- <p id="section-boilerplate.3-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>. <a href="#name-entry-zone" class="xref">Entry Zone</a><a href="#section-boilerplate.3-1.6.2.1.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>. <a href="#name-entry-zone" class="xref">Entry Zone</a><a href="#section-boilerplate.3-1.6.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.6.2.2">
- <p id="section-boilerplate.3-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>. <a href="#name-record-retrieval" class="xref">Record Retrieval</a><a href="#section-boilerplate.3-1.6.2.2.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>. <a href="#name-record-retrieval" class="xref">Record Retrieval</a><a href="#section-boilerplate.3-1.6.2.2.1" class="pilcrow">¶</a></p>
</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>
+ <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>
+ <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>
+ <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>
+ <p id="section-boilerplate.3-1.6.2.3.2.3.1"><a href="#section-6.3.3" class="xref">6.3.3</a>. <a href="#name-cname" class="xref">CNAME</a><a href="#section-boilerplate.3-1.6.2.3.2.3.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.6.2.3.2.4">
- <p id="section-boilerplate.3-1.6.2.3.2.4.1"><a href="#section-6.3.4" class="xref">6.3.4</a>. <a href="#name-box-2" class="xref">BOX</a><a href="#section-boilerplate.3-1.6.2.3.2.4.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.6.2.3.2.4.1"><a href="#section-6.3.4" class="xref">6.3.4</a>. <a href="#name-box-2" class="xref">BOX</a><a href="#section-boilerplate.3-1.6.2.3.2.4.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.6.2.3.2.5">
- <p id="section-boilerplate.3-1.6.2.3.2.5.1"><a href="#section-6.3.5" class="xref">6.3.5</a>. <a href="#name-vpn-2" class="xref">VPN</a><a href="#section-boilerplate.3-1.6.2.3.2.5.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.6.2.3.2.5.1"><a href="#section-6.3.5" class="xref">6.3.5</a>. <a href="#name-vpn-2" class="xref">VPN</a><a href="#section-boilerplate.3-1.6.2.3.2.5.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.7">
- <p id="section-boilerplate.3-1.7.1"><a href="#section-7" class="xref">7</a>. <a href="#name-zone-revocation" class="xref">Zone Revocation</a><a href="#section-boilerplate.3-1.7.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.7.1"><a href="#section-7" class="xref">7</a>. <a href="#name-zone-revocation" class="xref">Zone Revocation</a><a href="#section-boilerplate.3-1.7.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.8">
- <p id="section-boilerplate.3-1.8.1"><a href="#section-8" class="xref">8</a>. <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-boilerplate.3-1.8.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.8.1"><a href="#section-8" class="xref">8</a>. <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-boilerplate.3-1.8.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.9">
- <p id="section-boilerplate.3-1.9.1"><a href="#section-9" class="xref">9</a>. <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-boilerplate.3-1.9.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.9.1"><a href="#section-9" class="xref">9</a>. <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-boilerplate.3-1.9.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.10">
- <p id="section-boilerplate.3-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-test-vectors" class="xref">Test Vectors</a><a href="#section-boilerplate.3-1.10.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-test-vectors" class="xref">Test Vectors</a><a href="#section-boilerplate.3-1.10.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.11">
- <p id="section-boilerplate.3-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-boilerplate.3-1.11.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-boilerplate.3-1.11.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-boilerplate.3-1.12">
- <p id="section-boilerplate.3-1.12.1"><a href="#section-appendix.a" class="xref"></a> <a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-boilerplate.3-1.12.1" class="pilcrow">¶</a></p>
+ <p id="section-boilerplate.3-1.12.1"><a href="#section-appendix.a" class="xref"></a> <a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-boilerplate.3-1.12.1" class="pilcrow">¶</a></p>
</li>
</ul>
</nav>
@@ -1185,7 +1066,8 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
names. As the awareness of the central role DNS plays on the Internet
rises, various institutions are using their power (including legal means)
to engage in attacks on the DNS, thus threatening the global availability
- and integrity of information on the Internet.<a href="#section-1-1" class="pilcrow">¶</a></p>
+ and integrity of information on the Internet.
+ <a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
DNS was not designed with security as a goal. This makes it very
vulnerable, especially to attackers that have the technical capabilities
@@ -1196,7 +1078,8 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
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.<a href="#section-1-2" class="pilcrow">¶</a></p>
+ particular X.509 for the Web.
+ <a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">
This document contains the GNU Name System (GNS) technical specification
of the GNU Name System (GNS), a fully decentralized and censorship-resistant
@@ -1209,11 +1092,21 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
of providing a global, secure and memorable mapping without a trusted
authority. GNS uses the transitivity in the SDSI design to replace the
trusted root with secure delegation of authority thus making petnames
- useful to other users while operating under a very strong adversary model.<a href="#section-1-3" class="pilcrow">¶</a></p>
+ useful to other users while operating under a very strong adversary model.
+ <a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">
This document defines the normative wire format of resource records, resolution processes,
- cryptographic routines and security considerations for use by implementors.<a href="#section-1-4" class="pilcrow">¶</a></p>
-<p id="section-1-5"><a href="#section-1-5" class="pilcrow">¶</a></p>
+ cryptographic routines and security considerations for use by implementors.
+ <a href="#section-1-4" class="pilcrow">¶</a></p>
+<p id="section-1-5">
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+ NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described
+ in <span>[<a href="#RFC2119" class="xref">RFC2119</a>].
+ </span><a href="#section-1-5" class="pilcrow">¶</a></p>
+<p id="section-1-6">
+
+ <a href="#section-1-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="zones">
@@ -1225,38 +1118,43 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
A zone in GNS is defined by a public/private ECDSA key pair (d,zk),
where d is the private key and zk the corresponding public key.
GNS employs the curve parameters of the twisted edwards representation
- of Curve25519 <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span> (a.k.a. edwards25519)
- with the ECDSA scheme (<span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span>).
+ of Curve25519 <span>[<a href="#RFC7748" class="xref">RFC7748</a>] (a.k.a. edwards25519)
+ with the ECDSA scheme (</span><span>[<a href="#RFC6979" class="xref">RFC6979</a>]).
In the following, we use the following naming convention for our
- cryptographic primitives:<a href="#section-2-1" class="pilcrow">¶</a></p>
+ cryptographic primitives:
+ </span><a href="#section-2-1" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-2-2">
<dt id="section-2-2.1">d</dt>
<dd id="section-2-2.2">
is a 256-bit ECDSA private key.
In GNS, records are signed using a key derived from "d" as described in
- <a href="#publish" class="xref">Section 4</a>.<a href="#section-2-2.2" class="pilcrow">¶</a>
-</dd>
+ <a href="#publish" class="xref">Section 4</a>.
+ </dd>
<dt id="section-2-2.3">p</dt>
<dd id="section-2-2.4">
- is the prime of edwards25519 as defined in <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span>, i.e.
- 2^255 - 19.<a href="#section-2-2.4" class="pilcrow">¶</a>
+ is the prime of edwards25519 as defined in <span>[<a href="#RFC7748" class="xref">RFC7748</a>], i.e.
+ 2^255 - 19.
+ </span>
</dd>
<dt id="section-2-2.5">B</dt>
<dd id="section-2-2.6">
is the group generator (X(P),Y(P)) of edwards25519 as defined in
- <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span>.<a href="#section-2-2.6" class="pilcrow">¶</a>
+ <span>[<a href="#RFC7748" class="xref">RFC7748</a>].
+ </span>
</dd>
<dt id="section-2-2.7">L</dt>
<dd id="section-2-2.8">
- is the prime-order subgroup of edwards25519 in <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span>.<a href="#section-2-2.8" class="pilcrow">¶</a>
+ is the prime-order subgroup of edwards25519 in <span>[<a href="#RFC7748" class="xref">RFC7748</a>].
+ </span>
</dd>
<dt id="section-2-2.9">zk</dt>
<dd id="section-2-2.10">
is the ECDSA public key corresponding to d. It is defined in
- <span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span> as the curve point d*B where B is the group
+ <span>[<a href="#RFC6979" class="xref">RFC6979</a>] as the curve point d*B where B is the group
generator of the elliptic curve.
The public key is used to uniquely identify a GNS zone and is referred to
- as the "zone key".<a href="#section-2-2.10" class="pilcrow">¶</a>
+ as the "zone key".
+ </span>
</dd>
</dl>
</section>
@@ -1272,10 +1170,12 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
key pair. Records may be added to each zone, hence a (local) persistency
mechanism for resource records and zones must be provided.
This local zone database is used by the GNS resolver implementation
- and to publish record information.<a href="#section-3-1" class="pilcrow">¶</a></p>
+ and to publish record information.
+ <a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">
A GNS resource record holds the data of a specific record in a zone.
- The resource record format is defined as follows:<a href="#section-3-2" class="pilcrow">¶</a></p>
+ The resource record format is defined as follows:
+ <a href="#section-3-2" class="pilcrow">¶</a></p>
<div id="figure_gnsrecord">
<figure id="figure-1">
<div class="artwork art-text alignLeft" id="section-3-3.1">
@@ -1292,7 +1192,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
/ /
</pre>
</div>
-<figcaption><a href="#figure-1" class="selfRef">Figure 1</a></figcaption></figure>
+<figcaption><a href="#figure-1">Figure 1</a></figcaption></figure>
</div>
<p id="section-3-4">where:<a href="#section-3-4" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-3-5">
@@ -1300,32 +1200,33 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<dd id="section-3-5.2">
denotes the absolute 64-bit expiration date of the record.
In microseconds since midnight (0 hour), January 1, 1970 in network
- byte order.<a href="#section-3-5.2" class="pilcrow">¶</a>
-</dd>
+ byte order.
+ </dd>
<dt id="section-3-5.3">DATA SIZE</dt>
<dd id="section-3-5.4">
denotes the 32-bit size of the DATA field in bytes and in network byte
- order.<a href="#section-3-5.4" class="pilcrow">¶</a>
-</dd>
+ order.
+ </dd>
<dt id="section-3-5.5">TYPE</dt>
<dd id="section-3-5.6">
is the 32-bit resource record type. This type can be one of the GNS resource
records as defined in <a href="#rrecords" class="xref">Section 3</a> or a DNS record
- type as defined in <span>[<a href="#RFC1035" class="xref">RFC1035</a>]</span> or any of the
+ type as defined in <span>[<a href="#RFC1035" class="xref">RFC1035</a>] 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 (<span>[<a href="#RFC6895" class="xref">RFC6895</a>]</span>).<a href="#section-3-5.6" class="pilcrow">¶</a>
+ below 2^16 are reserved for allocation via IANA (</span><span>[<a href="#RFC6895" class="xref">RFC6895</a>]).
+ </span>
</dd>
<dt id="section-3-5.7">FLAGS</dt>
<dd id="section-3-5.8">
- is a 32-bit resource record flags field (see below).<a href="#section-3-5.8" class="pilcrow">¶</a>
-</dd>
+ is a 32-bit resource record flags field (see below).
+ </dd>
<dt id="section-3-5.9">DATA</dt>
<dd id="section-3-5.10">
the variable-length resource record data payload. The contents are defined
by the
- respective type of the resource record.<a href="#section-3-5.10" class="pilcrow">¶</a>
-</dd>
+ respective type of the resource record.
+ </dd>
</dl>
<p id="section-3-6">
Flags indicate metadata surrounding the resource record. A flag
@@ -1342,10 +1243,11 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
------+--------+--------+--------+--------+--------+
</pre>
</div>
-<figcaption><a href="#figure-2" class="selfRef">Figure 2</a></figcaption></figure>
+<figcaption><a href="#figure-2">Figure 2</a></figcaption></figure>
</div>
<p id="section-3-8">
- where:<a href="#section-3-8" class="pilcrow">¶</a></p>
+ where:
+ <a href="#section-3-8" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-3-9">
<dt id="section-3-9.1">SHADOW</dt>
<dd id="section-3-9.2">
@@ -1353,23 +1255,23 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
records of the same record type have expired. Used to allow zone publishers to
facilitate good performance when records change by allowing them to put future
values of records into the DHT. This way, future values can propagate and may be
- cached before the transition becomes active.<a href="#section-3-9.2" class="pilcrow">¶</a>
-</dd>
+ cached before the transition becomes active.
+ </dd>
<dt id="section-3-9.3">EXPREL</dt>
<dd id="section-3-9.4">
The expiration time value of the record is a relative time (still in microseconds)
and not an absolute time. This flag should never be encountered by a resolver
for records obtained from the DHT, but might be present when a resolver looks up
- private records of a zone hosted locally.<a href="#section-3-9.4" class="pilcrow">¶</a>
-</dd>
+ private records of a zone hosted locally.
+ </dd>
<dt id="section-3-9.5">PRIVATE</dt>
<dd id="section-3-9.6">
This is a private record of this peer and it should thus not be
published in the DHT. Thus, this flag should never be encountered by
a resolver for records obtained from the DHT.
Private records should still be considered just like
- regular records when resolving labels in local zones.<a href="#section-3-9.6" class="pilcrow">¶</a>
-</dd>
+ regular records when resolving labels in local zones.
+ </dd>
</dl>
<div id="gnsrecords_numbers">
<section id="section-3.1">
@@ -1379,7 +1281,8 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<p id="section-3.1-1">
GNS-specific record type numbers start at 2^16, i.e. after the record
type numbers for DNS. The following is a list of defined and reserved
- record types in GNS:<a href="#section-3.1-1" class="pilcrow">¶</a></p>
+ record types in GNS:
+ <a href="#section-3.1-1" class="pilcrow">¶</a></p>
<div id="figure_rrtypenums">
<figure id="figure-3">
<div class="artwork art-text alignLeft" id="section-3.1-2.1">
@@ -1396,7 +1299,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
2^24 up to 2^32 - 1 | - | Unassigned / For private use
</pre>
</div>
-<figcaption><a href="#figure-3" class="selfRef">Figure 3</a></figcaption></figure>
+<figcaption><a href="#figure-3">Figure 3</a></figcaption></figure>
</div>
</section>
</div>
@@ -1422,15 +1325,16 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-4" class="selfRef">Figure 4</a></figcaption></figure>
+<figcaption><a href="#figure-4">Figure 4</a></figcaption></figure>
</div>
<p id="section-3.2-3">
- where:<a href="#section-3.2-3" class="pilcrow">¶</a></p>
+ where:
+ <a href="#section-3.2-3" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-3.2-4">
<dt id="section-3.2-4.1">PUBLIC KEY</dt>
<dd id="section-3.2-4.2">
- A 256-bit ECDSA zone key.<a href="#section-3.2-4.2" class="pilcrow">¶</a>
-</dd>
+ A 256-bit ECDSA zone key.
+ </dd>
</dl>
</section>
</div>
@@ -1442,8 +1346,8 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<p id="section-3.3-1">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
- <span>[<a href="#RFC1034" class="xref">RFC1034</a>]</span> for DNS names.
- A GNS2DNS DATA entry has the following format:<a href="#section-3.3-1" class="pilcrow">¶</a></p>
+ <span>[<a href="#RFC1034" class="xref">RFC1034</a>] for DNS names.
+ A GNS2DNS DATA entry has the following format:</span><a href="#section-3.3-1" class="pilcrow">¶</a></p>
<div id="figure_gns2dnsrecord">
<figure id="figure-5">
<div class="artwork art-text alignLeft" id="section-3.3-2.1">
@@ -1462,21 +1366,22 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
+-----------------------------------------------+
</pre>
</div>
-<figcaption><a href="#figure-5" class="selfRef">Figure 5</a></figcaption></figure>
+<figcaption><a href="#figure-5">Figure 5</a></figcaption></figure>
</div>
<p id="section-3.3-3">
- where:<a href="#section-3.3-3" class="pilcrow">¶</a></p>
+ where:
+ <a href="#section-3.3-3" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-3.3-4">
<dt id="section-3.3-4.1">DNS NAME</dt>
<dd id="section-3.3-4.2">
- The name to continue with in DNS (0-terminated).<a href="#section-3.3-4.2" class="pilcrow">¶</a>
-</dd>
+ The name to continue with in DNS (0-terminated).
+ </dd>
<dt id="section-3.3-4.3">DNS SERVER NAME</dt>
<dd id="section-3.3-4.4">
The DNS server to use. May be an IPv4/IPv6 address in dotted decimal
form or a DNS name. It may also be a relative GNS name ending with a
- "+" top-level domain. (all 0-terminated)<a href="#section-3.3-4.4" class="pilcrow">¶</a>
-</dd>
+ "+" top-level domain. (all 0-terminated)
+ </dd>
</dl>
</section>
</div>
@@ -1506,20 +1411,22 @@ 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-6">Figure 6</a></figcaption></figure>
</div>
<p id="section-3.4-3">
- where:<a href="#section-3.4-3" class="pilcrow">¶</a></p>
+ where:
+ <a href="#section-3.4-3" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-3.4-4">
<dt id="section-3.4-4.1">LEGACY HOSTNAME</dt>
<dd id="section-3.4-4.2">
- A UTF-8 string (which is not 0-terminated) representing the legacy hostname.<a href="#section-3.4-4.2" class="pilcrow">¶</a>
-</dd>
+ A UTF-8 string (which is not 0-terminated) representing the legacy hostname.
+ </dd>
</dl>
<p id="section-3.4-5">
NOTE: If an application uses a LEHO value in an HTTP request header
(e.g. "Host:" header) it must be converted to a punycode representation
- <span>[<a href="#RFC5891" class="xref">RFC5891</a>]</span>.<a href="#section-3.4-5" class="pilcrow">¶</a></p>
+ <span>[<a href="#RFC5891" class="xref">RFC5891</a>].
+ </span><a href="#section-3.4-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="gnsrecords_nick">
@@ -1533,7 +1440,8 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
PKEY <a href="#gnsrecords_pkey" class="xref">Section 3.2</a> record containing this zone's
public zone key.
This record SHOULD only be stored under the empty label "@".
- A NICK DATA entry has the following format:<a href="#section-3.5-1" class="pilcrow">¶</a></p>
+ A NICK DATA entry has the following format:
+ <a href="#section-3.5-1" class="pilcrow">¶</a></p>
<div id="figure_nickrecord">
<figure id="figure-7">
<div class="artwork art-text alignLeft" id="section-3.5-2.1">
@@ -1547,16 +1455,17 @@ 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-7">Figure 7</a></figcaption></figure>
</div>
<p id="section-3.5-3">
- where:<a href="#section-3.5-3" class="pilcrow">¶</a></p>
+ where:
+ <a href="#section-3.5-3" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-3.5-4">
<dt id="section-3.5-4.1">NICKNAME</dt>
<dd id="section-3.5-4.2">
A UTF-8 string (which is not 0-terminated) representing the preferred
- label of the zone. This string MUST NOT inlcude a "." character.<a href="#section-3.5-4.2" class="pilcrow">¶</a>
-</dd>
+ label of the zone. This string MUST NOT inlcude a "." character.
+ </dd>
</dl>
</section>
</div>
@@ -1576,8 +1485,9 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
TLSA record for "_https._tcp.foo.gnu" will be stored in the record set of
"foo.gnu" as a BOX record with service (SVC) 443 (https) and protocol (PROTO) 6
(tcp) and record_type "TLSA".
- For reference, see also <span>[<a href="#RFC2782" class="xref">RFC2782</a>]</span>
- A BOX DATA entry has the following format:<a href="#section-3.6-1" class="pilcrow">¶</a></p>
+ For reference, see also <span>[<a href="#RFC2782" class="xref">RFC2782</a>]
+ A BOX DATA entry has the following format:
+ </span><a href="#section-3.6-1" class="pilcrow">¶</a></p>
<div id="figure_boxrecord">
<figure id="figure-8">
<div class="artwork art-text alignLeft" id="section-3.6-2.1">
@@ -1593,29 +1503,30 @@ 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-8">Figure 8</a></figcaption></figure>
</div>
<p id="section-3.6-3">
- where:<a href="#section-3.6-3" class="pilcrow">¶</a></p>
+ where:
+ <a href="#section-3.6-3" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-3.6-4">
<dt id="section-3.6-4.1">PROTO</dt>
<dd id="section-3.6-4.2">
- the 16-bit protocol number, e.g. 6 for tcp. In network byte order.<a href="#section-3.6-4.2" class="pilcrow">¶</a>
-</dd>
+ the 16-bit protocol number, e.g. 6 for tcp. In network byte order.
+ </dd>
<dt id="section-3.6-4.3">SVC</dt>
<dd id="section-3.6-4.4">
the 16-bit service value of the boxed record, i.e. the port number.
- In network byte order.<a href="#section-3.6-4.4" class="pilcrow">¶</a>
-</dd>
+ In network byte order.
+ </dd>
<dt id="section-3.6-4.5">TYPE</dt>
<dd id="section-3.6-4.6">
- is the 32-bit record type of the boxed record. In network byte order.<a href="#section-3.6-4.6" class="pilcrow">¶</a>
-</dd>
+ is the 32-bit record type of the boxed record. In network byte order.
+ </dd>
<dt id="section-3.6-4.7">RECORD DATA</dt>
<dd id="section-3.6-4.8">
is a variable length field containing the "DATA" format of TYPE as
- defined for the respective TYPE in DNS.<a href="#section-3.6-4.8" class="pilcrow">¶</a>
-</dd>
+ defined for the respective TYPE in DNS.
+ </dd>
</dl>
</section>
</div>
@@ -1644,7 +1555,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-9">Figure 9</a></figcaption></figure>
</div>
</section>
</div>
@@ -1662,14 +1573,16 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
encrypted and published together in a single resource records block
(RRBLOCK) in the DHT under a key "q": PUT(q, RRBLOCK).
The key "q" which is derived from the zone key "zk" and the respective
- label of the contained records.<a href="#section-4-1" class="pilcrow">¶</a></p>
+ label of the contained records.
+ <a href="#section-4-1" class="pilcrow">¶</a></p>
<div id="blinding">
<section id="section-4.1">
<h3 id="name-key-derivations">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-key-derivations" class="section-name selfRef">Key Derivations</a>
</h3>
<p id="section-4.1-1">
- Given a label, the DHT key "q" is derived as follows:<a href="#section-4.1-1" class="pilcrow">¶</a></p>
+ Given a label, the DHT key "q" is derived as follows:
+ <a href="#section-4.1-1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.1-2">
<pre>
PRK_h := HKDF-Extract ("key-derivation", zk)
@@ -1677,57 +1590,60 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
d_h := h * d mod L
zk_h := h mod L * zk
q := SHA512 (zk_h)
- </pre><a href="#section-4.1-2" class="pilcrow">¶</a>
+ </pre>
+<a href="#section-4.1-2" class="pilcrow">¶</a>
</div>
<p id="section-4.1-3">
We use a hash-based key derivation function (HKDF) as defined in
- <span>[<a href="#RFC5869" class="xref">RFC5869</a>]</span>. We use HMAC-SHA512 for the extraction
- phase and HMAC-SHA256 for the expansion phase.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
+ <span>[<a href="#RFC5869" class="xref">RFC5869</a>]. We use HMAC-SHA512 for the extraction
+ phase and HMAC-SHA256 for the expansion phase.
+ </span><a href="#section-4.1-3" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-4.1-4">
<dt id="section-4.1-4.1">PRK_h</dt>
<dd id="section-4.1-4.2">
is key material retrieved using an HKDF using the string
"key-derivation" as salt and the public zone key "zk" as initial
- keying material.<a href="#section-4.1-4.2" class="pilcrow">¶</a>
-</dd>
+ keying material.
+ </dd>
<dt id="section-4.1-4.3">h</dt>
<dd id="section-4.1-4.4">
is the 512-bit HKDF expansion result. The expansion info input is a
- concatenation of the label and string "gns".<a href="#section-4.1-4.4" class="pilcrow">¶</a>
-</dd>
+ concatenation of the label and string "gns".
+ </dd>
<dt id="section-4.1-4.5">d</dt>
<dd id="section-4.1-4.6">
- is the 256-bit private zone key as defined in <a href="#zones" class="xref">Section 2</a>.<a href="#section-4.1-4.6" class="pilcrow">¶</a>
-</dd>
+ is the 256-bit private zone key as defined in <a href="#zones" class="xref">Section 2</a>.
+ </dd>
<dt id="section-4.1-4.7">label</dt>
<dd id="section-4.1-4.8">
- is a UTF-8 string under which the resource records are published.<a href="#section-4.1-4.8" class="pilcrow">¶</a>
-</dd>
+ is a UTF-8 string under which the resource records are published.
+ </dd>
<dt id="section-4.1-4.9">d_h</dt>
<dd id="section-4.1-4.10">
is a 256-bit private key derived from the "d" using the
- keying material "h".<a href="#section-4.1-4.10" class="pilcrow">¶</a>
-</dd>
+ keying material "h".
+ </dd>
<dt id="section-4.1-4.11">zk_h</dt>
<dd id="section-4.1-4.12">
is a 256-bit public key derived from the zone key "zk" using the
- keying material "h".<a href="#section-4.1-4.12" class="pilcrow">¶</a>
-</dd>
+ keying material "h".
+ </dd>
<dt id="section-4.1-4.13">L</dt>
<dd id="section-4.1-4.14">
- is the prime-order subgroup as defined in <a href="#zones" class="xref">Section 2</a>.<a href="#section-4.1-4.14" class="pilcrow">¶</a>
-</dd>
+ is the prime-order subgroup as defined in <a href="#zones" class="xref">Section 2</a>.
+ </dd>
<dt id="section-4.1-4.15">q</dt>
<dd id="section-4.1-4.16">
Is the 512-bit DHT key under which the resource records block is
published.
It is the SHA512 hash over the public key "zk_h" corresponding to the
- derived private key "d_h".<a href="#section-4.1-4.16" class="pilcrow">¶</a>
-</dd>
+ derived private key "d_h".
+ </dd>
</dl>
<p id="section-4.1-5">
We point out that the multiplication of "zk" with "h" is a point multiplication,
- while the multiplication of "d" with "h" is a scalar multiplication.<a href="#section-4.1-5" class="pilcrow">¶</a></p>
+ while the multiplication of "d" with "h" is a scalar multiplication.
+ <a href="#section-4.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="wire">
@@ -1743,7 +1659,8 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
A GNS implementation must publish RRBLOCKs
in accordance to the properties and recommendations of the underlying
DHT. This may include a periodic refresh publication.
- A GNS RRBLOCK has the following format:<a href="#section-4.2-1" class="pilcrow">¶</a></p>
+ A GNS RRBLOCK has the following format:
+ <a href="#section-4.2-1" class="pilcrow">¶</a></p>
<div id="figure_record_block">
<figure id="figure-10">
<div class="artwork art-text alignLeft" id="section-4.2-2.1">
@@ -1774,23 +1691,24 @@ 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-10">Figure 10</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">
<dt id="section-4.2-4.1">SIGNATURE</dt>
<dd id="section-4.2-4.2">
A 512-bit ECDSA deterministic signature compliant with
- <span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span>. The signature is computed over the data
+ <span>[<a href="#RFC6979" class="xref">RFC6979</a>]. The signature is computed over the data
following the PUBLIC KEY field.
The signature is created using the derived private key "d_h" (see
- <a href="#publish" class="xref">Section 4</a>).<a href="#section-4.2-4.2" class="pilcrow">¶</a>
-</dd>
+ </span><a href="#publish" class="xref">Section 4</a>).
+ </dd>
<dt id="section-4.2-4.3">PUBLIC KEY</dt>
<dd id="section-4.2-4.4">
is the 256-bit public key "zk_h" to be used to verify SIGNATURE. The
- wire format of this value is defined in <span>[<a href="#RFC8032" class="xref">RFC8032</a>]</span>,
- Section 5.1.5.<a href="#section-4.2-4.4" class="pilcrow">¶</a>
+ wire format of this value is defined in <span>[<a href="#RFC8032" class="xref">RFC8032</a>],
+ Section 5.1.5.
+ </span>
</dd>
<dt id="section-4.2-4.5">SIZE</dt>
<dd id="section-4.2-4.6">
@@ -1800,13 +1718,13 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
addition to the length of the BDATA. While a 32-bit value is used,
implementations MAY refuse to publish blocks beyond a certain
size significantly below 4 GB. However, a minimum block size of
- 62 kilobytes MUST be supported.<a href="#section-4.2-4.6" class="pilcrow">¶</a>
-</dd>
+ 62 kilobytes MUST be supported.
+ </dd>
<dt id="section-4.2-4.7">PURPOSE</dt>
<dd id="section-4.2-4.8">
A 32-bit signature purpose flag. This field MUST be 15 (in network
- byte order).<a href="#section-4.2-4.8" class="pilcrow">¶</a>
-</dd>
+ byte order).
+ </dd>
<dt id="section-4.2-4.9">EXPIRATION</dt>
<dd id="section-4.2-4.10">
Specifies when the RRBLOCK expires and the encrypted block
@@ -1819,12 +1737,12 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
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>
+ (0 hour), January 1, 1970 in network byte order.
+ </dd>
<dt id="section-4.2-4.11">BDATA</dt>
<dd id="section-4.2-4.12">
- The encrypted resource records with a total size of SIZE - 16.<a href="#section-4.2-4.12" class="pilcrow">¶</a>
-</dd>
+ The encrypted resource records with a total size of SIZE - 16.
+ </dd>
</dl>
</section>
</div>
@@ -1835,7 +1753,8 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<p id="section-4.3-1">
A symmetric encryption scheme is used to encrypt the resource records
set RDATA into the BDATA field of a GNS RRBLOCK.
- The wire format of the RDATA looks as follows:<a href="#section-4.3-1" class="pilcrow">¶</a></p>
+ 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-11">
<div class="artwork art-text alignLeft" id="section-4.3-2.1">
@@ -1865,7 +1784,7 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
/ /
</pre>
</div>
-<figcaption><a href="#figure-11" class="selfRef">Figure 11</a></figcaption></figure>
+<figcaption><a href="#figure-11">Figure 11</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">
@@ -1873,15 +1792,15 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<dd id="section-4.3-4.2">
A 32-bit value containing the number of variable-length resource
records which are
- following after this field in network byte order.<a href="#section-4.3-4.2" class="pilcrow">¶</a>
-</dd>
+ following after this field in network byte order.
+ </dd>
<dt id="section-4.3-4.3">EXPIRATION, DATA SIZE, TYPE, FLAGS and DATA</dt>
<dd id="section-4.3-4.4">
These fields were defined
in the resource record format in <a href="#rrecords" class="xref">Section 3</a>.
There MUST be a total of RR COUNT of these resource records
- present.<a href="#section-4.3-4.4" class="pilcrow">¶</a>
-</dd>
+ present.
+ </dd>
<dt id="section-4.3-4.5">PADDING</dt>
<dd id="section-4.3-4.6">
The padding MUST contain the value 0 in all octets.
@@ -1889,31 +1808,34 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
COUNT field is a power of two.
As a special exception, record sets with (only) a PKEY record type
are never padded. Note that a record set with a PKEY record MUST NOT
- contain other records.<a href="#section-4.3-4.6" class="pilcrow">¶</a>
-</dd>
+ contain other records.
+ </dd>
</dl>
<p id="section-4.3-5">
The symmetric keys and initialization vectors are derived from the
record label and the zone key "zk". For decryption of the resource
records block payload, the key material "K" and initialization vector
- "IV" for the symmetric cipher are derived as follows:<a href="#section-4.3-5" class="pilcrow">¶</a></p>
+ "IV" for the symmetric cipher are derived as follows:
+ <a href="#section-4.3-5" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.3-6">
<pre>
PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk)
K := HKDF-Expand (PRK_k, label, 512 / 8);
IV := HKDF-Expand (PRK_iv, label, 256 / 8)
- </pre><a href="#section-4.3-6" class="pilcrow">¶</a>
+ </pre>
+<a href="#section-4.3-6" class="pilcrow">¶</a>
</div>
<p id="section-4.3-7">
HKDF is a hash-based key derivation function as defined in
- <span>[<a href="#RFC5869" class="xref">RFC5869</a>]</span>. Specifically, HMAC-SHA512 is used for the
+ <span>[<a href="#RFC5869" class="xref">RFC5869</a>]. Specifically, HMAC-SHA512 is used for the
extraction phase and HMAC-SHA256 for the expansion phase.
The output keying material is 64 octets (512 bit) for the symmetric
keys and 32 octets (256 bit) for the initialization vectors.
We divide the resulting keying material "K" into a 256-bit AES
- <span>[<a href="#RFC3826" class="xref">RFC3826</a>]</span> key
- and a 256-bit TWOFISH <span>[<a href="#TWOFISH" class="xref">TWOFISH</a>]</span> key:<a href="#section-4.3-7" class="pilcrow">¶</a></p>
+ </span><span>[<a href="#RFC3826" class="xref">RFC3826</a>] key
+ and a 256-bit TWOFISH </span><span>[<a href="#TWOFISH" class="xref">TWOFISH</a>] key:
+ </span><a href="#section-4.3-7" class="pilcrow">¶</a></p>
<div id="figure_hkdf_keys">
<figure id="figure-12">
<div class="artwork art-text alignLeft" id="section-4.3-8.1">
@@ -1932,11 +1854,12 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-12" class="selfRef">Figure 12</a></figcaption></figure>
+<figcaption><a href="#figure-12">Figure 12</a></figcaption></figure>
</div>
<p id="section-4.3-9">
Similarly, we divide "IV" into a 128-bit initialization vector
- and a 128-bit initialization vector:<a href="#section-4.3-9" class="pilcrow">¶</a></p>
+ and a 128-bit initialization vector:
+ <a href="#section-4.3-9" class="pilcrow">¶</a></p>
<div id="figure_hkdf_ivs">
<figure id="figure-13">
<div class="artwork art-text alignLeft" id="section-4.3-10.1">
@@ -1951,17 +1874,19 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-13" class="selfRef">Figure 13</a></figcaption></figure>
+<figcaption><a href="#figure-13">Figure 13</a></figcaption></figure>
</div>
<p id="section-4.3-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 (CFB) mode <span>[<a href="#RFC3826" class="xref">RFC3826</a>]</span>.<a href="#section-4.3-11" class="pilcrow">¶</a></p>
+ Cipher FeedBack (CFB) mode <span>[<a href="#RFC3826" class="xref">RFC3826</a>].
+ </span><a href="#section-4.3-11" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4.3-12">
<pre>
RDATA := AES(AES KEY, AES IV, TWOFISH(TWOFISH KEY, TWOFISH IV, BDATA))
BDATA := TWOFISH(TWOFISH KEY, TWOFISH IV, AES(AES KEY, AES IV, RDATA))
- </pre><a href="#section-4.3-12" class="pilcrow">¶</a>
+ </pre>
+<a href="#section-4.3-12" class="pilcrow">¶</a>
</div>
</section>
</section>
@@ -1972,10 +1897,11 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-internationalization-and-ch" class="section-name selfRef">Internationalization and Character Encoding</a>
</h2>
<p id="section-5-1">
- All labels in GNS are encoded in UTF-8 <span>[<a href="#RFC3629" class="xref">RFC3629</a>]</span>.
+ All labels in GNS are encoded in UTF-8 <span>[<a href="#RFC3629" class="xref">RFC3629</a>].
This does not include any DNS names found in DNS records, such as CNAME
records, which are internationalized through the IDNA specifications
- <span>[<a href="#RFC5890" class="xref">RFC5890</a>]</span>.<a href="#section-5-1" class="pilcrow">¶</a></p>
+ </span><span>[<a href="#RFC5890" class="xref">RFC5890</a>].
+ </span><a href="#section-5-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="resolution">
@@ -1984,7 +1910,8 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-name-resolution" class="section-name selfRef">Name Resolution</a>
</h2>
<p id="section-6-1">
- TODO<a href="#section-6-1" class="pilcrow">¶</a></p>
+ TODO
+ <a href="#section-6-1" class="pilcrow">¶</a></p>
<div id="entry_zone">
<section id="section-6.1">
<h3 id="name-entry-zone">
@@ -1992,7 +1919,8 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
</h3>
<p id="section-6.1-1">
There are three sources from which the entry zone can be determined
- which MUST be queried in this order:<a href="#section-6.1-1" class="pilcrow">¶</a></p>
+ which MUST be queried in this order:
+ <a href="#section-6.1-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal" id="section-6.1-2">
<li id="section-6.1-2.1">Check if top-level domain maps to a local zone key.<a href="#section-6.1-2.1" class="pilcrow">¶</a>
</li>
@@ -2004,18 +1932,21 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
</ol>
<p id="section-6.1-3">
If the TLD is a Base32-encoded public zone key "zk", the entry
- zone of the resolution process is implicitly given by the name.<a href="#section-6.1-3" class="pilcrow">¶</a></p>
+ zone of the resolution process is implicitly given by the name.
+ <a href="#section-6.1-3" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-6.1-4">
<pre>
Example name: www.example.<Base32(zk)>
=> Entry zone: zk
=> Name to resolve from entry zone: www.example
- </pre><a href="#section-6.1-4" class="pilcrow">¶</a>
+ </pre>
+<a href="#section-6.1-4" class="pilcrow">¶</a>
</div>
<p id="section-6.1-5">
Each local zone is associated with a single GNS label. If this label
is the top-level domain (TLD) of the name to resolve, resolution
- MUST start from this local zone.<a href="#section-6.1-5" class="pilcrow">¶</a></p>
+ MUST start from this local zone.
+ <a href="#section-6.1-5" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-6.1-6">
<pre>
Example name: www.example.gnu
@@ -2026,7 +1957,8 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
...
=> Entry zone: zk1
=> Name to resolve from entry zone: www.example
- </pre><a href="#section-6.1-6" class="pilcrow">¶</a>
+ </pre>
+<a href="#section-6.1-6" class="pilcrow">¶</a>
</div>
<p id="section-6.1-7">
If no matching local zone for the TLD is found, external prefix to
@@ -2036,7 +1968,8 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
The prefix may consist of multiple GNS labels concatenated with a
".". If multiple prefixes match the name to resolve, the longest
prefix is chosen. The prefix length of two results cannot be equal,
- as this would indicate a misconfiguration.<a href="#section-6.1-7" class="pilcrow">¶</a></p>
+ as this would indicate a misconfiguration.
+ <a href="#section-6.1-7" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-6.1-8">
<pre>
Example name: www.example.gnu
@@ -2047,7 +1980,8 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
...
=> Entry zone: zk1
=> Name to resolve from entry zone: www
- </pre><a href="#section-6.1-8" class="pilcrow">¶</a>
+ </pre>
+<a href="#section-6.1-8" class="pilcrow">¶</a>
</div>
</section>
</div>
@@ -2059,12 +1993,14 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<p id="section-6.2-1">
In order to resolve a name in GNS, a type MAY be given.
However, filtering of record results according to type is done after
- the resource record set is retrieved.<a href="#section-6.2-1" class="pilcrow">¶</a></p>
+ the resource record set is retrieved.
+ <a href="#section-6.2-1" class="pilcrow">¶</a></p>
<p id="section-6.2-2">
In each step of the recursive name resolution, there is an
authoritative zone zk and a name to resolve which may be empty.
Initially, the authoritative zone is the entry zone. If the name
- is empty, it is interpreted as the apex label "@".<a href="#section-6.2-2" class="pilcrow">¶</a></p>
+ is empty, it is interpreted as the apex label "@".
+ <a href="#section-6.2-2" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal" id="section-6.2-3">
<li id="section-6.2-3.1">Extract the right-most label from the name to look up.<a href="#section-6.2-3.1" class="pilcrow">¶</a>
</li>
@@ -2080,7 +2016,8 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
provided signature, the resolver MUST check that the authoritative
zone key was used to sign the record:
The derived zone key "h*zk" must match the public key provided in
- the RRBLOCK.<a href="#section-6.2-4" class="pilcrow">¶</a></p>
+ the RRBLOCK.
+ <a href="#section-6.2-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="record_processing">
@@ -2093,17 +2030,20 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
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>
+ 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
continued with the PKEY as authoritative zone and the empty apex
label "@" as remaining name. If the record type to be resolved is
- PKEY, the PKEY record set is returned and the resolution is concluded.<a href="#section-6.3-2" class="pilcrow">¶</a></p>
+ PKEY, the PKEY record set is returned and the resolution is concluded.
+ <a href="#section-6.3-2" class="pilcrow">¶</a></p>
<p id="section-6.3-3">
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>
+ 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">
@@ -2112,7 +2052,8 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<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>
+ 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">
@@ -2134,7 +2075,8 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
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>
+ 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">
@@ -2150,13 +2092,15 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
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>
+ 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>
+ CNAMEs using an upper bound.
+ <a href="#section-6.3.3-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="box_processing">
@@ -2169,7 +2113,8 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
must unbox it if the name to be resolved continues with "_SERVICE._PROTO",
otherwise it is to be left untouched. This way, TLSA (and SRV)
records do not require a separate network request, and TLSA
- records become inseparable from the corresponding address records.<a href="#section-6.3.4-1" class="pilcrow">¶</a></p>
+ records become inseparable from the corresponding address records.
+ <a href="#section-6.3.4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="vpn_processing">
@@ -2183,7 +2128,8 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
tunnel and return the IPv4 or IPv6 tunnel address, respectively.
The type of tunnel depends on the contents of the VPN record data.
No result is returned if the resolver implementation does not
- support any of the tunnnels provided in the VPN records.<a href="#section-6.3.5-1" class="pilcrow">¶</a></p>
+ support any of the tunnnels provided in the VPN records.
+ <a href="#section-6.3.5-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
@@ -2200,9 +2146,11 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
This object must be signed using the private zone key.
The revocation object is flooded in the overlay network. To prevent
flooding attacks, the revocation message must contain a proof-of-work.
- The revocation message may be calculated ahead of time.<a href="#section-7-1" class="pilcrow">¶</a></p>
+ The revocation message may be calculated ahead of time.
+ <a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">
- A revocation message is defined as follows:<a href="#section-7-2" class="pilcrow">¶</a></p>
+ A revocation message is defined as follows:
+ <a href="#section-7-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="security">
@@ -2211,7 +2159,8 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
</h2>
<p id="section-8-1">
- TODO<a href="#section-8-1" class="pilcrow">¶</a></p>
+ TODO
+ <a href="#section-8-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana">
@@ -2220,7 +2169,8 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
</h2>
<p id="section-9-1">
- This will be fun<a href="#section-9-1" class="pilcrow">¶</a></p>
+ This will be fun
+ <a href="#section-9-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-10">
@@ -2229,7 +2179,8 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
</h2>
<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>
+ 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"
@@ -2328,56 +2279,67 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
642920eee8e7a65a
001fd19a6406a721
713f0a0d
- </pre><a href="#section-10-2" class="pilcrow">¶</a>
+ </pre>
+<a href="#section-10-2" class="pilcrow">¶</a>
</div>
</section>
<section id="section-11">
<h2 id="name-normative-references">
-<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
+<a href="#name-normative-references" class="section-name selfRef">Normative References</a>
</h2>
<dl class="references">
<dt id="RFC1034">[RFC1034]</dt>
<dd>
-<span class="refAuthor">Mockapetris, P.</span>, <span class="refTitle">"Domain names - concepts and facilities"</span>, <span class="seriesInfo">STD 13</span>, <span class="seriesInfo">RFC 1034</span>, <span class="seriesInfo">DOI 10.17487/RFC1034</span>, <time datetime="1987-11">November 1987</time>, <span><<a href="https://www.rfc-editor.org/info/rfc1034">https://www.rfc-editor.org/info/rfc1034</a>></span>. </dd>
+<span class="refAuthor">Mockapetris, P.V.</span>, <span class="refTitle">"Domain names - concepts and facilities"</span>, <span class="seriesInfo">STD13</span>, <span class="seriesInfo">RFC1034</span>, <span class="seriesInfo">DOI10.17487/RFC1034</span>, <time datetime="1987-11">November 1987</time>
+ <span>, <<a href="https://www.rfc-editor.org/info/rfc1034">https://www.rfc-editor.org/info/rfc1034</a>></span>. </dd>
<dt id="RFC1035">[RFC1035]</dt>
<dd>
-<span class="refAuthor">Mockapetris, P.</span>, <span class="refTitle">"Domain names - implementation and specification"</span>, <span class="seriesInfo">STD 13</span>, <span class="seriesInfo">RFC 1035</span>, <span class="seriesInfo">DOI 10.17487/RFC1035</span>, <time datetime="1987-11">November 1987</time>, <span><<a href="https://www.rfc-editor.org/info/rfc1035">https://www.rfc-editor.org/info/rfc1035</a>></span>. </dd>
+<span class="refAuthor">Mockapetris, P.V.</span>, <span class="refTitle">"Domain names - implementation and specification"</span>, <span class="seriesInfo">STD13</span>, <span class="seriesInfo">RFC1035</span>, <span class="seriesInfo">DOI10.17487/RFC1035</span>, <time datetime="1987-11">November 1987</time>
+ <span>, <<a href="https://www.rfc-editor.org/info/rfc1035">https://www.rfc-editor.org/info/rfc1035</a>></span>. </dd>
+<dt id="RFC2119">[RFC2119]</dt>
+ <dd>
+<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP14</span>, <span class="seriesInfo">RFC2119</span>, <span class="seriesInfo">DOI10.17487/RFC2119</span>, <time datetime="1997-03">March 1997</time>
+ <span>, <<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>></span>. </dd>
<dt id="RFC2782">[RFC2782]</dt>
<dd>
-<span class="refAuthor">Gulbrandsen, A.</span><span class="refAuthor">, Vixie, P.</span><span class="refAuthor">, and L. Esibov</span>, <span class="refTitle">"
- A DNS RR for specifying the location of services (DNS SRV)
- "</span>, <span class="seriesInfo">RFC 2782</span>, <span class="seriesInfo">DOI 10.17487/RFC2782</span>, <time datetime="2000-02">February 2000</time>, <span><<a href="https://www.rfc-editor.org/info/rfc2782">https://www.rfc-editor.org/info/rfc2782</a>></span>. </dd>
+<span class="refAuthor">Gulbrandsen, A.</span><span class="refAuthor">, Vixie, P.</span><span class="refAuthor">, and L. Esibov</span>, <span class="refTitle">"A DNS RR for specifying the location of services (DNS SRV)"</span>, <span class="seriesInfo">RFC2782</span>, <span class="seriesInfo">DOI10.17487/RFC2782</span>, <time datetime="2000-02">February 2000</time>
+ <span>, <<a href="https://www.rfc-editor.org/info/rfc2782">https://www.rfc-editor.org/info/rfc2782</a>></span>. </dd>
<dt id="RFC3629">[RFC3629]</dt>
<dd>
-<span class="refAuthor">Yergeau, F.</span>, <span class="refTitle">"UTF-8, a transformation format of ISO 10646"</span>, <span class="seriesInfo">STD 63</span>, <span class="seriesInfo">RFC 3629</span>, <span class="seriesInfo">DOI 10.17487/RFC3629</span>, <time datetime="2003-11">November 2003</time>, <span><<a href="https://www.rfc-editor.org/info/rfc3629">https://www.rfc-editor.org/info/rfc3629</a>></span>. </dd>
+<span class="refAuthor">Yergeau, F.</span>, <span class="refTitle">"UTF-8, a transformation format of ISO 10646"</span>, <span class="seriesInfo">STD63</span>, <span class="seriesInfo">RFC3629</span>, <span class="seriesInfo">DOI10.17487/RFC3629</span>, <time datetime="2003-11">November 2003</time>
+ <span>, <<a href="https://www.rfc-editor.org/info/rfc3629">https://www.rfc-editor.org/info/rfc3629</a>></span>. </dd>
<dt id="RFC3826">[RFC3826]</dt>
<dd>
-<span class="refAuthor">Blumenthal, U.</span><span class="refAuthor">, Maino, F.</span><span class="refAuthor">, and K. McCloghrie</span>, <span class="refTitle">"The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model"</span>, <span class="seriesInfo">RFC 3826</span>, <span class="seriesInfo">DOI 10.17487/RFC3826</span>, <time datetime="2004-06">June 2004</time>, <span><<a href="https://www.rfc-editor.org/info/rfc3826">https://www.rfc-editor.org/info/rfc3826</a>></span>. </dd>
+<span class="refAuthor">Blumenthal, U.</span><span class="refAuthor">, Maino, F.</span><span class="refAuthor">, and K. McCloghrie</span>, <span class="refTitle">"The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model"</span>, <span class="seriesInfo">RFC3826</span>, <span class="seriesInfo">DOI10.17487/RFC3826</span>, <time datetime="2004-06">June 2004</time>
+ <span>, <<a href="https://www.rfc-editor.org/info/rfc3826">https://www.rfc-editor.org/info/rfc3826</a>></span>. </dd>
<dt id="RFC5869">[RFC5869]</dt>
<dd>
-<span class="refAuthor">Krawczyk, H.</span><span class="refAuthor"> and P. Eronen</span>, <span class="refTitle">"
- HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
- "</span>, <span class="seriesInfo">RFC 5869</span>, <span class="seriesInfo">DOI 10.17487/RFC5869</span>, <time datetime="2010-05">May 2010</time>, <span><<a href="https://www.rfc-editor.org/info/rfc5869">https://www.rfc-editor.org/info/rfc5869</a>></span>. </dd>
+<span class="refAuthor">Krawczyk, H.</span><span class="refAuthor"> and P. Eronen</span>, <span class="refTitle">"HMAC-based Extract-and-Expand Key Derivation Function (HKDF)"</span>, <span class="seriesInfo">RFC5869</span>, <span class="seriesInfo">DOI10.17487/RFC5869</span>, <time datetime="2010-05">May 2010</time>
+ <span>, <<a href="https://www.rfc-editor.org/info/rfc5869">https://www.rfc-editor.org/info/rfc5869</a>></span>. </dd>
<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>
+<span class="refAuthor">Klensin, J.</span>, <span class="refTitle">"Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework"</span>, <span class="seriesInfo">RFC5890</span>, <span class="seriesInfo">DOI10.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="RFC5891">[RFC5891]</dt>
<dd>
-<span class="refAuthor">Klensin, J.</span>, <span class="refTitle">"Internationalized Domain Names in Applications (IDNA): Protocol"</span>, <span class="seriesInfo">RFC 5891</span>, <span class="seriesInfo">DOI 10.17487/RFC5891</span>, <time datetime="2010-08">August 2010</time>, <span><<a href="https://www.rfc-editor.org/info/rfc5891">https://www.rfc-editor.org/info/rfc5891</a>></span>. </dd>
+<span class="refAuthor">Klensin, J.</span>, <span class="refTitle">"Internationalized Domain Names in Applications (IDNA): Protocol"</span>, <span class="seriesInfo">RFC5891</span>, <span class="seriesInfo">DOI10.17487/RFC5891</span>, <time datetime="2010-08">August 2010</time>
+ <span>, <<a href="https://www.rfc-editor.org/info/rfc5891">https://www.rfc-editor.org/info/rfc5891</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>
+<span class="refAuthor">Eastlake 3rd, D.</span>, <span class="refTitle">"Domain Name System (DNS) IANA Considerations"</span>, <span class="seriesInfo">BCP42</span>, <span class="seriesInfo">RFC6895</span>, <span class="seriesInfo">DOI10.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">"
- Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)
- "</span>, <span class="seriesInfo">RFC 6979</span>, <span class="seriesInfo">DOI 10.17487/RFC6979</span>, <time datetime="2013-08">August 2013</time>, <span><<a href="https://www.rfc-editor.org/info/rfc6979">https://www.rfc-editor.org/info/rfc6979</a>></span>. </dd>
+<span class="refAuthor">Pornin, T.</span>, <span class="refTitle">"Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)"</span>, <span class="seriesInfo">RFC6979</span>, <span class="seriesInfo">DOI10.17487/RFC6979</span>, <time datetime="2013-08">August 2013</time>
+ <span>, <<a href="https://www.rfc-editor.org/info/rfc6979">https://www.rfc-editor.org/info/rfc6979</a>></span>. </dd>
<dt id="RFC7748">[RFC7748]</dt>
<dd>
-<span class="refAuthor">Langley, A.</span><span class="refAuthor">, Hamburg, M.</span><span class="refAuthor">, and S. Turner</span>, <span class="refTitle">"Elliptic Curves for Security"</span>, <span class="seriesInfo">RFC 7748</span>, <span class="seriesInfo">DOI 10.17487/RFC7748</span>, <time datetime="2016-01">January 2016</time>, <span><<a href="https://www.rfc-editor.org/info/rfc7748">https://www.rfc-editor.org/info/rfc7748</a>></span>. </dd>
+<span class="refAuthor">Langley, A.</span><span class="refAuthor">, Hamburg, M.</span><span class="refAuthor">, and S. Turner</span>, <span class="refTitle">"Elliptic Curves for Security"</span>, <span class="seriesInfo">RFC7748</span>, <span class="seriesInfo">DOI10.17487/RFC7748</span>, <time datetime="2016-01">January 2016</time>
+ <span>, <<a href="https://www.rfc-editor.org/info/rfc7748">https://www.rfc-editor.org/info/rfc7748</a>></span>. </dd>
<dt id="RFC8032">[RFC8032]</dt>
<dd>
-<span class="refAuthor">Josefsson, S.</span><span class="refAuthor"> and I. Liusvaara</span>, <span class="refTitle">"Edwards-Curve Digital Signature Algorithm (EdDSA)"</span>, <span class="seriesInfo">RFC 8032</span>, <span class="seriesInfo">DOI 10.17487/RFC8032</span>, <time datetime="2017-01">January 2017</time>, <span><<a href="https://www.rfc-editor.org/info/rfc8032">https://www.rfc-editor.org/info/rfc8032</a>></span>. </dd>
+<span class="refAuthor">Josefsson, S.</span><span class="refAuthor"> and I. Liusvaara</span>, <span class="refTitle">"Edwards-Curve Digital Signature Algorithm (EdDSA)"</span>, <span class="seriesInfo">RFC8032</span>, <span class="seriesInfo">DOI10.17487/RFC8032</span>, <time datetime="2017-01">January 2017</time>
+ <span>, <<a href="https://www.rfc-editor.org/info/rfc8032">https://www.rfc-editor.org/info/rfc8032</a>></span>. </dd>
<dt id="TWOFISH">[TWOFISH]</dt>
<dd>
<span class="refAuthor">Schneier, B.</span>, <span class="refTitle">"
@@ -2391,38 +2353,38 @@ async function addMetadata(){try{const e=document.styleSheets[0].cssRules;for(le
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
</h2>
<address class="vcard">
- <div dir="auto" class="left"><span class="fn nameRole">Martin Schanzenbach</span></div>
-<div dir="auto" class="left"><span class="org">GNUnet e.V.</span></div>
-<div dir="auto" class="left"><span class="street-address">Boltzmannstrasse 3</span></div>
-<div dir="auto" class="left">
+ <div dir="auto"><span class="fn nameRole">Martin Schanzenbach</span></div>
+<div dir="auto"><span class="org">GNUnet e.V.</span></div>
+<div dir="auto"><span class="street-address">Boltzmannstrasse 3</span></div>
+<div dir="auto">
<span class="postal-code">85748</span> <span class="locality">Garching</span>
</div>
-<div dir="auto" class="left"><span class="country-name">Germany</span></div>
+<div dir="auto"><span class="country-name">Germany</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:schanzen@gnunet.org" class="email">schanzen@gnunet.org</a>
</div>
</address>
<address class="vcard">
- <div dir="auto" class="left"><span class="fn nameRole">Christian Grothoff</span></div>
-<div dir="auto" class="left"><span class="org">Berner Fachhochschule</span></div>
-<div dir="auto" class="left"><span class="street-address">Hoeheweg 80</span></div>
-<div dir="auto" class="left">CH-<span class="postal-code">2501</span> <span class="locality">Biel/Bienne</span>
+ <div dir="auto"><span class="org">Berner Fachhochschule</span></div>
+<div dir="auto"><span class="fn nameRole">Christian Grothoff</span></div>
+<div dir="auto"><span class="street-address">Hoeheweg 80</span></div>
+<div dir="auto">CH-<span class="postal-code">2501</span> <span class="locality">Biel/Bienne</span>
</div>
-<div dir="auto" class="left"><span class="country-name">Switzerland</span></div>
+<div dir="auto"><span class="country-name">Switzerland</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:schanzen@gnunet.org" class="email">schanzen@gnunet.org</a>
</div>
</address>
<address class="vcard">
- <div dir="auto" class="left"><span class="fn nameRole">Bernd Fix</span></div>
-<div dir="auto" class="left"><span class="org">GNUnet e.V.</span></div>
-<div dir="auto" class="left"><span class="street-address">Boltzmannstrasse 3</span></div>
-<div dir="auto" class="left">
+ <div dir="auto"><span class="fn nameRole">Bernd Fix</span></div>
+<div dir="auto"><span class="org">GNUnet e.V.</span></div>
+<div dir="auto"><span class="street-address">Boltzmannstrasse 3</span></div>
+<div dir="auto">
<span class="postal-code">85748</span> <span class="locality">Garching</span>
</div>
-<div dir="auto" class="left"><span class="country-name">Germany</span></div>
+<div dir="auto"><span class="country-name">Germany</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:fix@gnunet.org" class="email">fix@gnunet.org</a>
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
@@ -5,10 +5,10 @@
Independent Stream M. Schanzenbach
Internet-Draft GNUnet e.V.
Intended status: Informational C. Grothoff
-Expires: 24 January 2020 Berner Fachhochschule
+Expires: 13 May 2020 Berner Fachhochschule
B. Fix
GNUnet e.V.
- 23 July 2019
+ 10 November 2019
The GNU Name System Specification
@@ -34,7 +34,7 @@ Status of This Memo
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
- This Internet-Draft will expire on 24 January 2020.
+ This Internet-Draft will expire on 13 May 2020.
Copyright Notice
@@ -42,7 +42,7 @@ Copyright Notice
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents (https://trustee.ietf.org/
+ Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
@@ -50,46 +50,38 @@ Copyright Notice
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 1]
-
-Internet-Draft The GNU Name System July 2019
-
-
Table of Contents
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
- 2. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3. Resource Records . . . . . . . . . . . . . . . . . . . . . . 4
- 3.1. Record Types . . . . . . . . . . . . . . . . . . . . . . 5
- 3.2. PKEY . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 3.3. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 3.4. LEHO . . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 3.5. NICK . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 3.6. BOX . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 3.7. VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
- 4. Publishing Records . . . . . . . . . . . . . . . . . . . . . 10
- 4.1. Key Derivations . . . . . . . . . . . . . . . . . . . . . 10
- 4.2. Resource Records Block . . . . . . . . . . . . . . . . . 11
- 4.3. Record Data Encryption and Decryption . . . . . . . . . . 12
- 5. Internationalization and Character Encoding . . . . . . . . . 15
- 6. Name Resolution . . . . . . . . . . . . . . . . . . . . . . . 15
- 6.1. Entry Zone . . . . . . . . . . . . . . . . . . . . . . . 15
- 6.2. Record Retrieval . . . . . . . . . . . . . . . . . . . . 16
- 6.3. Record Processing . . . . . . . . . . . . . . . . . . . . 16
- 6.3.1. PKEY . . . . . . . . . . . . . . . . . . . . . . . . 17
- 6.3.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . 17
- 6.3.3. CNAME . . . . . . . . . . . . . . . . . . . . . . . . 17
- 6.3.4. BOX . . . . . . . . . . . . . . . . . . . . . . . . . 18
- 6.3.5. VPN . . . . . . . . . . . . . . . . . . . . . . . . . 18
- 7. Zone Revocation . . . . . . . . . . . . . . . . . . . . . . . 18
- 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
- 10. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 18
- 11. Normative References . . . . . . . . . . . . . . . . . . . . 20
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
+ 1. Introduction
+ 2. Zones
+ 3. Resource Records
+ 3.1. Record Types
+ 3.2. PKEY
+ 3.3. GNS2DNS
+ 3.4. LEHO
+ 3.5. NICK
+ 3.6. BOX
+ 3.7. VPN
+ 4. Publishing Records
+ 4.1. Key Derivations
+ 4.2. Resource Records Block
+ 4.3. Record Data Encryption and Decryption
+ 5. Internationalization and Character Encoding
+ 6. Name Resolution
+ 6.1. Entry Zone
+ 6.2. Record Retrieval
+ 6.3. Record Processing
+ 6.3.1. PKEY
+ 6.3.2. GNS2DNS
+ 6.3.3. CNAME
+ 6.3.4. BOX
+ 6.3.5. VPN
+ 7. Zone Revocation
+ 8. Security Considerations
+ 9. IANA Considerations
+ 10. Test Vectors
+ 11. Normative References
+ Authors' Addresses
1. Introduction
@@ -106,14 +98,6 @@ Table of Contents
vulnerable, especially to attackers that have the technical
capabilities of an entire nation state at their disposal. This
specification describes a censorship-resistant, privacy-preserving
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 2]
-
-Internet-Draft The GNU Name System July 2019
-
-
and decentralized name system: The GNU Name System (GNS). It is
designed to provide a secure alternative to DNS, especially when
censorship or manipulation is encountered. GNS can bind names to any
@@ -139,6 +123,10 @@ Internet-Draft The GNU Name System July 2019
resolution processes, cryptographic routines and security
considerations for use by implementors.
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
2. Zones
@@ -149,29 +137,21 @@ Internet-Draft The GNU Name System July 2019
([RFC6979]). In the following, we use the following naming
convention for our cryptographic primitives:
- d is a 256-bit ECDSA private key. In GNS, records are signed using
- a key derived from "d" as described in Section 4.
+ d is a 256-bit ECDSA private key. In GNS, records are signed using
+ a key derived from "d" as described in Section 4.
- p is the prime of edwards25519 as defined in [RFC7748], i.e. 2^255
- - 19.
+ p is the prime of edwards25519 as defined in [RFC7748], i.e. 2^255
+ - 19.
- B is the group generator (X(P),Y(P)) of edwards25519 as defined in
- [RFC7748].
+ B is the group generator (X(P),Y(P)) of edwards25519 as defined in
+ [RFC7748].
- L is the prime-order subgroup of edwards25519 in [RFC7748].
+ L is the prime-order subgroup of edwards25519 in [RFC7748].
zk is the ECDSA public key corresponding to d. It is defined in
- [RFC6979] as the curve point d*B where B is the group generator of
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 3]
-
-Internet-Draft The GNU Name System July 2019
-
-
- the elliptic curve. The public key is used to uniquely identify a
- GNS zone and is referred to as the "zone key".
+ [RFC6979] as the curve point d*B where B is the group generator
+ of the elliptic curve. The public key is used to uniquely
+ identify a GNS zone and is referred to as the "zone key".
3. Resource Records
@@ -201,30 +181,25 @@ Internet-Draft The GNU Name System July 2019
where:
EXPIRATION denotes the absolute 64-bit expiration date of the
- record. In microseconds since midnight (0 hour), January 1, 1970
- in network byte order.
+ record. In microseconds since midnight (0 hour), January
+ 1, 1970 in network byte order.
- DATA SIZE denotes the 32-bit size of the DATA field in bytes and in
- network byte order.
+ DATA SIZE denotes the 32-bit size of the DATA field in bytes and in
+ network byte order.
- TYPE is the 32-bit resource record type. This type can be one of
- the GNS resource records as defined in Section 3 or a DNS record
- type as 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 ([RFC6895]).
+ TYPE is the 32-bit resource record type. This type can be one
+ of the GNS resource records as defined in Section 3 or a
+ DNS record type as 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 ([RFC6895]).
- FLAGS is a 32-bit resource record flags field (see below).
-
- DATA the variable-length resource record data payload. The contents
- are defined by the respective type of the resource record.
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 4]
-
-Internet-Draft The GNU Name System July 2019
+ FLAGS is a 32-bit resource record flags field (see below).
+ DATA the variable-length resource record data payload. The
+ contents are defined by the respective type of the
+ resource record.
Flags indicate metadata surrounding the resource record. A flag
value of 0 indicates that all flags are unset. The following
@@ -240,24 +215,25 @@ Internet-Draft The GNU Name System July 2019
where:
- SHADOW If this flag is set, this record should be ignored by
- resolvers unless all (other) records of the same record type have
- expired. Used to allow zone publishers to facilitate good
- performance when records change by allowing them to put future
- values of records into the DHT. This way, future values can
- propagate and may be cached before the transition becomes active.
+ SHADOW If this flag is set, this record should be ignored by
+ resolvers unless all (other) records of the same record type
+ have expired. Used to allow zone publishers to facilitate
+ good performance when records change by allowing them to put
+ future values of records into the DHT. This way, future
+ values can propagate and may be cached before the transition
+ becomes active.
- EXPREL The expiration time value of the record is a relative time
- (still in microseconds) and not an absolute time. This flag
- should never be encountered by a resolver for records obtained
- from the DHT, but might be present when a resolver looks up
- private records of a zone hosted locally.
+ EXPREL The expiration time value of the record is a relative time
+ (still in microseconds) and not an absolute time. This flag
+ should never be encountered by a resolver for records
+ obtained from the DHT, but might be present when a resolver
+ looks up private records of a zone hosted locally.
PRIVATE This is a private record of this peer and it should thus not
- be published in the DHT. Thus, this flag should never be
- encountered by a resolver for records obtained from the DHT.
- Private records should still be considered just like regular
- records when resolving labels in local zones.
+ be published in the DHT. Thus, this flag should never be
+ encountered by a resolver for records obtained from the DHT.
+ Private records should still be considered just like regular
+ records when resolving labels in local zones.
3.1. Record Types
@@ -265,23 +241,6 @@ Internet-Draft The GNU Name System July 2019
type numbers for DNS. The following is a list of defined and
reserved record types in GNS:
-
-
-
-
-
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 5]
-
-Internet-Draft The GNU Name System July 2019
-
-
Number | Type | Comment
------------------------------------------------------------
65536 | PKEY | GNS delegation
@@ -325,19 +284,6 @@ Internet-Draft The GNU Name System July 2019
format defined in [RFC1034] for DNS names. A GNS2DNS 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
+-----+-----+-----+-----+-----+-----+-----+-----+
| DNS NAME |
@@ -355,11 +301,12 @@ Internet-Draft The GNU Name System July 2019
where:
- DNS NAME The name to continue with in DNS (0-terminated).
+ DNS NAME The name to continue with in DNS (0-terminated).
DNS SERVER NAME The DNS server to use. May be an IPv4/IPv6 address
- in dotted decimal form or a DNS name. It may also be a relative
- GNS name ending with a "+" top-level domain. (all 0-terminated)
+ in dotted decimal form or a DNS name. It may also
+ be a relative GNS name ending with a "+" top-level
+ domain. (all 0-terminated)
3.4. LEHO
@@ -383,16 +330,7 @@ Internet-Draft The GNU Name System July 2019
where:
LEGACY HOSTNAME A UTF-8 string (which is not 0-terminated)
- representing the legacy hostname.
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 7]
-
-Internet-Draft The GNU Name System July 2019
-
+ representing the legacy hostname.
NOTE: If an application uses a LEHO value in an HTTP request header
(e.g. "Host:" header) it must be converted to a punycode
@@ -420,8 +358,8 @@ Internet-Draft The GNU Name System July 2019
where:
NICKNAME A UTF-8 string (which is not 0-terminated) representing the
- preferred label of the zone. This string MUST NOT inlcude a "."
- character.
+ preferred label of the zone. This string MUST NOT inlcude
+ a "." character.
3.6. BOX
@@ -436,20 +374,6 @@ Internet-Draft The GNU Name System July 2019
(PROTO) 6 (tcp) and record_type "TLSA". For reference, see also
[RFC2782] A BOX DATA entry has the following format:
-
-
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 8]
-
-Internet-Draft The GNU Name System July 2019
-
-
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| PROTO | SVC | TYPE |
@@ -464,17 +388,17 @@ Internet-Draft The GNU Name System July 2019
where:
- PROTO the 16-bit protocol number, e.g. 6 for tcp. In network byte
- order.
+ PROTO the 16-bit protocol number, e.g. 6 for tcp. In network
+ byte order.
- SVC the 16-bit service value of the boxed record, i.e. the port
- number. In network byte order.
+ SVC the 16-bit service value of the boxed record, i.e. the
+ port number. In network byte order.
- TYPE is the 32-bit record type of the boxed record. In network byte
- order.
+ TYPE is the 32-bit record type of the boxed record. In
+ network byte order.
RECORD DATA is a variable length field containing the "DATA" format
- of TYPE as defined for the respective TYPE in DNS.
+ of TYPE as defined for the respective TYPE in DNS.
3.7. VPN
@@ -495,17 +419,6 @@ Internet-Draft The GNU Name System July 2019
Figure 9
-
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 9]
-
-Internet-Draft The GNU Name System July 2019
-
-
4. Publishing Records
GNS resource records are published in a distributed hash table (DHT).
@@ -531,36 +444,28 @@ Internet-Draft The GNU Name System July 2019
SHA256 for the expansion phase.
PRK_h is key material retrieved using an HKDF using the string "key-
- derivation" as salt and the public zone key "zk" as initial keying
- material.
+ derivation" as salt and the public zone key "zk" as initial
+ keying material.
- h is the 512-bit HKDF expansion result. The expansion info input is
- a concatenation of the label and string "gns".
+ h is the 512-bit HKDF expansion result. The expansion info
+ input is a concatenation of the label and string "gns".
- d is the 256-bit private zone key as defined in Section 2.
+ d is the 256-bit private zone key as defined in Section 2.
label is a UTF-8 string under which the resource records are
- published.
-
- d_h is a 256-bit private key derived from the "d" using the keying
- material "h".
-
- zk_h is a 256-bit public key derived from the zone key "zk" using
- the keying material "h".
-
- 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
- published. It is the SHA512 hash over the public key "zk_h"
- corresponding to the derived private key "d_h".
-
+ published.
+ d_h is a 256-bit private key derived from the "d" using the keying
+ material "h".
+ 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 10]
-
-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 published. It is the SHA512 hash over the public key
+ "zk_h" corresponding to the derived private key "d_h".
We point out that the multiplication of "zk" with "h" is a point
multiplication, while the multiplication of "d" with "h" is a scalar
@@ -604,48 +509,42 @@ Internet-Draft The GNU Name System July 2019
where:
- 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
- private key "d_h" (see Section 4).
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 11]
-
-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 private key "d_h" (see Section 4).
PUBLIC KEY is the 256-bit public key "zk_h" to be used to verify
- SIGNATURE. The wire format of this value is defined in [RFC8032],
- Section 5.1.5.
+ SIGNATURE. The wire format of this value is defined in
+ [RFC8032], Section 5.1.5.
- SIZE A 32-bit value containing the length of the signed data
- following the PUBLIC KEY field in network byte order. This value
- always includes the length of the fields SIZE (4), PURPOSE (4) and
- EXPIRATION (8) in addition to the length of the BDATA. While a
- 32-bit value is used, implementations MAY refuse to publish blocks
- beyond a certain size significantly below 4 GB. However, a
- minimum block size of 62 kilobytes MUST be supported.
+ SIZE A 32-bit value containing the length of the signed data
+ following the PUBLIC KEY field in network byte order.
+ This value always includes the length of the fields SIZE
+ (4), PURPOSE (4) and EXPIRATION (8) in addition to the
+ length of the BDATA. While a 32-bit value is used,
+ implementations MAY refuse to publish blocks beyond a
+ certain size significantly below 4 GB. However, a
+ minimum block size of 62 kilobytes MUST be supported.
- PURPOSE A 32-bit signature purpose flag. This field MUST be 15 (in
- network byte order).
+ PURPOSE A 32-bit signature purpose flag. This field MUST be 15
+ (in network byte order).
EXPIRATION Specifies when the RRBLOCK expires and the encrypted
- block SHOULD be removed from the DHT and caches as it is likely
- stale. However, applications MAY continue to use non-expired
- individual records until they expire. The value MUST be set to
- the expiration time of the resource record contained within this
- block 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.
+ block SHOULD be removed from the DHT and caches as it is
+ likely stale. However, applications MAY continue to use
+ non-expired individual records until they expire. The
+ value MUST be set to the expiration time of the resource
+ record contained within this block 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.
4.3. Record Data Encryption and Decryption
@@ -653,27 +552,6 @@ Internet-Draft The GNU Name System July 2019
set RDATA into the BDATA field of a GNS RRBLOCK. The wire format of
the RDATA looks as follows:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 12]
-
-Internet-Draft The GNU Name System July 2019
-
-
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| RR COUNT | EXPIRA- /
@@ -721,15 +599,6 @@ Internet-Draft The GNU Name System July 2019
records block payload, the key material "K" and initialization vector
"IV" for the symmetric cipher are derived as follows:
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 13]
-
-Internet-Draft The GNU Name System July 2019
-
-
PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk)
K := HKDF-Expand (PRK_k, label, 512 / 8);
@@ -779,13 +648,6 @@ Internet-Draft The GNU Name System July 2019
RDATA := AES(AES KEY, AES IV, TWOFISH(TWOFISH KEY, TWOFISH IV, BDATA))
BDATA := TWOFISH(TWOFISH KEY, TWOFISH IV, AES(AES KEY, AES IV, RDATA))
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 14]
-
-Internet-Draft The GNU Name System July 2019
-
-
5. Internationalization and Character Encoding
All labels in GNS are encoded in UTF-8 [RFC3629]. This does not
@@ -834,14 +696,6 @@ Internet-Draft The GNU Name System July 2019
SHOULD be configurable through the GNS implementation. A mapping has
the form "prefix = public zone key". The prefix may consist of
multiple GNS labels concatenated with a ".". If multiple prefixes
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 15]
-
-Internet-Draft The GNU Name System July 2019
-
-
match the name to resolve, the longest prefix is chosen. The prefix
length of two results cannot be equal, as this would indicate a
misconfiguration.
@@ -890,14 +744,6 @@ Internet-Draft The GNU Name System July 2019
If the remainder of the name to resolve is empty but we have received
a record set containing only a single PKEY record, the recursion is
continued with the PKEY as authoritative zone and the empty apex
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 16]
-
-Internet-Draft The GNU Name System July 2019
-
-
label "@" as remaining name. If the record type to be resolved is
PKEY, the PKEY record set is returned and the resolution is
concluded.
@@ -942,18 +788,6 @@ Internet-Draft The GNU Name System July 2019
prevent infinite loops, the resolver should implement loop detections
or limit the recursive resolution of CNAMEs using an upper bound.
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 17]
-
-Internet-Draft The GNU Name System July 2019
-
-
6.3.4. BOX
When a BOX record is received, a GNS resolver must unbox it if the
@@ -1002,14 +836,6 @@ Internet-Draft The GNU Name System July 2019
f89333903b284fe8
1878bf47f3b39da0
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 18]
-
-Internet-Draft The GNU Name System July 2019
-
-
zk (public zone key) :=
dff911496d025d7e
0885c03d19153e99
@@ -1058,14 +884,6 @@ Internet-Draft The GNU Name System July 2019
3425e8a811ae59d2
99e2747285d2a479
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 19]
-
-Internet-Draft The GNU Name System July 2019
-
-
TWOFISH_IV :=
071be189a9d236f9
b4a3654bb8c281d4
@@ -1109,23 +927,19 @@ Internet-Draft The GNU Name System July 2019
11. Normative References
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
- <https://www.rfc-editor.org/info/rfc1034>.
+ [RFC1034] Mockapetris, P.V., "Domain names - concepts and
+ facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034,
+ November 1987, <https://www.rfc-editor.org/info/rfc1034>.
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 20]
-
-Internet-Draft The GNU Name System July 2019
-
-
- [RFC1035] Mockapetris, P., "Domain names - implementation and
+ [RFC1035] Mockapetris, P.V., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000,
@@ -1169,15 +983,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 21]
-
-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,
@@ -1197,8 +1002,8 @@ Authors' Addresses
Email: schanzen@gnunet.org
- Christian Grothoff
Berner Fachhochschule
+ Christian Grothoff
Hoeheweg 80
CH-2501 Biel/Bienne
Switzerland
@@ -1213,20 +1018,3 @@ Authors' Addresses
Germany
Email: fix@gnunet.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schanzenbach, et al. Expires 24 January 2020 [Page 22]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
@@ -1,7 +1,18 @@
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" [
-<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
+<!ENTITY RFC1034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml">
+<!ENTITY RFC1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
+<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
+<!ENTITY RFC2782 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml">
<!ENTITY RFC3629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml">
+<!ENTITY RFC3826 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3826.xml">
+<!ENTITY RFC5869 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5869.xml">
+<!ENTITY RFC5890 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml">
+<!ENTITY RFC5891 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5891.xml">
+<!ENTITY RFC6895 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6895.xml">
+<!ENTITY RFC6979 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6979.xml">
+<!ENTITY RFC7748 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7748.xml">
+<!ENTITY RFC8032 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8032.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
@@ -54,7 +65,7 @@
</address>
</author>
- <date day="23" month="July" year="2019"/>
+ <date day="10" month="November" year="2019"/>
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Independent Stream</workgroup>
@@ -106,6 +117,12 @@
cryptographic routines and security considerations for use by implementors.
</t>
<t>
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+ NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described
+ in <xref target="RFC2119"/>.
+ </t>
+ <t>
</t>
</section>
@@ -1124,89 +1141,21 @@
<back>
<references>
<name>Normative References</name>
- <reference anchor="RFC7748" target="https://www.rfc-editor.org/info/rfc7748"><front><title>Elliptic Curves for Security</title><author initials="A." surname="Langley" fullname="A. Langley"><organization/></author><author initials="M." surname="Hamburg" fullname="M. Hamburg"><organization/></author><author initials="S." surname="Turner" fullname="S. Turner"><organization/></author><date year="2016" month="January"/><abstract><t>This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.</t></abstract></front><seriesInfo name="RFC" value="7748"/><seriesInfo name="DOI" value="10.17487/RFC7748"/></reference>
- <reference anchor="RFC3826" target="https://www.rfc-editor.org/info/rfc3826"><front><title>The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model</title><author initials="U." surname="Blumenthal" fullname="U. Blumenthal"><organization/></author><author initials="F." surname="Maino" fullname="F. Maino"><organization/></author><author initials="K." surname="McCloghrie" fullname="K. McCloghrie"><organization/></author><date year="2004" month="June"/><abstract><t>This document describes a symmetric encryption protocol that supplements the protocols described in the User-based Security Model (USM), which is a Security Subsystem for version 3 of the Simple Network Management Protocol for use in the SNMP Architecture. The symmetric encryption protocol described in this document is based on the Advanced Encryption Standard (AES) cipher algorithm used in Cipher FeedBack Mode (CFB), with a key size of 128 bits. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="3826"/><seriesInfo name="DOI" value="10.17487/RFC3826"/></reference>
- <reference anchor="RFC5890" target="https://www.rfc-editor.org/info/rfc5890"><front><title>Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework</title><author initials="J." surname="Klensin" fullname="J. Klensin"><organization/></author><date year="2010" month="August"/><abstract><t>This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="5890"/><seriesInfo name="DOI" value="10.17487/RFC5890"/></reference>
- <reference anchor="RFC5891" target="https://www.rfc-editor.org/info/rfc5891"><front><title>Internationalized Domain Names in Applications (IDNA): Protocol</title><author initials="J." surname="Klensin" fullname="J. Klensin"><organization/></author><date year="2010" month="August"/><abstract><t>This document is the revised protocol definition for Internationalized Domain Names (IDNs). The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalized Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="5891"/><seriesInfo name="DOI" value="10.17487/RFC5891"/></reference>
- <reference anchor="RFC5869" target="https://www.rfc-editor.org/info/rfc5869">
- <front>
- <title>
- HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
- </title>
- <author initials="H." surname="Krawczyk" fullname="H. Krawczyk">
- <organization/>
- </author>
- <author initials="P." surname="Eronen" fullname="P. Eronen">
- <organization/>
- </author>
- <date year="2010" month="May"/>
- <abstract>
- <t>
- This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.
- </t>
- </abstract>
- </front>
- <seriesInfo name="RFC" value="5869"/>
- <seriesInfo name="DOI" value="10.17487/RFC5869"/>
- </reference>
- <reference anchor="RFC3629" target="https://www.rfc-editor.org/info/rfc3629"><front><title>UTF-8, a transformation format of ISO 10646</title><author initials="F." surname="Yergeau" fullname="F. Yergeau"><organization/></author><date year="2003" month="November"/><abstract><t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.</t></abstract></front><seriesInfo name="STD" value="63"/><seriesInfo name="RFC" value="3629"/><seriesInfo name="DOI" value="10.17487/RFC3629"/>
- </reference>
- <reference anchor="RFC8032" target="https://www.rfc-editor.org/info/rfc8032">
- <front>
- <title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title>
- <author initials="S." surname="Josefsson" fullname="S. Josefsson">
- <organization/>
- </author>
- <author initials="I." surname="Liusvaara" fullname="I. Liusvaara">
- <organization/>
- </author>
- <date year="2017" month="January"/>
- <abstract>
- <t>
- This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.
- </t>
- </abstract>
- </front>
- <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>
- <title>Domain names - implementation and specification</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 specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.
- </t>
- </abstract>
- </front>
- <seriesInfo name="STD" value="13"/>
- <seriesInfo name="RFC" value="1035"/>
- <seriesInfo name="DOI" value="10.17487/RFC1035"/>
- </reference>
- <reference anchor="RFC6979" target="https://www.rfc-editor.org/info/rfc6979">
- <front>
- <title>
- Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)
- </title>
- <author initials="T." surname="Pornin" fullname="T. Pornin">
- <organization/>
- </author>
- <date year="2013" month="August"/>
- <abstract>
- <t>
- This document defines a deterministic digital signature generation procedure. Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein. Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness.
- </t>
- </abstract>
- </front>
- <seriesInfo name="RFC" value="6979"/>
- <seriesInfo name="DOI" value="10.17487/RFC6979"/>
- </reference>
+
+ &RFC1034;
+ &RFC1035;
+ &RFC2782;
+ &RFC2119;
+ &RFC3629;
+ &RFC3826;
+ &RFC5869;
+ &RFC5890;
+ &RFC5891;
+ &RFC6895;
+ &RFC6979;
+ &RFC7748;
+ &RFC8032;
+
<reference anchor="TWOFISH">
<front>
<title>
@@ -1218,31 +1167,6 @@
<date year="1999" month="March"/>
</front>
</reference>
- <reference anchor="RFC2782" target="https://www.rfc-editor.org/info/rfc2782">
- <front>
- <title>
- A DNS RR for specifying the location of services (DNS SRV)
- </title>
- <author initials="A." surname="Gulbrandsen" fullname="A. Gulbrandsen">
- <organization/>
- </author>
- <author initials="P." surname="Vixie" fullname="P. Vixie">
- <organization/>
- </author>
- <author initials="L." surname="Esibov" fullname="L. Esibov">
- <organization/>
- </author>
- <date year="2000" month="February"/>
- <abstract>
- <t>
- This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. [STANDARDS-TRACK]
- </t>
- </abstract>
- </front>
- <seriesInfo name="RFC" value="2782"/>
- <seriesInfo name="DOI" value="10.17487/RFC2782"/>
- </reference>
-
<!-- <reference anchor="ISO20022">
<front>
