[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: update
|
From: |
gnunet |
|
Subject: |
[lsd0001] branch master updated: update |
|
Date: |
Sat, 30 Nov 2019 21:30:44 +0100 |
This is an automated email from the git hooks/post-receive script.
martin-schanzenbach pushed a commit to branch master
in repository lsd0001.
The following commit(s) were added to refs/heads/master by this push:
new a74f5a3 update
a74f5a3 is described below
commit a74f5a3b65f32f56f5ff097dd0ba29ac2853f47c
Author: Schanzenbach, Martin <address@hidden>
AuthorDate: Sat Nov 30 21:27:49 2019 +0100
update
---
draft-schanzen-gns.html | 734 +++++++++++++++++++++++++-----------------------
draft-schanzen-gns.txt | 508 ++++++++++++++++++++++++---------
draft-schanzen-gns.xml | 7 +-
3 files changed, 764 insertions(+), 485 deletions(-)
diff --git a/draft-schanzen-gns.html b/draft-schanzen-gns.html
index f9fc894..6899bb7 100644
--- a/draft-schanzen-gns.html
+++ b/draft-schanzen-gns.html
@@ -2,20 +2,35 @@
<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 name="author" content="Martin Schanzenbach">
-<meta name="author" content="Christian Grothoff">
-<meta name="author" content="Bernd Fix">
-<meta name="description" content="
+<meta content="Martin Schanzenbach" name="author">
+<meta content="Christian Grothoff" name="author">
+<meta content="Bernd Fix" name="author">
+<meta content="
This document contains the GNU Name System (GNS) technical
specification.
- ">
-<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 */
+ " 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 */
@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 */
@@ -181,11 +196,16 @@ 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 {
@@ -198,7 +218,7 @@ a {
text-decoration: none;
}
a[href] {
- color: #3E8EDE;
+ color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
background-color: #f2f2f2;
@@ -251,6 +271,7 @@ aside, blockquote {
}
blockquote {
background-color: #f9f9f9;
+ color: #111; /* Arlen: WCAG 2019 */
border: 1px solid #ddd;
border-radius: 3px;
margin: 1em 0;
@@ -294,7 +315,7 @@ table p {
/* pilcrow */
a.pilcrow {
- color: #777;
+ color: #666; /* Arlen: AHDJ 2019 */
text-decoration: none;
visibility: hidden;
user-select: none;
@@ -355,7 +376,7 @@ hr {
/* The prepared/rendered info at the very bottom of the page */
.docInfo {
- color: #999;
+ color: #666; /* Arlen: WCAG 2019 */
font-size: 0.9em;
font-style: italic;
margin-top: 2em;
@@ -469,17 +490,17 @@ hr.addr {
right: 0.2em;
padding: 0.2em;
content: "The RFC Editor will remove this note";
- color: #b76427;
- background-color: rgba(249, 232, 105, 0.3);
+ color: #9e2a00; /* Arlen: WCAG 2019 */
+ background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
position: relative;
padding-top: 1.8em;
- background-color: rgba(249, 232, 105, 0.3);
+ background-color: #ffd; /* Arlen: WCAG 2019 */
border-radius: 3px;
}
.cref {
- background-color: rgba(249, 232, 105, 0.3);
+ background-color: #ffd; /* Arlen: WCAG 2019 */
padding: 2px 4px;
}
.crefSource {
@@ -586,7 +607,7 @@ hr.addr {
/* pagination */
@media print {
body {
- font-family: 'Noto Serif', "Times New Roman", Times, serif;
+
width: 100%;
}
p {
@@ -628,6 +649,9 @@ 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();
}
@@ -651,6 +675,7 @@ hr.addr {
.ears tfoot .right {
string-set: ears-bottom-right content();
}
+*/
@page :first {
padding-top: 0;
@@ -672,6 +697,9 @@ 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;
@@ -707,10 +735,15 @@ 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;
@@ -769,10 +802,12 @@ 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;
@@ -833,10 +868,18 @@ caption {
script don't end up on the other side of the page. */
address.vcard {
- max-width: 20em;
+ max-width: 30em;
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 {
@@ -856,10 +899,80 @@ 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 rel="stylesheet" href="rfc-local.css" type="text/css">
+<link href="rfc-local.css" type="text/css" rel="stylesheet">
</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=aw [...]
+<script src="metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">Internet-Draft</td>
@@ -915,17 +1028,21 @@ caption a[href] {
<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 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
+ 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
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 13 May
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">
@@ -933,17 +1050,19 @@ caption a[href] {
<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
- (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>
+ (<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>
</section>
</div>
<div id="toc">
@@ -953,102 +1072,102 @@ caption a[href] {
</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>
@@ -1066,8 +1185,7 @@ caption a[href] {
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
@@ -1078,8 +1196,7 @@ caption a[href] {
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
@@ -1092,21 +1209,16 @@ caption a[href] {
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>
+ 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>
+ 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">
@@ -1118,43 +1230,38 @@ caption a[href] {
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>]
(a.k.a. edwards25519)
- with the ECDSA scheme (</span><span>[<a href="#RFC6979"
class="xref">RFC6979</a>]).
+ 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>).
In the following, we use the following naming convention for our
- cryptographic primitives:
- </span><a href="#section-2-1" class="pilcrow">¶</a></p>
+ cryptographic primitives:<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>.
- </dd>
+ <a href="#publish" class="xref">Section 4</a>.<a
href="#section-2-2.2" class="pilcrow">¶</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>], i.e.
- 2^255 - 19.
- </span>
+ 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>
</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>
+ <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span>.<a
href="#section-2-2.6" class="pilcrow">¶</a>
</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>
+ 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>
</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>] as the curve
point d*B where B is the group
+ <span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span> 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".
- </span>
+ as the "zone key".<a href="#section-2-2.10" class="pilcrow">¶</a>
</dd>
</dl>
</section>
@@ -1170,12 +1277,10 @@ caption a[href] {
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">
@@ -1192,7 +1297,7 @@ caption a[href] {
/ /
</pre>
</div>
-<figcaption><a href="#figure-1">Figure 1</a></figcaption></figure>
+<figcaption><a href="#figure-1" class="selfRef">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">
@@ -1200,33 +1305,32 @@ caption a[href] {
<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.
- </dd>
+ byte order.<a href="#section-3-5.2" class="pilcrow">¶</a>
+</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.
- </dd>
+ order.<a href="#section-3-5.4" class="pilcrow">¶</a>
+</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>] or any of the
+ type as defined in <span>[<a href="#RFC1035"
class="xref">RFC1035</a>]</span> or any of the
complementary standardized DNS resource record types. This value must
be
stored in network byte order. Note that values
- below 2^16 are reserved for allocation via IANA (</span><span>[<a
href="#RFC6895" class="xref">RFC6895</a>]).
- </span>
+ 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>
</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).
- </dd>
+ is a 32-bit resource record flags field (see below).<a
href="#section-3-5.8" class="pilcrow">¶</a>
+</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.
- </dd>
+ respective type of the resource record.<a href="#section-3-5.10"
class="pilcrow">¶</a>
+</dd>
</dl>
<p id="section-3-6">
Flags indicate metadata surrounding the resource record. A flag
@@ -1243,11 +1347,10 @@ caption a[href] {
------+--------+--------+--------+--------+--------+
</pre>
</div>
-<figcaption><a href="#figure-2">Figure 2</a></figcaption></figure>
+<figcaption><a href="#figure-2" class="selfRef">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">
@@ -1255,23 +1358,23 @@ caption a[href] {
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.
- </dd>
+ cached before the transition becomes active.<a href="#section-3-9.2"
class="pilcrow">¶</a>
+</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.
- </dd>
+ private records of a zone hosted locally.<a href="#section-3-9.4"
class="pilcrow">¶</a>
+</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.
- </dd>
+ regular records when resolving labels in local zones.<a
href="#section-3-9.6" class="pilcrow">¶</a>
+</dd>
</dl>
<div id="gnsrecords_numbers">
<section id="section-3.1">
@@ -1281,8 +1384,7 @@ caption a[href] {
<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">
@@ -1299,7 +1401,7 @@ caption a[href] {
2^24 up to 2^32 - 1 | - | Unassigned / For private
use
</pre>
</div>
-<figcaption><a href="#figure-3">Figure 3</a></figcaption></figure>
+<figcaption><a href="#figure-3" class="selfRef">Figure
3</a></figcaption></figure>
</div>
</section>
</div>
@@ -1325,16 +1427,15 @@ caption a[href] {
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-4">Figure 4</a></figcaption></figure>
+<figcaption><a href="#figure-4" class="selfRef">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.
- </dd>
+ A 256-bit ECDSA zone key.<a href="#section-3.2-4.2"
class="pilcrow">¶</a>
+</dd>
</dl>
</section>
</div>
@@ -1346,8 +1447,8 @@ caption a[href] {
<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>] for DNS names.
- A GNS2DNS DATA entry has the following format:</span><a
href="#section-3.3-1" class="pilcrow">¶</a></p>
+ <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>
<div id="figure_gns2dnsrecord">
<figure id="figure-5">
<div class="artwork art-text alignLeft" id="section-3.3-2.1">
@@ -1366,22 +1467,22 @@ caption a[href] {
+-----------------------------------------------+
</pre>
</div>
-<figcaption><a href="#figure-5">Figure 5</a></figcaption></figure>
+<figcaption><a href="#figure-5" class="selfRef">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).
- </dd>
+ The name to continue with in DNS (0-terminated).<a
href="#section-3.3-4.2" class="pilcrow">¶</a>
+</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)
- </dd>
+ "+" top-level domain. The value is UTF-8 encoded (also for DNS
names)
+ and 0-terminated.<a href="#section-3.3-4.4" class="pilcrow">¶</a>
+</dd>
</dl>
</section>
</div>
@@ -1411,22 +1512,20 @@ caption a[href] {
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-6">Figure 6</a></figcaption></figure>
+<figcaption><a href="#figure-6" class="selfRef">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.
- </dd>
+ A UTF-8 string (which is not 0-terminated) representing the legacy
hostname.<a href="#section-3.4-4.2" class="pilcrow">¶</a>
+</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">
@@ -1441,8 +1540,7 @@ caption a[href] {
public zone key.
This record SHOULD only be stored under the empty label "@" but
MAY be returned with record sets under any 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">
@@ -1456,17 +1554,16 @@ caption a[href] {
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-7">Figure 7</a></figcaption></figure>
+<figcaption><a href="#figure-7" class="selfRef">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 include a "." character.
- </dd>
+ label of the zone. This string MUST NOT include a "." character.<a
href="#section-3.5-4.2" class="pilcrow">¶</a>
+</dd>
</dl>
</section>
</div>
@@ -1486,9 +1583,8 @@ caption a[href] {
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>].
- A BOX DATA entry has the following format:
- </span><a href="#section-3.6-1" class="pilcrow">¶</a></p>
+ 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>
<div id="figure_boxrecord">
<figure id="figure-8">
<div class="artwork art-text alignLeft" id="section-3.6-2.1">
@@ -1504,30 +1600,29 @@ caption a[href] {
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-8">Figure 8</a></figcaption></figure>
+<figcaption><a href="#figure-8" class="selfRef">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.
- </dd>
+ 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>
<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.
- </dd>
+ In network byte order.<a href="#section-3.6-4.4"
class="pilcrow">¶</a>
+</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.
- </dd>
+ 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>
<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.
- </dd>
+ defined for the respective TYPE in DNS.<a href="#section-3.6-4.8"
class="pilcrow">¶</a>
+</dd>
</dl>
</section>
</div>
@@ -1557,27 +1652,26 @@ caption a[href] {
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-9">Figure 9</a></figcaption></figure>
+<figcaption><a href="#figure-9" class="selfRef">Figure
9</a></figcaption></figure>
</div>
<p id="section-3.7-3">
- where:
- <a href="#section-3.7-3" class="pilcrow">¶</a></p>
+ where:<a href="#section-3.7-3" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-3.7-4">
<dt id="section-3.7-4.1">HOSTING PEER PUBLIC KEY</dt>
<dd id="section-3.7-4.2">
is a 256-bit EdDSA public key identifying the peer hosting the
- service.
- </dd>
+ service.<a href="#section-3.7-4.2" class="pilcrow">¶</a>
+</dd>
<dt id="section-3.7-4.3">PROTO</dt>
<dd id="section-3.7-4.4">
- the 16-bit protocol number, e.g. 6 for TCP. In network byte order.
- </dd>
+ the 16-bit protocol number, e.g. 6 for TCP. In network byte
order.<a href="#section-3.7-4.4" class="pilcrow">¶</a>
+</dd>
<dt id="section-3.7-4.5">SERVICE NAME</dt>
<dd id="section-3.7-4.6">
a shared secret used to identify the service at the hosting peer,
used to derive the port number requird to connect to the service.
- The service name MUST be a 0-terminated UTF-8 string.
- </dd>
+ The service name MUST be a 0-terminated UTF-8 string.<a
href="#section-3.7-4.6" class="pilcrow">¶</a>
+</dd>
</dl>
</section>
</div>
@@ -1595,16 +1689,14 @@ caption a[href] {
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)
@@ -1612,60 +1704,57 @@ caption a[href] {
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>]. 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>
+ <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>
<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.
- </dd>
+ keying material.<a href="#section-4.1-4.2" class="pilcrow">¶</a>
+</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".
- </dd>
+ concatenation of the label and string "gns".<a
href="#section-4.1-4.4" class="pilcrow">¶</a>
+</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>.
- </dd>
+ 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>
<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.
- </dd>
+ is a UTF-8 string under which the resource records are published.<a
href="#section-4.1-4.8" class="pilcrow">¶</a>
+</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".
- </dd>
+ keying material "h".<a href="#section-4.1-4.10"
class="pilcrow">¶</a>
+</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".
- </dd>
+ keying material "h".<a href="#section-4.1-4.12"
class="pilcrow">¶</a>
+</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>.
- </dd>
+ 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>
<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".
- </dd>
+ derived private key "d_h".<a href="#section-4.1-4.16"
class="pilcrow">¶</a>
+</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">
@@ -1681,8 +1770,7 @@ caption a[href] {
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">
@@ -1713,24 +1801,23 @@ caption a[href] {
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-10">Figure 10</a></figcaption></figure>
+<figcaption><a href="#figure-10" class="selfRef">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>]. The signature
is computed over the data
+ <span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span>. The
signature is computed over the data
following the PUBLIC KEY field.
The signature is created using the derived private key "d_h" (see
- </span><a href="#publish" class="xref">Section 4</a>).
- </dd>
+ <a href="#publish" class="xref">Section 4</a>).<a
href="#section-4.2-4.2" class="pilcrow">¶</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>],
- Section 5.1.5.
- </span>
+ 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>
</dd>
<dt id="section-4.2-4.5">SIZE</dt>
<dd id="section-4.2-4.6">
@@ -1740,13 +1827,13 @@ caption a[href] {
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.
- </dd>
+ 62 kilobytes MUST be supported.<a href="#section-4.2-4.6"
class="pilcrow">¶</a>
+</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).
- </dd>
+ byte order).<a href="#section-4.2-4.8" class="pilcrow">¶</a>
+</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
@@ -1759,12 +1846,12 @@ caption a[href] {
expiration time of all shadow records with matching type and the
expiration times of the non-shadow records is considered.
This is a 64-bit absolute date in microseconds since midnight
- (0 hour), January 1, 1970 in network byte order.
- </dd>
+ (0 hour), January 1, 1970 in network byte order.<a
href="#section-4.2-4.10" class="pilcrow">¶</a>
+</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.
- </dd>
+ The encrypted resource records with a total size of SIZE - 16.<a
href="#section-4.2-4.12" class="pilcrow">¶</a>
+</dd>
</dl>
</section>
</div>
@@ -1775,8 +1862,7 @@ caption a[href] {
<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">
@@ -1806,7 +1892,7 @@ caption a[href] {
/ /
</pre>
</div>
-<figcaption><a href="#figure-11">Figure 11</a></figcaption></figure>
+<figcaption><a href="#figure-11" class="selfRef">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">
@@ -1814,15 +1900,15 @@ caption a[href] {
<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.
- </dd>
+ following after this field in network byte order.<a
href="#section-4.3-4.2" class="pilcrow">¶</a>
+</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.
- </dd>
+ present.<a href="#section-4.3-4.4" class="pilcrow">¶</a>
+</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.
@@ -1830,34 +1916,31 @@ caption a[href] {
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.
- </dd>
+ contain other records.<a href="#section-4.3-4.6"
class="pilcrow">¶</a>
+</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>]. Specifically,
HMAC-SHA512 is used for the
+ <span>[<a href="#RFC5869" class="xref">RFC5869</a>]</span>.
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><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>
+ <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>
<div id="figure_hkdf_keys">
<figure id="figure-12">
<div class="artwork art-text alignLeft" id="section-4.3-8.1">
@@ -1876,12 +1959,11 @@ caption a[href] {
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-12">Figure 12</a></figcaption></figure>
+<figcaption><a href="#figure-12" class="selfRef">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">
@@ -1896,19 +1978,17 @@ caption a[href] {
+-----+-----+-----+-----+-----+-----+-----+-----+
</pre>
</div>
-<figcaption><a href="#figure-13">Figure 13</a></figcaption></figure>
+<figcaption><a href="#figure-13" class="selfRef">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>
@@ -1919,11 +1999,10 @@ caption a[href] {
<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>].
+ All labels in GNS are encoded in UTF-8 <span>[<a href="#RFC3629"
class="xref">RFC3629</a>]</span>.
This does not include any DNS names found in DNS records, such as CNAME
records, which are internationalized through the IDNA specifications
- </span><span>[<a href="#RFC5890" class="xref">RFC5890</a>].
- </span><a href="#section-5-1" class="pilcrow">¶</a></p>
+ <span>[<a href="#RFC5890" class="xref">RFC5890</a>]</span>.<a
href="#section-5-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="resolution">
@@ -1932,8 +2011,9 @@ caption a[href] {
<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>
+ Names in GNS are resolved by recursively querying the DHT record
storage.
+ In the following, we define how resolution is initiated and each
+ iteration in the resolution is processed.<a href="#section-6-1"
class="pilcrow">¶</a></p>
<div id="entry_zone">
<section id="section-6.1">
<h3 id="name-entry-zone">
@@ -1941,8 +2021,7 @@ caption a[href] {
</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>
@@ -1954,21 +2033,18 @@ caption a[href] {
</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
@@ -1979,8 +2055,7 @@ caption a[href] {
...
=> 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 suffix to
@@ -1990,8 +2065,7 @@ caption a[href] {
The suffix may consist of multiple GNS labels concatenated with a
".". If multiple suffixes match the name to resolve, the longest
matching
suffix MUST be used. The suffix 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
@@ -2002,8 +2076,7 @@ caption a[href] {
...
=> 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>
@@ -2020,14 +2093,12 @@ caption a[href] {
is desired.
However, filtering of record sets according to the required record
types
- MUST still be done by the client after the resource record set is
retrieved.
- <a href="#section-6.2-1" class="pilcrow">¶</a></p>
+ MUST still be done by the client after 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>
@@ -2044,8 +2115,7 @@ caption a[href] {
zone key was used to sign the record:
The derived zone key "h*zk" MUST match the public key provided in
the RRBLOCK, otherwise the RRBLOCK MUST be ignored and the DHT
lookup
- GET(q) MUST continue.
- <a href="#section-6.2-4" class="pilcrow">¶</a></p>
+ GET(q) MUST continue.<a href="#section-6.2-4"
class="pilcrow">¶</a></p>
</section>
</div>
<div id="record_processing">
@@ -2057,13 +2127,11 @@ caption a[href] {
If the remainder of the name to resolve is not empty, the records
result MUST consist of a single PKEY record, CNAME record,
or one or more GNS2DNS records. Otherwise, resolution fails
- and GNS returns an empty record set.
- <a href="#section-6.3-1" class="pilcrow">¶</a></p>
+ and GNS returns an empty record set.<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 and the records set
does not consist of a PKEY, CNAME or DNS2GNS record, the record set
- is the result and the resolution is concluded.
- <a href="#section-6.3-2" class="pilcrow">¶</a></p>
+ is the result and the resolution is concluded.<a
href="#section-6.3-2" class="pilcrow">¶</a></p>
<div id="pkey_processing">
<section id="section-6.3.1">
<h4 id="name-pkey-2">
@@ -2073,16 +2141,14 @@ caption a[href] {
When a resolver encounters a PKEY record and the remainder of
the name is non-empty, 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>
<p id="section-6.3.1-2">
If the remainder of the name to resolve is empty and 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, except in the case where the desired
record type is PKEY, in which case the PKEY record is returned and
- the resolution is concluded without resolving the empty apex
label.
- <a href="#section-6.3.1-2" class="pilcrow">¶</a></p>
+ the resolution is concluded without resolving the empty apex
label.<a href="#section-6.3.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="gns2dns_processing">
@@ -2093,8 +2159,7 @@ caption a[href] {
<p id="section-6.3.2-1">
When a resolver encounters a GNS2DNS record and the remaining name
is empty and the desired record type is GNS2DNS, the GNS2DNS
records
- are returned.
- <a href="#section-6.3.2-1" class="pilcrow">¶</a></p>
+ are returned.<a href="#section-6.3.2-1" class="pilcrow">¶</a></p>
<p id="section-6.3.2-2">
Otherwise, it is expected that the resolver first
resolves the IP(s) of the DNS specified name server(s). GNS2DNS
@@ -2104,15 +2169,16 @@ caption a[href] {
DNS server name ends in ".+", the rest of the name is to be
interpreted
relative to the zone of the GNS2DNS record.
If the DNS server name ends in ".<Base32(zk)>", the DNS
server name
- is to be resolved against the GNS zone zk.
- <a href="#section-6.3.2-2" class="pilcrow">¶</a></p>
+ is to be resolved against the GNS zone zk.<a
href="#section-6.3.2-2" class="pilcrow">¶</a></p>
<p id="section-6.3.2-3">
Multiple
GNS2DNS records may be stored under the same label, in which case
the
resolver MUST try all of them. The resolver may try them in any
order or even in parallel. If multiple GNS2DNS records
are present, the DNS name MUST be identical for all of them, if
- not the resolution fails. <a href="#section-6.3.2-3"
class="pilcrow">¶</a></p>
+ not the resolution fails.
+ The first successful recursive name resolution result
+ is returned to the client.<a href="#section-6.3.2-3"
class="pilcrow">¶</a></p>
<p id="section-6.3.2-4">
Once the IP addresses of the DNS servers have been determined,
the DNS name from the GNS2DNS record is appended
@@ -2120,8 +2186,7 @@ caption a[href] {
resolved by querying the name server(s). As the DNS servers
are likely authoritative DNS servers, the GNS resolver MUST
support recursive resolution and not delegate this to the
- authoritative DNS servers.
- <a href="#section-6.3.2-4" class="pilcrow">¶</a></p>
+ authoritative DNS servers.<a href="#section-6.3.2-4"
class="pilcrow">¶</a></p>
</section>
</div>
<div id="cname_processing">
@@ -2137,16 +2202,14 @@ caption a[href] {
If the canonical name ends in ".+",
resolution continues in GNS with the new name in the
current zone. Otherwise, the resulting name is resolved via the
- default operating system name resolution process.
- <a href="#section-6.3.3-1" class="pilcrow">¶</a></p>
+ default operating system name resolution process.<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
(if it ends in a ".<Base32(zk)>").
In order to prevent infinite loops, the resolver MUST
implement loop detections or limit the number of recursive
resolution
- steps.
- <a href="#section-6.3.3-2" class="pilcrow">¶</a></p>
+ steps.<a href="#section-6.3.3-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="box_processing">
@@ -2159,8 +2222,7 @@ caption a[href] {
must unbox it if the name to be resolved continues with
"_SERVICE._PROTO".
Otherwise, the BOX record 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">
@@ -2174,8 +2236,7 @@ caption a[href] {
tunnel and return the IPv4 or IPv6 tunnel address, respectively.
The type of tunnel depends on the contents of the VPN record data.
The VPN record MUST be returned if the resolver implementation
does not
- support setting up a tunnnel.
- <a href="#section-6.3.5-1" class="pilcrow">¶</a></p>
+ support setting up a tunnnel.<a href="#section-6.3.5-1"
class="pilcrow">¶</a></p>
</section>
</div>
</section>
@@ -2193,11 +2254,9 @@ caption a[href] {
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 including the proof-of-work MAY be calculated
- ahead of time to support timely revocation.
- <a href="#section-7-1" class="pilcrow">¶</a></p>
+ ahead of time to support timely revocation.<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">
@@ -2206,8 +2265,7 @@ caption a[href] {
<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">
@@ -2216,8 +2274,7 @@ caption a[href] {
<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">
@@ -2226,8 +2283,7 @@ caption a[href] {
</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"
@@ -2326,67 +2382,53 @@ caption a[href] {
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="#name-normative-references" class="section-name selfRef">Normative
References</a>
+<a href="#section-11" class="section-number selfRef">11. </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.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>
+<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>
<dt id="RFC1035">[RFC1035]</dt>
<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>
+<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>
<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>
+<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words
for use in RFCs to Indicate Requirement Levels"</span>, <span
class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>,
<span class="seriesInfo">DOI 10.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">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>
+<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>
<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">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>
+<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>
<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">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>
+<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/ [...]
<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">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>
+<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>
<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">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>
+<span class="refAuthor">Klensin, J.</span>, <span
class="refTitle">"Internationalized Domain Names for Applications (IDNA):
Definitions and Document Framework"</span>, <span class="seriesInfo">RFC
5890</span>, <span class="seriesInfo">DOI 10.17487/RFC5890</span>, <time
datetime="2010-08">August 2010</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc5890";>https://www.rfc-editor.org/info/rfc5890</a>></span>.
</dd>
<dt id="RFC5891">[RFC5891]</dt>
<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>
+<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>
<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">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>
+<span class="refAuthor">Eastlake 3rd, D.</span>, <span
class="refTitle">"Domain Name System (DNS) IANA Considerations"</span>, <span
class="seriesInfo">BCP 42</span>, <span class="seriesInfo">RFC 6895</span>,
<span class="seriesInfo">DOI 10.17487/RFC6895</span>, <time
datetime="2013-04">April 2013</time>, <span><<a
href="https://www.rfc-editor.org/info/rfc6895";>https://www.rfc-editor.org/info/rfc6895</a>></span>.
</dd>
<dt id="RFC6979">[RFC6979]</dt>
<dd>
-<span class="refAuthor">Pornin, T.</span>, <span
class="refTitle">"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>
+<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>
<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">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>
+<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>
<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">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>
+<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>
<dt id="TWOFISH">[TWOFISH]</dt>
<dd>
<span class="refAuthor">Schneier, B.</span>, <span class="refTitle">"
@@ -2400,38 +2442,38 @@ caption a[href] {
<a href="#name-authors-addresses" class="section-name selfRef">Authors'
Addresses</a>
</h2>
<address class="vcard">
- <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">
+ <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">
<span class="postal-code">85748</span> <span class="locality">Garching</span>
</div>
-<div dir="auto"><span class="country-name">Germany</span></div>
+<div dir="auto" class="left"><span class="country-name">Germany</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:address@hidden"; class="email">address@hidden</a>
</div>
</address>
<address class="vcard">
- <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 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>
-<div dir="auto"><span class="country-name">Switzerland</span></div>
+<div dir="auto" class="left"><span
class="country-name">Switzerland</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:address@hidden"; class="email">address@hidden</a>
</div>
</address>
<address class="vcard">
- <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">
+ <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">
<span class="postal-code">85748</span> <span class="locality">Garching</span>
</div>
-<div dir="auto"><span class="country-name">Germany</span></div>
+<div dir="auto" class="left"><span class="country-name">Germany</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:address@hidden"; class="email">address@hidden</a>
diff --git a/draft-schanzen-gns.txt b/draft-schanzen-gns.txt
index afaa08d..9fbadd3 100644
--- a/draft-schanzen-gns.txt
+++ b/draft-schanzen-gns.txt
@@ -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 (http://trustee.ietf.org/
+ Provisions Relating to IETF Documents (https://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,38 +50,46 @@ 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 13 May 2020 [Page 1]
+
+Internet-Draft The GNU Name System November 2019
+
+
Table of Contents
- 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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . 13
+ 5. Internationalization and Character Encoding . . . . . . . . . 15
+ 6. Name Resolution . . . . . . . . . . . . . . . . . . . . . . . 15
+ 6.1. Entry Zone . . . . . . . . . . . . . . . . . . . . . . . 15
+ 6.2. Record Retrieval . . . . . . . . . . . . . . . . . . . . 16
+ 6.3. Record Processing . . . . . . . . . . . . . . . . . . . . 17
+ 6.3.1. PKEY . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 6.3.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . 17
+ 6.3.3. CNAME . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 6.3.4. BOX . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 6.3.5. VPN . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 7. Zone Revocation . . . . . . . . . . . . . . . . . . . . . . . 19
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
+ 10. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 11. Normative References . . . . . . . . . . . . . . . . . . . . 21
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction
@@ -98,6 +106,14 @@ 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 13 May 2020 [Page 2]
+
+Internet-Draft The GNU Name System November 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
@@ -137,21 +153,29 @@ Table of Contents
([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].
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 3]
+
+Internet-Draft The GNU Name System November 2019
+
+
+ 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 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
@@ -181,25 +205,31 @@ Table of Contents
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.
+
+ 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]).
- 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]).
- 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 13 May 2020 [Page 4]
+
+Internet-Draft The GNU Name System November 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
@@ -215,25 +245,24 @@ Table of Contents
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
@@ -241,6 +270,18 @@ Table of Contents
type numbers for DNS. The following is a list of defined and
reserved record types in GNS:
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 5]
+
+Internet-Draft The GNU Name System November 2019
+
+
Number | Type | Comment
------------------------------------------------------------
65536 | PKEY | GNS delegation
@@ -284,6 +325,19 @@ Table of Contents
format defined in [RFC1034] for DNS names. A GNS2DNS DATA entry has
the following format:
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 6]
+
+Internet-Draft The GNU Name System November 2019
+
+
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| DNS NAME |
@@ -301,12 +355,12 @@ Table of Contents
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. The value is UTF-8
+ encoded (also for DNS names) and 0-terminated.
3.4. LEHO
@@ -330,7 +384,15 @@ Table of Contents
where:
LEGACY HOSTNAME A UTF-8 string (which is not 0-terminated)
- representing the legacy hostname.
+ representing the legacy hostname.
+
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 7]
+
+Internet-Draft The GNU Name System November 2019
+
NOTE: If an application uses a LEHO value in an HTTP request header
(e.g. "Host:" header) it must be converted to a punycode
@@ -359,8 +421,8 @@ Table of Contents
where:
NICKNAME A UTF-8 string (which is not 0-terminated) representing the
- preferred label of the zone. This string MUST NOT include
- a "." character.
+ preferred label of the zone. This string MUST NOT include a "."
+ character.
3.6. BOX
@@ -375,6 +437,19 @@ Table of Contents
(PROTO) 6 (tcp) and record TYPE "TLSA". For reference, see also
[RFC2782]. A BOX DATA entry has the following format:
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 8]
+
+Internet-Draft The GNU Name System November 2019
+
+
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| PROTO | SVC | TYPE |
@@ -389,17 +464,17 @@ Table of Contents
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
@@ -423,6 +498,14 @@ Table of Contents
where:
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 9]
+
+Internet-Draft The GNU Name System November 2019
+
+
HOSTING PEER PUBLIC KEY is a 256-bit EdDSA public key identifying
the peer hosting the service.
@@ -459,28 +542,37 @@ Table of Contents
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.
+ published.
+
+
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 10]
+
+Internet-Draft The GNU Name System November 2019
- 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".
+ d_h is a 256-bit private key derived from the "d" using the keying
+ material "h".
- L is the prime-order subgroup as defined in Section 2.
+ zk_h is a 256-bit public key derived from the zone key "zk" using
+ the keying material "h".
- 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".
+ 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
@@ -495,6 +587,37 @@ Table of Contents
underlying DHT. This may include a periodic refresh publication. A
GNS RRBLOCK has the following format:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 11]
+
+Internet-Draft The GNU Name System November 2019
+
+
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| SIGNATURE |
@@ -524,42 +647,46 @@ Table of Contents
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).
+ 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.
+
+ PURPOSE A 32-bit signature purpose flag. This field MUST be 15 (in
+ network byte order).
+
+
- 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.
+Schanzenbach, et al. Expires 13 May 2020 [Page 12]
+
+Internet-Draft The GNU Name System November 2019
- 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
@@ -595,6 +722,14 @@ Table of Contents
where:
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 13]
+
+Internet-Draft The GNU Name System November 2019
+
+
RR COUNT A 32-bit value containing the number of variable-length
resource records which are following after this field in network
byte order.
@@ -642,6 +777,15 @@ Table of Contents
Figure 12
+
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 14]
+
+Internet-Draft The GNU Name System November 2019
+
+
Similarly, we divide "IV" into a 128-bit initialization vector and a
128-bit initialization vector:
@@ -672,7 +816,9 @@ Table of Contents
6. Name Resolution
- TODO
+ Names in GNS are resolved by recursively querying the DHT record
+ storage. In the following, we define how resolution is initiated and
+ each iteration in the resolution is processed.
6.1. Entry Zone
@@ -689,6 +835,13 @@ Table of Contents
If the TLD is a Base32-encoded public zone key "zk", the entry zone
of the resolution process is implicitly given by the name.
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 15]
+
+Internet-Draft The GNU Name System November 2019
+
+
Example name: www.example.<Base32(zk)>
=> Entry zone: zk
=> Name to resolve from entry zone: www.example
@@ -738,6 +891,13 @@ Table of Contents
Initially, the authoritative zone is the entry zone. If the name is
empty, it is interpreted as the apex label "@".
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 16]
+
+Internet-Draft The GNU Name System November 2019
+
+
1. Extract the right-most label from the name to look up.
2. Calculate q using the label and zk.
@@ -786,6 +946,14 @@ Table of Contents
Otherwise, it is expected that the resolver first resolves the IP(s)
of the DNS specified name server(s). GNS2DNS records MAY contain
numeric IPv4 or IPv6 addresses, allowing the resolver to skip this
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 17]
+
+Internet-Draft The GNU Name System November 2019
+
+
step. The DNS server names may themselves be names in GNS or DNS.
If the DNS server name ends in ".+", the rest of the name is to be
interpreted relative to the zone of the GNS2DNS record. If the DNS
@@ -796,7 +964,8 @@ Table of Contents
case the resolver MUST try all of them. The resolver may try them in
any order or even in parallel. If multiple GNS2DNS records are
present, the DNS name MUST be identical for all of them, if not the
- resolution fails.
+ resolution fails. The first successful recursive name resolution
+ result is returned to the client.
Once the IP addresses of the DNS servers have been determined, the
DNS name from the GNS2DNS record is appended to the remainder of the
@@ -829,6 +998,18 @@ Table of Contents
do not require a separate network request, and TLSA records become
inseparable from the corresponding address records.
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 18]
+
+Internet-Draft The GNU Name System November 2019
+
+
6.3.5. VPN
If the queried record type is either A or AAAA and the retrieved
@@ -877,6 +1058,14 @@ Table of Contents
17fc32dc410e082e
h :=
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 19]
+
+Internet-Draft The GNU Name System November 2019
+
+
2af3275a9cf90e54
f2dbf7930be76fb9
5e7c80b1416f8ca6
@@ -925,6 +1114,14 @@ Table of Contents
RDATA :=
0000000100059412 RR COUNT | EXPIRA-
09ddea0f00000014 -TION | DATA SIZE (20)
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 20]
+
+Internet-Draft The GNU Name System November 2019
+
+
0000000f00000000 TYPE (15=MX) | FLAGS (0)
000a046d61696c07 Priority (10) |4 | mail | 7
6578616d706c6503 example | 3
@@ -961,11 +1158,11 @@ Table of Contents
11. Normative References
- [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>.
+ [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>.
- [RFC1035] Mockapetris, P.V., "Domain names - implementation and
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
@@ -974,6 +1171,13 @@ Table of Contents
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 21]
+
+Internet-Draft The GNU Name System November 2019
+
+
[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,
@@ -1022,6 +1226,14 @@ Table of Contents
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 22]
+
+Internet-Draft The GNU Name System November 2019
+
+
[TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm: A
128-Bit Block Cipher, 1st Edition", March 1999.
@@ -1036,8 +1248,8 @@ Authors' Addresses
Email: address@hidden
- Berner Fachhochschule
Christian Grothoff
+ Berner Fachhochschule
Hoeheweg 80
CH-2501 Biel/Bienne
Switzerland
@@ -1052,3 +1264,25 @@ Authors' Addresses
Germany
Email: address@hidden
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schanzenbach, et al. Expires 13 May 2020 [Page 23]
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 6d50f25..d4aea50 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -359,7 +359,8 @@
<dd>
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)
+ "+" top-level domain. The value is UTF-8 encoded (also for DNS
names)
+ and 0-terminated.
</dd>
</dl>
</section>
@@ -847,7 +848,9 @@
<section anchor="resolution" numbered="true" toc="default">
<name>Name Resolution</name>
<t>
- TODO
+ Names in GNS are resolved by recursively querying the DHT record
storage.
+ In the following, we define how resolution is initiated and each
+ iteration in the resolution is processed.
</t>
<section anchor="entry_zone" numbered="true" toc="default">
<name>Entry Zone</name>
--
To stop receiving notification emails like this one, please contact
address@hidden.