aboutsummaryrefslogtreecommitdiff
path: root/rfc9498.xml
diff options
context:
space:
mode:
Diffstat (limited to 'rfc9498.xml')
-rw-r--r--rfc9498.xml5434
1 files changed, 5434 insertions, 0 deletions
diff --git a/rfc9498.xml b/rfc9498.xml
new file mode 100644
index 0000000..db28c64
--- /dev/null
+++ b/rfc9498.xml
@@ -0,0 +1,5434 @@
1<?xml version='1.0' encoding='utf-8'?>
2<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" submissionType="independent" category="info" docName="draft-schanzen-gns-28" number="9498" ipr="trust200902" sortRefs="false" symRefs="true" tocDepth="3" tocInclude="true" updates="" obsoletes="" xml:lang="en" prepTime="2023-11-20T18:08:49" indexInclude="true" scripts="Common,Latin">
3 <link href="https://datatracker.ietf.org/doc/draft-schanzen-gns-28" rel="prev"/>
4 <link href="https://dx.doi.org/10.17487/rfc9498" rel="alternate"/>
5 <link href="urn:issn:2070-1721" rel="alternate"/>
6 <front>
7 <title abbrev="The GNU Name System">The GNU Name System</title>
8 <seriesInfo name="RFC" value="9498" stream="independent"/>
9 <author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach">
10 <organization showOnFrontPage="true">Fraunhofer AISEC</organization>
11 <address>
12 <postal>
13 <street>Lichtenbergstrasse 11</street>
14 <city>Garching</city>
15 <code>85748</code>
16 <country>Germany</country>
17 </postal>
18 <email>martin.schanzenbach@aisec.fraunhofer.de</email>
19 </address>
20 </author>
21 <author fullname="Christian Grothoff" initials="C." surname="Grothoff">
22 <organization showOnFrontPage="true">Berner Fachhochschule</organization>
23 <address>
24 <postal>
25 <street>Hoeheweg 80</street>
26 <city>Biel/Bienne</city>
27 <code>2501</code>
28 <country>Switzerland</country>
29 </postal>
30 <email>christian.grothoff@bfh.ch</email>
31 </address>
32 </author>
33 <author fullname="Bernd Fix" initials="B." surname="Fix">
34 <organization showOnFrontPage="true">GNUnet e.V.</organization>
35 <address>
36 <postal>
37 <street>Boltzmannstrasse 3</street>
38 <city>Garching</city>
39 <code>85748</code>
40 <country>Germany</country>
41 </postal>
42 <email>fix@gnunet.org</email>
43 </address>
44 </author>
45 <date month="11" year="2023"/>
46 <keyword>name systems</keyword>
47 <abstract pn="section-abstract">
48 <t indent="0" pn="section-abstract-1">
49 This document provides the GNU Name System (GNS) technical
50 specification.
51 GNS is a decentralized and censorship-resistant domain name
52 resolution protocol that provides a privacy-enhancing alternative to the
53 Domain Name System (DNS) protocols.
54 </t>
55 <t indent="0" pn="section-abstract-2">
56 This document defines the normative wire format of resource records,
57 resolution processes, cryptographic routines, and security and privacy
58 considerations for use by implementers.
59 </t>
60 <t indent="0" pn="section-abstract-3">
61 This specification was developed outside the IETF and does not have
62 IETF consensus. It is published here to inform readers about the
63 function of GNS, guide future GNS implementations, and ensure
64 interoperability among implementations (for example, pre-existing
65 GNUnet implementations).
66 </t>
67 </abstract>
68 <boilerplate>
69 <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
70 <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
71 <t indent="0" pn="section-boilerplate.1-1">
72 This document is not an Internet Standards Track specification; it is
73 published for informational purposes.
74 </t>
75 <t indent="0" pn="section-boilerplate.1-2">
76 This is a contribution to the RFC Series, independently of any
77 other RFC stream. The RFC Editor has chosen to publish this
78 document at its discretion and makes no statement about its value
79 for implementation or deployment. Documents approved for
80 publication by the RFC Editor are not candidates for any level of
81 Internet Standard; see Section 2 of RFC 7841.
82 </t>
83 <t indent="0" pn="section-boilerplate.1-3">
84 Information about the current status of this document, any
85 errata, and how to provide feedback on it may be obtained at
86 <eref target="https://www.rfc-editor.org/info/rfc9498" brackets="none"/>.
87 </t>
88 </section>
89 <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
90 <name slugifiedName="name-copyright-notice">Copyright Notice</name>
91 <t indent="0" pn="section-boilerplate.2-1">
92 Copyright (c) 2023 IETF Trust and the persons identified as the
93 document authors. All rights reserved.
94 </t>
95 <t indent="0" pn="section-boilerplate.2-2">
96 This document is subject to BCP 78 and the IETF Trust's Legal
97 Provisions Relating to IETF Documents
98 (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
99 publication of this document. Please review these documents
100 carefully, as they describe your rights and restrictions with
101 respect to this document.
102 </t>
103 </section>
104 </boilerplate>
105 <toc>
106 <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
107 <name slugifiedName="name-table-of-contents">Table of Contents</name>
108 <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
109 <li pn="section-toc.1-1.1">
110 <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
111 <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
112 <li pn="section-toc.1-1.1.2.1">
113 <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-notation">Requirements Notation</xref></t>
114 </li>
115 </ul>
116 </li>
117 <li pn="section-toc.1-1.2">
118 <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
119 </li>
120 <li pn="section-toc.1-1.3">
121 <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-overview">Overview</xref></t>
122 <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
123 <li pn="section-toc.1-1.3.2.1">
124 <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-names-and-zones">Names and Zones</xref></t>
125 </li>
126 <li pn="section-toc.1-1.3.2.2">
127 <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-publishing-binding-informat">Publishing Binding Information</xref></t>
128 </li>
129 <li pn="section-toc.1-1.3.2.3">
130 <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-resolving-names">Resolving Names</xref></t>
131 </li>
132 </ul>
133 </li>
134 <li pn="section-toc.1-1.4">
135 <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-zones">Zones</xref></t>
136 <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
137 <li pn="section-toc.1-1.4.2.1">
138 <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-zone-top-level-domain-ztld">Zone Top-Level Domain (zTLD)</xref></t>
139 </li>
140 <li pn="section-toc.1-1.4.2.2">
141 <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-zone-revocation">Zone Revocation</xref></t>
142 </li>
143 </ul>
144 </li>
145 <li pn="section-toc.1-1.5">
146 <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-resource-records">Resource Records</xref></t>
147 <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
148 <li pn="section-toc.1-1.5.2.1">
149 <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-zone-delegation-records">Zone Delegation Records</xref></t>
150 <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.1.2">
151 <li pn="section-toc.1-1.5.2.1.2.1">
152 <t indent="0" pn="section-toc.1-1.5.2.1.2.1.1"><xref derivedContent="5.1.1" format="counter" sectionFormat="of" target="section-5.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-pkey">PKEY</xref></t>
153 </li>
154 <li pn="section-toc.1-1.5.2.1.2.2">
155 <t indent="0" pn="section-toc.1-1.5.2.1.2.2.1"><xref derivedContent="5.1.2" format="counter" sectionFormat="of" target="section-5.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-edkey">EDKEY</xref></t>
156 </li>
157 </ul>
158 </li>
159 <li pn="section-toc.1-1.5.2.2">
160 <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-redirection-records">Redirection Records</xref></t>
161 <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.2.2">
162 <li pn="section-toc.1-1.5.2.2.2.1">
163 <t indent="0" pn="section-toc.1-1.5.2.2.2.1.1"><xref derivedContent="5.2.1" format="counter" sectionFormat="of" target="section-5.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-redirect">REDIRECT</xref></t>
164 </li>
165 <li pn="section-toc.1-1.5.2.2.2.2">
166 <t indent="0" pn="section-toc.1-1.5.2.2.2.2.1"><xref derivedContent="5.2.2" format="counter" sectionFormat="of" target="section-5.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-gns2dns">GNS2DNS</xref></t>
167 </li>
168 </ul>
169 </li>
170 <li pn="section-toc.1-1.5.2.3">
171 <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-auxiliary-records">Auxiliary Records</xref></t>
172 <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.3.2">
173 <li pn="section-toc.1-1.5.2.3.2.1">
174 <t indent="0" pn="section-toc.1-1.5.2.3.2.1.1"><xref derivedContent="5.3.1" format="counter" sectionFormat="of" target="section-5.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-leho">LEHO</xref></t>
175 </li>
176 <li pn="section-toc.1-1.5.2.3.2.2">
177 <t indent="0" pn="section-toc.1-1.5.2.3.2.2.1"><xref derivedContent="5.3.2" format="counter" sectionFormat="of" target="section-5.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-nick">NICK</xref></t>
178 </li>
179 <li pn="section-toc.1-1.5.2.3.2.3">
180 <t indent="0" pn="section-toc.1-1.5.2.3.2.3.1"><xref derivedContent="5.3.3" format="counter" sectionFormat="of" target="section-5.3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-box">BOX</xref></t>
181 </li>
182 </ul>
183 </li>
184 </ul>
185 </li>
186 <li pn="section-toc.1-1.6">
187 <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-record-encoding-for-remote-">Record Encoding for Remote Storage</xref></t>
188 <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
189 <li pn="section-toc.1-1.6.2.1">
190 <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-storage-key">The Storage Key</xref></t>
191 </li>
192 <li pn="section-toc.1-1.6.2.2">
193 <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-plaintext-record-data-rdata">Plaintext Record Data (RDATA)</xref></t>
194 </li>
195 <li pn="section-toc.1-1.6.2.3">
196 <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-resource-record-block">The Resource Record Block</xref></t>
197 </li>
198 </ul>
199 </li>
200 <li pn="section-toc.1-1.7">
201 <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-name-resolution">Name Resolution</xref></t>
202 <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
203 <li pn="section-toc.1-1.7.2.1">
204 <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-start-zones">Start Zones</xref></t>
205 </li>
206 <li pn="section-toc.1-1.7.2.2">
207 <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-recursion">Recursion</xref></t>
208 </li>
209 <li pn="section-toc.1-1.7.2.3">
210 <t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-record-processing">Record Processing</xref></t>
211 <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2.3.2">
212 <li pn="section-toc.1-1.7.2.3.2.1">
213 <t indent="0" pn="section-toc.1-1.7.2.3.2.1.1"><xref derivedContent="7.3.1" format="counter" sectionFormat="of" target="section-7.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-redirect-2">REDIRECT</xref></t>
214 </li>
215 <li pn="section-toc.1-1.7.2.3.2.2">
216 <t indent="0" pn="section-toc.1-1.7.2.3.2.2.1"><xref derivedContent="7.3.2" format="counter" sectionFormat="of" target="section-7.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-gns2dns-2">GNS2DNS</xref></t>
217 </li>
218 <li pn="section-toc.1-1.7.2.3.2.3">
219 <t indent="0" pn="section-toc.1-1.7.2.3.2.3.1"><xref derivedContent="7.3.3" format="counter" sectionFormat="of" target="section-7.3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-box-2">BOX</xref></t>
220 </li>
221 <li pn="section-toc.1-1.7.2.3.2.4">
222 <t indent="0" pn="section-toc.1-1.7.2.3.2.4.1"><xref derivedContent="7.3.4" format="counter" sectionFormat="of" target="section-7.3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-zone-delegation-records-2">Zone Delegation Records</xref></t>
223 </li>
224 <li pn="section-toc.1-1.7.2.3.2.5">
225 <t indent="0" pn="section-toc.1-1.7.2.3.2.5.1"><xref derivedContent="7.3.5" format="counter" sectionFormat="of" target="section-7.3.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-nick-2">NICK</xref></t>
226 </li>
227 </ul>
228 </li>
229 </ul>
230 </li>
231 <li pn="section-toc.1-1.8">
232 <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-internationalization-and-ch">Internationalization and Character Encoding</xref></t>
233 </li>
234 <li pn="section-toc.1-1.9">
235 <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-and-privacy-consid">Security and Privacy Considerations</xref></t>
236 <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
237 <li pn="section-toc.1-1.9.2.1">
238 <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-availability">Availability</xref></t>
239 </li>
240 <li pn="section-toc.1-1.9.2.2">
241 <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-agility">Agility</xref></t>
242 </li>
243 <li pn="section-toc.1-1.9.2.3">
244 <t indent="0" pn="section-toc.1-1.9.2.3.1"><xref derivedContent="9.3" format="counter" sectionFormat="of" target="section-9.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cryptography">Cryptography</xref></t>
245 </li>
246 <li pn="section-toc.1-1.9.2.4">
247 <t indent="0" pn="section-toc.1-1.9.2.4.1"><xref derivedContent="9.4" format="counter" sectionFormat="of" target="section-9.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-abuse-mitigation">Abuse Mitigation</xref></t>
248 </li>
249 <li pn="section-toc.1-1.9.2.5">
250 <t indent="0" pn="section-toc.1-1.9.2.5.1"><xref derivedContent="9.5" format="counter" sectionFormat="of" target="section-9.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-zone-management">Zone Management</xref></t>
251 </li>
252 <li pn="section-toc.1-1.9.2.6">
253 <t indent="0" pn="section-toc.1-1.9.2.6.1"><xref derivedContent="9.6" format="counter" sectionFormat="of" target="section-9.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dhts-as-remote-storage">DHTs as Remote Storage</xref></t>
254 </li>
255 <li pn="section-toc.1-1.9.2.7">
256 <t indent="0" pn="section-toc.1-1.9.2.7.1"><xref derivedContent="9.7" format="counter" sectionFormat="of" target="section-9.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-revocations">Revocations</xref></t>
257 </li>
258 <li pn="section-toc.1-1.9.2.8">
259 <t indent="0" pn="section-toc.1-1.9.2.8.1"><xref derivedContent="9.8" format="counter" sectionFormat="of" target="section-9.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-zone-privacy">Zone Privacy</xref></t>
260 </li>
261 <li pn="section-toc.1-1.9.2.9">
262 <t indent="0" pn="section-toc.1-1.9.2.9.1"><xref derivedContent="9.9" format="counter" sectionFormat="of" target="section-9.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-zone-governance">Zone Governance</xref></t>
263 </li>
264 <li pn="section-toc.1-1.9.2.10">
265 <t indent="0" pn="section-toc.1-1.9.2.10.1"><xref derivedContent="9.10" format="counter" sectionFormat="of" target="section-9.10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-namespace-ambiguity">Namespace Ambiguity</xref></t>
266 </li>
267 </ul>
268 </li>
269 <li pn="section-toc.1-1.10">
270 <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-gana-considerations">GANA Considerations</xref></t>
271 <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
272 <li pn="section-toc.1-1.10.2.1">
273 <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-gnunet-signature-purposes-r">GNUnet Signature Purposes Registry</xref></t>
274 </li>
275 <li pn="section-toc.1-1.10.2.2">
276 <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-gns-record-types-registry">GNS Record Types Registry</xref></t>
277 </li>
278 <li pn="section-toc.1-1.10.2.3">
279 <t indent="0" pn="section-toc.1-1.10.2.3.1"><xref derivedContent="10.3" format="counter" sectionFormat="of" target="section-10.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-alt-subdomains-registry">.alt Subdomains Registry</xref></t>
280 </li>
281 </ul>
282 </li>
283 <li pn="section-toc.1-1.11">
284 <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
285 </li>
286 <li pn="section-toc.1-1.12">
287 <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" format="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-implementation-and-deployme">Implementation and Deployment Status</xref></t>
288 </li>
289 <li pn="section-toc.1-1.13">
290 <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="13" format="counter" sectionFormat="of" target="section-13"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
291 <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.13.2">
292 <li pn="section-toc.1-1.13.2.1">
293 <t indent="0" pn="section-toc.1-1.13.2.1.1"><xref derivedContent="13.1" format="counter" sectionFormat="of" target="section-13.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
294 </li>
295 <li pn="section-toc.1-1.13.2.2">
296 <t indent="0" pn="section-toc.1-1.13.2.2.1"><xref derivedContent="13.2" format="counter" sectionFormat="of" target="section-13.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
297 </li>
298 </ul>
299 </li>
300 <li pn="section-toc.1-1.14">
301 <t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-usage-and-migration">Usage and Migration</xref></t>
302 <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.14.2">
303 <li pn="section-toc.1-1.14.2.1">
304 <t indent="0" pn="section-toc.1-1.14.2.1.1"><xref derivedContent="A.1" format="counter" sectionFormat="of" target="section-appendix.a.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-zone-dissemination">Zone Dissemination</xref></t>
305 </li>
306 <li pn="section-toc.1-1.14.2.2">
307 <t indent="0" pn="section-toc.1-1.14.2.2.1"><xref derivedContent="A.2" format="counter" sectionFormat="of" target="section-appendix.a.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-start-zone-configuration">Start Zone Configuration</xref></t>
308 </li>
309 <li pn="section-toc.1-1.14.2.3">
310 <t indent="0" pn="section-toc.1-1.14.2.3.1"><xref derivedContent="A.3" format="counter" sectionFormat="of" target="section-appendix.a.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-globally-unique-names-and-t">Globally Unique Names and the Web</xref></t>
311 </li>
312 <li pn="section-toc.1-1.14.2.4">
313 <t indent="0" pn="section-toc.1-1.14.2.4.1"><xref derivedContent="A.4" format="counter" sectionFormat="of" target="section-appendix.a.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-migration-paths">Migration Paths</xref></t>
314 </li>
315 </ul>
316 </li>
317 <li pn="section-toc.1-1.15">
318 <t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="Appendix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-example-flows">Example Flows</xref></t>
319 <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.15.2">
320 <li pn="section-toc.1-1.15.2.1">
321 <t indent="0" pn="section-toc.1-1.15.2.1.1"><xref derivedContent="B.1" format="counter" sectionFormat="of" target="section-appendix.b.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-aaaa-example-resolution">AAAA Example Resolution</xref></t>
322 </li>
323 <li pn="section-toc.1-1.15.2.2">
324 <t indent="0" pn="section-toc.1-1.15.2.2.1"><xref derivedContent="B.2" format="counter" sectionFormat="of" target="section-appendix.b.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-redirect-example-resolution">REDIRECT Example Resolution</xref></t>
325 </li>
326 <li pn="section-toc.1-1.15.2.3">
327 <t indent="0" pn="section-toc.1-1.15.2.3.1"><xref derivedContent="B.3" format="counter" sectionFormat="of" target="section-appendix.b.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-gns2dns-example-resolution">GNS2DNS Example Resolution</xref></t>
328 </li>
329 </ul>
330 </li>
331 <li pn="section-toc.1-1.16">
332 <t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="Appendix C" format="default" sectionFormat="of" target="section-appendix.c"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-base32gns">Base32GNS</xref></t>
333 </li>
334 <li pn="section-toc.1-1.17">
335 <t indent="0" pn="section-toc.1-1.17.1"><xref derivedContent="Appendix D" format="default" sectionFormat="of" target="section-appendix.d"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-test-vectors">Test Vectors</xref></t>
336 <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.17.2">
337 <li pn="section-toc.1-1.17.2.1">
338 <t indent="0" pn="section-toc.1-1.17.2.1.1"><xref derivedContent="D.1" format="counter" sectionFormat="of" target="section-appendix.d.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-base32gns-encoding-decoding">Base32GNS Encoding/Decoding</xref></t>
339 </li>
340 <li pn="section-toc.1-1.17.2.2">
341 <t indent="0" pn="section-toc.1-1.17.2.2.1"><xref derivedContent="D.2" format="counter" sectionFormat="of" target="section-appendix.d.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-record-sets">Record Sets</xref></t>
342 </li>
343 <li pn="section-toc.1-1.17.2.3">
344 <t indent="0" pn="section-toc.1-1.17.2.3.1"><xref derivedContent="D.3" format="counter" sectionFormat="of" target="section-appendix.d.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-zone-revocation-2">Zone Revocation</xref></t>
345 </li>
346 </ul>
347 </li>
348 <li pn="section-toc.1-1.18">
349 <t indent="0" pn="section-toc.1-1.18.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.e"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
350 </li>
351 <li pn="section-toc.1-1.19">
352 <t indent="0" pn="section-toc.1-1.19.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.f"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
353 </li>
354 </ul>
355 </section>
356 </toc>
357 </front>
358 <middle>
359 <section anchor="introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
360 <name slugifiedName="name-introduction">Introduction</name>
361 <t indent="0" pn="section-1-1">
362 This specification describes the GNU Name System (GNS), a
363 censorship-resistant, privacy-preserving, and decentralized
364 domain name resolution protocol. GNS cryptographically secures
365 the binding of names to arbitrary tokens, enabling it to double
366 in some respects as an alternative to some of today's public
367 key infrastructures.
368 </t>
369 <t indent="0" pn="section-1-2">
370 Per Domain Name System (DNS) terminology <xref target="RFC1035" format="default" sectionFormat="of" derivedContent="RFC1035"/>, GNS roughly follows the idea of a local
371 root zone deployment (see <xref target="RFC8806" format="default" sectionFormat="of" derivedContent="RFC8806"/>), with the
372 difference that the design encourages alternative roots and
373 does not expect all deployments to use the same or any specific
374 root zone. In the GNS reference implementation, users can
375 autonomously and freely delegate control of names to zones
376 through their local configurations.
377 GNS expects each user to be in control of their setup.
378 By following the guidelines in <xref target="namespace_ambiguity" format="default" sectionFormat="of" derivedContent="Section 9.10"/>,
379 users should manage to avoid any confusion as to how names are
380 resolved.
381 </t>
382 <t indent="0" pn="section-1-3">
383 Name resolution and zone dissemination are based on the
384 principle of a petname system where users can assign local
385 names to zones. The GNS has its roots in ideas from the Simple
386 Distributed Security Infrastructure <xref target="SDSI" format="default" sectionFormat="of" derivedContent="SDSI"/>,
387 enabling the decentralized mapping of secure identifiers to
388 memorable names. One of the first academic descriptions of the
389 cryptographic ideas behind GNS can be found in <xref target="GNS" format="default" sectionFormat="of" derivedContent="GNS"/>.
390 </t>
391 <t indent="0" pn="section-1-4">
392 This document defines the normative wire format of resource
393 records, resolution processes, cryptographic routines, and
394 security and privacy considerations for use by implementers.
395 </t>
396 <section numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
397 <name slugifiedName="name-requirements-notation">Requirements Notation</name>
398 <t indent="0" pn="section-1.1-1">The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
399 "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
400 "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
401 "<bcp14>SHOULD NOT</bcp14>",
402 "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
403 "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
404 are to be interpreted as described in BCP 14
405 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only
406 when, they appear in all capitals, as shown here.</t>
407 </section>
408 </section>
409 <section numbered="true" removeInRFC="false" toc="include" pn="section-2">
410 <name slugifiedName="name-terminology">Terminology</name>
411 <dl newline="false" indent="3" spacing="normal" pn="section-2-1">
412 <dt pn="section-2-1.1">Apex Label:</dt>
413 <dd pn="section-2-1.2">
414 This type of label is used to publish resource
415 records in a zone that can be resolved without providing a specific
416 label. It is the GNS method for providing what is called the "zone apex" in DNS
417 <xref target="RFC4033" format="default" sectionFormat="of" derivedContent="RFC4033"/>.
418 The apex label is represented using the character U+0040 ("@" without the quotes).
419 </dd>
420 <dt pn="section-2-1.3">Application:</dt>
421 <dd pn="section-2-1.4">
422 An application is a component that uses a GNS implementation
423 to resolve names into records and processes its contents.
424 </dd>
425 <dt pn="section-2-1.5">Blinded Zone Key:</dt>
426 <dd pn="section-2-1.6">
427 A blinded zone key is a key derived from a zone key and a label.
428 The zone key and any blinded zone key derived from it are unlinkable
429 without knowledge of the specific label used for the derivation.
430 </dd>
431 <dt pn="section-2-1.7">Extension Label:</dt>
432 <dd pn="section-2-1.8">
433 This type of label is used to refer to the authoritative zone that the record is in.
434 The primary use for the extension label is in redirections where the redirection
435 target is defined relative to the authoritative zone of the redirection
436 record (see <xref target="gnsrecords_redirect" format="default" sectionFormat="of" derivedContent="Section 5.2"/>).
437 The extension label is represented using the character U+002B ("+" without the quotes).
438 </dd>
439 <dt pn="section-2-1.9">Label Separator:</dt>
440 <dd pn="section-2-1.10">
441 Labels in a name are separated using the label separator U+002E
442 ("." without the quotes).
443 In GNS, except for zone Top-Level Domains (zTLDs)
444 (see below) and boxed records (see <xref target="gnsrecords_box" format="default" sectionFormat="of" derivedContent="Section 5.3.3"/>),
445 every label separator in a name indicates delegation to another zone.
446 </dd>
447 <dt pn="section-2-1.11">Label:</dt>
448 <dd pn="section-2-1.12">
449 A GNS label is a label as defined in <xref target="RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/>.
450 Labels are UTF-8 strings in Unicode
451 Normalization Form C (NFC) <xref target="Unicode-UAX15" format="default" sectionFormat="of" derivedContent="Unicode-UAX15"/>.
452 The apex label and the extension label have
453 special purposes in the resolution protocol that are defined
454 in the rest of this document.
455 Zone administrators <bcp14>MAY</bcp14> disallow certain labels that
456 might be easily confused with other labels through registration policies
457 (see also <xref target="security_abuse" format="default" sectionFormat="of" derivedContent="Section 9.4"/>).
458 </dd>
459 <dt pn="section-2-1.13">Name:</dt>
460 <dd pn="section-2-1.14">
461 A name in GNS is a domain name as defined in <xref target="RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/>:
462 names are UTF-8 strings <xref target="RFC3629" format="default" sectionFormat="of" derivedContent="RFC3629"/> consisting of an
463 ordered list of labels concatenated with a label separator.
464 Names are resolved starting from the rightmost label.
465 GNS does not impose length restrictions on names or labels.
466 However, applications <bcp14>MAY</bcp14> ensure that name and label lengths are
467 compatible with DNS and, in particular, Internationalized Domain Names for
468 Applications (IDNA) <xref target="RFC5890" format="default" sectionFormat="of" derivedContent="RFC5890"/>.
469 In the spirit of <xref target="RFC5895" format="default" sectionFormat="of" derivedContent="RFC5895"/>, applications <bcp14>MAY</bcp14> preprocess
470 names and labels to ensure compatibility with DNS or support
471 specific user expectations -- for example, according to
472 <xref target="Unicode-UTS46" format="default" sectionFormat="of" derivedContent="Unicode-UTS46"/>.
473 A GNS name may be indistinguishable from a DNS name, and care must
474 be taken by applications and implementers when handling GNS names
475 (see <xref target="namespace_ambiguity" format="default" sectionFormat="of" derivedContent="Section 9.10"/>).
476 In order to avoid misinterpretation of example domains with (reserved)
477 DNS domains, this document uses the suffix ".gns.alt" in compliance with
478 <xref target="RFC9476" format="default" sectionFormat="of" derivedContent="RFC9476"/>.  ".gns.alt" is also registered in the GANA ".alt Subdomains" registry
479 <xref target="GANA" format="default" sectionFormat="of" derivedContent="GANA"/>.
480 </dd>
481 <dt pn="section-2-1.15">Resolver:</dt>
482 <dd pn="section-2-1.16">
483 In this document, a resolver is the component of a GNS implementation that provides
484 the recursive name resolution logic defined in
485 <xref target="resolution" format="default" sectionFormat="of" derivedContent="Section 7"/>.
486 </dd>
487 <dt pn="section-2-1.17">Resource Record:</dt>
488 <dd pn="section-2-1.18">
489 A GNS resource record is the information associated with a label in a
490 GNS zone.
491 A GNS resource record contains information as defined by its
492 resource record type.
493 </dd>
494 <dt pn="section-2-1.19">Start Zone:</dt>
495 <dd pn="section-2-1.20">
496 In order to resolve any given GNS name, an initial Start Zone must be
497 determined for this name.
498 The Start Zone can be explicitly defined as part of the name using a
499 zTLD.
500 Otherwise, it is determined through a local suffix-to-zone mapping
501 (see <xref target="governance" format="default" sectionFormat="of" derivedContent="Section 7.1"/>).
502 </dd>
503 <dt pn="section-2-1.21">Top-Level Domain (TLD):</dt>
504 <dd pn="section-2-1.22">
505 The rightmost part of a GNS name is a GNS TLD.
506 A GNS TLD can consist of one or more labels.
507 Unlike DNS TLDs (defined in <xref target="RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/>),
508 GNS does not expect all users to use the same global root zone. Instead,
509 with the exception of zTLDs (see <xref target="zTLD" format="default" sectionFormat="of" derivedContent="Section 4.1"/>),
510 GNS TLDs are typically part of the configuration of the local resolver
511 (see <xref target="governance" format="default" sectionFormat="of" derivedContent="Section 7.1"/>) and thus might not be globally unique.
512 </dd>
513 <dt pn="section-2-1.23">Zone:</dt>
514 <dd pn="section-2-1.24">
515 A GNS zone contains authoritative information (resource records).
516 A zone is uniquely identified by its zone key. Unlike DNS zones,
517 a GNS zone does not need to have an SOA record under the apex label.
518 </dd>
519 <dt pn="section-2-1.25">Zone Key:</dt>
520 <dd pn="section-2-1.26">
521 The zone key is a key that uniquely identifies a zone.
522 It is usually a public key of an asymmetric key pair.
523 However, the established technical term "public key" is misleading,
524 as in GNS a zone key may be a shared secret
525 that should not be disclosed to unauthorized parties.
526 </dd>
527 <dt pn="section-2-1.27">Zone Key Derivation Function:</dt>
528 <dd pn="section-2-1.28">
529 The zone key derivation function (ZKDF) blinds a zone key using a label.
530 </dd>
531 <dt pn="section-2-1.29">Zone Publisher:</dt>
532 <dd pn="section-2-1.30">
533 The zone publisher is the component of a GNS implementation that provides
534 local zone management and publication as defined in
535 <xref target="publish" format="default" sectionFormat="of" derivedContent="Section 6"/>.
536 </dd>
537 <dt pn="section-2-1.31">Zone Owner:</dt>
538 <dd pn="section-2-1.32">
539 The zone owner is the holder of the secret (typically a private key),
540 which (together with a label and a value to sign) allows the creation of zone
541 signatures that can be validated against the respective blinded zone key.
542 </dd>
543 <dt pn="section-2-1.33">Zone Top-Level Domain (zTLD):</dt>
544 <dd pn="section-2-1.34">
545 A GNS zTLD is a sequence of GNS labels at
546 the end of a GNS name. The zTLD encodes a zone type and
547 zone key of a zone (see <xref target="zTLD" format="default" sectionFormat="of" derivedContent="Section 4.1"/>).
548 Due to the statistical uniqueness of zone keys, zTLDs are also globally unique.
549 A zTLD label sequence can only be distinguished from ordinary TLD label sequences
550 by attempting to decode the labels into a zone type and zone key.
551 </dd>
552 <dt pn="section-2-1.35">Zone Type:</dt>
553 <dd pn="section-2-1.36">
554 The type of a GNS zone determines the cipher system and binary encoding
555 format of the zone key, blinded zone keys, and cryptographic signatures.
556 </dd>
557 </dl>
558 </section>
559 <section anchor="overview" numbered="true" removeInRFC="false" toc="include" pn="section-3">
560 <name slugifiedName="name-overview">Overview</name>
561 <t indent="0" pn="section-3-1">
562 GNS exhibits the three properties that are commonly used to describe
563 a petname system:
564 </t>
565 <dl newline="true" indent="3" spacing="normal" pn="section-3-2">
566 <dt pn="section-3-2.1">
567 Global names through the concept of zTLDs:</dt>
568 <dd pn="section-3-2.2">As zones can be uniquely identified by their zone keys
569 and are statistically unique, zTLDs are globally unique mappings to zones.
570 Consequently, GNS domain names with a zTLD suffix are also globally unique.
571 Names with zTLD suffixes are not memorable.</dd>
572 <dt pn="section-3-2.3">
573 Memorable petnames for zones:</dt>
574 <dd pn="section-3-2.4">Users can configure local, memorable references to zones.
575 Such petnames serve as zTLD monikers that provide
576 convenient names for zones to the local operator.
577 The petnames may also be published as suggestions for other
578 users searching for a good label to use when referencing the
579 respective zone.</dd>
580 <dt pn="section-3-2.5">
581 A secure mapping from names to records:</dt>
582 <dd pn="section-3-2.6">GNS allows zone owners to map labels to resource records or to
583 delegate authority of names in the subdomain induced by a label to other zones.
584 Zone owners may choose to publish this information to make it
585 available to other users.
586 Mappings are encrypted and signed
587 using keys derived from the respective label before being published in remote storage.
588 When names are resolved, signatures on resource records,
589 including delegations, are verified by the recursive resolver.</dd>
590 </dl>
591 <t indent="0" pn="section-3-3">
592 In the remainder of this document, the "implementer" refers to the developer building
593 a GNS implementation that includes the resolver, zone publisher, and
594 supporting configuration such as Start Zones (see <xref target="governance" format="default" sectionFormat="of" derivedContent="Section 7.1"/>).
595 </t>
596 <section anchor="names" numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
597 <name slugifiedName="name-names-and-zones">Names and Zones</name>
598 <t indent="0" pn="section-3.1-1">
599 It follows from the above that GNS does not support names that are
600 simultaneously global, secure, and memorable.
601 Instead, names are either global and not memorable or not globally
602 unique and memorable.
603 An example for a global name pointing to the record "example" in
604 a zone is as follows:
605 </t>
606 <sourcecode markers="false" pn="section-3.1-2">
607example.000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884
608</sourcecode>
609 <t indent="0" pn="section-3.1-3">
610 Now consider the case where a user locally configured the petname
611 "pet.gns.alt" for the zone with the "example" record of the name
612 above.
613 The name "example.pet.gns.alt" would then point to the same record as the
614 globally unique name above, but name resolution would only
615 work on the local system where the "pet.gns.alt" petname is
616 configured.
617 </t>
618 <t indent="0" pn="section-3.1-4">
619 The delegation of petnames and subsequent resolution of delegation
620 build on ideas from the Simple Distributed Security Infrastructure
621 <xref target="SDSI" format="default" sectionFormat="of" derivedContent="SDSI"/>.
622 In GNS, any user can create and manage any number of zones
623 (see <xref target="zones" format="default" sectionFormat="of" derivedContent="Section 4"/>) if their system provides a zone publisher implementation.
624 For each zone, the zone type determines the respective set of cryptographic operations
625 and the wire formats for encrypted data, public keys, and signatures.
626 A zone can be populated with mappings from labels to resource records
627 (see <xref target="rrecords" format="default" sectionFormat="of" derivedContent="Section 5"/>) by its owner.
628 A label can be mapped to a delegation record; this results in the
629 corresponding subdomain being delegated to another zone. Circular
630 delegations are explicitly allowed, including delegating a subdomain
631 to its immediate parent zone. In
632 order to support (legacy) applications as well as to facilitate the use
633 of petnames, GNS defines auxiliary record types in addition to
634 supporting existing DNS records.
635 </t>
636 </section>
637 <section anchor="publishing" numbered="true" removeInRFC="false" toc="include" pn="section-3.2">
638 <name slugifiedName="name-publishing-binding-informat">Publishing Binding Information</name>
639 <t indent="0" pn="section-3.2-1">
640 Zone contents are encrypted and signed
641 before being published in remote key-value storage (see <xref target="publish" format="default" sectionFormat="of" derivedContent="Section 6"/>),
642 as illustrated in <xref target="figure_arch_publish" format="default" sectionFormat="of" derivedContent="Figure 1"/>.
643 In this process, unique zone identification is hidden from the network
644 through the use of key blinding.
645 Key blinding allows the creation of signatures for zone contents
646 using a blinded public/private key pair.
647 This blinding is realized using a deterministic key
648 derivation from
649 the original zone key and corresponding private key using record label values
650 as inputs from which blinding factors are derived.
651 Specifically, the zone owner can derive blinded private keys for each record
652 set published under a label, and a
653 resolver can derive the corresponding blinded public keys.
654 It is expected that GNS implementations use decentralized remote
655 storage entities, such as distributed hash tables (DHTs), in order to facilitate
656 availability within a network without the need for dedicated infrastructure.
657 The specification of such a distributed or decentralized storage entity is out of
658 scope for this document, but possible existing implementations include those
659 based on <xref target="RFC7363" format="default" sectionFormat="of" derivedContent="RFC7363"/>, <xref target="Kademlia" format="default" sectionFormat="of" derivedContent="Kademlia"/>, or
660 <xref target="R5N" format="default" sectionFormat="of" derivedContent="R5N"/>.
661 </t>
662 <figure anchor="figure_arch_publish" align="left" suppress-title="false" pn="figure-1">
663 <name slugifiedName="name-an-example-diagram-of-two-h">An Example Diagram of Two Hosts Publishing GNS Zones</name>
664 <artwork name="" type="" alt="" align="left" pn="section-3.2-2.1">
665 Host A | Remote | Host B
666 | Storage |
667 | |
668 | +---------+ |
669 | / /| |
670 Publish | +---------+ | | Publish
671 +-----------+ Records | | | | | Records +-----------+
672 | Zone |----------|-&gt;| Record | |&lt;-|----------| Zone |
673 | Publisher | | | Storage | | | | Publisher |
674 +-----------+ | | |/ | +-----------+
675 A | +---------+ | A
676 | | | |
677 +---------+ | | +---------+
678 / | /| | | / | /|
679 +---------+ | | | +---------+ |
680 | | | | | | | |
681 | Local | | | | | Local | |
682 | Zones | | | | | Zones | |
683 | |/ | | | |/
684 +---------+ | | +---------+
685 </artwork>
686 </figure>
687 <t indent="0" pn="section-3.2-3">
688 A zone publisher implementation <bcp14>SHOULD</bcp14> be provided as
689 part of a GNS implementation to enable users to create and manage zones.
690 If this functionality is not implemented, names can still be resolved
691 if zone keys for the initial step in the name resolution have been
692 configured (see <xref target="resolution" format="default" sectionFormat="of" derivedContent="Section 7"/>) or if the names end with a
693 zTLD suffix.
694 </t>
695 </section>
696 <section anchor="resolving" numbered="true" removeInRFC="false" toc="include" pn="section-3.3">
697 <name slugifiedName="name-resolving-names">Resolving Names</name>
698 <t indent="0" pn="section-3.3-1">
699 Applications use the resolver to look up GNS names.
700 Starting from a configurable Start Zone, names are resolved by following zone
701 delegations recursively, as illustrated in <xref target="figure_arch_resolv" format="default" sectionFormat="of" derivedContent="Figure 2"/>.
702 For each label in a name, the recursive GNS resolver
703 fetches the respective record set from the storage layer (see <xref target="resolution" format="default" sectionFormat="of" derivedContent="Section 7"/>).
704 Without knowledge of the label values and the zone keys, the
705 different derived keys are unlinkable to both the original zone key and each
706 other.
707 This prevents zone enumeration (except via expensive online
708 brute-force attacks): to confirm the affiliation of a
709 query or the corresponding encrypted record set with a
710 specific zone requires knowledge of both the zone key and the label,
711 neither of which is disclosed to remote storage by the protocol.
712 At the same time, the blinded zone key and digital signatures
713 associated with each encrypted record set allow resolvers and oblivious remote
714 storage to verify the integrity of the published information
715 without disclosing anything about the originating zone or the record sets.
716 </t>
717 <figure anchor="figure_arch_resolv" align="left" suppress-title="false" pn="figure-2">
718 <name slugifiedName="name-high-level-view-of-the-gns-">High-Level View of the GNS Resolution Process</name>
719 <artwork name="" type="" alt="" align="left" pn="section-3.3-2.1">
720 Local Host | Remote
721 | Storage
722 |
723 | +---------+
724 | / /|
725 | +---------+ |
726+-----------+ Name +----------+ Recursive | | | |
727| | Lookup | | Resolution | | Record | |
728|Application|---------&gt;| Resolver |-------------|-&gt;| Storage | |
729| |&lt;---------| |&lt;------------|--| |/
730+-----------+ Results +----------+ Intermediate| +---------+
731 A Results |
732 | |
733 +---------+ |
734 / | /| |
735 +---------+ | |
736 | | | |
737 | Start | | |
738 | Zones | | |
739 | |/ |
740 +---------+ |
741 </artwork>
742 </figure>
743 </section>
744 </section>
745 <section anchor="zones" numbered="true" removeInRFC="false" toc="include" pn="section-4">
746 <name slugifiedName="name-zones">Zones</name>
747 <t indent="0" pn="section-4-1">
748 A zone in GNS is uniquely identified by its zone type (ztype) and zone key.
749 Each zone can be referenced by its zTLD
750 (see <xref target="zTLD" format="default" sectionFormat="of" derivedContent="Section 4.1"/>), which is a string that encodes the zone type and zone key.
751 The ztype is a unique 32-bit number that corresponds to
752 a resource record type number identifying a delegation record type
753 in the GANA "GNS Record Types" registry <xref target="GANA" format="default" sectionFormat="of" derivedContent="GANA"/>.
754 The ztype is a unique identifier for the set cryptographic functions
755 of the zone and the format of the delegation record type.
756 Any ztype registration <bcp14>MUST</bcp14> define the following set of cryptographic functions:
757 </t>
758 <dl newline="true" indent="3" spacing="normal" pn="section-4-2">
759 <dt pn="section-4-2.1">KeyGen() -&gt; d, zkey</dt>
760 <dd pn="section-4-2.2">
761 A function for generating a new private key d and
762 the corresponding public zone key zkey.
763 </dd>
764 <dt pn="section-4-2.3">ZKDF(zkey, label) -&gt; zkey'</dt>
765 <dd pn="section-4-2.4">
766 A ZKDF that blinds a zone key zkey
767 using a label.  zkey and zkey' must be unlinkable. Furthermore,
768 blinding zkey with different values for the label must result
769 in different, unlinkable zkey' values.
770 </dd>
771 <dt pn="section-4-2.5">S-Encrypt(zkey, label, expiration, plaintext) -&gt; ciphertext</dt>
772 <dd pn="section-4-2.6">
773 A symmetric encryption function that encrypts the plaintext
774 to derive ciphertext based on key material derived from the zone key zkey,
775 a label, and an expiration timestamp.
776 In order to leverage performance-enhancing caching features of certain
777 underlying storage entities -- in particular, DHTs -- a deterministic encryption
778 scheme is recommended.
779 </dd>
780 <dt pn="section-4-2.7">S-Decrypt(zkey, label, expiration, ciphertext) -&gt; plaintext</dt>
781 <dd pn="section-4-2.8">
782 A symmetric decryption function that decrypts the ciphertext
783 into plaintext based on key material derived from the zone key,
784 a label, and an expiration timestamp.
785 </dd>
786 <dt pn="section-4-2.9">Sign(d, message) -&gt; signature</dt>
787 <dd pn="section-4-2.10">
788 A function for signing a message using the private
789 key d, yielding an unforgeable cryptographic signature.
790 In order to leverage performance-enhancing caching features of certain
791 underlying storage entities -- in particular, DHTs -- a deterministic signature
792 scheme is recommended.
793 </dd>
794 <dt pn="section-4-2.11">Verify(zkey, message, signature) -&gt; boolean</dt>
795 <dd pn="section-4-2.12">
796 A function for verifying that the signature was created using
797 the private key d corresponding to the zone key zkey
798 where d,zkey := KeyGen().
799 The function returns a boolean value of "TRUE" if the signature is valid
800 and "FALSE" otherwise.
801 </dd>
802 <dt pn="section-4-2.13">SignDerived(d, label, message) -&gt; signature</dt>
803 <dd pn="section-4-2.14">
804 A function for signing a message (typically encrypted record data) that
805 can be verified using the derived zone key zkey' := ZKDF(zkey, label).
806 In order to leverage performance-enhancing caching features of certain
807 underlying storage entities -- in particular, DHTs -- a deterministic signature
808 scheme is recommended.
809 </dd>
810 <dt pn="section-4-2.15">VerifyDerived(zkey', message, signature) -&gt; boolean</dt>
811 <dd pn="section-4-2.16">
812 A function for verifying the signature using the derived zone key
813 zkey' := ZKDF(zkey, label). The function returns a boolean value
814 of "TRUE" if the signature is valid and "FALSE" otherwise. Depending
815 on the signature scheme used, this function can be identical to
816 the Verify() function.
817 </dd>
818 </dl>
819 <t indent="0" pn="section-4-3">
820 The cryptographic functions of the default ztypes are specified with
821 their corresponding delegation records as discussed in <xref target="gnsrecords_delegation" format="default" sectionFormat="of" derivedContent="Section 5.1"/>.
822 In order to support cryptographic agility, additional ztypes <bcp14>MAY</bcp14>
823 be defined in the future that replace or update the default ztypes defined in this
824 document.
825 All ztypes <bcp14>MUST</bcp14> be registered as dedicated zone delegation
826 record types in the GANA "GNS Record Types" registry (see <xref target="GANA" format="default" sectionFormat="of" derivedContent="GANA"/>).
827 When defining new record types, the cryptographic security considerations
828 of this document -- in particular, <xref target="security_cryptography" format="default" sectionFormat="of" derivedContent="Section 9.3"/> -- apply.
829 </t>
830 <section anchor="zTLD" numbered="true" removeInRFC="false" toc="include" pn="section-4.1">
831 <name slugifiedName="name-zone-top-level-domain-ztld">Zone Top-Level Domain (zTLD)</name>
832 <t indent="0" pn="section-4.1-1">
833 A zTLD is a string that encodes the
834 zone type and zone key into a domain name suffix.
835 A zTLD is used as a globally unique reference to a
836 zone in the process of name resolution.
837 It is created by encoding a binary concatenation of the zone type and
838 zone key (see <xref target="figure_zid" format="default" sectionFormat="of" derivedContent="Figure 3"/>).
839 The used encoding is a variation of the Crockford Base32 encoding
840 <xref target="CrockfordB32" format="default" sectionFormat="of" derivedContent="CrockfordB32"/> called Base32GNS.
841 The encoding and decoding symbols for Base32GNS, including this
842 variation, are defined in <xref target="CrockfordB32Encode" format="default" sectionFormat="of" derivedContent="Table 4"/>, found in <xref target="app-c" format="default" sectionFormat="of" derivedContent="Appendix C"/>.
843 The functions for encoding and decoding based on <xref target="CrockfordB32Encode" format="default" sectionFormat="of" derivedContent="Table 4"/> are called
844 Base32GNS-Encode and Base32GNS-Decode, respectively.
845 </t>
846 <figure anchor="figure_zid" align="left" suppress-title="false" pn="figure-3">
847 <name slugifiedName="name-the-binary-representation-o">The Binary Representation of the zTLD</name>
848 <artwork name="" type="" alt="" align="left" pn="section-4.1-2.1">
8490 8 16 24 32 40 48 56
850+-----+-----+-----+-----+-----+-----+-----+-----+
851| ZONE TYPE | ZONE KEY /
852+-----+-----+-----+-----+ /
853/ /
854/ /
855+-----+-----+-----+-----+-----+-----+-----+-----+
856 </artwork>
857 </figure>
858 <t indent="0" pn="section-4.1-3">
859 The ZONE TYPE <bcp14>MUST</bcp14> be encoded in network byte order. The format
860 of the ZONE KEY depends entirely on the ZONE TYPE.
861 </t>
862 <t indent="0" pn="section-4.1-4">
863 Consequently, a zTLD is encoded and decoded as follows:
864 </t>
865 <artwork name="" type="" alt="" align="left" pn="section-4.1-5">
866zTLD := Base32GNS-Encode(ztype||zkey)
867ztype||zkey := Base32GNS-Decode(zTLD)
868 </artwork>
869 <t indent="0" pn="section-4.1-6">
870 where "||" is the concatenation operator.
871 </t>
872 <t indent="0" pn="section-4.1-7">
873 The zTLD can be used "as is" as a rightmost label in a GNS name.
874 If an application wants to ensure DNS compatibility of the name,
875 it <bcp14>MAY</bcp14> also represent the zTLD as follows:
876 if the zTLD is less than or equal to 63 characters, it can
877 be used as a zTLD as is.
878 If the zTLD is longer than 63 characters, the
879 zTLD is divided into smaller labels separated by the label separator.
880 Here, the most significant bytes of the "ztype||zkey" concatenation
881 must be contained in the rightmost label of the resulting string and
882 the least significant bytes in the leftmost label of the resulting string. This allows the
883 resolver to determine the ztype and zTLD length from the rightmost
884 label and to subsequently determine how many labels the zTLD should span.
885 A GNS implementation <bcp14>MUST</bcp14> support the division of zTLDs
886 in DNS-compatible label lengths.
887 For example, assuming a zTLD of 130 characters, the division is as follows:
888 </t>
889 <artwork name="" type="" alt="" align="left" pn="section-4.1-8">
890zTLD[126..129].zTLD[63..125].zTLD[0..62]
891 </artwork>
892 </section>
893 <section anchor="revocation" numbered="true" removeInRFC="false" toc="include" pn="section-4.2">
894 <name slugifiedName="name-zone-revocation">Zone Revocation</name>
895 <t indent="0" pn="section-4.2-1">
896 In order to revoke a zone key, a signed revocation message <bcp14>MUST</bcp14> be
897 published.
898 This message <bcp14>MUST</bcp14> be signed using the private key of the zone.
899 The revocation message is broadcast to the network.
900 The specification of the broadcast mechanism is out of scope for this
901 document.
902 A possible broadcast mechanism for efficient flooding in a distributed
903 network is implemented in <xref target="GNUnet" format="default" sectionFormat="of" derivedContent="GNUnet"/>.
904 Alternatively, revocation messages could also be distributed via a
905 distributed ledger or a trusted central server.
906 To prevent
907 flooding attacks, the revocation message <bcp14>MUST</bcp14> contain a proof of work
908 (PoW).
909 The revocation message, including the PoW, <bcp14>MAY</bcp14> be calculated
910 ahead of time to support timely revocation.
911 </t>
912 <t indent="0" pn="section-4.2-2">
913 For all occurrences below, "Argon2id" is the password-based key
914 derivation function as defined in <xref target="RFC9106" format="default" sectionFormat="of" derivedContent="RFC9106"/>. For the
915 PoW calculations, the algorithm is instantiated with the
916 following parameters:
917 </t>
918 <dl newline="false" indent="3" spacing="normal" pn="section-4.2-3">
919 <dt pn="section-4.2-3.1">S:</dt>
920 <dd pn="section-4.2-3.2">The salt. Fixed 16-byte string: "GnsRevocationPow"</dd>
921 <dt pn="section-4.2-3.3">t:</dt>
922 <dd pn="section-4.2-3.4">Number of iterations: 3</dd>
923 <dt pn="section-4.2-3.5">m:</dt>
924 <dd pn="section-4.2-3.6">Memory size in KiB: 1024</dd>
925 <dt pn="section-4.2-3.7">T:</dt>
926 <dd pn="section-4.2-3.8">Output length of hash in bytes: 64</dd>
927 <dt pn="section-4.2-3.9">p:</dt>
928 <dd pn="section-4.2-3.10">Parallelization parameter: 1</dd>
929 <dt pn="section-4.2-3.11">v:</dt>
930 <dd pn="section-4.2-3.12">Algorithm version: 0x13</dd>
931 <dt pn="section-4.2-3.13">y:</dt>
932 <dd pn="section-4.2-3.14">Algorithm type (Argon2id): 2</dd>
933 <dt pn="section-4.2-3.15">X:</dt>
934 <dd pn="section-4.2-3.16">Unused</dd>
935 <dt pn="section-4.2-3.17">K:</dt>
936 <dd pn="section-4.2-3.18">Unused</dd>
937 </dl>
938 <t indent="0" pn="section-4.2-4">
939 <xref target="figure_revocation" format="default" sectionFormat="of" derivedContent="Figure 4"/> illustrates the format
940 of the data "P" on which the PoW is calculated.
941 </t>
942 <figure anchor="figure_revocation" align="left" suppress-title="false" pn="figure-4">
943 <name slugifiedName="name-the-format-of-the-pow-data">The Format of the PoW Data</name>
944 <artwork name="" type="" alt="" align="left" pn="section-4.2-5.1">
9450 8 16 24 32 40 48 56
946+-----+-----+-----+-----+-----+-----+-----+-----+
947| POW |
948+-----------------------------------------------+
949| TIMESTAMP |
950+-----------------------------------------------+
951| ZONE TYPE | ZONE KEY /
952+-----+-----+-----+-----+ /
953/ /
954/ /
955+-----+-----+-----+-----+-----+-----+-----+-----+
956 </artwork>
957 </figure>
958 <dl newline="false" indent="3" spacing="normal" pn="section-4.2-6">
959 <dt pn="section-4.2-6.1">POW:</dt>
960 <dd pn="section-4.2-6.2">
961 A 64-bit value that is a solution to the PoW. In network byte order.
962 </dd>
963 <dt pn="section-4.2-6.3">TIMESTAMP:</dt>
964 <dd pn="section-4.2-6.4">
965 Denotes the absolute 64-bit date when the revocation was computed.
966 In microseconds since midnight (0 hour), January 1, 1970 UTC in network
967 byte order.
968 </dd>
969 <dt pn="section-4.2-6.5">ZONE TYPE:</dt>
970 <dd pn="section-4.2-6.6">
971 The 32-bit zone type in network byte order.
972 </dd>
973 <dt pn="section-4.2-6.7">ZONE KEY:</dt>
974 <dd pn="section-4.2-6.8">
975 The 256-bit public key zkey of the zone that is being revoked.
976 The wire format of this value is defined by the ZONE TYPE.
977 </dd>
978 </dl>
979 <t indent="0" pn="section-4.2-7">
980 Usually, PoW schemes require that one POW value be found, such that
981 a specific number of leading zeroes are found in the hash result.
982 This number is then referred to as the difficulty of the PoW.
983 In order to reduce the variance in time it takes to calculate the
984 PoW, a valid GNS revocation requires that a number of different PoWs (Z, as defined below)
985 must be found that on average have at least D leading zeroes.
986 </t>
987 <t indent="0" pn="section-4.2-8">
988 Given an average difficulty of D, the proofs have an
989 expiration time of EPOCH. Applications <bcp14>MAY</bcp14> calculate proofs
990 with a difficulty that is higher than D by providing POW
991 values where there are (on average) more than D bits of leading zeroes.
992 With each additional bit of difficulty, the
993 lifetime of the proof is prolonged by another EPOCH.
994 Consequently, by calculating a more difficult PoW, the lifetime of the
995 proof -- and thus the persistence of the revocation message --
996 can be increased on demand by the zone owner.
997 </t>
998 <t indent="0" pn="section-4.2-9">
999 The parameters are defined as follows:
1000 </t>
1001 <dl newline="false" indent="3" spacing="normal" pn="section-4.2-10">
1002 <dt pn="section-4.2-10.1">Z:</dt>
1003 <dd pn="section-4.2-10.2">The number of PoWs that are required. Its value is fixed at 32.</dd>
1004 <dt pn="section-4.2-10.3">D:</dt>
1005 <dd pn="section-4.2-10.4">The lower limit of the average difficulty. Its value is fixed at 22.</dd>
1006 <dt pn="section-4.2-10.5">EPOCH:</dt>
1007 <dd pn="section-4.2-10.6">A single epoch. Its value is fixed at 365 days in microseconds.</dd>
1008 </dl>
1009 <t indent="0" pn="section-4.2-11">
1010 The revocation message wire format is illustrated in
1011 <xref target="figure_revocationdata" format="default" sectionFormat="of" derivedContent="Figure 5"/>.
1012 </t>
1013 <figure anchor="figure_revocationdata" align="left" suppress-title="false" pn="figure-5">
1014 <name slugifiedName="name-the-revocation-message-wire">The Revocation Message Wire Format</name>
1015 <artwork name="" type="" alt="" align="left" pn="section-4.2-12.1">
10160 8 16 24 32 40 48 56
1017+-----+-----+-----+-----+-----+-----+-----+-----+
1018| TIMESTAMP |
1019+-----+-----+-----+-----+-----+-----+-----+-----+
1020| TTL |
1021+-----+-----+-----+-----+-----+-----+-----+-----+
1022| POW_0 |
1023+-----+-----+-----+-----+-----+-----+-----+-----+
1024| ... |
1025+-----+-----+-----+-----+-----+-----+-----+-----+
1026| POW_(Z-1) |
1027+-----------------------------------------------+
1028| ZONE TYPE | ZONE KEY /
1029+-----+-----+-----+-----+ /
1030/ /
1031/ /
1032+-----+-----+-----+-----+-----+-----+-----+-----+
1033/ SIGNATURE /
1034/ /
1035/ /
1036/ /
1037+-----+-----+-----+-----+-----+-----+-----+-----+
1038 </artwork>
1039 </figure>
1040 <dl newline="false" indent="3" spacing="normal" pn="section-4.2-13">
1041 <dt pn="section-4.2-13.1">TIMESTAMP:</dt>
1042 <dd pn="section-4.2-13.2">
1043 Denotes the absolute 64-bit date when the revocation was computed.
1044 In microseconds since midnight (0 hour), January 1, 1970 UTC in network
1045 byte order. This is the same value as the timestamp used in the
1046 individual PoW calculations.
1047 </dd>
1048 <dt pn="section-4.2-13.3">TTL:</dt>
1049 <dd pn="section-4.2-13.4">
1050 Denotes the relative 64-bit time to live of the record in
1051 microseconds in network byte order.
1052 The field <bcp14>SHOULD</bcp14> be set to EPOCH * 1.1.
1053 Given an average number of leading zeroes D', then the field value
1054 <bcp14>MAY</bcp14> be increased up to (D'-D+1) * EPOCH * 1.1.
1055 Validators <bcp14>MAY</bcp14> reject messages with lower or higher
1056 values when received.
1057 </dd>
1058 <dt pn="section-4.2-13.5">POW_i:</dt>
1059 <dd pn="section-4.2-13.6">
1060 The values calculated as part of the PoW, in network byte order.
1061 Each POW_i <bcp14>MUST</bcp14> be unique in the set of POW values.
1062 To facilitate fast verification
1063 of uniqueness, the POW values <bcp14>MUST</bcp14> be given in strictly
1064 monotonically increasing order in the message.
1065 </dd>
1066 <dt pn="section-4.2-13.7">ZONE TYPE:</dt>
1067 <dd pn="section-4.2-13.8">
1068 The 32-bit zone type corresponding to the zone key in network byte order.
1069 </dd>
1070 <dt pn="section-4.2-13.9">ZONE KEY:</dt>
1071 <dd pn="section-4.2-13.10">
1072 The public key zkey of the zone that is being revoked and
1073 the key to be used to verify SIGNATURE.
1074 </dd>
1075 <dt pn="section-4.2-13.11">SIGNATURE:</dt>
1076 <dd pn="section-4.2-13.12">
1077 A signature over a timestamp and the zone zkey of the zone
1078 that is revoked and corresponds to the key used in the PoW.
1079 The signature is created using the Sign() function of
1080 the cryptosystem of the zone and the private key
1081 (see <xref target="zones" format="default" sectionFormat="of" derivedContent="Section 4"/>).
1082 </dd>
1083 </dl>
1084 <t indent="0" pn="section-4.2-14">
1085 The signature in the revocation message covers a 32-bit header
1086 prefixed to the TIMESTAMP, ZONE TYPE, and ZONE KEY fields.
1087 The header includes the key length and signature purpose.
1088 The wire format is illustrated
1089 in <xref target="figure_revsigwithpseudo" format="default" sectionFormat="of" derivedContent="Figure 6"/>.
1090 </t>
1091 <figure anchor="figure_revsigwithpseudo" align="left" suppress-title="false" pn="figure-6">
1092 <name slugifiedName="name-the-wire-format-of-the-revo">The Wire Format of the Revocation Data for Signing</name>
1093 <artwork name="" type="" alt="" align="left" pn="section-4.2-15.1">
10940 8 16 24 32 40 48 56
1095+-----+-----+-----+-----+-----+-----+-----+-----+
1096| SIZE | PURPOSE (0x03) |
1097+-----+-----+-----+-----+-----+-----+-----+-----+
1098| TIMESTAMP |
1099+-----+-----+-----+-----+-----+-----+-----+-----+
1100| ZONE TYPE | ZONE KEY /
1101+-----+-----+-----+-----+ /
1102/ /
1103/ /
1104+-----+-----+-----+-----+-----+-----+-----+-----+
1105 </artwork>
1106 </figure>
1107 <dl newline="false" indent="3" spacing="normal" pn="section-4.2-16">
1108 <dt pn="section-4.2-16.1">SIZE:</dt>
1109 <dd pn="section-4.2-16.2">
1110 A 32-bit value containing the length of the signed data in bytes
1111 in network byte order.
1112 </dd>
1113 <dt pn="section-4.2-16.3">PURPOSE:</dt>
1114 <dd pn="section-4.2-16.4">
1115 A 32-bit signature purpose flag.
1116 The value of this field <bcp14>MUST</bcp14> be 3.
1117 The value is encoded in network byte order.
1118 It defines the context in which
1119 the signature is created so that it cannot be reused in other parts
1120 of the protocol that might include possible future extensions.
1121 The value of this field corresponds to an entry in the
1122 GANA "GNUnet Signature Purposes" registry <xref target="GANA" format="default" sectionFormat="of" derivedContent="GANA"/>.
1123 </dd>
1124 <dt pn="section-4.2-16.5">TIMESTAMP:</dt>
1125 <dd pn="section-4.2-16.6">
1126 Field as defined in the revocation message above.
1127 </dd>
1128 <dt pn="section-4.2-16.7">ZONE TYPE:</dt>
1129 <dd pn="section-4.2-16.8">
1130 Field as defined in the revocation message above.
1131 </dd>
1132 <dt pn="section-4.2-16.9">ZONE KEY:</dt>
1133 <dd pn="section-4.2-16.10">Field as defined in the revocation message above.</dd>
1134 </dl>
1135 <t indent="0" pn="section-4.2-17">
1136 In order to validate a revocation, the following steps <bcp14>MUST</bcp14> be taken:
1137 </t>
1138 <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-4.2-18">
1139 <li pn="section-4.2-18.1" derivedCounter="1.">The signature <bcp14>MUST</bcp14> be verified against the zone key.</li>
1140 <li pn="section-4.2-18.2" derivedCounter="2.">The set of POW values <bcp14>MUST NOT</bcp14> contain duplicates; this <bcp14>MUST</bcp14> be checked by verifying that the values are strictly monotonically increasing.</li>
1141 <li pn="section-4.2-18.3" derivedCounter="3.">The average number of leading zeroes D' resulting from the provided
1142 POW values <bcp14>MUST</bcp14> be greater than or equal to D. Implementers
1143 <bcp14>MUST NOT</bcp14> use an integer data type to calculate or represent D'.</li>
1144 </ol>
1145 <t indent="0" pn="section-4.2-19">
1146 The TTL field in the revocation message is informational.
1147 A revocation <bcp14>MAY</bcp14> be discarded without checking the POW
1148 values or the signature if the TTL (in combination with TIMESTAMP)
1149 indicates that the revocation has already expired.
1150 The actual validity period of the
1151 revocation <bcp14>MUST</bcp14> be determined by examining the leading
1152 zeroes in the POW values.
1153 </t>
1154 <t indent="0" pn="section-4.2-20">
1155 The validity period of the revocation is calculated as
1156 (D'-D+1) * EPOCH * 1.1. The EPOCH is extended by
1157 10% in order to deal with poorly synchronized clocks.
1158 The validity period added on top of the TIMESTAMP yields the
1159 expiration date.
1160 If the current time is after the expiration date, the
1161 revocation is considered stale.
1162 </t>
1163 <t indent="0" pn="section-4.2-21">
1164 Verified revocations <bcp14>MUST</bcp14> be stored locally.
1165 The implementation <bcp14>MAY</bcp14> discard stale revocations and
1166 evict them from the local store at any time.
1167 </t>
1168 <t indent="0" pn="section-4.2-22">
1169 It is important that implementations broadcast received revocations
1170 if they are valid and not stale.
1171 Should the calculated validity period differ from the TTL field value,
1172 the calculated value <bcp14>MUST</bcp14> be used as the TTL field value
1173 when forwarding the revocation message.
1174 Systems might disagree on the current time, so implementations
1175 <bcp14>MAY</bcp14> use stale but otherwise valid
1176 revocations but <bcp14>SHOULD NOT</bcp14> broadcast them.
1177 Forwarded stale revocations <bcp14>MAY</bcp14> be discarded by the receiver.
1178 </t>
1179 <t indent="0" pn="section-4.2-23">
1180 Any locally stored revocation <bcp14>MUST</bcp14> be considered during
1181 delegation record processing (see <xref target="delegation_processing" format="default" sectionFormat="of" derivedContent="Section 7.3.4"/>).
1182 </t>
1183 </section>
1184 </section>
1185 <section anchor="rrecords" numbered="true" removeInRFC="false" toc="include" pn="section-5">
1186 <name slugifiedName="name-resource-records">Resource Records</name>
1187 <t indent="0" pn="section-5-1">
1188 A GNS implementation <bcp14>SHOULD</bcp14> provide a mechanism for creating and managing local
1189 zones as well as a persistence mechanism (such as a local database) for resource
1190 records.
1191 A new local zone is established by selecting a zone type and creating a
1192 zone key pair.
1193 If this mechanism is not implemented,
1194 no zones can be published in storage (see <xref target="publish" format="default" sectionFormat="of" derivedContent="Section 6"/>)
1195 and name resolution is limited to non-local Start Zones
1196 (see <xref target="governance" format="default" sectionFormat="of" derivedContent="Section 7.1"/>).
1197 </t>
1198 <t indent="0" pn="section-5-2">
1199 A GNS resource record holds the data of a specific record in a zone.
1200 The resource record format is illustrated in
1201 <xref target="figure_gnsrecord" format="default" sectionFormat="of" derivedContent="Figure 7"/>.
1202 </t>
1203 <figure anchor="figure_gnsrecord" align="left" suppress-title="false" pn="figure-7">
1204 <name slugifiedName="name-the-resource-record-wire-fo">The Resource Record Wire Format</name>
1205 <artwork name="" type="" alt="" align="left" pn="section-5-3.1">
12060 8 16 24 32 40 48 56
1207+-----+-----+-----+-----+-----+-----+-----+-----+
1208| EXPIRATION |
1209+-----+-----+-----+-----+-----+-----+-----+-----+
1210| SIZE | FLAGS | TYPE |
1211+-----+-----+-----+-----+-----+-----+-----+-----+
1212| DATA /
1213/ /
1214/ /
1215 </artwork>
1216 </figure>
1217 <dl newline="false" indent="3" spacing="normal" pn="section-5-4">
1218 <dt pn="section-5-4.1">EXPIRATION:</dt>
1219 <dd pn="section-5-4.2">
1220 Denotes the absolute 64-bit expiration date of the record.
1221 In microseconds since midnight (0 hour), January 1, 1970 UTC in network
1222 byte order.
1223 </dd>
1224 <dt pn="section-5-4.3">SIZE:</dt>
1225 <dd pn="section-5-4.4">
1226 Denotes the 16-bit size of the DATA field in bytes in network byte
1227 order.
1228 </dd>
1229 <dt pn="section-5-4.5">FLAGS:</dt>
1230 <dd pn="section-5-4.6">
1231 A 16-bit field indicating special properties of the resource record.
1232 The semantics of the different bits are defined below.
1233 </dd>
1234 <dt pn="section-5-4.7">TYPE:</dt>
1235 <dd pn="section-5-4.8">
1236 The 32-bit resource record type in
1237 network byte order. This type can be one of the GNS resource
1238 records as defined in <xref target="rrecords" format="default" sectionFormat="of" derivedContent="Section 5"/>, a DNS record
1239 type as defined in <xref target="RFC1035" format="default" sectionFormat="of" derivedContent="RFC1035"/>, or any of the
1240 complementary standardized DNS resource record types.
1241 Note that values
1242 below 2<sup>16</sup> are reserved for 16-bit DNS resource record types allocated by IANA <xref target="RFC6895" format="default" sectionFormat="of" derivedContent="RFC6895"/>.
1243 Values above 2<sup>16</sup> are allocated by the
1244 GANA "GNS Record Types" registry <xref target="GANA" format="default" sectionFormat="of" derivedContent="GANA"/>.
1245 </dd>
1246 <dt pn="section-5-4.9">DATA:</dt>
1247 <dd pn="section-5-4.10">
1248 The variable-length resource record data payload. The content is defined
1249 by the
1250 respective type of the resource record.
1251 </dd>
1252 </dl>
1253 <t indent="0" pn="section-5-5">
1254 The FLAGS field is used to indicate special properties of the resource record.
1255 An application creating resource records <bcp14>MUST</bcp14> set all bits
1256 in FLAGS to 0 unless it specifically understands and
1257 wants to set the respective flag.
1258 As additional flags can be defined in future protocol versions,
1259 if an application or implementation encounters a flag that it does not
1260 recognize, the flag <bcp14>MUST</bcp14> be ignored. However, all implementations
1261 <bcp14>MUST</bcp14> understand the SHADOW and CRITICAL flags defined below.
1262 Any combination of the flags specified below is valid.
1263 <xref target="figure_flag" format="default" sectionFormat="of" derivedContent="Figure 8"/>
1264 illustrates the flag distribution in the 16-bit FLAGS field of a
1265 resource record:
1266 </t>
1267 <figure anchor="figure_flag" align="left" suppress-title="false" pn="figure-8">
1268 <name slugifiedName="name-the-resource-record-flag-wi">The Resource Record Flag Wire Format</name>
1269 <artwork name="" type="" alt="" align="left" pn="section-5-6.1">
12700 13 14 15
1271+--------...+-------------+-------+---------+
1272| Reserved |SUPPLEMENTAL |SHADOW |CRITICAL |
1273+--------...+-------------+-------+---------+
1274 </artwork>
1275 </figure>
1276 <dl newline="false" indent="3" spacing="normal" pn="section-5-7">
1277 <dt pn="section-5-7.1">CRITICAL:</dt>
1278 <dd pn="section-5-7.2">
1279 If this flag is set, it indicates that processing is critical.
1280 Implementations that do not support the record type or are otherwise
1281 unable to process the record <bcp14>MUST</bcp14> abort resolution upon encountering
1282 the record in the resolution process.
1283 </dd>
1284 <dt pn="section-5-7.3">SHADOW:</dt>
1285 <dd pn="section-5-7.4">
1286 If this flag is set, this record <bcp14>MUST</bcp14> be ignored by resolvers unless all (other)
1287 records of the same record type have expired. Used to allow zone publishers to
1288 facilitate good performance when records change by allowing them to put future
1289 values of records into storage.
1290 This way, future values can propagate and can be
1291 cached before the transition becomes active.
1292 </dd>
1293 <dt pn="section-5-7.5">SUPPLEMENTAL:</dt>
1294 <dd pn="section-5-7.6">
1295 This is a supplemental record. It is provided in addition to the
1296 other records. This flag indicates that this record is not explicitly
1297 managed alongside the other records under the respective name but
1298 might be useful for the application.
1299 </dd>
1300 </dl>
1301 <section anchor="gnsrecords_delegation" numbered="true" removeInRFC="false" toc="include" pn="section-5.1">
1302 <name slugifiedName="name-zone-delegation-records">Zone Delegation Records</name>
1303 <t indent="0" pn="section-5.1-1">
1304 This section defines the initial set of zone delegation record types.
1305 Any implementation <bcp14>SHOULD</bcp14> support all zone types defined here and
1306 <bcp14>MAY</bcp14> support any number of additional delegation records defined in
1307 the GANA "GNS Record Types" registry (see <xref target="GANA" format="default" sectionFormat="of" derivedContent="GANA"/>).
1308 Not supporting some zone types will result in resolution failures if
1309 the respective zone type is encountered.
1310 This can be a valid choice if some zone delegation record types have been
1311 determined to be cryptographically insecure.
1312 Zone delegation records <bcp14>MUST NOT</bcp14> be stored or published
1313 under the apex label.
1314 A zone delegation record type value is the same as the respective ztype
1315 value.
1316 The ztype defines the cryptographic primitives for the zone that is
1317 being delegated to.
1318 A zone delegation record payload contains the public key of
1319 the zone to delegate to.
1320 A zone delegation record <bcp14>MUST</bcp14> have the CRITICAL flag set
1321 and <bcp14>MUST</bcp14> be the only non-supplemental record under a label.
1322 There <bcp14>MAY</bcp14> be inactive records of the same type that have
1323 the SHADOW flag set in order to facilitate smooth key rollovers.
1324 </t>
1325 <t indent="0" pn="section-5.1-2">
1326 In the following, "||" is the concatenation operator of two byte strings.
1327 The algorithm specification uses character strings such as GNS labels or
1328 constant values.
1329 When used in concatenations or as input to functions, the
1330 zero terminator of the character strings <bcp14>MUST NOT</bcp14> be
1331 included.
1332 </t>
1333 <section anchor="gnsrecords_pkey" numbered="true" removeInRFC="false" toc="include" pn="section-5.1.1">
1334 <name slugifiedName="name-pkey">PKEY</name>
1335 <t indent="0" pn="section-5.1.1-1">
1336 In GNS, a delegation of a label to a zone of type "PKEY" is
1337 represented through a PKEY record. The PKEY DATA entry wire format is illustrated in <xref target="figure_pkeyrecord" format="default" sectionFormat="of" derivedContent="Figure 9"/>.
1338 </t>
1339 <figure anchor="figure_pkeyrecord" align="left" suppress-title="false" pn="figure-9">
1340 <name slugifiedName="name-the-pkey-wire-format">The PKEY Wire Format</name>
1341 <artwork name="" type="" alt="" align="left" pn="section-5.1.1-2.1">
13420 8 16 24 32 40 48 56
1343+-----+-----+-----+-----+-----+-----+-----+-----+
1344| PUBLIC KEY |
1345| |
1346| |
1347| |
1348+-----+-----+-----+-----+-----+-----+-----+-----+
1349 </artwork>
1350 </figure>
1351 <dl newline="false" indent="3" spacing="normal" pn="section-5.1.1-3">
1352 <dt pn="section-5.1.1-3.1">PUBLIC KEY:</dt>
1353 <dd pn="section-5.1.1-3.2">
1354 A 256-bit Ed25519 public key.
1355 </dd>
1356 </dl>
1357 <t indent="0" pn="section-5.1.1-4">
1358 For PKEY zones, the zone key material is derived using the
1359 curve parameters of the twisted Edwards representation
1360 of Curve25519 <xref target="RFC7748" format="default" sectionFormat="of" derivedContent="RFC7748"/> (the reasoning behind choosing
1361 this curve can be found in <xref target="security_cryptography" format="default" sectionFormat="of" derivedContent="Section 9.3"/>)
1362 with the ECDSA scheme <xref target="RFC6979" format="default" sectionFormat="of" derivedContent="RFC6979"/>.
1363 The following naming convention is used for the cryptographic primitives of PKEY zones:
1364 </t>
1365 <dl newline="false" indent="3" spacing="normal" pn="section-5.1.1-5">
1366 <dt pn="section-5.1.1-5.1">d:</dt>
1367 <dd pn="section-5.1.1-5.2">
1368 A 256-bit Ed25519 private key (clamped private scalar).
1369 </dd>
1370 <dt pn="section-5.1.1-5.3">zkey:</dt>
1371 <dd pn="section-5.1.1-5.4">
1372 The Ed25519 public zone key corresponding to d.
1373 </dd>
1374 <dt pn="section-5.1.1-5.5">p:</dt>
1375 <dd pn="section-5.1.1-5.6">
1376 The prime of edwards25519 as defined in <xref target="RFC7748" format="default" sectionFormat="of" derivedContent="RFC7748"/>, i.e.,
1377 2<sup>255</sup> - 19.
1378 </dd>
1379 <dt pn="section-5.1.1-5.7">G:</dt>
1380 <dd pn="section-5.1.1-5.8">
1381 The group generator (X(P),Y(P)). With X(P),Y(P) of edwards25519 as defined in
1382 <xref target="RFC7748" format="default" sectionFormat="of" derivedContent="RFC7748"/>.
1383 </dd>
1384 <dt pn="section-5.1.1-5.9">L:</dt>
1385 <dd pn="section-5.1.1-5.10">
1386 The order of the prime-order subgroup of edwards25519 as defined in <xref target="RFC7748" format="default" sectionFormat="of" derivedContent="RFC7748"/>.
1387 </dd>
1388 <dt pn="section-5.1.1-5.11">KeyGen():</dt>
1389 <dd pn="section-5.1.1-5.12">The generation of the private
1390 scalar d and the curve point zkey := d*G (where G is the group generator
1391 of the elliptic curve) as defined in <xref target="RFC6979" sectionFormat="of" section="2.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6979#section-2.2" derivedContent="RFC6979"/> represents the KeyGen() function.
1392 </dd>
1393 </dl>
1394 <t indent="0" pn="section-5.1.1-6">
1395 The zone type and zone key of a PKEY are 4 + 32 bytes in length. This means that
1396 a zTLD will always fit into a single label and does
1397 not need any further conversion.
1398 Given a label, the output zkey' of the ZKDF(zkey, label) function is
1399 calculated as follows for PKEY zones:
1400 </t>
1401 <artwork name="" type="" alt="" align="left" pn="section-5.1.1-7">
1402ZKDF(zkey, label):
1403 PRK_h := HKDF-Extract("key-derivation", zkey)
1404 h := HKDF-Expand(PRK_h, label || "gns", 512 / 8)
1405 zkey' := (h mod L) * zkey
1406 return zkey'
1407 </artwork>
1408 <t indent="0" pn="section-5.1.1-8">
1409 The PKEY cryptosystem uses an HMAC-based key derivation function (HKDF) as defined in
1410 <xref target="RFC5869" format="default" sectionFormat="of" derivedContent="RFC5869"/>, using SHA-512 <xref target="RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/> for the extraction
1411 phase and SHA-256 <xref target="RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/> for the expansion phase.
1412 PRK_h is key material retrieved using an HKDF that uses the string
1413 "key-derivation" as the salt and the zone key as the initial
1414 keying material.
1415 h is the 512-bit HKDF expansion result and must be interpreted in
1416 network byte order. The expansion information input is
1417 a concatenation of the label and the string "gns".
1418 The multiplication of zkey with h in ZKDF() is a point multiplication,
1419 while the multiplication of d with h in SignDerived() below is a scalar multiplication.
1420 </t>
1421 <t indent="0" pn="section-5.1.1-9">
1422 The Sign() and Verify() functions
1423 for PKEY zones are implemented using 512-bit ECDSA deterministic
1424 signatures as specified in <xref target="RFC6979" format="default" sectionFormat="of" derivedContent="RFC6979"/>.
1425 The same functions can be used for derived keys:
1426 </t>
1427 <artwork name="" type="" alt="" align="left" pn="section-5.1.1-10">
1428SignDerived(d, label, message):
1429 zkey := d * G
1430 PRK_h := HKDF-Extract("key-derivation", zkey)
1431 h := HKDF-Expand(PRK_h, label || "gns", 512 / 8)
1432 d' := (h * d) mod L
1433 return Sign(d', message)
1434 </artwork>
1435 <t indent="0" pn="section-5.1.1-11">
1436 A signature is valid for the derived public key zkey' := ZKDF(zkey, label) if the following holds:
1437 </t>
1438 <artwork name="" type="" alt="" align="left" pn="section-5.1.1-12">
1439VerifyDerived(zkey', message, signature):
1440 return Verify(zkey', message, signature)
1441 </artwork>
1442 <t indent="0" pn="section-5.1.1-13">
1443 The S-Encrypt() and S-Decrypt() functions use AES in counter mode
1444 as defined in <xref target="MODES" format="default" sectionFormat="of" derivedContent="MODES"/> (CTR-AES256):
1445 </t>
1446 <artwork name="" type="" alt="" align="left" pn="section-5.1.1-14">
1447S-Encrypt(zkey, label, expiration, plaintext):
1448 PRK_k := HKDF-Extract("gns-aes-ctx-key", zkey)
1449 PRK_n := HKDF-Extract("gns-aes-ctx-iv", zkey)
1450 K := HKDF-Expand(PRK_k, label, 256 / 8)
1451 NONCE := HKDF-Expand(PRK_n, label, 32 / 8)
1452 BLOCK_COUNTER := 0x0000000000000001
1453 IV := NONCE || expiration || BLOCK_COUNTER
1454 return CTR-AES256(K, IV, plaintext)
1455
1456S-Decrypt(zkey, label, expiration, ciphertext):
1457 PRK_k := HKDF-Extract("gns-aes-ctx-key", zkey)
1458 PRK_n := HKDF-Extract("gns-aes-ctx-iv", zkey)
1459 K := HKDF-Expand(PRK_k, label, 256 / 8)
1460 NONCE := HKDF-Expand(PRK_n, label, 32 / 8)
1461 BLOCK_COUNTER := 0x0000000000000001
1462 IV := NONCE || expiration || BLOCK_COUNTER
1463 return CTR-AES256(K, IV, ciphertext)
1464 </artwork>
1465 <t indent="0" pn="section-5.1.1-15">
1466 The key K and counter Initialization Vector (IV) are derived from
1467 the record label and the zone key zkey, using an HKDF as defined in <xref target="RFC5869" format="default" sectionFormat="of" derivedContent="RFC5869"/>.
1468 SHA-512 <xref target="RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/> is used for the
1469 extraction phase and SHA-256 <xref target="RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/> for the expansion phase.
1470 The output keying material is 32 bytes (256 bits) for the symmetric
1471 key and 4 bytes (32 bits) for the NONCE.
1472 The symmetric key K is a 256-bit AES key <xref target="RFC3826" format="default" sectionFormat="of" derivedContent="RFC3826"/>.
1473 </t>
1474 <t indent="0" pn="section-5.1.1-16">
1475 The nonce is combined with a 64-bit IV and a
1476 32-bit block counter as defined in <xref target="RFC3686" format="default" sectionFormat="of" derivedContent="RFC3686"/>.
1477 The block counter begins with a value of 1, and it is incremented
1478 to generate subsequent portions of the key stream.
1479 The block counter is a 32-bit integer value in network byte order.
1480 The format of the counter IV used by the S-Encrypt() and S-Decrypt()
1481 functions is illustrated in
1482 <xref target="figure_hkdf_ivs_pkey" format="default" sectionFormat="of" derivedContent="Figure 10"/>.
1483 </t>
1484 <figure anchor="figure_hkdf_ivs_pkey" align="left" suppress-title="false" pn="figure-10">
1485 <name slugifiedName="name-structure-of-the-counter-iv">Structure of the Counter IV as Used in S-Encrypt() and
1486 S-Decrypt()</name>
1487 <artwork name="" type="" alt="" align="left" pn="section-5.1.1-17.1">
14880 8 16 24 32
1489+-----+-----+-----+-----+
1490| NONCE |
1491+-----+-----+-----+-----+
1492| EXPIRATION |
1493| |
1494+-----+-----+-----+-----+
1495| BLOCK COUNTER |
1496+-----+-----+-----+-----+
1497 </artwork>
1498 </figure>
1499 </section>
1500 <section anchor="gnsrecords_edkey" numbered="true" removeInRFC="false" toc="include" pn="section-5.1.2">
1501 <name slugifiedName="name-edkey">EDKEY</name>
1502 <t indent="0" pn="section-5.1.2-1">
1503 In GNS, a delegation of a label to a zone of type "EDKEY" is
1504 represented through an EDKEY record.
1505 The EDKEY DATA entry wire format
1506 is illustrated in <xref target="figure_edkeyrecord" format="default" sectionFormat="of" derivedContent="Figure 11"/>.
1507 </t>
1508 <figure anchor="figure_edkeyrecord" align="left" suppress-title="false" pn="figure-11">
1509 <name slugifiedName="name-the-edkey-data-wire-format">The EDKEY DATA Wire Format</name>
1510 <artwork name="" type="" alt="" align="left" pn="section-5.1.2-2.1">
15110 8 16 24 32 40 48 56
1512+-----+-----+-----+-----+-----+-----+-----+-----+
1513| PUBLIC KEY |
1514| |
1515| |
1516| |
1517+-----+-----+-----+-----+-----+-----+-----+-----+
1518 </artwork>
1519 </figure>
1520 <dl newline="false" indent="3" spacing="normal" pn="section-5.1.2-3">
1521 <dt pn="section-5.1.2-3.1">PUBLIC KEY:</dt>
1522 <dd pn="section-5.1.2-3.2">
1523 A 256-bit EdDSA zone key.
1524 </dd>
1525 </dl>
1526 <t indent="0" pn="section-5.1.2-4">
1527 For EDKEY zones, the zone key material is derived using the
1528 curve parameters of the twisted Edwards representation
1529 of Curve25519 <xref target="RFC7748" format="default" sectionFormat="of" derivedContent="RFC7748"/> (a.k.a. Ed25519)
1530 with the Ed25519 scheme <xref target="ed25519" format="default" sectionFormat="of" derivedContent="ed25519"/> as specified in
1531 <xref target="RFC8032" format="default" sectionFormat="of" derivedContent="RFC8032"/>.
1532 The following naming convention is used for the
1533 cryptographic primitives of EDKEY zones:
1534 </t>
1535 <dl newline="false" indent="3" spacing="normal" pn="section-5.1.2-5">
1536 <dt pn="section-5.1.2-5.1">d:</dt>
1537 <dd pn="section-5.1.2-5.2">
1538 A 256-bit EdDSA private key.
1539 </dd>
1540 <dt pn="section-5.1.2-5.3">a:</dt>
1541 <dd pn="section-5.1.2-5.4">
1542 An integer derived from d using the SHA-512 hash function
1543 as defined in <xref target="RFC8032" format="default" sectionFormat="of" derivedContent="RFC8032"/>.
1544 </dd>
1545 <dt pn="section-5.1.2-5.5">zkey:</dt>
1546 <dd pn="section-5.1.2-5.6">
1547 The EdDSA public key corresponding to d. It is defined
1548 as the curve point a*G where G is the
1549 group generator of the elliptic curve
1550 as defined in <xref target="RFC8032" format="default" sectionFormat="of" derivedContent="RFC8032"/>.
1551 </dd>
1552 <dt pn="section-5.1.2-5.7">p:</dt>
1553 <dd pn="section-5.1.2-5.8">
1554 The prime of edwards25519 as defined in <xref target="RFC8032" format="default" sectionFormat="of" derivedContent="RFC8032"/>, i.e.,
1555 2<sup>255</sup> - 19.
1556 </dd>
1557 <dt pn="section-5.1.2-5.9">G:</dt>
1558 <dd pn="section-5.1.2-5.10">
1559 The group generator (X(P),Y(P)). With X(P),Y(P) of edwards25519 as defined in
1560 <xref target="RFC8032" format="default" sectionFormat="of" derivedContent="RFC8032"/>.
1561 </dd>
1562 <dt pn="section-5.1.2-5.11">L:</dt>
1563 <dd pn="section-5.1.2-5.12">
1564 The order of the prime-order subgroup of edwards25519 as defined in <xref target="RFC8032" format="default" sectionFormat="of" derivedContent="RFC8032"/>.
1565 </dd>
1566 <dt pn="section-5.1.2-5.13">KeyGen():</dt>
1567 <dd pn="section-5.1.2-5.14">
1568 The generation of the private key d and the associated public
1569 key zkey := a*G (where G is the
1570 group generator of the elliptic curve and a is an integer
1571 derived from d using the SHA-512 hash function)
1572 as defined
1573 in <xref target="RFC8032" sectionFormat="of" section="5.1.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8032#section-5.1.5" derivedContent="RFC8032"/>
1574 represents the KeyGen()
1575 function.
1576 </dd>
1577 </dl>
1578 <t indent="0" pn="section-5.1.2-6">
1579 The zone type and zone key of an EDKEY are 4 + 32 bytes in length. This means that
1580 a zTLD will always fit into a single label and does
1581 not need any further conversion.
1582 </t>
1583 <t indent="0" pn="section-5.1.2-7">
1584 The "EDKEY" ZKDF instantiation is based on <xref target="Tor224" format="default" sectionFormat="of" derivedContent="Tor224"/>.
1585 As noted above for KeyGen(), a is calculated from d using the
1586 SHA-512 hash function as defined in <xref target="RFC8032" sectionFormat="of" section="5.1.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8032#section-5.1.5" derivedContent="RFC8032"/>.
1587 Given a label, the output of the ZKDF function is
1588 calculated as follows:
1589 </t>
1590 <artwork name="" type="" alt="" align="left" pn="section-5.1.2-8">
1591ZKDF(zkey, label):
1592 /* Calculate the blinding factor */
1593 PRK_h := HKDF-Extract("key-derivation", zkey)
1594 h := HKDF-Expand(PRK_h, label || "gns", 512 / 8)
1595 /* Ensure that h == h mod L */
1596 h := h mod L
1597
1598 zkey' := h * zkey
1599 return zkey'
1600 </artwork>
1601 <t indent="0" pn="section-5.1.2-9">
1602 Implementers <bcp14>SHOULD</bcp14> employ a constant-time scalar
1603 multiplication for the constructions above to protect against
1604 timing attacks. Otherwise, timing attacks could leak private key
1605 material if an attacker can predict when a system starts the
1606 publication process.
1607 </t>
1608 <t indent="0" pn="section-5.1.2-10">
1609 The EDKEY cryptosystem uses an HKDF as defined in
1610 <xref target="RFC5869" format="default" sectionFormat="of" derivedContent="RFC5869"/>, using SHA-512 <xref target="RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/> for the extraction
1611 phase and HMAC-SHA-256 <xref target="RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/> for the expansion phase.
1612 PRK_h is key material retrieved using an HKDF that uses the string
1613 "key-derivation" as the salt and the zone key as the initial
1614 keying material.
1615 The blinding factor h is the 512-bit HKDF expansion result.
1616 The expansion information input is
1617 a concatenation of the label and the string "gns".
1618 The result of the HKDF must be clamped and interpreted in network
1619 byte order.
1620 a is the 256-bit integer corresponding to the 256-bit private
1621 key d.
1622 The multiplication of zkey with h is a point multiplication.
1623 </t>
1624 <t indent="0" pn="section-5.1.2-11">
1625 The Sign(d, message) and Verify(zkey, message, signature) procedures <bcp14>MUST</bcp14>
1626 be implemented as defined in <xref target="RFC8032" format="default" sectionFormat="of" derivedContent="RFC8032"/>.
1627 </t>
1628 <t indent="0" pn="section-5.1.2-12">
1629 Signatures for EDKEY zones use a derived private scalar d';
1630 this is not compliant with <xref target="RFC8032" format="default" sectionFormat="of" derivedContent="RFC8032"/>.
1631 As the private key that corresponds to the derived private scalar
1632 is not known, it is not possible to deterministically derive the
1633 signature part R according to <xref target="RFC8032" format="default" sectionFormat="of" derivedContent="RFC8032"/>.
1634 Instead, signatures <bcp14>MUST</bcp14> be generated as follows for any given
1635 message and private zone key:
1636 a nonce is calculated from the highest 32 bytes of the
1637 expansion of the private key d and the blinding factor h.
1638 The nonce is then hashed with the message to r.
1639 This way, the full derivation path is included in the calculation
1640 of the R value of the signature, ensuring that it is never reused
1641 for two different derivation paths or messages.
1642 </t>
1643 <artwork name="" type="" alt="" align="left" pn="section-5.1.2-13">
1644SignDerived(d, label, message):
1645 /* Key expansion */
1646 dh := SHA-512(d)
1647 /* EdDSA clamping */
1648 a := dh[0..31]
1649 a[0] := a[0] &amp; 248
1650 a[31] := a[31] &amp; 127
1651 a[31] := a[31] | 64
1652 /* Calculate zkey corresponding to d */
1653 zkey := a * G
1654
1655 /* Calculate blinding factor */
1656 PRK_h := HKDF-Extract("key-derivation", zkey)
1657 h := HKDF-Expand(PRK_h, label || "gns", 512 / 8)
1658 /* Ensure that h == h mod L */
1659 h := h mod L
1660
1661 d' := (h * a) mod L
1662 nonce := SHA-256(dh[32..63] || h)
1663 r := SHA-512(nonce || message)
1664 R := r * G
1665 S := r + SHA-512(R || zkey' || message) * d' mod L
1666 return (R,S)
1667 </artwork>
1668 <t indent="0" pn="section-5.1.2-14">
1669 A signature (R,S) is valid for the derived public key zkey' :=
1670 ZKDF(zkey, label) if the following holds:
1671 </t>
1672 <artwork name="" type="" alt="" align="left" pn="section-5.1.2-15">
1673VerifyDerived(zkey', message, signature):
1674 (R,S) := signature
1675 return S * G == R + SHA-512(R, zkey', message) * zkey'
1676 </artwork>
1677 <t indent="0" pn="section-5.1.2-16">
1678 The S-Encrypt() and S-Decrypt() functions use XSalsa20
1679 as defined in <xref target="XSalsa20" format="default" sectionFormat="of" derivedContent="XSalsa20"/>
1680 and use the XSalsa20-Poly1305 encryption function:
1681 </t>
1682 <artwork name="" type="" alt="" align="left" pn="section-5.1.2-17">
1683S-Encrypt(zkey, label, expiration, plaintext):
1684 PRK_k := HKDF-Extract("gns-xsalsa-ctx-key", zkey)
1685 PRK_n := HKDF-Extract("gns-xsalsa-ctx-iv", zkey)
1686 K := HKDF-Expand(PRK_k, label, 256 / 8)
1687 NONCE := HKDF-Expand(PRK_n, label, 128 / 8)
1688 IV := NONCE || expiration
1689 return XSalsa20-Poly1305(K, IV, plaintext)
1690
1691S-Decrypt(zkey, label, expiration, ciphertext):
1692 PRK_k := HKDF-Extract("gns-xsalsa-ctx-key", zkey)
1693 PRK_n := HKDF-Extract("gns-xsalsa-ctx-iv", zkey)
1694 K := HKDF-Expand(PRK_k, label, 256 / 8)
1695 NONCE := HKDF-Expand(PRK_n, label, 128 / 8)
1696 IV := NONCE || expiration
1697 return XSalsa20-Poly1305(K, IV, ciphertext)
1698 </artwork>
1699 <t indent="0" pn="section-5.1.2-18">
1700 The result of the XSalsa20-Poly1305 encryption function is the encrypted
1701 ciphertext followed by the 128-bit authentication
1702 tag.
1703 Accordingly, the length of encrypted data equals the length of the
1704 data plus the 16 bytes of the authentication tag.
1705 </t>
1706 <t indent="0" pn="section-5.1.2-19">
1707 The key K and counter IV are derived from
1708 the record label and the zone key zkey using an HKDF as defined in
1709 <xref target="RFC5869" format="default" sectionFormat="of" derivedContent="RFC5869"/>.
1710 SHA-512 <xref target="RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/> is used for the
1711 extraction phase and SHA-256 <xref target="RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/> for the expansion phase.
1712 The output keying material is 32 bytes (256 bits) for the symmetric
1713 key and 16 bytes (128 bits) for the NONCE.
1714 The symmetric key K is a 256-bit XSalsa20 key
1715 <xref target="XSalsa20" format="default" sectionFormat="of" derivedContent="XSalsa20"/>.
1716 No additional authenticated data (AAD) is used.
1717 </t>
1718 <t indent="0" pn="section-5.1.2-20">
1719 The nonce is combined with an 8-byte IV.
1720 The IV is the expiration time of the
1721 resource record block in network byte order.
1722 The resulting counter (IV) wire format is illustrated in
1723 <xref target="figure_hkdf_ivs_edkey" format="default" sectionFormat="of" derivedContent="Figure 12"/>.
1724 </t>
1725 <figure anchor="figure_hkdf_ivs_edkey" align="left" suppress-title="false" pn="figure-12">
1726 <name slugifiedName="name-the-counter-block-initializ">The Counter Block Initialization Vector</name>
1727 <artwork name="" type="" alt="" align="left" pn="section-5.1.2-21.1">
17280 8 16 24 32 40 48 56
1729+-----+-----+-----+-----+-----+-----+-----+-----+
1730| NONCE |
1731| |
1732+-----+-----+-----+-----+-----+-----+-----+-----+
1733| EXPIRATION |
1734+-----+-----+-----+-----+-----+-----+-----+-----+
1735 </artwork>
1736 </figure>
1737 </section>
1738 </section>
1739 <section anchor="gnsrecords_redirect" numbered="true" removeInRFC="false" toc="include" pn="section-5.2">
1740 <name slugifiedName="name-redirection-records">Redirection Records</name>
1741 <t indent="0" pn="section-5.2-1">
1742 Redirection records are used to redirect resolution.
1743 Any implementation <bcp14>SHOULD</bcp14> support all redirection record types defined here
1744 and <bcp14>MAY</bcp14> support any number of additional redirection records defined in
1745 the GANA "GNS Record Types" registry <xref target="GANA" format="default" sectionFormat="of" derivedContent="GANA"/>.
1746 Redirection records <bcp14>MUST</bcp14> have the CRITICAL flag set.
1747 Not supporting some record types can result in resolution failures.
1748 This can be a valid choice if some redirection record types have been
1749 determined to be insecure, or if an application has reasons to not
1750 support redirection to DNS for reasons such as complexity or security.
1751 Redirection records <bcp14>MUST NOT</bcp14> be stored or published under the apex label.
1752 </t>
1753 <section anchor="gnsrecords_rdr" numbered="true" removeInRFC="false" toc="include" pn="section-5.2.1">
1754 <name slugifiedName="name-redirect">REDIRECT</name>
1755 <t indent="0" pn="section-5.2.1-1">
1756 A REDIRECT record is the GNS equivalent of a CNAME record in DNS.
1757 A REDIRECT record <bcp14>MUST</bcp14> be the only non-supplemental
1758 record under a label.
1759 There <bcp14>MAY</bcp14> be inactive records of the same type that have
1760 the SHADOW flag set in order to facilitate smooth changes of redirection
1761 targets.
1762 No other records are allowed.
1763 Details on the processing of this record are provided in <xref target="redirect_processing" format="default" sectionFormat="of" derivedContent="Section 7.3.1"/>.
1764
1765 A REDIRECT DATA entry is illustrated in <xref target="figure_redirectrecord" format="default" sectionFormat="of" derivedContent="Figure 13"/>.
1766 </t>
1767 <figure anchor="figure_redirectrecord" align="left" suppress-title="false" pn="figure-13">
1768 <name slugifiedName="name-the-redirect-data-wire-form">The REDIRECT DATA Wire Format</name>
1769 <artwork name="" type="" alt="" align="left" pn="section-5.2.1-2.1">
17700 8 16 24 32 40 48 56
1771+-----+-----+-----+-----+-----+-----+-----+-----+
1772| REDIRECT NAME |
1773/ /
1774/ /
1775| |
1776+-----+-----+-----+-----+-----+-----+-----+-----+
1777 </artwork>
1778 </figure>
1779 <dl newline="false" indent="3" spacing="normal" pn="section-5.2.1-3">
1780 <dt pn="section-5.2.1-3.1">REDIRECT NAME:</dt>
1781 <dd pn="section-5.2.1-3.2">
1782 The name to continue with.
1783 This value can be a regular name or a relative
1784 name.
1785 Relative GNS names are indicated by an extension label (U+002B ("+"))
1786 as the rightmost label.
1787 The string is UTF-8 encoded and zero terminated.
1788 </dd>
1789 </dl>
1790 </section>
1791 <section anchor="gnsrecords_gns2dns" numbered="true" removeInRFC="false" toc="include" pn="section-5.2.2">
1792 <name slugifiedName="name-gns2dns">GNS2DNS</name>
1793 <t indent="0" pn="section-5.2.2-1">
1794 A GNS2DNS record delegates resolution to DNS.
1795 The resource record contains a DNS name for the resolver to continue with
1796 in DNS followed by a DNS server. Both names are in the format defined in
1797 <xref target="RFC1034" format="default" sectionFormat="of" derivedContent="RFC1034"/> for DNS names.
1798 There <bcp14>MAY</bcp14> be multiple GNS2DNS records under a label.
1799 There <bcp14>MAY</bcp14> also be DNSSEC DS records or any other records used to
1800 secure the connection with the DNS servers under the same label.
1801 There <bcp14>MAY</bcp14> be inactive records of the same type or types that have
1802 the SHADOW flag set in order to facilitate smooth changes of redirection
1803 targets.
1804 No other non-supplemental record types are allowed in the same record set.
1805 A GNS2DNS DATA entry is illustrated in <xref target="figure_gns2dnsrecord" format="default" sectionFormat="of" derivedContent="Figure 14"/>.</t>
1806 <figure anchor="figure_gns2dnsrecord" align="left" suppress-title="false" pn="figure-14">
1807 <name slugifiedName="name-the-gns2dns-data-wire-forma">The GNS2DNS DATA Wire Format</name>
1808 <artwork name="" type="" alt="" align="left" pn="section-5.2.2-2.1">
18090 8 16 24 32 40 48 56
1810+-----+-----+-----+-----+-----+-----+-----+-----+
1811| NAME |
1812/ /
1813/ /
1814| |
1815+-----+-----+-----+-----+-----+-----+-----+-----+
1816| DNS SERVER NAME |
1817/ /
1818/ /
1819| |
1820+-----------------------------------------------+
1821 </artwork>
1822 </figure>
1823 <dl newline="false" indent="3" spacing="normal" pn="section-5.2.2-3">
1824 <dt pn="section-5.2.2-3.1">NAME:</dt>
1825 <dd pn="section-5.2.2-3.2">
1826 The name to continue with in DNS. The value is UTF-8 encoded and
1827 zero terminated.
1828 </dd>
1829 <dt pn="section-5.2.2-3.3">DNS SERVER NAME:</dt>
1830 <dd pn="section-5.2.2-3.4">
1831 The DNS server to use. This value can be an IPv4 address in dotted-decimal
1832 form, an IPv6 address in colon-hexadecimal form, or a DNS name.
1833 It can also be a relative GNS name ending with a
1834 "+" as the rightmost label.
1835 The implementation <bcp14>MUST</bcp14> check the string syntactically for
1836 an IP address in the respective notation before checking for a
1837 relative GNS name.
1838 If all three checks fail, the name <bcp14>MUST</bcp14> be treated as a DNS name.
1839 The value is UTF-8 encoded and zero terminated.
1840 </dd>
1841 </dl>
1842 <t indent="0" pn="section-5.2.2-4">
1843 NOTE: If an application uses DNS names obtained from GNS2DNS records
1844 in a DNS request, they <bcp14>MUST</bcp14> first be converted to an IDNA-compliant
1845 representation <xref target="RFC5890" format="default" sectionFormat="of" derivedContent="RFC5890"/>.
1846 </t>
1847 </section>
1848 </section>
1849 <section anchor="gnsrecords_other" numbered="true" removeInRFC="false" toc="include" pn="section-5.3">
1850 <name slugifiedName="name-auxiliary-records">Auxiliary Records</name>
1851 <t indent="0" pn="section-5.3-1">
1852 This section defines the initial set of auxiliary GNS record types. Any
1853 implementation <bcp14>SHOULD</bcp14> be able to process the specified record types
1854 according to <xref target="record_processing" format="default" sectionFormat="of" derivedContent="Section 7.3"/>.
1855 </t>
1856 <section anchor="gnsrecords_leho" numbered="true" removeInRFC="false" toc="include" pn="section-5.3.1">
1857 <name slugifiedName="name-leho">LEHO</name>
1858 <t indent="0" pn="section-5.3.1-1">
1859 The LEHO (LEgacy HOstname) record is used to provide a hint for legacy hostnames:
1860 applications can use the GNS to look up IPv4 or IPv6 addresses of
1861 Internet services.
1862 However, connecting to such services sometimes not only requires
1863 the knowledge of an IP address and port but also requires the canonical
1864 DNS name of the service to be transmitted over the transport protocol.
1865 In GNS, legacy hostname records provide applications the DNS name that
1866 is required to establish a connection to such a service.
1867 The most common use case is HTTP virtual hosting and TLS Server Name
1868 Indication <xref target="RFC6066" format="default" sectionFormat="of" derivedContent="RFC6066"/>, where a DNS name must
1869 be supplied in the HTTP "Host"-header and the TLS handshake,
1870 respectively.
1871 Using a GNS name in those cases might not work, as
1872 it might not be globally unique. Furthermore, even if uniqueness is
1873 not an issue, the legacy service might not even be aware of GNS.
1874 </t>
1875 <t indent="0" pn="section-5.3.1-2">
1876 A LEHO resource record is expected to be found together with A or AAAA
1877 resource records with IPv4 or IPv6 addresses.
1878 A LEHO DATA entry is illustrated in <xref target="figure_lehorecord" format="default" sectionFormat="of" derivedContent="Figure 15"/>.
1879 </t>
1880 <figure anchor="figure_lehorecord" align="left" suppress-title="false" pn="figure-15">
1881 <name slugifiedName="name-the-leho-data-wire-format">The LEHO DATA Wire Format</name>
1882 <artwork name="" type="" alt="" align="left" pn="section-5.3.1-3.1">
18830 8 16 24 32 40 48 56
1884+-----+-----+-----+-----+-----+-----+-----+-----+
1885| LEGACY HOSTNAME |
1886/ /
1887/ /
1888| |
1889+-----+-----+-----+-----+-----+-----+-----+-----+
1890 </artwork>
1891 </figure>
1892 <dl newline="false" indent="3" spacing="normal" pn="section-5.3.1-4">
1893 <dt pn="section-5.3.1-4.1">LEGACY HOSTNAME:</dt>
1894 <dd pn="section-5.3.1-4.2">
1895 A UTF-8 string (which is not zero terminated) representing the legacy hostname.
1896 </dd>
1897 </dl>
1898 <t indent="0" pn="section-5.3.1-5">
1899 NOTE: If an application uses a LEHO value in an HTTP request header
1900 (e.g., a "Host"-header), it <bcp14>MUST</bcp14> be converted to an IDNA-compliant representation
1901 <xref target="RFC5890" format="default" sectionFormat="of" derivedContent="RFC5890"/>.
1902 </t>
1903 </section>
1904 <section anchor="gnsrecords_nick" numbered="true" removeInRFC="false" toc="include" pn="section-5.3.2">
1905 <name slugifiedName="name-nick">NICK</name>
1906 <t indent="0" pn="section-5.3.2-1">
1907 Nickname records can be used by zone administrators to publish a
1908 label that a zone prefers to have used when it is referred to.
1909 This is a suggestion for other zones regarding what label to use when creating a
1910 delegation record (<xref target="gnsrecords_delegation" format="default" sectionFormat="of" derivedContent="Section 5.1"/>) containing
1911 this zone key.
1912 This record <bcp14>SHOULD</bcp14> only be stored locally
1913 under the apex label "@" but <bcp14>MAY</bcp14> be
1914 returned with record sets under any label as a supplemental record.
1915 <xref target="nick_processing" format="default" sectionFormat="of" derivedContent="Section 7.3.5"/> details how a resolver must process
1916 supplemental and non-supplemental NICK records.
1917 A NICK DATA entry is illustrated in <xref target="figure_nickrecord" format="default" sectionFormat="of" derivedContent="Figure 16"/>.
1918 </t>
1919 <figure anchor="figure_nickrecord" align="left" suppress-title="false" pn="figure-16">
1920 <name slugifiedName="name-the-nick-data-wire-format">The NICK DATA Wire Format</name>
1921 <artwork name="" type="" alt="" align="left" pn="section-5.3.2-2.1">
19220 8 16 24 32 40 48 56
1923+-----+-----+-----+-----+-----+-----+-----+-----+
1924| NICKNAME |
1925/ /
1926/ /
1927| |
1928+-----+-----+-----+-----+-----+-----+-----+-----+
1929 </artwork>
1930 </figure>
1931 <dl newline="false" indent="3" spacing="normal" pn="section-5.3.2-3">
1932 <dt pn="section-5.3.2-3.1">NICKNAME:</dt>
1933 <dd pn="section-5.3.2-3.2">
1934 A UTF-8 string (which is not zero terminated) representing the preferred
1935 label of the zone. This string <bcp14>MUST</bcp14> be a valid GNS label.
1936 </dd>
1937 </dl>
1938 </section>
1939 <section anchor="gnsrecords_box" numbered="true" removeInRFC="false" toc="include" pn="section-5.3.3">
1940 <name slugifiedName="name-box">BOX</name>
1941 <t indent="0" pn="section-5.3.3-1">
1942 GNS lookups are expected to return all of the required useful
1943 information in one record set. This avoids unnecessary additional
1944 lookups and cryptographically ties together information that belongs
1945 together, making it impossible for an adversarial storage entity to provide
1946 partial answers that might omit information critical for security.
1947 </t>
1948 <t indent="0" pn="section-5.3.3-2">
1949 This general strategy is incompatible with the
1950 special labels used by DNS for SRV and TLSA records. Thus, GNS
1951 defines the BOX record format to box up SRV and TLSA records and
1952 include them in the record set of the label they are associated
1953 with. For example, a
1954 TLSA record for "_https._tcp.example.org" will be stored in the record set of
1955 "example.org" as a BOX record with service (SVC) 443 (https), protocol (PROTO) 6
1956 (tcp), and record TYPE "TLSA".
1957 For reference, see also <xref target="RFC2782" format="default" sectionFormat="of" derivedContent="RFC2782"/>.
1958 A BOX DATA entry is illustrated in <xref target="figure_boxrecord" format="default" sectionFormat="of" derivedContent="Figure 17"/>.
1959 </t>
1960 <figure anchor="figure_boxrecord" align="left" suppress-title="false" pn="figure-17">
1961 <name slugifiedName="name-the-box-data-wire-format">The BOX DATA Wire Format</name>
1962 <artwork name="" type="" alt="" align="left" pn="section-5.3.3-3.1">
19630 8 16 24 32 40 48 56
1964+-----+-----+-----+-----+-----+-----+-----+-----+
1965| PROTO | SVC | TYPE |
1966+-----------+-----------------------------------+
1967| RECORD DATA |
1968/ /
1969/ /
1970| |
1971+-----+-----+-----+-----+-----+-----+-----+-----+
1972 </artwork>
1973 </figure>
1974 <dl newline="false" indent="3" spacing="normal" pn="section-5.3.3-4">
1975 <dt pn="section-5.3.3-4.1">PROTO:</dt>
1976 <dd pn="section-5.3.3-4.2">
1977 The 16-bit protocol number in network byte order.
1978 Values
1979 below 2<sup>8</sup> are reserved for 8-bit Internet Protocol numbers allocated by IANA <xref target="RFC5237" format="default" sectionFormat="of" derivedContent="RFC5237"/>
1980 (e.g., 6 for TCP).
1981 Values above 2<sup>8</sup> are allocated by the
1982 GANA "GNUnet Overlay Protocols" registry <xref target="GANA" format="default" sectionFormat="of" derivedContent="GANA"/>.
1983 </dd>
1984 <dt pn="section-5.3.3-4.3">SVC:</dt>
1985 <dd pn="section-5.3.3-4.4">
1986 The 16-bit service value of the boxed record in network byte order. In the case of
1987 TCP and UDP, it is the port number.
1988 </dd>
1989 <dt pn="section-5.3.3-4.5">TYPE:</dt>
1990 <dd pn="section-5.3.3-4.6">
1991 The 32-bit record type of the boxed record in network byte order.
1992 </dd>
1993 <dt pn="section-5.3.3-4.7">RECORD DATA:</dt>
1994 <dd pn="section-5.3.3-4.8">
1995 A variable-length field containing the "DATA" format of TYPE as
1996 defined for the respective TYPE. Thus, for TYPE values below 2<sup>16</sup>, the
1997 format is the same as the respective record type's binary format in DNS.
1998 </dd>
1999 </dl>
2000 </section>
2001 </section>
2002 </section>
2003 <section anchor="publish" numbered="true" removeInRFC="false" toc="include" pn="section-6">
2004 <name slugifiedName="name-record-encoding-for-remote-">Record Encoding for Remote Storage</name>
2005 <t indent="0" pn="section-6-1">
2006 Any API that allows storing a block under a 512-bit key and retrieving
2007 one or more blocks from a key can be used by an implementation for remote storage.
2008 To be useful, and to be able to support the defined zone delegation
2009 record encodings, the API <bcp14>MUST</bcp14> permit storing blocks of size
2010 176 bytes or more and <bcp14>SHOULD</bcp14> allow blocks of size 1024 bytes
2011 or more.
2012 In the following, it is assumed that an implementation realizes two
2013 procedures on top of storage:
2014 </t>
2015 <artwork name="" type="" alt="" align="left" pn="section-6-2">
2016PUT(key, block)
2017GET(key) -&gt; block
2018</artwork>
2019 <t indent="0" pn="section-6-3">
2020 A GNS implementation publishes blocks
2021 in accordance with the properties and recommendations of the underlying
2022 remote storage. This can include a periodic refresh operation to preserve the
2023 availability of published blocks.
2024 </t>
2025 <t indent="0" pn="section-6-4">
2026 There is no mechanism for explicitly deleting individual blocks from remote storage.
2027 However, blocks include an EXPIRATION field, which guides remote
2028 storage implementations to decide when to delete blocks. Given multiple blocks
2029 for the same key, remote storage implementations <bcp14>SHOULD</bcp14> try
2030 to preserve and return the block with the largest EXPIRATION value.
2031 </t>
2032 <t indent="0" pn="section-6-5">
2033 All resource records from the same zone sharing the same label are
2034 encrypted and published together in a single resource record block
2035 (RRBLOCK) in the remote storage under a key q, as illustrated
2036 in <xref target="figure_storage_publish" format="default" sectionFormat="of" derivedContent="Figure 18"/>.
2037 A GNS implementation <bcp14>MUST NOT</bcp14> include expired resource
2038 records in blocks.
2039 An implementation <bcp14>MUST</bcp14> use the PUT storage procedure
2040 when record sets change to update the zone contents. Implementations
2041 <bcp14>MUST</bcp14> ensure that the EXPIRATION fields of RRBLOCKs
2042 increase strictly monotonically for every change, even if the smallest
2043 expiration time of records in the block does not increase.
2044 </t>
2045 <figure anchor="figure_storage_publish" align="left" suppress-title="false" pn="figure-18">
2046 <name slugifiedName="name-management-and-publication-">Management and Publication of Local Zones in Distributed Storage</name>
2047 <artwork name="" type="" alt="" align="left" pn="section-6-6.1">
2048 Local Host | Remote
2049 | Storage
2050 |
2051 | +---------+
2052 | / /|
2053 | +---------+ |
2054+-----------+ | | | |
2055| | +-----------+PUT(q, RRBLOCK) | | Record | |
2056| User | | Zone |----------------|-&gt;| Storage | |
2057| | | Publisher | | | |/
2058+-----------+ +-----------+ | +---------+
2059 | A |
2060 | | Zone records |
2061 | | grouped by label |
2062 | | |
2063 | +---------+ |
2064 |Create / Delete / | /| |
2065 |and Update +---------+ | |
2066 |Local Zones | | | |
2067 | | Local | | |
2068 +--------------&gt;| Zones | | |
2069 | |/ |
2070 +---------+ |
2071 </artwork>
2072 </figure>
2073 <t indent="0" pn="section-6-7">
2074 Storage key derivation and record
2075 block creation are specified in the following sections and
2076 illustrated in <xref target="figure_storage_derivations" format="default" sectionFormat="of" derivedContent="Figure 19"/>.
2077 </t>
2078 <figure anchor="figure_storage_derivations" align="left" suppress-title="false" pn="figure-19">
2079 <name slugifiedName="name-storage-key-and-record-bloc">Storage Key and Record Block Creation Overview</name>
2080 <artwork name="" type="" alt="" align="left" pn="section-6-8.1">
2081+----------+ +-------+ +------------+ +-------------+
2082| Zone Key | | Label | | Record Set | | Private Key |
2083+----------+ +-------+ +------------+ +-------------+
2084 | | | |
2085 | | v |
2086 | | +-----------+ |
2087 | +----------&gt;| S-Encrypt | |
2088 +----------|----------&gt;+-----------+ |
2089 | | | | |
2090 | | | v v
2091 | | | +-------------+
2092 | +---------------|--&gt;| SignDerived |
2093 | | | +-------------+
2094 | | | |
2095 | v v v
2096 | +------+ +--------------+
2097 +-----&gt;| ZKDF |-------&gt;| Record Block |
2098 +------+ +--------------+
2099 |
2100 v
2101 +------+ +-------------+
2102 | Hash |-------&gt;| Storage Key |
2103 +------+ +-------------+
2104 </artwork>
2105 </figure>
2106 <section anchor="blinding" numbered="true" removeInRFC="false" toc="include" pn="section-6.1">
2107 <name slugifiedName="name-the-storage-key">The Storage Key</name>
2108 <t indent="0" pn="section-6.1-1">
2109 The storage key is derived from the zone key and the respective
2110 label of the contained records.
2111 The required knowledge of both the zone key and the label in combination
2112 with the similarly derived symmetric secret keys and blinded zone keys
2113 ensures query privacy (see <xref target="RFC8324" sectionFormat="comma" section="3.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8324#section-3.5" derivedContent="RFC8324"/>).
2114 </t>
2115 <t indent="0" pn="section-6.1-2">
2116 Given a label, the storage key q is derived as follows:
2117 </t>
2118 <artwork name="" type="" alt="" align="left" pn="section-6.1-3">
2119q := SHA-512(ZKDF(zkey, label))
2120 </artwork>
2121 <dl newline="false" indent="3" spacing="normal" pn="section-6.1-4">
2122 <dt pn="section-6.1-4.1">label:</dt>
2123 <dd pn="section-6.1-4.2">A UTF-8 string under which the resource records are published.
2124 </dd>
2125 <dt pn="section-6.1-4.3">zkey:</dt>
2126 <dd pn="section-6.1-4.4">
2127 The zone key.
2128 </dd>
2129 <dt pn="section-6.1-4.5">q:</dt>
2130 <dd pn="section-6.1-4.6">
2131 The 512-bit storage key under which the resource record block is
2132 published.
2133 It is the SHA-512 hash <xref target="RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/> over the derived zone key.
2134 </dd>
2135 </dl>
2136 </section>
2137 <section anchor="rdata" numbered="true" removeInRFC="false" toc="include" pn="section-6.2">
2138 <name slugifiedName="name-plaintext-record-data-rdata">Plaintext Record Data (RDATA)</name>
2139 <t indent="0" pn="section-6.2-1">
2140 GNS records from a zone are grouped by their labels such that all
2141 records under the same label are published together as a single
2142 block in storage. Such grouped record sets <bcp14>MAY</bcp14> be paired with
2143 supplemental records.
2144 </t>
2145 <t indent="0" pn="section-6.2-2">
2146 Record data (RDATA) is the format used to encode such a group of GNS records.
2147 The binary format of RDATA is illustrated in
2148 <xref target="figure_rdata" format="default" sectionFormat="of" derivedContent="Figure 20"/>.
2149 </t>
2150 <figure anchor="figure_rdata" align="left" suppress-title="false" pn="figure-20">
2151 <name slugifiedName="name-the-rdata-wire-format">The RDATA Wire Format</name>
2152 <artwork name="" type="" alt="" align="left" pn="section-6.2-3.1">
21530 8 16 24 32 40 48 56
2154+-----+-----+-----+-----+-----+-----+-----+-----+
2155| EXPIRATION |
2156+-----+-----+-----+-----+-----+-----+-----+-----+
2157| SIZE | FLAGS | TYPE |
2158+-----+-----+-----+-----+-----+-----+-----+-----+
2159| DATA /
2160/ /
2161/ /
2162+-----+-----+-----+-----+-----+-----+-----+-----+
2163| EXPIRATION |
2164+-----+-----+-----+-----+-----+-----+-----+-----+
2165| SIZE | FLAGS | TYPE |
2166+-----+-----+-----+-----+-----+-----+-----+-----+
2167| DATA /
2168/ /
2169+-----+-----+-----+-----+-----+-----+-----+-----+
2170| PADDING /
2171/ /
2172+-----+-----+-----+-----+-----+-----+-----+-----+
2173 </artwork>
2174 </figure>
2175 <dl newline="false" indent="3" spacing="normal" pn="section-6.2-4">
2176 <dt pn="section-6.2-4.1">EXPIRATION, SIZE, TYPE, FLAGS, and DATA:</dt>
2177 <dd pn="section-6.2-4.2">
2178 Definitions for these fields are provided below <xref target="figure_gnsrecord" format="default" sectionFormat="of" derivedContent="Figure 7"/>
2179 in <xref target="rrecords" format="default" sectionFormat="of" derivedContent="Section 5"/>.
2180 </dd>
2181 <dt pn="section-6.2-4.3">PADDING:</dt>
2182 <dd pn="section-6.2-4.4">
2183 When serializing records into RDATA, a GNS implementation <bcp14>MUST</bcp14> ensure that
2184 the size of the RDATA is a power of two
2185 using this field. The field <bcp14>MUST</bcp14> be set to zero and <bcp14>MUST</bcp14> be
2186 ignored on receipt.
2187 As a special exception, record sets with (only) a zone delegation
2188 record type are never padded.
2189 </dd>
2190 </dl>
2191 </section>
2192 <section anchor="records_block" numbered="true" removeInRFC="false" toc="include" pn="section-6.3">
2193 <name slugifiedName="name-the-resource-record-block">The Resource Record Block</name>
2194 <t indent="0" pn="section-6.3-1">
2195 The resource records grouped in an RDATA are encrypted using the S-Encrypt()
2196 function defined by the zone type of the zone to which the resource records belong
2197 and prefixed with metadata into a resource record block (RRBLOCK) for remote storage.
2198 The GNS RRBLOCK wire format is illustrated in
2199 <xref target="figure_record_block" format="default" sectionFormat="of" derivedContent="Figure 21"/>.
2200 </t>
2201 <figure anchor="figure_record_block" align="left" suppress-title="false" pn="figure-21">
2202 <name slugifiedName="name-the-rrblock-wire-format">The RRBLOCK Wire Format</name>
2203 <artwork name="" type="" alt="" align="left" pn="section-6.3-2.1">
22040 8 16 24 32 40 48 56
2205+-----+-----+-----+-----+-----+-----+-----+-----+
2206| SIZE | ZONE TYPE |
2207+-----+-----+-----+-----+-----+-----+-----+-----+
2208| ZONE KEY /
2209/ (BLINDED) /
2210| |
2211+-----+-----+-----+-----+-----+-----+-----+-----+
2212| SIGNATURE |
2213/ /
2214/ /
2215| |
2216+-----+-----+-----+-----+-----+-----+-----+-----+
2217| EXPIRATION |
2218+-----+-----+-----+-----+-----+-----+-----+-----+
2219| BDATA |
2220/ /
2221/ /
2222+-----+-----+-----+-----+-----+-----+-----+-----+
2223 </artwork>
2224 </figure>
2225 <dl newline="false" indent="3" spacing="normal" pn="section-6.3-3">
2226 <dt pn="section-6.3-3.1">SIZE:</dt>
2227 <dd pn="section-6.3-3.2">
2228 A 32-bit value containing the length of the block in bytes in network byte order.
2229 Despite the message format's use of a 32-bit value,
2230 implementations <bcp14>MAY</bcp14> refuse to publish blocks beyond a certain
2231 size significantly below the theoretical block size limit of 4 GB.
2232 </dd>
2233 <dt pn="section-6.3-3.3">ZONE TYPE:</dt>
2234 <dd pn="section-6.3-3.4">
2235 The 32-bit ztype in network byte order.
2236 </dd>
2237 <dt pn="section-6.3-3.5">ZONE KEY (BLINDED):</dt>
2238 <dd pn="section-6.3-3.6">
2239 The blinded zone key "ZKDF(zkey, label)"
2240 to be used to verify SIGNATURE.
2241 The length and format of the blinded public key depend on the ztype.
2242 </dd>
2243 <dt pn="section-6.3-3.7">SIGNATURE:</dt>
2244 <dd pn="section-6.3-3.8">
2245 The signature is computed over the EXPIRATION and BDATA fields
2246 as shown in <xref target="figure_rrsigwithpseudo" format="default" sectionFormat="of" derivedContent="Figure 22"/>.
2247 The length and format of the signature depend on the ztype.
2248 The signature is created using the SignDerived() function of
2249 the cryptosystem of the zone (see <xref target="zones" format="default" sectionFormat="of" derivedContent="Section 4"/>).
2250 </dd>
2251 <dt pn="section-6.3-3.9">EXPIRATION:</dt>
2252 <dd pn="section-6.3-3.10">
2253 Specifies when the RRBLOCK expires and the encrypted block
2254 <bcp14>SHOULD</bcp14> be removed from storage and caches, as it is likely stale.
2255 However, applications <bcp14>MAY</bcp14> continue to use non-expired individual
2256 records until they expire. The RRBLOCK expiration value <bcp14>MUST</bcp14> be computed by first determining for each record type present in the RRBLOCK the maximum expiration time of all records of that type, including shadow
2257records. Then, the minimum of all of these expiration times is taken. The final expiration time is then the larger value of (1) the previous EXPIRATION value of a previous RRBLOCK for the same storage key plus one (if any) and (2) the computed minimum expiration time across the contained record types. This ensures strict monotonicity (see <xref target="security_cryptography" format="default" sectionFormat="of" derivedContent="Section 9.3"/>).
2258 This is a 64-bit absolute date in microseconds since midnight
2259 (0 hour), January 1, 1970 UTC in network byte order.
2260 </dd>
2261 <dt pn="section-6.3-3.11">BDATA:</dt>
2262 <dd pn="section-6.3-3.12">
2263 The encrypted RDATA computed using S-Encrypt() with the
2264 zone key, label, and expiration time as additional inputs.
2265 Its ultimate size and content are determined by
2266 the S-Encrypt() function of the ztype.
2267 </dd>
2268 </dl>
2269 <t indent="0" pn="section-6.3-4">
2270 The signature over the public key covers a 32-bit pseudo header
2271 conceptually prefixed to the EXPIRATION and BDATA fields.
2272 The wire format is illustrated
2273 in <xref target="figure_rrsigwithpseudo" format="default" sectionFormat="of" derivedContent="Figure 22"/>.
2274 </t>
2275 <figure anchor="figure_rrsigwithpseudo" align="left" suppress-title="false" pn="figure-22">
2276 <name slugifiedName="name-the-wire-format-used-for-cr">The Wire Format Used for Creating the Signature of the RRBLOCK</name>
2277 <artwork name="" type="" alt="" align="left" pn="section-6.3-5.1">
22780 8 16 24 32 40 48 56
2279+-----+-----+-----+-----+-----+-----+-----+-----+
2280| SIZE | PURPOSE (0x0F) |
2281+-----+-----+-----+-----+-----+-----+-----+-----+
2282| EXPIRATION |
2283+-----+-----+-----+-----+-----+-----+-----+-----+
2284| BDATA |
2285/ /
2286/ /
2287+-----+-----+-----+-----+-----+-----+-----+-----+
2288 </artwork>
2289 </figure>
2290 <dl newline="false" indent="3" spacing="normal" pn="section-6.3-6">
2291 <dt pn="section-6.3-6.1">SIZE:</dt>
2292 <dd pn="section-6.3-6.2">
2293 A 32-bit value containing the length of the signed data in bytes
2294 in network byte order.
2295 </dd>
2296 <dt pn="section-6.3-6.3">PURPOSE:</dt>
2297 <dd pn="section-6.3-6.4">
2298 A 32-bit signature purpose flag in network byte order. The value of this
2299 field <bcp14>MUST</bcp14> be 15. It defines the context in which
2300 the signature is created so that it cannot be reused in other parts
2301 of the protocol that might include possible future extensions.
2302 The value of this field corresponds to an entry in the
2303 GANA "GNUnet Signature Purposes" registry <xref target="GANA" format="default" sectionFormat="of" derivedContent="GANA"/>.
2304 </dd>
2305 <dt pn="section-6.3-6.5">EXPIRATION:</dt>
2306 <dd pn="section-6.3-6.6">
2307 Field as defined in the RRBLOCK message above.
2308 </dd>
2309 <dt pn="section-6.3-6.7">BDATA:</dt>
2310 <dd pn="section-6.3-6.8">Field as defined in the RRBLOCK message above.</dd>
2311 </dl>
2312 </section>
2313 </section>
2314 <section anchor="resolution" numbered="true" removeInRFC="false" toc="include" pn="section-7">
2315 <name slugifiedName="name-name-resolution">Name Resolution</name>
2316 <t indent="0" pn="section-7-1">
2317 Names in GNS are resolved by recursively querying the record storage.
2318 Recursive in this context means that a resolver does not provide
2319 intermediate results for a query to the application.
2320 Instead, it <bcp14>MUST</bcp14> respond to a resolution request with either the
2321 requested resource record or an error message if resolution
2322 fails.
2323 <xref target="figure_resolution" format="default" sectionFormat="of" derivedContent="Figure 23"/> illustrates how an application
2324 requests the lookup of a GNS name (1).
2325 The application <bcp14>MAY</bcp14> provide a desired record type to the resolver.
2326 Subsequently, a Start Zone is determined (2) and the recursive
2327 resolution process started.
2328 This is where the desired record type is used to guide processing.
2329 For example, if a zone delegation record type is requested, the
2330 resolution of the apex label in that zone must be skipped, as
2331 the desired record is already found.
2332 Details on how the resolution process is initiated and each iterative
2333 result (3a,3b) in the resolution is processed are provided in the sections below.
2334 The results of the lookup are eventually returned to the application (4).
2335 The implementation <bcp14>MUST NOT</bcp14> filter the returned resource
2336 record sets according to the desired record type.
2337 Filtering of record sets is typically done by the application.
2338 </t>
2339 <figure anchor="figure_resolution" align="left" suppress-title="false" pn="figure-23">
2340 <name slugifiedName="name-the-recursive-gns-resolutio">The Recursive GNS Resolution Process</name>
2341 <artwork name="" type="" alt="" align="left" pn="section-7-2.1">
2342 Local Host | Remote
2343 | Storage
2344 |
2345 | +---------+
2346 | / /|
2347 | +---------+ |
2348+-----------+ (1) Name +----------+ | | | |
2349| | Lookup | | (3a) GET(q) | | Record | |
2350|Application|----------| Resolver |---------------|-&gt;| Storage | |
2351| |&lt;---------| |&lt;--------------|--| |/
2352+-----------+ (4) +----------+ (3b) RRBLOCK | +---------+
2353 Records A |
2354 | |
2355 (2) Determination of | |
2356 Start Zone | |
2357 | |
2358 +---------+ |
2359 / | /| |
2360 +---------+ | |
2361 | | | |
2362 | Start | | |
2363 | Zones | | |
2364 | |/ |
2365 +---------+ |
2366 </artwork>
2367 </figure>
2368 <section anchor="governance" numbered="true" removeInRFC="false" toc="include" pn="section-7.1">
2369 <name slugifiedName="name-start-zones">Start Zones</name>
2370 <t indent="0" pn="section-7.1-1">
2371 The resolution of a GNS name starts by identifying the Start Zone
2372 suffix. Once the Start Zone suffix is identified, recursive resolution
2373 of the remainder of the name is initiated (see <xref target="recursion" format="default" sectionFormat="of" derivedContent="Section 7.2"/>).
2374 There are two types of Start Zone suffixes: zTLDs and local
2375 suffix-to-zone mappings.
2376 The choice of available suffix-to-zone mappings is at the sole
2377 discretion of the local system administrator or user.
2378 This property addresses the issue of a single hierarchy with a
2379 centrally controlled root and the related issue of distribution and
2380 management of root servers in DNS (see Sections <xref target="RFC8324" section="3.12" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8324#section-3.12" derivedContent="RFC8324"/> and <xref target="RFC8324" section="3.10" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8324#section-3.10" derivedContent="RFC8324"/> of <xref target="RFC8324" format="default" sectionFormat="of" derivedContent="RFC8324"/>, respectively).
2381 </t>
2382 <t indent="0" pn="section-7.1-2">
2383 For names ending with a zTLD, the Start Zone is explicitly given in the
2384 suffix of the name to resolve.
2385 In order to ensure uniqueness of names with zTLDs, any
2386 implementation <bcp14>MUST</bcp14> use the given zone as the Start Zone.
2387 An implementation <bcp14>MUST</bcp14> first try to interpret the rightmost label of
2388 the given name as the beginning of a zTLD (see <xref target="zTLD" format="default" sectionFormat="of" derivedContent="Section 4.1"/>).
2389 If the rightmost label cannot be (partially) decoded or if it does not
2390 indicate a supported ztype, the name is treated as a normal name and
2391 Start Zone discovery <bcp14>MUST</bcp14> continue with finding a local suffix-to-zone
2392 mapping.
2393 If a valid ztype can be found in the rightmost label, the
2394 implementation <bcp14>MUST</bcp14> try to synthesize and decode the zTLD to retrieve
2395 the Start Zone key according to <xref target="zTLD" format="default" sectionFormat="of" derivedContent="Section 4.1"/>.
2396 If the zTLD cannot be synthesized or decoded, the resolution of
2397 the name fails and an error is returned to the application.
2398 Otherwise, the zone key <bcp14>MUST</bcp14> be used as the Start Zone:
2399 </t>
2400 <artwork name="" type="" alt="" align="left" pn="section-7.1-3">
2401Example name: www.example.&lt;zTLD&gt;
2402=&gt; Start Zone: zkey of type ztype
2403=&gt; Name to resolve from Start Zone: www.example
2404 </artwork>
2405 <t indent="0" pn="section-7.1-4">
2406 For names not ending with a zTLD, the resolver <bcp14>MUST</bcp14> determine the Start
2407 Zone through a local suffix-to-zone mapping.
2408 Suffix-to-zone mappings <bcp14>MUST</bcp14> be configurable through a local
2409 configuration file or database by the user or system administrator.
2410 A suffix <bcp14>MAY</bcp14> consist of multiple GNS labels concatenated with a
2411 label separator.
2412 If multiple suffixes match the name to resolve, the longest
2413 matching suffix <bcp14>MUST</bcp14> be used. The suffix length of two results
2414 <bcp14>MUST NOT</bcp14> be equal. This indicates a misconfiguration, and the
2415 implementation <bcp14>MUST</bcp14> return an error.
2416 The following is a non-normative example mapping of Start Zones:
2417 </t>
2418 <artwork name="" type="" alt="" align="left" pn="section-7.1-5">
2419Example name: www.example.xyz.gns.alt
2420Local suffix mappings:
2421xyz.gns.alt = zTLD0 := Base32GNS(ztype0||zkey0)
2422example.xyz.gns.alt = zTLD1 := Base32GNS(ztype1||zkey1)
2423example.com.gns.alt = zTLD2 := Base32GNS(ztype2||zkey2)
2424...
2425=&gt; Start Zone: zkey1
2426=&gt; Name to resolve from Start Zone: www
2427 </artwork>
2428 <t indent="0" pn="section-7.1-6">
2429 The process given above <bcp14>MAY</bcp14> be supplemented with other mechanisms if
2430 the particular application requires a different process.
2431 If no Start Zone can be identified, resolution <bcp14>MUST</bcp14> fail and an
2432 error <bcp14>MUST</bcp14> be returned to the application.
2433 </t>
2434 </section>
2435 <section anchor="recursion" numbered="true" removeInRFC="false" toc="include" pn="section-7.2">
2436 <name slugifiedName="name-recursion">Recursion</name>
2437 <t indent="0" pn="section-7.2-1">
2438 In each step of the recursive name resolution, there is an
2439 authoritative zone zkey and a name to resolve.
2440 The name <bcp14>MAY</bcp14> be empty.
2441 If the name is empty, it is interpreted as the apex label "@".
2442 Initially, the authoritative zone is the Start Zone.
2443 </t>
2444 <t indent="0" pn="section-7.2-2">
2445 From here, the following steps are recursively executed, in order:
2446 </t>
2447 <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-7.2-3">
2448 <li pn="section-7.2-3.1" derivedCounter="1.">Extract the rightmost label from the name to look up.</li>
2449 <li pn="section-7.2-3.2" derivedCounter="2.">Calculate q using the label and zkey as defined in
2450 <xref target="blinding" format="default" sectionFormat="of" derivedContent="Section 6.1"/>.</li>
2451 <li pn="section-7.2-3.3" derivedCounter="3.">Perform a storage query GET(q) to retrieve the RRBLOCK.</li>
2452 <li pn="section-7.2-3.4" derivedCounter="4.">Check that (a) the block is not expired, (b) the SHA-512 hash
2453 of the derived authoritative zone key zkey' from the RRBLOCK matches
2454 the query q, and (c) the signature is valid. If any of these
2455 tests fail, the RRBLOCK <bcp14>MUST</bcp14>
2456 be ignored and, if applicable, the storage lookup GET(q)
2457 <bcp14>MUST</bcp14> continue to look for other RRBLOCKs.</li>
2458 <li pn="section-7.2-3.5" derivedCounter="5.">Obtain the RDATA by decrypting the BDATA contained in the
2459 RRBLOCK using S-Decrypt() as defined by the zone type, effectively
2460 inverting the process described in <xref target="records_block" format="default" sectionFormat="of" derivedContent="Section 6.3"/>.</li>
2461 </ol>
2462 <t indent="0" pn="section-7.2-4">
2463 Once a well-formed block has been decrypted, the records from
2464 RDATA are subjected to record processing.
2465 </t>
2466 </section>
2467 <section anchor="record_processing" numbered="true" removeInRFC="false" toc="include" pn="section-7.3">
2468 <name slugifiedName="name-record-processing">Record Processing</name>
2469 <t indent="0" pn="section-7.3-1">
2470 In record processing, only the valid records obtained are considered.
2471 To filter records by validity, the resolver
2472 <bcp14>MUST</bcp14> at least check the expiration time and the FLAGS field of the
2473 respective record.
2474 Specifically, the resolver <bcp14>MUST</bcp14> disregard expired records.
2475 Furthermore, SHADOW and
2476 SUPPLEMENTAL flags can also exclude records from being considered.
2477 If the resolver encounters a record with the CRITICAL flag set and
2478 does not support the record type, the resolution <bcp14>MUST</bcp14> be aborted
2479 and an error <bcp14>MUST</bcp14> be returned. Information indicating that the critical
2480 record could not be processed <bcp14>SHOULD</bcp14> be returned in the error
2481 description. The implementation <bcp14>MAY</bcp14> choose not to return the reason for the failure,
2482 merely complicating troubleshooting for the user.
2483 </t>
2484 <t indent="0" pn="section-7.3-2">
2485 The next steps depend on the context of the name that is being
2486 resolved:
2487 </t>
2488 <dl newline="false" indent="3" spacing="normal" pn="section-7.3-3">
2489 <dt pn="section-7.3-3.1">Case 1:</dt>
2490 <dd pn="section-7.3-3.2">If the filtered record set consists of a single REDIRECT record,
2491 the remainder of the name is prepended to the REDIRECT DATA and the
2492 recursion is started again from the resulting name.
2493 Details are provided in <xref target="redirect_processing" format="default" sectionFormat="of" derivedContent="Section 7.3.1"/>.</dd>
2494 <dt pn="section-7.3-3.3">Case 2:</dt>
2495 <dd pn="section-7.3-3.4">If the filtered record set consists exclusively of one or more GNS2DNS records,
2496 resolution continues with DNS.
2497 Details are provided in <xref target="gns2dns_processing" format="default" sectionFormat="of" derivedContent="Section 7.3.2"/>.</dd>
2498 <dt pn="section-7.3-3.5">Case 3:</dt>
2499 <dd pn="section-7.3-3.6">If the remainder of the name to be resolved is of the format
2500 "_SERVICE._PROTO" and the record set contains one or more matching BOX
2501 records, the records in the BOX records are the final result and the recursion
2502 is concluded as described in <xref target="box_processing" format="default" sectionFormat="of" derivedContent="Section 7.3.3"/>.</dd>
2503 <dt pn="section-7.3-3.7">Case 4:</dt>
2504 <dd pn="section-7.3-3.8">If the current record set
2505 consists of a single delegation record,
2506 resolution of the remainder of the name is delegated to
2507 the target zone as described in <xref target="delegation_processing" format="default" sectionFormat="of" derivedContent="Section 7.3.4"/>.</dd>
2508 <dt pn="section-7.3-3.9">Case 5:</dt>
2509 <dd pn="section-7.3-3.10">If the remainder of the name to resolve is empty,
2510 the record set is the final result.
2511 If any NICK records are in the final result set, they <bcp14>MUST</bcp14>
2512 first be processed according to <xref target="nick_processing" format="default" sectionFormat="of" derivedContent="Section 7.3.5"/>.
2513 Otherwise, the record result set is directly returned as the final result.</dd>
2514 </dl>
2515 <t indent="0" pn="section-7.3-4">Finally, if none of the above cases are applicable, resolution fails and the
2516 resolver <bcp14>MUST</bcp14> return an empty record set.</t>
2517 <section anchor="redirect_processing" numbered="true" removeInRFC="false" toc="include" pn="section-7.3.1">
2518 <name slugifiedName="name-redirect-2">REDIRECT</name>
2519 <t indent="0" pn="section-7.3.1-1">
2520 If the remaining name is empty and the desired record type is
2521 REDIRECT, the resolution concludes with the REDIRECT record.
2522 If the rightmost label of the REDIRECT NAME is the extension label
2523 (U+002B ("+")),
2524 resolution continues in GNS with the new name in the
2525 current zone.
2526 Otherwise, the resulting name is resolved via the
2527 default operating system name resolution process.
2528 This can in turn trigger a GNS name resolution process, depending
2529 on the system configuration.
2530 If resolution continues in DNS, the name <bcp14>MUST</bcp14> first be
2531 converted to an IDNA-compliant representation <xref target="RFC5890" format="default" sectionFormat="of" derivedContent="RFC5890"/>.
2532 </t>
2533 <t indent="0" pn="section-7.3.1-2">
2534 In order to prevent infinite loops, the resolver <bcp14>MUST</bcp14>
2535 implement loop detection or limit the number of recursive
2536 resolution steps.
2537 The loop detection <bcp14>MUST</bcp14> be effective even
2538 if a REDIRECT found in GNS triggers subsequent GNS lookups via
2539 the default operating system name resolution process.
2540 </t>
2541 </section>
2542 <section anchor="gns2dns_processing" numbered="true" removeInRFC="false" toc="include" pn="section-7.3.2">
2543 <name slugifiedName="name-gns2dns-2">GNS2DNS</name>
2544 <t indent="0" pn="section-7.3.2-1">
2545 A resolver returns GNS2DNS records when all of the following
2546 conditions are met:
2547 </t>
2548 <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-7.3.2-2">
2549 <li pn="section-7.3.2-2.1" derivedCounter="1.">The resolver encounters one or more GNS2DNS records;</li>
2550 <li pn="section-7.3.2-2.2" derivedCounter="2.">The remaining name is empty; and</li>
2551 <li pn="section-7.3.2-2.3" derivedCounter="3.">The desired record type is GNS2DNS.</li>
2552 </ol>
2553 <t indent="0" pn="section-7.3.2-3">
2554 Otherwise, it is expected that the resolver first resolves the
2555 IP addresses of the specified DNS name servers.
2556 The DNS name <bcp14>MUST</bcp14> be converted to an IDNA-compliant
2557 representation <xref target="RFC5890" format="default" sectionFormat="of" derivedContent="RFC5890"/> for resolution in DNS.
2558 GNS2DNS records <bcp14>MAY</bcp14>
2559 contain numeric IPv4 or IPv6 addresses, allowing the resolver to
2560 skip this step.
2561 The DNS server names might themselves be names in GNS or DNS.
2562 If the rightmost label of the DNS server name is the extension label
2563 (U+002B ("+")), the rest of the name is to be
2564 interpreted relative to the zone of the GNS2DNS record.
2565 If the DNS server name ends in a label representation of a
2566 zone key, the DNS server name is to be resolved against
2567 the GNS zone zkey.
2568 </t>
2569 <t indent="0" pn="section-7.3.2-4">
2570 Multiple GNS2DNS records can be stored under the same label,
2571 in which case the resolver <bcp14>MUST</bcp14> try all of them.
2572 The resolver <bcp14>MAY</bcp14> try them in any order or even in parallel.
2573 If multiple GNS2DNS records are present, the DNS name <bcp14>MUST</bcp14> be
2574 identical for all of them. Otherwise, it is not clear which name
2575 the resolver is supposed to follow. If different DNS names are
2576 present, the resolution fails and an
2577 appropriate error <bcp14>SHOULD</bcp14> be returned to the application.
2578 </t>
2579 <t indent="0" pn="section-7.3.2-5">
2580 If there are DNSSEC DS records or any other records used to
2581 secure the connection with the DNS servers stored under the label,
2582 the DNS resolver <bcp14>SHOULD</bcp14> use them to secure the connection with
2583 the DNS server.
2584 </t>
2585 <t indent="0" pn="section-7.3.2-6">
2586 Once the IP addresses of the DNS servers have been determined,
2587 the DNS name from the GNS2DNS record is appended
2588 to the remainder of the name to be resolved and is
2589 resolved by querying the DNS name server(s).
2590 The synthesized name has to be converted to an IDNA-compliant
2591 representation <xref target="RFC5890" format="default" sectionFormat="of" derivedContent="RFC5890"/> for resolution in DNS.
2592 If such a conversion is not possible, the resolution <bcp14>MUST</bcp14> be aborted
2593 and an error <bcp14>MUST</bcp14> be returned. Information indicating that the critical
2594 record could not be processed <bcp14>SHOULD</bcp14> be returned in the error
2595 description. The implementation <bcp14>MAY</bcp14> choose not to return the reason for the failure,
2596 merely complicating troubleshooting for the user.
2597 </t>
2598 <t indent="0" pn="section-7.3.2-7">
2599 As the DNS servers
2600 specified are possibly authoritative DNS servers, the GNS resolver <bcp14>MUST</bcp14>
2601 support recursive DNS resolution and <bcp14>MUST NOT</bcp14> delegate this to the
2602 authoritative DNS servers.
2603 The first successful recursive name resolution result
2604 is returned to the application.
2605 In addition, the resolver <bcp14>SHOULD</bcp14> return the queried DNS name as a
2606 supplemental LEHO record (see <xref target="gnsrecords_leho" format="default" sectionFormat="of" derivedContent="Section 5.3.1"/>) with a
2607 relative expiration time of one hour.
2608 </t>
2609 <t indent="0" pn="section-7.3.2-8">
2610 Once the transition from GNS to DNS is made through a
2611 GNS2DNS record, there is no "going back".
2612 The (possibly recursive) resolution of the DNS name <bcp14>MUST NOT</bcp14>
2613 delegate back into GNS and should only follow the DNS specifications.
2614 For example, names contained in DNS CNAME records <bcp14>MUST NOT</bcp14> be
2615 interpreted by resolvers that support both DNS and GNS as GNS names.
2616 </t>
2617 <t indent="0" pn="section-7.3.2-9">
2618 GNS resolvers <bcp14>SHOULD</bcp14> offer a configuration
2619 option to disable DNS processing to avoid information leakage
2620 and provide a consistent security profile for all name resolutions.
2621 Such resolvers would return an empty record set upon encountering
2622 a GNS2DNS record during the recursion. However, if GNS2DNS records
2623 are encountered in the record set for the apex label and a GNS2DNS record
2624 is explicitly requested by the application, such records <bcp14>MUST</bcp14>
2625 still be returned, even if DNS support is disabled by the
2626 GNS resolver configuration.
2627 </t>
2628 </section>
2629 <section anchor="box_processing" numbered="true" removeInRFC="false" toc="include" pn="section-7.3.3">
2630 <name slugifiedName="name-box-2">BOX</name>
2631 <t indent="0" pn="section-7.3.3-1">
2632 When a BOX record is received, a GNS resolver must unbox it if the
2633 name to be resolved continues with "_SERVICE._PROTO".
2634 Otherwise, the BOX record is to be left untouched. This way, TLSA
2635 (and SRV) records do not require a separate network request, and
2636 TLSA records become inseparable from the corresponding address
2637 records.
2638 </t>
2639 </section>
2640 <section anchor="delegation_processing" numbered="true" removeInRFC="false" toc="include" pn="section-7.3.4">
2641 <name slugifiedName="name-zone-delegation-records-2">Zone Delegation Records</name>
2642 <t indent="0" pn="section-7.3.4-1">
2643 When the resolver encounters a record of a supported
2644 zone delegation record type (such as PKEY or EDKEY)
2645 and the remainder of the name is not empty, resolution continues
2646 recursively with the remainder of the name in the
2647 GNS zone specified in the delegation record.
2648 </t>
2649 <t indent="0" pn="section-7.3.4-2">
2650 Whenever a resolver encounters a new GNS zone, it <bcp14>MUST</bcp14>
2651 check against the local revocation list (see <xref target="revocation" format="default" sectionFormat="of" derivedContent="Section 4.2"/>) to see
2652 whether the respective
2653 zone key has been revoked. If the zone key was revoked, the
2654 resolution <bcp14>MUST</bcp14> fail with an empty result set.
2655 </t>
2656 <t indent="0" pn="section-7.3.4-3">
2657 Implementations <bcp14>MUST NOT</bcp14> allow multiple different zone
2658 delegations under a single label (except if some are shadow records).
2659 Implementations <bcp14>MAY</bcp14> support any subset of ztypes.
2660 Implementations <bcp14>MUST NOT</bcp14> process zone delegation records
2661 stored under the apex label ("@"). If a zone delegation record is encountered under
2662 the apex label, resolution fails and an error <bcp14>MUST</bcp14> be returned. The
2663 implementation <bcp14>MAY</bcp14> choose not to return the reason for the failure,
2664 merely impacting troubleshooting information for the user.
2665 </t>
2666 <t indent="0" pn="section-7.3.4-4">
2667 If the remainder of the name to resolve is empty and a record set was
2668 received containing only a single delegation record, the recursion is
2669 continued with the record value as the authoritative zone and the
2670 apex label "@" as the remaining name. The exception is the case
2671 where the desired record type as specified by the application is
2672 equal to the ztype, in which case the delegation record is returned.
2673 </t>
2674 </section>
2675 <section anchor="nick_processing" numbered="true" removeInRFC="false" toc="include" pn="section-7.3.5">
2676 <name slugifiedName="name-nick-2">NICK</name>
2677 <t indent="0" pn="section-7.3.5-1">
2678 NICK records are only relevant to the recursive resolver
2679 if the record set in question is the final result, which is to
2680 be returned to the application. The encountered NICK records can be either
2681 supplemental (see <xref target="rrecords" format="default" sectionFormat="of" derivedContent="Section 5"/>) or
2682 non-supplemental.
2683 If the NICK record is supplemental, the resolver only returns the
2684 record set if one of the non-supplemental records matches the
2685 queried record type.
2686 It is possible that one record set contains both supplemental
2687 and non-supplemental NICK records.
2688 </t>
2689 <t indent="0" pn="section-7.3.5-2">
2690 The differentiation between a supplemental and non-supplemental
2691 NICK record allows the application to match the record to the
2692 authoritative zone. Consider the following example:
2693 </t>
2694 <artwork name="" type="" alt="" align="left" pn="section-7.3.5-3">
2695Query: alice.example.gns.alt (type=A)
2696Result:
2697A: 192.0.2.1
2698NICK: eve (non-supplemental)
2699 </artwork>
2700 <t indent="0" pn="section-7.3.5-4">
2701 In this example, the returned NICK record is non-supplemental.
2702 For the application, this means that the NICK belongs to the zone
2703 "alice.example.gns.alt" and is published under the apex label along with an A
2704 record. The NICK record is interpreted as follows: the zone defined by
2705 "alice.example.gns.alt" wants to be referred to as "eve".
2706 In contrast, consider the following:
2707 </t>
2708 <artwork name="" type="" alt="" align="left" pn="section-7.3.5-5">
2709Query: alice.example.gns.alt (type=AAAA)
2710Result:
2711AAAA: 2001:db8::1
2712NICK: john (supplemental)
2713 </artwork>
2714 <t indent="0" pn="section-7.3.5-6">
2715 In this case, the NICK record is marked as supplemental. This means that
2716 the NICK record belongs to the zone "example.gns.alt" and is published under the
2717 label "alice" along with a AAAA record. Here, the NICK record should be
2718 interpreted as follows: the zone defined by "example.gns.alt" wants to be referred to as
2719 "john". This distinction is likely useful for other records published as
2720 supplemental.
2721 </t>
2722 </section>
2723 </section>
2724 </section>
2725 <section anchor="encoding" numbered="true" removeInRFC="false" toc="include" pn="section-8">
2726 <name slugifiedName="name-internationalization-and-ch">Internationalization and Character Encoding</name>
2727 <t indent="0" pn="section-8-1">
2728 All names in GNS are encoded in UTF-8 <xref target="RFC3629" format="default" sectionFormat="of" derivedContent="RFC3629"/>.
2729 Labels <bcp14>MUST</bcp14> be canonicalized using
2730 Normalization Form C (NFC) <xref target="Unicode-UAX15" format="default" sectionFormat="of" derivedContent="Unicode-UAX15"/>.
2731 This does not include any DNS names found in DNS records, such as CNAME
2732 record data, which is internationalized through the IDNA specifications;
2733 see <xref target="RFC5890" format="default" sectionFormat="of" derivedContent="RFC5890"/>.
2734 </t>
2735 </section>
2736 <section anchor="security" numbered="true" removeInRFC="false" toc="include" pn="section-9">
2737 <name slugifiedName="name-security-and-privacy-consid">Security and Privacy Considerations</name>
2738 <section anchor="security_availability" numbered="true" removeInRFC="false" toc="include" pn="section-9.1">
2739 <name slugifiedName="name-availability">Availability</name>
2740 <t indent="0" pn="section-9.1-1">
2741 In order to ensure availability of records beyond their
2742 absolute expiration times, implementations <bcp14>MAY</bcp14> allow
2743 relative expiration time values of records to be locally defined.
2744 Records can then be published recurringly with updated
2745 absolute expiration times by the implementation.
2746 </t>
2747 <t indent="0" pn="section-9.1-2">
2748 Implementations <bcp14>MAY</bcp14> allow users to manage private records in
2749 their zones that are not published in storage.
2750 Private records are treated just like
2751 regular records when resolving labels in local zones,
2752 but their data is completely unavailable to non-local users.
2753 </t>
2754 </section>
2755 <section anchor="security_agility" numbered="true" removeInRFC="false" toc="include" pn="section-9.2">
2756 <name slugifiedName="name-agility">Agility</name>
2757 <t indent="0" pn="section-9.2-1">
2758 The security of cryptographic systems depends on both the strength of
2759 the cryptographic algorithms chosen and the strength of the keys used
2760 with those algorithms. This security also depends on the engineering
2761 of the protocol used by the system to ensure that there are no
2762 non-cryptographic ways to bypass the security of the overall system.
2763 This is why developers of applications managing GNS zones <bcp14>SHOULD</bcp14>
2764 select a default ztype considered secure at the time of
2765 releasing the software.
2766 For applications targeting end users that are not expected to
2767 understand cryptography, the application developer <bcp14>MUST NOT</bcp14> leave
2768 the ztype selection of new zones to end users.
2769 </t>
2770 <t indent="0" pn="section-9.2-2">
2771 This document concerns itself with the selection of cryptographic
2772 algorithms used in GNS.
2773 The algorithms identified in this document are not known to be
2774 broken (in the cryptographic sense) at the current time, and
2775 cryptographic research so far leads us to believe that they are
2776 likely to remain secure into the foreseeable future. However, this
2777 is not necessarily forever, and it is expected that new revisions of
2778 this document will be issued from time to time to reflect the current
2779 best practices in this area.
2780 </t>
2781 <t indent="0" pn="section-9.2-3">
2782 In terms of crypto-agility, whenever the need for an updated cryptographic
2783 scheme arises to, for example, replace ECDSA over Ed25519 for
2784 PKEY records, it can simply be introduced
2785 through a new record type.
2786 Zone administrators can then replace
2787 the delegation record type for future records.
2788 The old record type remains,
2789 and zones can iteratively migrate to the updated zone keys.
2790 To ensure that implementations correctly generate an error message
2791 when encountering a ztype that they do not support,
2792 current and future delegation records must always have the
2793 CRITICAL flag set.
2794 </t>
2795 </section>
2796 <section anchor="security_cryptography" numbered="true" removeInRFC="false" toc="include" pn="section-9.3">
2797 <name slugifiedName="name-cryptography">Cryptography</name>
2798 <t indent="0" pn="section-9.3-1">
2799 The following considerations provide background on the design choices
2800 of the ztypes specified in this document.
2801 When specifying new ztypes as per <xref target="zones" format="default" sectionFormat="of" derivedContent="Section 4"/>, the same
2802 considerations apply.
2803 </t>
2804 <t indent="0" pn="section-9.3-2">
2805 GNS PKEY zone keys use ECDSA over Ed25519.
2806 This is an unconventional choice,
2807 as ECDSA is usually used with other curves. However, standardized
2808 ECDSA curves are problematic for a range of reasons, as described in
2809 the Curve25519 and EdDSA papers <xref target="RFC7748" format="default" sectionFormat="of" derivedContent="RFC7748"/> <xref target="ed25519" format="default" sectionFormat="of" derivedContent="ed25519"/>.
2810 Using EdDSA directly is also
2811 not possible, as a hash function is used on the private key and
2812 will destroy the linearity that the key blinding in GNS depends upon.
2813 We are not aware of anyone suggesting that using Ed25519 instead
2814 of another common curve of similar size would lower the security of
2815 ECDSA. GNS uses 256-bit curves; that way, the encoded (public)
2816 keys fit into a single DNS label, which is good for usability.
2817 </t>
2818 <t indent="0" pn="section-9.3-3">
2819 In order to ensure ciphertext indistinguishability, care must be
2820 taken with respect to the IV in the counter
2821 block. In our design, the IV always includes the expiration time of the
2822 record block.
2823 When applications store records with relative expiration times,
2824 monotonicity is implicitly
2825 ensured because each time a block is published in storage, its IV is
2826 unique, as the expiration time is calculated dynamically and increases
2827 monotonically with the system time. Still,
2828 an implementation <bcp14>MUST</bcp14> ensure that when relative expiration times
2829 are decreased, the expiration time of the next record block <bcp14>MUST</bcp14>
2830 be after the last published block.
2831 For records where an absolute expiration time is used, the implementation
2832 <bcp14>MUST</bcp14> ensure that the expiration time is always increased when the record
2833 data changes. For example, the expiration time on the wire could be increased
2834 by a single microsecond even if the user did not request a change.
2835 In the case of deletion of all resource records under a label, the
2836 implementation <bcp14>MUST</bcp14> keep track of the last absolute expiration time
2837 of the last published resource block. Implementations <bcp14>MAY</bcp14> define
2838 and use a special record type as a tombstone that preserves the last
2839 absolute expiration time but then <bcp14>MUST</bcp14> take care to not publish a
2840 block with such a tombstone record.
2841 When new records are added under this label later, the implementation
2842 <bcp14>MUST</bcp14> ensure that the expiration times are after the last published
2843 block.
2844 Finally, in order to ensure monotonically increasing expiration times,
2845 the implementation <bcp14>MUST</bcp14> keep a local record of the last time obtained
2846 from the system clock, so as to construct a monotonic clock if
2847 the system clock jumps backwards.
2848 </t>
2849 </section>
2850 <section anchor="security_abuse" numbered="true" removeInRFC="false" toc="include" pn="section-9.4">
2851 <name slugifiedName="name-abuse-mitigation">Abuse Mitigation</name>
2852 <t indent="0" pn="section-9.4-1">
2853 GNS names are UTF-8 strings. Consequently, GNS faces issues
2854 with respect to name spoofing similar to those for DNS with respect to internationalized
2855 domain names.
2856 In DNS, attackers can register similar-sounding or similar-looking
2857 names (see above) in order to execute phishing attacks.
2858 GNS zone administrators must take into account this attack vector and
2859 incorporate rules in order to mitigate it.
2860 </t>
2861 <t indent="0" pn="section-9.4-2">
2862 Further, DNS can be used to combat illegal content on the Internet
2863 by having the respective domains seized by authorities.
2864 However, the same mechanisms can also be abused in order to impose
2865 state censorship.
2866 Avoiding that possibility is one of the motivations behind GNS.
2867 In GNS, TLDs are not enumerable. By design, the Start Zone of
2868 the resolver is defined locally, and hence such a seizure is
2869 difficult and ineffective in GNS.
2870 </t>
2871 </section>
2872 <section anchor="security_keymanagement" numbered="true" removeInRFC="false" toc="include" pn="section-9.5">
2873 <name slugifiedName="name-zone-management">Zone Management</name>
2874 <t indent="0" pn="section-9.5-1">
2875 In GNS, zone administrators need to manage and protect their zone
2876 keys. Once a private zone key is lost, it cannot be recovered, and
2877 the zone revocation message cannot be computed anymore.
2878 Revocation messages can be precalculated if revocation is
2879 required in cases where a private zone key is lost.
2880 Zone administrators, and for GNS this includes end users, are
2881 required to responsibly and diligently protect their cryptographic
2882 keys.
2883 GNS supports signing records in advance ("offline") in order to
2884 support processes (such as air gaps) that aim to protect private keys.
2885 </t>
2886 <t indent="0" pn="section-9.5-2">
2887 Similarly, users are required to manage their local Start Zone configuration.
2888 In order to ensure the integrity and availability of names, users must
2889 ensure that their local Start Zone information is not compromised or
2890 outdated.
2891 It can be expected that the processing of zone revocations and an
2892 initial Start Zone are provided with a GNS implementation
2893 ("drop shipping").
2894 Shipping an initial Start Zone configuration effectively establishes
2895 a root zone.
2896 Extension and customization of the zone are at the full discretion of
2897 the user.
2898 </t>
2899 <t indent="0" pn="section-9.5-3">
2900 While implementations following this specification will be
2901 interoperable, if two implementations connect to different remote storage entities,
2902 they are mutually unreachable.
2903 This can lead to a state where a record exists in the global
2904 namespace for a particular name, but the implementation is not
2905 communicating with the remote storage entity that contains the respective
2906 block and is hence unable to resolve it.
2907 This situation is similar to a split-horizon DNS configuration.
2908 The remote storage entity used will most likely depend on the specific application
2909 context using GNS resolution.
2910 For example, one application is the resolution of hidden services
2911 within the Tor network <xref target="TorRendSpec" format="default" sectionFormat="of" derivedContent="TorRendSpec"/>, which would suggest using Tor routers for remote storage.
2912 Implementations of "aggregated" remote storage entities are conceivable but
2913 are expected to be the exception.
2914 </t>
2915 </section>
2916 <section anchor="security_dht" numbered="true" removeInRFC="false" toc="include" pn="section-9.6">
2917 <name slugifiedName="name-dhts-as-remote-storage">DHTs as Remote Storage</name>
2918 <t indent="0" pn="section-9.6-1">
2919 This document does not specify the properties of the underlying
2920 remote storage, which is required by any GNS implementation.
2921 It is important to note that the properties of the underlying
2922 remote storage are directly inherited by the
2923 GNS implementation. This includes both security and
2924 other non-functional properties such as scalability and performance.
2925 Implementers should take great care when selecting or implementing
2926 a DHT for use as remote storage in a GNS implementation.
2927 DHTs with reasonable security and performance properties exist
2928 <xref target="R5N" format="default" sectionFormat="of" derivedContent="R5N"/>.
2929 It should also be taken into consideration that GNS implementations
2930 that build upon different DHT overlays are unlikely to be
2931 mutually reachable.
2932 </t>
2933 </section>
2934 <section anchor="security_rev" numbered="true" removeInRFC="false" toc="include" pn="section-9.7">
2935 <name slugifiedName="name-revocations">Revocations</name>
2936 <t indent="0" pn="section-9.7-1">
2937 Zone administrators are advised to pregenerate zone revocations
2938 and to securely store the revocation information if the zone
2939 key is lost, compromised, or replaced in the future.
2940 Precalculated revocations can cease to be valid due to expirations
2941 or protocol changes such as epoch adjustments.
2942 Consequently, implementers and users must take precautions in order
2943 to manage revocations accordingly.
2944 </t>
2945 <t indent="0" pn="section-9.7-2">
2946 Revocation payloads do not include a "new" key for key replacement.
2947 Inclusion of such a key would have two major disadvantages:
2948 </t>
2949 <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-9.7-3">
2950 <li pn="section-9.7-3.1" derivedCounter="1.">
2951 If a revocation is published after a private key was compromised,
2952 allowing key replacement would be dangerous: if an
2953 adversary took over the private key, the adversary could then
2954 broadcast a revocation with a key replacement. For the replacement,
2955 the compromised owner would have no chance to issue a
2956 revocation. Thus, allowing a revocation message to replace a private
2957 key makes dealing with key compromise situations worse.
2958 </li>
2959 <li pn="section-9.7-3.2" derivedCounter="2.">
2960 Sometimes, key revocations are used with the objective of changing
2961 cryptosystems. Migration to another cryptosystem by replacing keys
2962 via a revocation message would only be secure as long as both
2963 cryptosystems are still secure against forgery. Such a planned,
2964 non-emergency migration to another cryptosystem should be done by
2965 running zones for both cipher systems in parallel for a while. The
2966 migration would conclude by revoking the legacy zone key only when
2967 it is deemed no longer secure and, hopefully, after most users have
2968 migrated to the replacement.
2969 </li>
2970 </ol>
2971 </section>
2972 <section anchor="privacy_labels" numbered="true" removeInRFC="false" toc="include" pn="section-9.8">
2973 <name slugifiedName="name-zone-privacy">Zone Privacy</name>
2974 <t indent="0" pn="section-9.8-1">
2975 GNS does not support authenticated denial of existence of names
2976 within a zone.
2977 Record data is published in encrypted form using keys derived from the
2978 zone key and record label. Zone administrators should
2979 carefully consider whether (1) a label and zone key are public or
2980 (2) one or both of these should be used as a shared secret to restrict access
2981 to the corresponding record data.
2982 Unlike public zone keys, low-entropy labels can be guessed by an attacker. If an attacker
2983 knows the public zone key, the use of well-known or guessable
2984 labels effectively threatens the disclosure of the corresponding records.
2985 </t>
2986 <t indent="0" pn="section-9.8-2">
2987 It should be noted that the guessing attack on labels only applies if the
2988 zone key is somehow disclosed to the adversary. GNS itself
2989 does not disclose it during a lookup or when resource records are
2990 published (as only the blinded zone keys are used on the network).
2991 However, zone keys do become public during revocation.
2992 </t>
2993 <t indent="0" pn="section-9.8-3">
2994 It is thus <bcp14>RECOMMENDED</bcp14> to use a
2995 label with sufficient entropy to prevent guessing attacks
2996 if any data in a resource record set is sensitive.
2997 </t>
2998 </section>
2999 <section anchor="sec_governance" numbered="true" removeInRFC="false" toc="include" pn="section-9.9">
3000 <name slugifiedName="name-zone-governance">Zone Governance</name>
3001 <t indent="0" pn="section-9.9-1">
3002 While DNS is distributed, in practice it
3003 relies on centralized, trusted registrars to provide globally unique
3004 names. As awareness of the central role DNS plays on the Internet
3005 increases, various institutions are using their power (including legal means)
3006 to engage in attacks on the DNS, thus threatening the global availability
3007 and integrity of information on the Internet.
3008 While a wider discussion of this issue is out of scope for this document,
3009 analyses and investigations can be found in recent academic research
3010 works, including <xref target="SecureNS" format="default" sectionFormat="of" derivedContent="SecureNS"/>.
3011 </t>
3012 <t indent="0" pn="section-9.9-2">
3013 GNS is designed to provide a secure, privacy-enhancing alternative to the
3014 DNS name resolution protocol, especially when censorship or manipulation
3015 is encountered.
3016 In particular, it directly addresses concerns in DNS with respect to
3017 query privacy.
3018 However, depending on the governance of the root zone, any deployment
3019 will likely suffer from the issue of a
3020 single hierarchy with a centrally controlled root and the
3021 related issue of distribution and management of root servers in DNS, as
3022 raised in Sections <xref target="RFC8324" section="3.12" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8324#section-3.12" derivedContent="RFC8324"/> and <xref target="RFC8324" section="3.10" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8324#section-3.10" derivedContent="RFC8324"/> of <xref target="RFC8324" format="default" sectionFormat="of" derivedContent="RFC8324"/>, respectively.
3023 In DNS, those issues directly result from the centralized root
3024 zone governance at the Internet Corporation for Assigned Names and
3025 Numbers (ICANN), which allows it to provide globally unique names.
3026 </t>
3027 <t indent="0" pn="section-9.9-3">
3028 In GNS, Start Zones give users local authority over their preferred
3029 root zone governance.
3030 It enables users to replace or enhance a trusted root zone
3031 configuration provided by a third party (e.g., the implementer or a
3032 multi-stakeholder governance body like ICANN) with secure delegation of
3033 authority using local petnames while operating under a
3034 very strong adversary model.
3035 In combination with zTLDs, this provides users of GNS with a global,
3036 secure, and memorable mapping without a trusted authority.
3037 </t>
3038 <t indent="0" pn="section-9.9-4">
3039 Any GNS implementation <bcp14>MAY</bcp14> provide a default
3040 governance model in the form of an initial Start Zone mapping.
3041 </t>
3042 </section>
3043 <section anchor="namespace_ambiguity" numbered="true" removeInRFC="false" toc="include" pn="section-9.10">
3044 <name slugifiedName="name-namespace-ambiguity">Namespace Ambiguity</name>
3045 <t indent="0" pn="section-9.10-1">
3046 Technically, the GNS protocol can be used to resolve names in the
3047 namespace of the global DNS.
3048 However, this would require the respective governance bodies and
3049 stakeholders (e.g., the IETF and ICANN) to standardize the use of GNS for this particular use
3050 case.
3051 </t>
3052 <t indent="0" pn="section-9.10-2">
3053 This capability implies that GNS names may be
3054 indistinguishable from DNS names in their
3055 respective common display format <xref target="RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/> or
3056 other special-use domain names <xref target="RFC6761" format="default" sectionFormat="of" derivedContent="RFC6761"/> if
3057 a local Start Zone configuration maps suffixes from the
3058 global DNS to GNS zones.
3059 For applications, which name system should be
3060 used in order to resolve a given name will then be ambiguous.
3061 This poses a risk when trying to resolve a name through DNS when
3062 it is actually a GNS name, as discussed in <xref target="RFC8244" format="default" sectionFormat="of" derivedContent="RFC8244"/>.
3063 In such a case, the GNS name is likely to be leaked as part of the DNS
3064 resolution.
3065 </t>
3066 <t indent="0" pn="section-9.10-3">
3067 In order to prevent disclosure of queried GNS names, it is
3068 <bcp14>RECOMMENDED</bcp14> that GNS-aware applications try to resolve
3069 a given name in GNS before any other method, taking into account
3070 potential suffix-to-zone mappings and zTLDs.
3071 Suffix-to-zone mappings are expected to be configured by the user or
3072 local administrator, and as such the resolution in GNS is
3073 in line with user expectations even if the name could also be resolved
3074 through DNS.
3075 If no suffix-to-zone mapping for the name exists and no zTLD is found,
3076 resolution <bcp14>MAY</bcp14> continue with other methods such as DNS.
3077 If a suffix-to-zone mapping for the name exists or the name ends with
3078 a zTLD, it <bcp14>MUST</bcp14> be resolved using GNS, and
3079 resolution <bcp14>MUST NOT</bcp14> continue by any other means
3080 independent of the GNS resolution result.
3081 </t>
3082 <t indent="0" pn="section-9.10-4">
3083 Mechanisms such as the Name Service Switch (NSS) of UNIX-like
3084 operating systems are an example of how such a resolution process
3085 can be implemented and used.
3086 The NSS allows system administrators to configure hostname resolution
3087 precedence and is integrated with the system resolver implementation.
3088 </t>
3089 <t indent="0" pn="section-9.10-5">
3090 For use cases where GNS names may be confused with names
3091 of other name resolution mechanisms (in particular, DNS), the
3092 ".gns.alt" domain <bcp14>SHOULD</bcp14> be used.
3093 For use cases like implementing sinkholes to block
3094 malware sites or serving DNS domains via GNS to bypass censorship,
3095 GNS <bcp14>MAY</bcp14> be deliberately used in ways that interfere
3096 with resolution of another name system.
3097 </t>
3098 </section>
3099 </section>
3100 <section anchor="gana" numbered="true" removeInRFC="false" toc="include" pn="section-10">
3101 <name slugifiedName="name-gana-considerations">GANA Considerations</name>
3102 <section anchor="gana_gnunet-sig-purposes" numbered="true" removeInRFC="false" toc="include" pn="section-10.1">
3103 <name slugifiedName="name-gnunet-signature-purposes-r">GNUnet Signature Purposes Registry</name>
3104 <t indent="0" pn="section-10.1-1">
3105 GANA <xref target="GANA" format="default" sectionFormat="of" derivedContent="GANA"/> has assigned signature purposes in its
3106 "GNUnet Signature Purposes" registry as listed in
3107 <xref target="tab_purposenums" format="default" sectionFormat="of" derivedContent="Table 1"/>.
3108 </t>
3109 <table anchor="tab_purposenums" align="center" pn="table-1">
3110 <name slugifiedName="name-the-gana-gnunet-signature-p">The GANA GNUnet Signature Purposes Registry</name>
3111 <thead>
3112 <tr>
3113 <th align="left" colspan="1" rowspan="1">Purpose</th>
3114 <th align="left" colspan="1" rowspan="1">Name</th>
3115 <th align="left" colspan="1" rowspan="1">References</th>
3116 <th align="left" colspan="1" rowspan="1">Comment</th>
3117 </tr>
3118 </thead>
3119 <tbody>
3120 <tr>
3121 <td align="left" colspan="1" rowspan="1">3</td>
3122 <td align="left" colspan="1" rowspan="1">GNS_REVOCATION</td>
3123 <td align="left" colspan="1" rowspan="1">RFC 9498</td>
3124 <td align="left" colspan="1" rowspan="1">GNS zone key revocation</td>
3125 </tr>
3126 <tr>
3127 <td align="left" colspan="1" rowspan="1">15</td>
3128 <td align="left" colspan="1" rowspan="1">GNS_RECORD_SIGN</td>
3129 <td align="left" colspan="1" rowspan="1">RFC 9498</td>
3130 <td align="left" colspan="1" rowspan="1">GNS record set signature</td>
3131 </tr>
3132 </tbody>
3133 </table>
3134 </section>
3135 <section anchor="gana_gnsrr" numbered="true" removeInRFC="false" toc="include" pn="section-10.2">
3136 <name slugifiedName="name-gns-record-types-registry">GNS Record Types Registry</name>
3137 <t indent="0" pn="section-10.2-1">
3138 GANA <xref target="GANA" format="default" sectionFormat="of" derivedContent="GANA"/>
3139 manages the "GNS Record Types" registry.
3140 </t>
3141 <t indent="0" pn="section-10.2-2">Each entry has the following format:
3142 </t>
3143 <dl newline="false" indent="3" spacing="normal" pn="section-10.2-3">
3144 <dt pn="section-10.2-3.1">Name:</dt>
3145 <dd pn="section-10.2-3.2">The name of the record type (case-insensitive ASCII
3146 string, restricted to alphanumeric characters). For zone delegation
3147 records, the assigned number represents the ztype value of the zone.</dd>
3148 <dt pn="section-10.2-3.3">Number:</dt>
3149 <dd pn="section-10.2-3.4">A 32-bit number above 65535.</dd>
3150 <dt pn="section-10.2-3.5">Comment:</dt>
3151 <dd pn="section-10.2-3.6">Optionally, brief English text describing the purpose of
3152 the record type (in UTF-8).</dd>
3153 <dt pn="section-10.2-3.7">Contact:</dt>
3154 <dd pn="section-10.2-3.8">Optionally, the contact information for a person to contact for
3155 further information.</dd>
3156 <dt pn="section-10.2-3.9">References:</dt>
3157 <dd pn="section-10.2-3.10">Optionally, references (such as an RFC) describing the record type.</dd>
3158 </dl>
3159 <t indent="0" pn="section-10.2-4">
3160 The registration policy for this registry is "First Come First
3161 Served". This policy is modeled on that described in <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>
3162 and describes the actions taken by GANA:
3163 </t>
3164 <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-10.2-5">
3165 <li pn="section-10.2-5.1">
3166 Adding new entries is possible after review by any authorized
3167 GANA contributor, using a
3168 first-come-first-served policy for unique name allocation.
3169 Reviewers are responsible for ensuring that the chosen "Name" is
3170 appropriate for the record type.
3171 The registry will define a unique number for the entry.
3172 </li>
3173 <li pn="section-10.2-5.2">
3174 Authorized GANA contributors for review of new entries are reachable at
3175 &lt;gns-registry@gnunet.org&gt;.
3176 </li>
3177 <li pn="section-10.2-5.3">
3178 Any request <bcp14>MUST</bcp14> contain a unique name and a point of contact.
3179 The contact information <bcp14>MAY</bcp14> be added to the registry, with the consent
3180 of the requester.
3181 The request <bcp14>MAY</bcp14> optionally also contain relevant references as well
3182 as a descriptive comment, as defined above.
3183 </li>
3184 </ul>
3185 <t indent="0" pn="section-10.2-6">
3186 GANA has assigned numbers for the record types defined in this
3187 specification in the "GNS Record Types" registry as listed in
3188 <xref target="tab_rrtypenums" format="default" sectionFormat="of" derivedContent="Table 2"/>.
3189 </t>
3190 <table anchor="tab_rrtypenums" align="center" pn="table-2">
3191 <name slugifiedName="name-the-gana-gns-record-types-r">The GANA GNS Record Types Registry</name>
3192 <thead>
3193 <tr>
3194 <th align="left" colspan="1" rowspan="1">Number</th>
3195 <th align="left" colspan="1" rowspan="1">Name</th>
3196 <th align="left" colspan="1" rowspan="1">Contact</th>
3197 <th align="left" colspan="1" rowspan="1">References</th>
3198 <th align="left" colspan="1" rowspan="1">Comment</th>
3199 </tr>
3200 </thead>
3201 <tbody>
3202 <tr>
3203 <td align="left" colspan="1" rowspan="1">65536</td>
3204 <td align="left" colspan="1" rowspan="1">PKEY</td>
3205 <td align="left" colspan="1" rowspan="1">(*)</td>
3206 <td align="left" colspan="1" rowspan="1">RFC 9498</td>
3207 <td align="left" colspan="1" rowspan="1">GNS zone delegation (PKEY)</td>
3208 </tr>
3209 <tr>
3210 <td align="left" colspan="1" rowspan="1">65537</td>
3211 <td align="left" colspan="1" rowspan="1">NICK</td>
3212 <td align="left" colspan="1" rowspan="1">(*)</td>
3213 <td align="left" colspan="1" rowspan="1">RFC 9498</td>
3214 <td align="left" colspan="1" rowspan="1">GNS zone nickname</td>
3215 </tr>
3216 <tr>
3217 <td align="left" colspan="1" rowspan="1">65538</td>
3218 <td align="left" colspan="1" rowspan="1">LEHO</td>
3219 <td align="left" colspan="1" rowspan="1">(*)</td>
3220 <td align="left" colspan="1" rowspan="1">RFC 9498</td>
3221 <td align="left" colspan="1" rowspan="1">GNS legacy hostname</td>
3222 </tr>
3223 <tr>
3224 <td align="left" colspan="1" rowspan="1">65540</td>
3225 <td align="left" colspan="1" rowspan="1">GNS2DNS</td>
3226 <td align="left" colspan="1" rowspan="1">(*)</td>
3227 <td align="left" colspan="1" rowspan="1">RFC 9498</td>
3228 <td align="left" colspan="1" rowspan="1">Delegation to DNS</td>
3229 </tr>
3230 <tr>
3231 <td align="left" colspan="1" rowspan="1">65541</td>
3232 <td align="left" colspan="1" rowspan="1">BOX</td>
3233 <td align="left" colspan="1" rowspan="1">(*)</td>
3234 <td align="left" colspan="1" rowspan="1">RFC 9498</td>
3235 <td align="left" colspan="1" rowspan="1">Box records</td>
3236 </tr>
3237 <tr>
3238 <td align="left" colspan="1" rowspan="1">65551</td>
3239 <td align="left" colspan="1" rowspan="1">REDIRECT</td>
3240 <td align="left" colspan="1" rowspan="1">(*)</td>
3241 <td align="left" colspan="1" rowspan="1">RFC 9498</td>
3242 <td align="left" colspan="1" rowspan="1">Redirection record</td>
3243 </tr>
3244 <tr>
3245 <td align="left" colspan="1" rowspan="1">65556</td>
3246 <td align="left" colspan="1" rowspan="1">EDKEY</td>
3247 <td align="left" colspan="1" rowspan="1">(*)</td>
3248 <td align="left" colspan="1" rowspan="1">RFC 9498</td>
3249 <td align="left" colspan="1" rowspan="1">GNS zone delegation (EDKEY)</td>
3250 </tr>
3251 </tbody>
3252 <tfoot>
3253 <tr>
3254 <td align="left" colspan="5" rowspan="1">(*): gns-registry@gnunet.org</td>
3255 </tr>
3256 </tfoot>
3257 </table>
3258 </section>
3259 <section anchor="gana_alt" numbered="true" removeInRFC="false" toc="include" pn="section-10.3">
3260 <name slugifiedName="name-alt-subdomains-registry">.alt Subdomains Registry</name>
3261 <t indent="0" pn="section-10.3-1">
3262 GANA <xref target="GANA" format="default" sectionFormat="of" derivedContent="GANA"/>
3263 manages the ".alt Subdomains" registry. This GANA-operated .alt registry
3264 may or may not be taken into account by any particular implementer, and
3265 it is not in any way associated with or sanctioned by the IETF or ICANN.
3266 </t>
3267 <t indent="0" pn="section-10.3-2">Each entry has the following format:
3268 </t>
3269 <dl newline="false" indent="3" spacing="normal" pn="section-10.3-3">
3270 <dt pn="section-10.3-3.1">Label:</dt>
3271 <dd pn="section-10.3-3.2">The label of the subdomain (in DNS "letters, digits, hyphen" (LDH) format as defined in <xref target="RFC5890" sectionFormat="of" section="2.3.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5890#section-2.3.1" derivedContent="RFC5890"/>).</dd>
3272 <dt pn="section-10.3-3.3">Description:</dt>
3273 <dd pn="section-10.3-3.4">Optionally, brief English text describing the purpose of
3274 the subdomain (in UTF-8).</dd>
3275 <dt pn="section-10.3-3.5">Contact:</dt>
3276 <dd pn="section-10.3-3.6">Optionally, the contact information for a person to contact for
3277 further information.</dd>
3278 <dt pn="section-10.3-3.7">References:</dt>
3279 <dd pn="section-10.3-3.8">Optionally, references (such as an RFC) describing the record type.</dd>
3280 </dl>
3281 <t indent="0" pn="section-10.3-4">
3282 The registration policy for this registry is "First Come First
3283 Served". This policy is modeled on that described in <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>
3284 and describes the actions taken by GANA:
3285 </t>
3286 <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-10.3-5">
3287 <li pn="section-10.3-5.1">
3288 Adding new entries is possible after review by any authorized
3289 GANA contributor, using a
3290 first-come-first-served policy for unique subdomain allocation.
3291 Reviewers are responsible for ensuring that the chosen "Subdomain" is
3292 appropriate for the purpose.
3293 </li>
3294 <li pn="section-10.3-5.2">
3295 Authorized GANA contributors for review of new entries are reachable at
3296 &lt;alt-registry@gnunet.org&gt;.
3297 </li>
3298 <li pn="section-10.3-5.3">
3299 Any request <bcp14>MUST</bcp14> contain a unique subdomain and a point of contact.
3300 The contact information <bcp14>MAY</bcp14> be added to the registry, with the consent
3301 of the requester.
3302 The request <bcp14>MAY</bcp14> optionally also contain relevant references as well
3303 as a descriptive comment, as defined above.
3304 </li>
3305 </ul>
3306 <t indent="0" pn="section-10.3-6">
3307 GANA has assigned the subdomain defined in this
3308 specification in the ".alt Subdomains" registry
3309 as listed in <xref target="tab_altsubdomains" format="default" sectionFormat="of" derivedContent="Table 3"/>.
3310 </t>
3311 <table anchor="tab_altsubdomains" align="center" pn="table-3">
3312 <name slugifiedName="name-the-gana-alt-subdomains-reg">The GANA .alt Subdomains Registry</name>
3313 <thead>
3314 <tr>
3315 <th align="left" colspan="1" rowspan="1">Label</th>
3316 <th align="left" colspan="1" rowspan="1">Contact</th>
3317 <th align="left" colspan="1" rowspan="1">References</th>
3318 <th align="left" colspan="1" rowspan="1">Description</th>
3319 </tr>
3320 </thead>
3321 <tbody>
3322 <tr>
3323 <td align="left" colspan="1" rowspan="1">gns</td>
3324 <td align="left" colspan="1" rowspan="1">(*)</td>
3325 <td align="left" colspan="1" rowspan="1">RFC 9498</td>
3326 <td align="left" colspan="1" rowspan="1">The .alt subdomain for GNS</td>
3327 </tr>
3328 </tbody>
3329 <tfoot>
3330 <tr>
3331 <td align="left" colspan="4" rowspan="1">(*): alt-registry@gnunet.org</td>
3332 </tr>
3333 </tfoot>
3334 </table>
3335 </section>
3336 </section>
3337 <section numbered="true" removeInRFC="false" toc="include" pn="section-11">
3338 <name slugifiedName="name-iana-considerations">IANA Considerations</name>
3339 <t indent="0" pn="section-11-1">
3340 This document has no IANA actions.
3341 </t>
3342 </section>
3343 <section numbered="true" removeInRFC="false" toc="include" pn="section-12">
3344 <name slugifiedName="name-implementation-and-deployme">Implementation and Deployment Status</name>
3345 <t indent="0" pn="section-12-1">
3346 There are two implementations conforming to this specification, written
3347 in C and Go, respectively. The C implementation as part of GNUnet
3348 <xref target="GNUnetGNS" format="default" sectionFormat="of" derivedContent="GNUnetGNS"/> represents the original
3349 and reference implementation. The Go implementation
3350 <xref target="GoGNS" format="default" sectionFormat="of" derivedContent="GoGNS"/> demonstrates how two implementations of GNS are
3351 interoperable if they are built on top of the same underlying
3352 DHT storage.
3353 </t>
3354 <t indent="0" pn="section-12-2">
3355 Currently, the GNUnet peer-to-peer network <xref target="GNUnet" format="default" sectionFormat="of" derivedContent="GNUnet"/>
3356 is an active deployment of GNS on top of its DHT <xref target="R5N" format="default" sectionFormat="of" derivedContent="R5N"/>. The Go implementation <xref target="GoGNS" format="default" sectionFormat="of" derivedContent="GoGNS"/> uses this deployment
3357 by building on top of the GNUnet DHT services available on any
3358 GNUnet peer. It shows how GNS implementations
3359 can attach to this existing deployment and participate in name
3360 resolution as well as zone publication.
3361 </t>
3362 <t indent="0" pn="section-12-3">
3363 The self-sovereign identity system re:claimID <xref target="reclaim" format="default" sectionFormat="of" derivedContent="reclaim"/>
3364 is using GNS in order to selectively share identity attributes and
3365 attestations with third parties.
3366 </t>
3367 <t indent="0" pn="section-12-4">
3368 The Ascension tool <xref target="Ascension" format="default" sectionFormat="of" derivedContent="Ascension"/> facilitates the migration of DNS zones to
3369 GNS zones by translating information retrieved from a DNS zone
3370 transfer into a GNS zone.
3371 </t>
3372 </section>
3373 </middle>
3374 <back>
3375 <references pn="section-13">
3376 <name slugifiedName="name-references">References</name>
3377 <references pn="section-13.1">
3378 <name slugifiedName="name-normative-references">Normative References</name>
3379 <reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc1034" quoteTitle="true" derivedAnchor="RFC1034">
3380 <front>
3381 <title>Domain names - concepts and facilities</title>
3382 <author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/>
3383 <date month="November" year="1987"/>
3384 <abstract>
3385 <t indent="0">This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them.</t>
3386 </abstract>
3387 </front>
3388 <seriesInfo name="STD" value="13"/>
3389 <seriesInfo name="RFC" value="1034"/>
3390 <seriesInfo name="DOI" value="10.17487/RFC1034"/>
3391 </reference>
3392 <reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1035" quoteTitle="true" derivedAnchor="RFC1035">
3393 <front>
3394 <title>Domain names - implementation and specification</title>
3395 <author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/>
3396 <date month="November" year="1987"/>
3397 <abstract>
3398 <t indent="0">This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.</t>
3399 </abstract>
3400 </front>
3401 <seriesInfo name="STD" value="13"/>
3402 <seriesInfo name="RFC" value="1035"/>
3403 <seriesInfo name="DOI" value="10.17487/RFC1035"/>
3404 </reference>
3405 <reference anchor="RFC2782" target="https://www.rfc-editor.org/info/rfc2782" quoteTitle="true" derivedAnchor="RFC2782">
3406 <front>
3407 <title>A DNS RR for specifying the location of services (DNS SRV)</title>
3408 <author fullname="A. Gulbrandsen" initials="A." surname="Gulbrandsen"/>
3409 <author fullname="P. Vixie" initials="P." surname="Vixie"/>
3410 <author fullname="L. Esibov" initials="L." surname="Esibov"/>
3411 <date month="February" year="2000"/>
3412 <abstract>
3413 <t indent="0">This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. [STANDARDS-TRACK]</t>
3414 </abstract>
3415 </front>
3416 <seriesInfo name="RFC" value="2782"/>
3417 <seriesInfo name="DOI" value="10.17487/RFC2782"/>
3418 </reference>
3419 <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
3420 <front>
3421 <title>Key words for use in RFCs to Indicate Requirement Levels</title>
3422 <author fullname="S. Bradner" initials="S." surname="Bradner"/>
3423 <date month="March" year="1997"/>
3424 <abstract>
3425 <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
3426 </abstract>
3427 </front>
3428 <seriesInfo name="BCP" value="14"/>
3429 <seriesInfo name="RFC" value="2119"/>
3430 <seriesInfo name="DOI" value="10.17487/RFC2119"/>
3431 </reference>
3432 <reference anchor="RFC3629" target="https://www.rfc-editor.org/info/rfc3629" quoteTitle="true" derivedAnchor="RFC3629">
3433 <front>
3434 <title>UTF-8, a transformation format of ISO 10646</title>
3435 <author fullname="F. Yergeau" initials="F." surname="Yergeau"/>
3436 <date month="November" year="2003"/>
3437 <abstract>
3438 <t indent="0">ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.</t>
3439 </abstract>
3440 </front>
3441 <seriesInfo name="STD" value="63"/>
3442 <seriesInfo name="RFC" value="3629"/>
3443 <seriesInfo name="DOI" value="10.17487/RFC3629"/>
3444 </reference>
3445 <reference anchor="RFC3686" target="https://www.rfc-editor.org/info/rfc3686" quoteTitle="true" derivedAnchor="RFC3686">
3446 <front>
3447 <title>Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)</title>
3448 <author fullname="R. Housley" initials="R." surname="Housley"/>
3449 <date month="January" year="2004"/>
3450 <abstract>
3451 <t indent="0">This document describes the use of Advanced Encryption Standard (AES) Counter Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload (ESP) confidentiality mechanism.</t>
3452 </abstract>
3453 </front>
3454 <seriesInfo name="RFC" value="3686"/>
3455 <seriesInfo name="DOI" value="10.17487/RFC3686"/>
3456 </reference>
3457 <reference anchor="RFC3826" target="https://www.rfc-editor.org/info/rfc3826" quoteTitle="true" derivedAnchor="RFC3826">
3458 <front>
3459 <title>The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model</title>
3460 <author fullname="U. Blumenthal" initials="U." surname="Blumenthal"/>
3461 <author fullname="F. Maino" initials="F." surname="Maino"/>
3462 <author fullname="K. McCloghrie" initials="K." surname="McCloghrie"/>
3463 <date month="June" year="2004"/>
3464 <abstract>
3465 <t indent="0">This document describes a symmetric encryption protocol that supplements the protocols described in the User-based Security Model (USM), which is a Security Subsystem for version 3 of the Simple Network Management Protocol for use in the SNMP Architecture. The symmetric encryption protocol described in this document is based on the Advanced Encryption Standard (AES) cipher algorithm used in Cipher FeedBack Mode (CFB), with a key size of 128 bits. [STANDARDS-TRACK]</t>
3466 </abstract>
3467 </front>
3468 <seriesInfo name="RFC" value="3826"/>
3469 <seriesInfo name="DOI" value="10.17487/RFC3826"/>
3470 </reference>
3471 <reference anchor="RFC5237" target="https://www.rfc-editor.org/info/rfc5237" quoteTitle="true" derivedAnchor="RFC5237">
3472 <front>
3473 <title>IANA Allocation Guidelines for the Protocol Field</title>
3474 <author fullname="J. Arkko" initials="J." surname="Arkko"/>
3475 <author fullname="S. Bradner" initials="S." surname="Bradner"/>
3476 <date month="February" year="2008"/>
3477 <abstract>
3478 <t indent="0">This document revises the IANA guidelines for allocating new Protocol field values in IPv4 header. It modifies the rules specified in RFC 2780 by removing the Expert Review option. The change will also affect the allocation of Next Header field values in IPv6. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
3479 </abstract>
3480 </front>
3481 <seriesInfo name="BCP" value="37"/>
3482 <seriesInfo name="RFC" value="5237"/>
3483 <seriesInfo name="DOI" value="10.17487/RFC5237"/>
3484 </reference>
3485 <reference anchor="RFC5869" target="https://www.rfc-editor.org/info/rfc5869" quoteTitle="true" derivedAnchor="RFC5869">
3486 <front>
3487 <title>HMAC-based Extract-and-Expand Key Derivation Function (HKDF)</title>
3488 <author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/>
3489 <author fullname="P. Eronen" initials="P." surname="Eronen"/>
3490 <date month="May" year="2010"/>
3491 <abstract>
3492 <t indent="0">This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
3493 </abstract>
3494 </front>
3495 <seriesInfo name="RFC" value="5869"/>
3496 <seriesInfo name="DOI" value="10.17487/RFC5869"/>
3497 </reference>
3498 <reference anchor="RFC5890" target="https://www.rfc-editor.org/info/rfc5890" quoteTitle="true" derivedAnchor="RFC5890">
3499 <front>
3500 <title>Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework</title>
3501 <author fullname="J. Klensin" initials="J." surname="Klensin"/>
3502 <date month="August" year="2010"/>
3503 <abstract>
3504 <t indent="0">This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK]</t>
3505 </abstract>
3506 </front>
3507 <seriesInfo name="RFC" value="5890"/>
3508 <seriesInfo name="DOI" value="10.17487/RFC5890"/>
3509 </reference>
3510 <reference anchor="RFC5895" target="https://www.rfc-editor.org/info/rfc5895" quoteTitle="true" derivedAnchor="RFC5895">
3511 <front>
3512 <title>Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008</title>
3513 <author fullname="P. Resnick" initials="P." surname="Resnick"/>
3514 <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
3515 <date month="September" year="2010"/>
3516 <abstract>
3517 <t indent="0">In the original version of the Internationalized Domain Names in Applications (IDNA) protocol, any Unicode code points taken from user input were mapped into a set of Unicode code points that "made sense", and then encoded and passed to the domain name system (DNS). The IDNA2008 protocol (described in RFCs 5890, 5891, 5892, and 5893) presumes that the input to the protocol comes from a set of "permitted" code points, which it then encodes and passes to the DNS, but does not specify what to do with the result of user input. This document describes the actions that can be taken by an implementation between receiving user input and passing permitted code points to the new IDNA protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
3518 </abstract>
3519 </front>
3520 <seriesInfo name="RFC" value="5895"/>
3521 <seriesInfo name="DOI" value="10.17487/RFC5895"/>
3522 </reference>
3523 <reference anchor="RFC6234" target="https://www.rfc-editor.org/info/rfc6234" quoteTitle="true" derivedAnchor="RFC6234">
3524 <front>
3525 <title>US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)</title>
3526 <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
3527 <author fullname="T. Hansen" initials="T." surname="Hansen"/>
3528 <date month="May" year="2011"/>
3529 <abstract>
3530 <t indent="0">Federal Information Processing Standard, FIPS</t>
3531 </abstract>
3532 </front>
3533 <seriesInfo name="RFC" value="6234"/>
3534 <seriesInfo name="DOI" value="10.17487/RFC6234"/>
3535 </reference>
3536 <reference anchor="RFC6895" target="https://www.rfc-editor.org/info/rfc6895" quoteTitle="true" derivedAnchor="RFC6895">
3537 <front>
3538 <title>Domain Name System (DNS) IANA Considerations</title>
3539 <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
3540 <date month="April" year="2013"/>
3541 <abstract>
3542 <t indent="0">This document specifies Internet Assigned Numbers Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597.</t>
3543 </abstract>
3544 </front>
3545 <seriesInfo name="BCP" value="42"/>
3546 <seriesInfo name="RFC" value="6895"/>
3547 <seriesInfo name="DOI" value="10.17487/RFC6895"/>
3548 </reference>
3549 <reference anchor="RFC6979" target="https://www.rfc-editor.org/info/rfc6979" quoteTitle="true" derivedAnchor="RFC6979">
3550 <front>
3551 <title>Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)</title>
3552 <author fullname="T. Pornin" initials="T." surname="Pornin"/>
3553 <date month="August" year="2013"/>
3554 <abstract>
3555 <t indent="0">This document defines a deterministic digital signature generation procedure. Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein. Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness.</t>
3556 </abstract>
3557 </front>
3558 <seriesInfo name="RFC" value="6979"/>
3559 <seriesInfo name="DOI" value="10.17487/RFC6979"/>
3560 </reference>
3561 <reference anchor="RFC7748" target="https://www.rfc-editor.org/info/rfc7748" quoteTitle="true" derivedAnchor="RFC7748">
3562 <front>
3563 <title>Elliptic Curves for Security</title>
3564 <author fullname="A. Langley" initials="A." surname="Langley"/>
3565 <author fullname="M. Hamburg" initials="M." surname="Hamburg"/>
3566 <author fullname="S. Turner" initials="S." surname="Turner"/>
3567 <date month="January" year="2016"/>
3568 <abstract>
3569 <t indent="0">This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.</t>
3570 </abstract>
3571 </front>
3572 <seriesInfo name="RFC" value="7748"/>
3573 <seriesInfo name="DOI" value="10.17487/RFC7748"/>
3574 </reference>
3575 <reference anchor="RFC8032" target="https://www.rfc-editor.org/info/rfc8032" quoteTitle="true" derivedAnchor="RFC8032">
3576 <front>
3577 <title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title>
3578 <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
3579 <author fullname="I. Liusvaara" initials="I." surname="Liusvaara"/>
3580 <date month="January" year="2017"/>
3581 <abstract>
3582 <t indent="0">This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.</t>
3583 </abstract>
3584 </front>
3585 <seriesInfo name="RFC" value="8032"/>
3586 <seriesInfo name="DOI" value="10.17487/RFC8032"/>
3587 </reference>
3588 <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126">
3589 <front>
3590 <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
3591 <author fullname="M. Cotton" initials="M." surname="Cotton"/>
3592 <author fullname="B. Leiba" initials="B." surname="Leiba"/>
3593 <author fullname="T. Narten" initials="T." surname="Narten"/>
3594 <date month="June" year="2017"/>
3595 <abstract>
3596 <t indent="0">Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
3597 <t indent="0">To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
3598 <t indent="0">This is the third edition of this document; it obsoletes RFC 5226.</t>
3599 </abstract>
3600 </front>
3601 <seriesInfo name="BCP" value="26"/>
3602 <seriesInfo name="RFC" value="8126"/>
3603 <seriesInfo name="DOI" value="10.17487/RFC8126"/>
3604 </reference>
3605 <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
3606 <front>
3607 <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
3608 <author fullname="B. Leiba" initials="B." surname="Leiba"/>
3609 <date month="May" year="2017"/>
3610 <abstract>
3611 <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
3612 </abstract>
3613 </front>
3614 <seriesInfo name="BCP" value="14"/>
3615 <seriesInfo name="RFC" value="8174"/>
3616 <seriesInfo name="DOI" value="10.17487/RFC8174"/>
3617 </reference>
3618 <reference anchor="RFC8499" target="https://www.rfc-editor.org/info/rfc8499" quoteTitle="true" derivedAnchor="RFC8499">
3619 <front>
3620 <title>DNS Terminology</title>
3621 <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
3622 <author fullname="A. Sullivan" initials="A." surname="Sullivan"/>
3623 <author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/>
3624 <date month="January" year="2019"/>
3625 <abstract>
3626 <t indent="0">The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.</t>
3627 <t indent="0">This document obsoletes RFC 7719 and updates RFC 2308.</t>
3628 </abstract>
3629 </front>
3630 <seriesInfo name="BCP" value="219"/>
3631 <seriesInfo name="RFC" value="8499"/>
3632 <seriesInfo name="DOI" value="10.17487/RFC8499"/>
3633 </reference>
3634 <reference anchor="RFC9106" target="https://www.rfc-editor.org/info/rfc9106" quoteTitle="true" derivedAnchor="RFC9106">
3635 <front>
3636 <title>Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications</title>
3637 <author fullname="A. Biryukov" initials="A." surname="Biryukov"/>
3638 <author fullname="D. Dinu" initials="D." surname="Dinu"/>
3639 <author fullname="D. Khovratovich" initials="D." surname="Khovratovich"/>
3640 <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
3641 <date month="September" year="2021"/>
3642 <abstract>
3643 <t indent="0">This document describes the Argon2 memory-hard function for password hashing and proof-of-work applications. We provide an implementer-oriented description with test vectors. The purpose is to simplify adoption of Argon2 for Internet protocols. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</t>
3644 </abstract>
3645 </front>
3646 <seriesInfo name="RFC" value="9106"/>
3647 <seriesInfo name="DOI" value="10.17487/RFC9106"/>
3648 </reference>
3649 <reference anchor="GANA" target="https://gana.gnunet.org/" quoteTitle="true" derivedAnchor="GANA">
3650 <front>
3651 <title>GNUnet Assigned Numbers Authority (GANA)</title>
3652 <author>
3653 <organization showOnFrontPage="true">GNUnet e.V.</organization>
3654 </author>
3655 <date year="2023"/>
3656 </front>
3657 </reference>
3658 <reference anchor="MODES" target="https://doi.org/10.6028/NIST.SP.800-38A" quoteTitle="true" derivedAnchor="MODES">
3659 <front>
3660 <title>Recommendation for Block Cipher Modes of Operation: Methods and Techniques</title>
3661 <author initials="M." surname="Dworkin" fullname="Morris Dworkin">
3662 <organization showOnFrontPage="true">NIST</organization>
3663 </author>
3664 <date year="2001" month="December"/>
3665 </front>
3666 <refcontent>NIST Special Publication 800-38A</refcontent>
3667 <seriesInfo name="DOI" value="10.6028/NIST.SP.800-38A"/>
3668 </reference>
3669 <reference anchor="CrockfordB32" target="https://www.crockford.com/base32.html" quoteTitle="true" derivedAnchor="CrockfordB32">
3670 <front>
3671 <title>Base 32</title>
3672 <author initials="D." surname="Crockford" fullname="Douglas Crockford">
3673 </author>
3674 <date year="2019" month="March"/>
3675 </front>
3676 </reference>
3677 <reference anchor="XSalsa20" target="https://cr.yp.to/papers.html#xsalsa" quoteTitle="true" derivedAnchor="XSalsa20">
3678 <front>
3679 <title>Extending the Salsa20 nonce</title>
3680 <author initials="D. J." surname="Bernstein" fullname="Daniel Bernstein">
3681 <organization showOnFrontPage="true">University of Illinois at Chicago</organization>
3682 </author>
3683 <date year="2011"/>
3684 </front>
3685 </reference>
3686 <reference anchor="Unicode-UAX15" target="https://www.unicode.org/reports/tr15/tr15-31.html" quoteTitle="true" derivedAnchor="Unicode-UAX15">
3687 <front>
3688 <title>Unicode Standard Annex #15: Unicode Normalization Forms</title>
3689 <author initials="M." surname="Davis" fullname="Mark Davis">
3690 <organization showOnFrontPage="true"/>
3691 </author>
3692 <author initials="K." surname="Whistler" fullname="Ken Whistler">
3693 <organization showOnFrontPage="true"/>
3694 </author>
3695 <author initials="M." surname="Dürst" fullname="Martin Dürst">
3696 <organization showOnFrontPage="true"/>
3697 </author>
3698 <date year="2009" month="September"/>
3699 </front>
3700 <refcontent>Revision 31, The Unicode Consortium, Mountain View</refcontent>
3701 </reference>
3702 <reference anchor="Unicode-UTS46" target="https://www.unicode.org/reports/tr46" quoteTitle="true" derivedAnchor="Unicode-UTS46">
3703 <front>
3704 <title>Unicode Technical Standard #46: Unicode IDNA Compatibility Processing</title>
3705 <author initials="M." surname="Davis" fullname="Mark Davis">
3706 <organization showOnFrontPage="true"/>
3707 </author>
3708 <author initials="M." surname="Suignard" fullname="Michel Suignard">
3709 <organization showOnFrontPage="true"/>
3710 </author>
3711 <date year="2023" month="September"/>
3712 </front>
3713 <refcontent>Revision 31, The Unicode Consortium, Mountain View</refcontent>
3714 </reference>
3715 </references>
3716 <references pn="section-13.2">
3717 <name slugifiedName="name-informative-references">Informative References</name>
3718 <reference anchor="RFC1928" target="https://www.rfc-editor.org/info/rfc1928" quoteTitle="true" derivedAnchor="RFC1928">
3719 <front>
3720 <title>SOCKS Protocol Version 5</title>
3721 <author fullname="M. Leech" initials="M." surname="Leech"/>
3722 <author fullname="M. Ganis" initials="M." surname="Ganis"/>
3723 <author fullname="Y. Lee" initials="Y." surname="Lee"/>
3724 <author fullname="R. Kuris" initials="R." surname="Kuris"/>
3725 <author fullname="D. Koblas" initials="D." surname="Koblas"/>
3726 <author fullname="L. Jones" initials="L." surname="Jones"/>
3727 <date month="March" year="1996"/>
3728 <abstract>
3729 <t indent="0">This memo describes a protocol that is an evolution of the previous version of the protocol, version 4 [1]. This new protocol stems from active discussions and prototype implementations. [STANDARDS-TRACK]</t>
3730 </abstract>
3731 </front>
3732 <seriesInfo name="RFC" value="1928"/>
3733 <seriesInfo name="DOI" value="10.17487/RFC1928"/>
3734 </reference>
3735 <reference anchor="RFC4033" target="https://www.rfc-editor.org/info/rfc4033" quoteTitle="true" derivedAnchor="RFC4033">
3736 <front>
3737 <title>DNS Security Introduction and Requirements</title>
3738 <author fullname="R. Arends" initials="R." surname="Arends"/>
3739 <author fullname="R. Austein" initials="R." surname="Austein"/>
3740 <author fullname="M. Larson" initials="M." surname="Larson"/>
3741 <author fullname="D. Massey" initials="D." surname="Massey"/>
3742 <author fullname="S. Rose" initials="S." surname="Rose"/>
3743 <date month="March" year="2005"/>
3744 <abstract>
3745 <t indent="0">The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK]</t>
3746 </abstract>
3747 </front>
3748 <seriesInfo name="RFC" value="4033"/>
3749 <seriesInfo name="DOI" value="10.17487/RFC4033"/>
3750 </reference>
3751 <reference anchor="RFC6066" target="https://www.rfc-editor.org/info/rfc6066" quoteTitle="true" derivedAnchor="RFC6066">
3752 <front>
3753 <title>Transport Layer Security (TLS) Extensions: Extension Definitions</title>
3754 <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
3755 <date month="January" year="2011"/>
3756 <abstract>
3757 <t indent="0">This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK]</t>
3758 </abstract>
3759 </front>
3760 <seriesInfo name="RFC" value="6066"/>
3761 <seriesInfo name="DOI" value="10.17487/RFC6066"/>
3762 </reference>
3763 <reference anchor="RFC7363" target="https://www.rfc-editor.org/info/rfc7363" quoteTitle="true" derivedAnchor="RFC7363">
3764 <front>
3765 <title>Self-Tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD)</title>
3766 <author fullname="J. Maenpaa" initials="J." surname="Maenpaa"/>
3767 <author fullname="G. Camarillo" initials="G." surname="Camarillo"/>
3768 <date month="September" year="2014"/>
3769 <abstract>
3770 <t indent="0">REsource LOcation And Discovery (RELOAD) is a peer-to-peer (P2P) signaling protocol that provides an overlay network service. Peers in a RELOAD overlay network collectively run an overlay algorithm to organize the overlay and to store and retrieve data. This document describes how the default topology plugin of RELOAD can be extended to support self-tuning, that is, to adapt to changing operating conditions such as churn and network size.</t>
3771 </abstract>
3772 </front>
3773 <seriesInfo name="RFC" value="7363"/>
3774 <seriesInfo name="DOI" value="10.17487/RFC7363"/>
3775 </reference>
3776 <reference anchor="RFC8324" target="https://www.rfc-editor.org/info/rfc8324" quoteTitle="true" derivedAnchor="RFC8324">
3777 <front>
3778 <title>DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look?</title>
3779 <author fullname="J. Klensin" initials="J." surname="Klensin"/>
3780 <date month="February" year="2018"/>
3781 <abstract>
3782 <t indent="0">The basic design of the Domain Name System was completed almost 30 years ago. The last half of that period has been characterized by significant changes in requirements and expectations, some of which either require changes to how the DNS is used or can be accommodated only poorly or not at all. This document asks the question of whether it is time to either redesign and replace the DNS to match contemporary requirements and expectations (rather than continuing to try to design and implement incremental patches that are not fully satisfactory) or draw some clear lines about functionality that is not really needed or that should be performed in some other way.</t>
3783 </abstract>
3784 </front>
3785 <seriesInfo name="RFC" value="8324"/>
3786 <seriesInfo name="DOI" value="10.17487/RFC8324"/>
3787 </reference>
3788 <reference anchor="RFC8806" target="https://www.rfc-editor.org/info/rfc8806" quoteTitle="true" derivedAnchor="RFC8806">
3789 <front>
3790 <title>Running a Root Server Local to a Resolver</title>
3791 <author fullname="W. Kumari" initials="W." surname="Kumari"/>
3792 <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
3793 <date month="June" year="2020"/>
3794 <abstract>
3795 <t indent="0">Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server; those resolvers may have difficulty getting responses from the root servers, such as during a network attack. Some DNS recursive resolver operators want to prevent snooping by third parties of requests sent to DNS root servers. In both cases, resolvers can greatly decrease the round-trip time and prevent observation of requests by serving a copy of the full root zone on the same server, such as on a loopback address or in the resolver software. This document shows how to start and maintain such a copy of the root zone that does not cause problems for other users of the DNS, at the cost of adding some operational fragility for the operator.</t>
3796 <t indent="0">This document obsoletes RFC 7706.</t>
3797 </abstract>
3798 </front>
3799 <seriesInfo name="RFC" value="8806"/>
3800 <seriesInfo name="DOI" value="10.17487/RFC8806"/>
3801 </reference>
3802 <reference anchor="RFC6761" target="https://www.rfc-editor.org/info/rfc6761" quoteTitle="true" derivedAnchor="RFC6761">
3803 <front>
3804 <title>Special-Use Domain Names</title>
3805 <author fullname="S. Cheshire" initials="S." surname="Cheshire"/>
3806 <author fullname="M. Krochmal" initials="M." surname="Krochmal"/>
3807 <date month="February" year="2013"/>
3808 <abstract>
3809 <t indent="0">This document describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names.</t>
3810 </abstract>
3811 </front>
3812 <seriesInfo name="RFC" value="6761"/>
3813 <seriesInfo name="DOI" value="10.17487/RFC6761"/>
3814 </reference>
3815 <reference anchor="RFC8244" target="https://www.rfc-editor.org/info/rfc8244" quoteTitle="true" derivedAnchor="RFC8244">
3816 <front>
3817 <title>Special-Use Domain Names Problem Statement</title>
3818 <author fullname="T. Lemon" initials="T." surname="Lemon"/>
3819 <author fullname="R. Droms" initials="R." surname="Droms"/>
3820 <author fullname="W. Kumari" initials="W." surname="Kumari"/>
3821 <date month="October" year="2017"/>
3822 <abstract>
3823 <t indent="0">The policy defined in RFC 6761 for IANA registrations in the "Special-Use Domain Names" registry has been shown, through experience, to present challenges that were not anticipated when RFC 6761 was written. This memo presents a list, intended to be comprehensive, of the problems that have since been identified. In addition, it reviews the history of domain names and summarizes current IETF publications and some publications from other organizations relating to Special-Use Domain Names.</t>
3824 <t indent="0">This document should be considered required reading for IETF participants who wish to express an informed opinion on the topic of Special-Use Domain Names.</t>
3825 </abstract>
3826 </front>
3827 <seriesInfo name="RFC" value="8244"/>
3828 <seriesInfo name="DOI" value="10.17487/RFC8244"/>
3829 </reference>
3830 <reference anchor="RFC9476" target="https://www.rfc-editor.org/info/rfc9476" quoteTitle="true" derivedAnchor="RFC9476">
3831 <front>
3832 <title>The .alt Special-Use Top-Level Domain</title>
3833 <author fullname="W. Kumari" initials="W." surname="Kumari"/>
3834 <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
3835 <date month="September" year="2023"/>
3836 <abstract>
3837 <t indent="0">This document reserves a Top-Level Domain (TLD) label "alt" to be used in non-DNS contexts. It also provides advice and guidance to developers creating alternative namespaces.</t>
3838 </abstract>
3839 </front>
3840 <seriesInfo name="RFC" value="9476"/>
3841 <seriesInfo name="DOI" value="10.17487/RFC9476"/>
3842 </reference>
3843 <reference anchor="TorRendSpec" target="https://github.com/torproject/torspec/blob/main/rend-spec-v3.txt" quoteTitle="true" derivedAnchor="TorRendSpec">
3844 <front>
3845 <title>Tor Rendezvous Specification - Version 3</title>
3846 <author>
3847 <organization showOnFrontPage="true">Tor Project</organization>
3848 </author>
3849 <date month="June" year="2023"/>
3850 </front>
3851 <refcontent>commit b345ca0</refcontent>
3852 </reference>
3853 <reference anchor="Tor224" target="https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n2135" quoteTitle="true" derivedAnchor="Tor224">
3854 <front>
3855 <title>Next-Generation Hidden Services in Tor</title>
3856 <author initials="D." surname="Goulet" fullname="David Goulet">
3857 </author>
3858 <author initials="G." surname="Kadianakis" fullname="George Kadianakis">
3859 </author>
3860 <author initials="N." surname="Mathewson" fullname="Nick Mathewson">
3861 </author>
3862 <date year="2013" month="November"/>
3863 </front>
3864 <refcontent>Appendix A.2 ("Tor's key derivation scheme")</refcontent>
3865 </reference>
3866 <reference anchor="SDSI" target="https://citeseerx.ist.psu.edu/document?repid=rep1&amp;type=pdf&amp;doi=3837e0206bf73e5e8f0ba6db767a2f714ea7c367" quoteTitle="true" derivedAnchor="SDSI">
3867 <front>
3868 <title>SDSI - A Simple Distributed Security Infrastructure</title>
3869 <author initials="R. L." surname="Rivest" fullname="Ron L. Rivest">
3870 </author>
3871 <author initials="B." surname="Lampson" fullname="Butler Lampson">
3872 </author>
3873 <date year="1996" month="October"/>
3874 </front>
3875 </reference>
3876 <reference anchor="Kademlia" target="https://css.csail.mit.edu/6.824/2014/papers/kademlia.pdf" quoteTitle="true" derivedAnchor="Kademlia">
3877 <front>
3878 <title>Kademlia: A Peer-to-peer Information System Based on the XOR Metric</title>
3879 <author initials="P." surname="Maymounkov" fullname="Petar Maymounkov">
3880 </author>
3881 <author initials="D." surname="Mazières" fullname="David Mazières">
3882 </author>
3883 <date year="2002"/>
3884 </front>
3885 <seriesInfo name="DOI" value="10.1007/3-540-45748-8_5"/>
3886 </reference>
3887 <reference anchor="ed25519" target="https://ed25519.cr.yp.to/ed25519-20110926.pdf" quoteTitle="true" derivedAnchor="ed25519">
3888 <front>
3889 <title>High-speed high-security signatures</title>
3890 <author initials="D. J." surname="Bernstein" fullname="Daniel Bernstein">
3891 <organization showOnFrontPage="true">University of Illinois at Chicago</organization>
3892 </author>
3893 <author initials="N." surname="Duif" fullname="Niels Duif">
3894 <organization showOnFrontPage="true">Technische Universiteit Eindhoven</organization>
3895 </author>
3896 <author initials="T." surname="Lange" fullname="Tanja Lange">
3897 <organization showOnFrontPage="true">Technische Universiteit Eindhoven</organization>
3898 </author>
3899 <author initials="P." surname="Schwabe" fullname="Peter Schwabe">
3900 <organization showOnFrontPage="true">National Taiwan University</organization>
3901 </author>
3902 <author initials="B-Y." surname="Yang" fullname="Bo-Yin Yang">
3903 <organization showOnFrontPage="true">Academia Sinica</organization>
3904 </author>
3905 <date year="2011"/>
3906 </front>
3907 <seriesInfo name="DOI" value="10.1007/s13389-012-0027-1"/>
3908 </reference>
3909 <reference anchor="GNS" target="https://sci-hub.st/10.1007/978-3-319-12280-9_9" quoteTitle="true" derivedAnchor="GNS">
3910 <front>
3911 <title>A Censorship-Resistant, Privacy-Enhancing and Fully Decentralized Name System</title>
3912 <author initials="M." surname="Wachs" fullname="Matthias Wachs">
3913 <organization showOnFrontPage="true">Technische Universität München</organization>
3914 </author>
3915 <author initials="M." surname="Schanzenbach" fullname="Martin Schanzenbach">
3916 <organization showOnFrontPage="true">Technische Universität München</organization>
3917 </author>
3918 <author initials="C." surname="Grothoff" fullname="Christian Grothoff">
3919 <organization showOnFrontPage="true">Technische Universität München</organization>
3920 </author>
3921 <date month="October" year="2014"/>
3922 </front>
3923 <refcontent>13th International Conference on Cryptology and Network Security (CANS)</refcontent>
3924 <seriesInfo name="DOI" value="10.13140/2.1.4642.3044"/>
3925 </reference>
3926 <reference anchor="R5N" target="https://sci-hub.st/10.1109/ICNSS.2011.6060022" quoteTitle="true" derivedAnchor="R5N">
3927 <front>
3928 <title>R5N: Randomized Recursive Routing for Restricted-Route Networks</title>
3929 <author initials="N. S." surname="Evans" fullname="Nathan S. Evans">
3930 <organization showOnFrontPage="true">Technische Universität München</organization>
3931 </author>
3932 <author initials="C." surname="Grothoff" fullname="Christian Grothoff">
3933 <organization showOnFrontPage="true">Technische Universität München</organization>
3934 </author>
3935 <date month="September" year="2011"/>
3936 </front>
3937 <refcontent>5th International Conference on Network and System Security (NSS)</refcontent>
3938 <seriesInfo name="DOI" value="10.1109/ICNSS.2011.6060022"/>
3939 </reference>
3940 <reference anchor="SecureNS" target="https://sci-hub.st/https://doi.org/10.1016/j.cose.2018.01.018" quoteTitle="true" derivedAnchor="SecureNS">
3941 <front>
3942 <title>Toward secure name resolution on the Internet</title>
3943 <author initials="C." surname="Grothoff" fullname="Christian Grothoff">
3944 <organization showOnFrontPage="true">Bern University of Applied Sciences</organization>
3945 </author>
3946 <author initials="M." surname="Wachs" fullname="Matthias Wachs">
3947 <organization showOnFrontPage="true">Technische Universität München</organization>
3948 </author>
3949 <author initials="M." surname="Ermert" fullname="Monika Ermert">
3950 </author>
3951 <author initials="J." surname="Appelbaum" fullname="Jacob Appelbaum">
3952 <organization showOnFrontPage="true">TU Eindhoven</organization>
3953 </author>
3954 <date month="August" year="2018"/>
3955 </front>
3956 <refcontent>Computers and Security, Volume 77, Issue C, pp. 694-708</refcontent>
3957 <seriesInfo name="DOI" value="10.1016/j.cose.2018.01.018"/>
3958 </reference>
3959 <reference anchor="GNUnetGNS" target="https://git.gnunet.org/gnunet.git" quoteTitle="true" derivedAnchor="GNUnetGNS">
3960 <front>
3961 <title>gnunet.git - GNUnet core repository</title>
3962 <author>
3963 <organization showOnFrontPage="true">GNUnet e.V.</organization>
3964 </author>
3965 <date year="2023"/>
3966 </front>
3967 </reference>
3968 <reference anchor="Ascension" target="https://git.gnunet.org/ascension.git" quoteTitle="true" derivedAnchor="Ascension">
3969 <front>
3970 <title>ascension.git - DNS zones to GNS migrating using incremental zone transfer (AXFR/IXFR)</title>
3971 <author>
3972 <organization showOnFrontPage="true">GNUnet e.V.</organization>
3973 </author>
3974 <date year="2023"/>
3975 </front>
3976 </reference>
3977 <reference anchor="GNUnet" target="https://gnunet.org" quoteTitle="true" derivedAnchor="GNUnet">
3978 <front>
3979 <title>The GNUnet Project (Home Page)</title>
3980 <author>
3981 <organization showOnFrontPage="true">GNUnet e.V.</organization>
3982 </author>
3983 <date year="2023"/>
3984 </front>
3985 </reference>
3986 <reference anchor="reclaim" target="https://reclaim.gnunet.org" quoteTitle="true" derivedAnchor="reclaim">
3987 <front>
3988 <title>re:claimID - Self-sovereign, Decentralised Identity Management and Personal Data Sharing</title>
3989 <author>
3990 <organization showOnFrontPage="true">GNUnet e.V.</organization>
3991 </author>
3992 <date year="2023"/>
3993 </front>
3994 </reference>
3995 <reference anchor="GoGNS" target="https://github.com/bfix/gnunet-go/tree/master/src/gnunet/service/gns" quoteTitle="true" derivedAnchor="GoGNS">
3996 <front>
3997 <title>gnunet-go (Go GNS)</title>
3998 <author initials="B." surname="Fix" fullname="Bernd Fix">
3999 </author>
4000 <date month="July" year="2023"/>
4001 </front>
4002 <refcontent>commit 5c815ba</refcontent>
4003 </reference>
4004 <reference anchor="nsswitch" target="https://www.gnu.org/software/libc/manual/html_node/Name-Service-Switch.html" quoteTitle="true" derivedAnchor="nsswitch">
4005 <front>
4006 <title>System Databases and Name Service Switch (Section 29)</title>
4007 <author>
4008 <organization showOnFrontPage="true">GNU Project</organization>
4009 </author>
4010 </front>
4011 </reference>
4012 </references>
4013 </references>
4014 <section numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a">
4015 <name slugifiedName="name-usage-and-migration">Usage and Migration</name>
4016 <t indent="0" pn="section-appendix.a-1">
4017 This section outlines a number of specific use cases that may
4018 help readers of this technical specification better understand the protocol.
4019 The considerations below are not meant to be normative for the
4020 GNS protocol in any way.
4021 Instead, they are provided in order to give context and to provide
4022 some background on what the intended use of the protocol is
4023 by its designers.
4024 Further, this section provides pointers to migration paths.
4025 </t>
4026 <section anchor="day_in_zoneowner" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.1">
4027 <name slugifiedName="name-zone-dissemination">Zone Dissemination</name>
4028 <t indent="0" pn="section-appendix.a.1-1">
4029 In order to become a zone owner, it is sufficient to generate
4030 a zone key and a corresponding secret key using a GNS implementation.
4031 At this point, the zone owner can manage GNS resource records in a
4032 local zone database.
4033 The resource records can then be published by a GNS implementation
4034 as defined in <xref target="publish" format="default" sectionFormat="of" derivedContent="Section 6"/>.
4035 For other users to resolve the resource records, the respective
4036 zone information must be disseminated first.
4037 The zone owner may decide to make the zone key and labels known
4038 to a selected set of users only or to make this information available
4039 to the general public.
4040 </t>
4041 <t indent="0" pn="section-appendix.a.1-2">
4042 Sharing zone information directly with specific users not only allows
4043 an implementation to potentially preserve zone and record privacy but also allows
4044 the zone owner and the user to establish strong trust relationships.
4045 For example, a bank may send a customer letter with a QR code that
4046 contains the GNS zone of the bank.
4047 This allows the user to scan the QR code and establish a strong
4048 link to the zone of the bank and with it, for example, the IP address
4049 of the online banking web site.
4050 </t>
4051 <t indent="0" pn="section-appendix.a.1-3">
4052 Most Internet services likely want to make their zones available
4053 to the general public in the most efficient way possible.
4054 First, it is reasonable to assume that zones that are commanding
4055 high levels of reputation and trust are likely included in the
4056 default suffix-to-zone mappings of implementations.
4057 Hence, dissemination of a zone through delegation under such zones
4058 can be a viable path in order to disseminate a zone publicly.
4059 For example, it is conceivable that organizations such as ICANN
4060 or country-code TLD registrars also manage GNS zones
4061 and offer registration or delegation services.
4062 </t>
4063 <t indent="0" pn="section-appendix.a.1-4">
4064 Following best practices, particularly those related to
4065 security and abuse mitigation, are methods that allow zone owners
4066 and aspiring registrars to gain a good reputation and, eventually,
4067 trust.
4068 This includes, of course, diligent protection of private zone key
4069 material.
4070 Formalizing such best practices is out of scope for this
4071 specification and should be addressed in a separate document that takes
4072 <xref target="security" format="default" sectionFormat="of" derivedContent="Section 9"/> of this document into account.
4073 </t>
4074 </section>
4075 <section numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.2">
4076 <name slugifiedName="name-start-zone-configuration">Start Zone Configuration</name>
4077 <t indent="0" pn="section-appendix.a.2-1">
4078 A user is expected to install a GNS implementation if it is not already
4079 provided through other means such as the operating system
4080 or the browser.
4081 It is likely that the implementation ships with a
4082 default Start Zone configuration.
4083 This means that the user is able to resolve GNS names ending on a
4084 zTLD or ending on any suffix-to-name mapping that is part of the
4085 default Start Zone configuration.
4086 At this point, the user may delete or otherwise modify the
4087 implementation's default configuration:
4088 </t>
4089 <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-appendix.a.2-2">
4090 <li pn="section-appendix.a.2-2.1">
4091 Deletion of suffix-to-zone mappings may become necessary if the
4092 zone owner referenced by the mapping has lost the trust of the user.
4093 For example, this could be due to lax registration policies resulting
4094 in phishing activities.
4095 Modification and addition of new mappings are means to heal the
4096 namespace perforation that would occur in the case of a deletion
4097 or to simply establish a strong direct trust relationship.
4098 However, this requires the user's knowledge of the respective zone
4099 keys.
4100 This information must be retrieved out of band, as illustrated in
4101 <xref target="day_in_zoneowner" format="default" sectionFormat="of" derivedContent="Appendix A.1"/>:
4102 a bank may send the user a letter with a QR code that contains the
4103 GNS zone of the bank.
4104 The user scans the QR code and adds a new suffix-to-name mapping
4105 using a chosen local name for their bank.
4106 Other examples include scanning zone information off the device of
4107 a friend, from a storefront, or from an advertisement.
4108 The level of trust in the respective zone is contextual and likely
4109 varies from user to user.
4110 Trust in a zone provided through a letter from a bank that
4111 may also include a credit card is certainly different from a zone
4112 found on a random advertisement on the street.
4113 However, this trust is immediately tangible to the user and can
4114 be reflected in the local naming as well.
4115 </li>
4116 <li pn="section-appendix.a.2-2.2">
4117 Users that are also clients should facilitate the modification of the Start Zone
4118 configuration -- for example, by providing a QR code reader or other
4119 import mechanisms.
4120 Implementations are ideally implemented
4121 according to best practices and addressing applicable points
4122 from <xref target="security" format="default" sectionFormat="of" derivedContent="Section 9"/>.
4123 Formalizing such best practices is out of scope for this
4124 specification.
4125 </li>
4126 </ul>
4127 </section>
4128 <section anchor="uc_virthost" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.3">
4129 <name slugifiedName="name-globally-unique-names-and-t">Globally Unique Names and the Web</name>
4130 <t indent="0" pn="section-appendix.a.3-1">
4131 HTTP virtual hosting and TLS Server Name Indication (SNI) are common
4132 use cases on the Web.
4133 HTTP clients supply a DNS name in the HTTP
4134 "Host"-header or as part of the TLS handshake, respectively.
4135 This allows the HTTP server to serve the indicated virtual host
4136 with a matching TLS certificate.
4137 The global uniqueness of DNS names is a prerequisite of those use cases.
4138 </t>
4139 <t indent="0" pn="section-appendix.a.3-2">
4140 Not all GNS names are globally unique.
4141 However, any resource record in GNS can be represented as a
4142 concatenation of a GNS label and the zTLD of the zone.
4143 While not memorable, this globally unique GNS name can be
4144 leveraged in order to facilitate the same use cases.
4145 Consider the GNS name "www.example.gns.alt" entered in a GNS-aware
4146 HTTP client.
4147 At first, "www.example.gns.alt" is resolved using GNS, yielding a record
4148 set.
4149 Then, the HTTP client determines the virtual host as follows:
4150 </t>
4151 <t indent="0" pn="section-appendix.a.3-3">
4152 If there is a LEHO record (<xref target="gnsrecords_leho" format="default" sectionFormat="of" derivedContent="Section 5.3.1"/>)
4153 containing "www.example.com" in the record set, then the HTTP
4154 client uses this as the value of the
4155 "Host"-header field of the HTTP request:
4156 </t>
4157 <sourcecode name="" type="http-message" markers="false" pn="section-appendix.a.3-4">
4158GET / HTTP/1.1
4159Host: www.example.com
4160</sourcecode>
4161 <t indent="0" pn="section-appendix.a.3-5">
4162In the absence of a LEHO record, an additional GNS resolution is
4163required to check whether "www.example.gns.alt" itself points to a
4164zone delegation record, which implies that the record set that was
4165originally resolved is published under the apex label.
4166 </t>
4167 <t indent="0" pn="section-appendix.a.3-6">
4168If it does, the unique GNS name is simply the zTLD representation of
4169the delegated zone:
4170 </t>
4171 <sourcecode name="" type="http-message" markers="false" pn="section-appendix.a.3-7">
4172GET / HTTP/1.1
4173Host: 000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W
4174</sourcecode>
4175 <t indent="0" pn="section-appendix.a.3-8">
4176On the other hand, if there is no zone delegation record for
4177"www.example.gns.alt", then the unique GNS name is the concatenation of
4178the leftmost label (e.g., "www") and the zTLD representation of the zone:
4179 </t>
4180 <sourcecode name="" type="http-message" markers="false" pn="section-appendix.a.3-9">
4181GET / HTTP/1.1
4182Host: www.000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W
4183</sourcecode>
4184 <t indent="0" pn="section-appendix.a.3-10">
4185Note that this second GNS resolution does not require any additional
4186network operation, as only the local record processing differs as per
4187the exception mentioned in the last sentence of <xref target="delegation_processing" format="default" sectionFormat="of" derivedContent="Section 7.3.4"/>.
4188 </t>
4189 <t indent="0" pn="section-appendix.a.3-11">
4190 If the HTTP client is a browser, the use of a unique GNS name
4191 for virtual hosting or TLS SNI does not necessarily have to be
4192 shown to the user.
4193 For example, the name in the URL bar may remain as "www.example.gns.alt"
4194 even if the used unique name in the "Host"-header differs.
4195 </t>
4196 </section>
4197 <section numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.4">
4198 <name slugifiedName="name-migration-paths">Migration Paths</name>
4199 <t indent="0" pn="section-appendix.a.4-1">
4200 DNS resolution is built into a variety of existing software
4201 components -- most significantly, operating systems and HTTP clients.
4202 This section illustrates possible migration paths for both in order
4203 to enable legacy applications to resolve GNS names.
4204 </t>
4205 <t indent="0" pn="section-appendix.a.4-2">
4206 One way to efficiently facilitate the resolution of GNS names
4207 is via GNS-enabled DNS server implementations.
4208 Local DNS queries are thereby either rerouted or explicitly configured
4209 to be resolved by a "DNS-to-GNS" server that runs locally.
4210 This DNS server tries to interpret any incoming query for a name
4211 as a GNS resolution request.
4212 If no Start Zone can be found for the name and it does not end in
4213 a zTLD, the server tries to resolve the name in DNS.
4214 Otherwise, the name is resolved in GNS.
4215 In the latter case, the resulting record set is converted to a DNS
4216 answer packet and is returned accordingly.
4217 An implementation of a DNS-to-GNS server can be found in
4218 <xref target="GNUnet" format="default" sectionFormat="of" derivedContent="GNUnet"/>.
4219 </t>
4220 <t indent="0" pn="section-appendix.a.4-3">
4221 A similar approach is to use operating system extensions such as
4222 the NSS <xref target="nsswitch" format="default" sectionFormat="of" derivedContent="nsswitch"/>.
4223 It allows the system administrator to configure plugins
4224 that are used for hostname resolution.
4225 A GNS nsswitch plugin can be used in a fashion similar to
4226 that used for the DNS-to-GNS server.
4227 An implementation of a glibc-compatible nsswitch plugin for GNS
4228 can be found in <xref target="GNUnet" format="default" sectionFormat="of" derivedContent="GNUnet"/>.
4229 </t>
4230 <t indent="0" pn="section-appendix.a.4-4">
4231 The methods above are usually also effective for HTTP client
4232 software.
4233 However, HTTP clients are commonly used in combination with
4234 TLS.
4235 TLS certificate validation, and SNI in particular, require additional logic in HTTP clients when GNS names are
4236 in play (<xref target="uc_virthost" format="default" sectionFormat="of" derivedContent="Appendix A.3"/>).
4237 In order to transparently enable this functionality for migration
4238 purposes, a local GNS-aware SOCKS5 proxy <xref target="RFC1928" format="default" sectionFormat="of" derivedContent="RFC1928"/>
4239 can be configured to resolve domain names.
4240 The SOCKS5 proxy, similar to the DNS-to-GNS server, is capable
4241 of resolving both GNS and DNS names.
4242 In the event of a TLS connection request with a GNS name, the SOCKS5
4243 proxy can terminate the TLS connection
4244 and establish a secure connection against the requested host.
4245 In order to establish a secure connection, the proxy may use LEHO
4246 and TLSA records stored in the record set under the GNS name.
4247 The proxy must provide a locally trusted certificate for the GNS
4248 name to the HTTP client; this usually requires the generation and
4249 configuration of a local trust anchor in the browser.
4250 An implementation of this SOCKS5 proxy can be found in
4251 <xref target="GNUnet" format="default" sectionFormat="of" derivedContent="GNUnet"/>.
4252 </t>
4253 </section>
4254 </section>
4255 <section numbered="true" removeInRFC="false" toc="include" pn="section-appendix.b">
4256 <name slugifiedName="name-example-flows">Example Flows</name>
4257 <section numbered="true" removeInRFC="false" toc="include" pn="section-appendix.b.1">
4258 <name slugifiedName="name-aaaa-example-resolution">AAAA Example Resolution</name>
4259 <figure anchor="figure_resolution_ex_aaaa" align="left" suppress-title="false" pn="figure-24">
4260 <name slugifiedName="name-example-resolution-of-an-ip">Example Resolution of an IPv6 Address</name>
4261 <artwork name="" type="" alt="" align="left" pn="section-appendix.b.1-1.1">
4262 Local Host | Remote
4263 | Storage
4264 |
4265 | +---------+
4266 | / /|
4267 | +---------+ |
4268+-----------+ (1) +----------+ | | | |
4269| | | | (4,6) | | Record | |
4270|Application|----------| Resolver |---------------|-&gt;| Storage | |
4271| |&lt;---------| |&lt;--------------|--| |/
4272+-----------+ (8) +----------+ (5,7) | +---------+
4273 A |
4274 | |
4275 (2,3) | |
4276 | |
4277 | |
4278 +---------+ |
4279 / v /| |
4280 +---------+ | |
4281 | | | |
4282 | Start | | |
4283 | Zones | | |
4284 | |/ |
4285 +---------+ |
4286 </artwork>
4287 </figure>
4288 <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-appendix.b.1-2">
4289 <li pn="section-appendix.b.1-2.1" derivedCounter="1.">Look up AAAA record for name: "www.example.gnu.gns.alt".</li>
4290 <li pn="section-appendix.b.1-2.2" derivedCounter="2.">Determine Start Zone for "www.example.gnu.gns.alt".</li>
4291 <li pn="section-appendix.b.1-2.3" derivedCounter="3.">Start Zone: zkey0 - Remainder: "www.example".</li>
4292 <li pn="section-appendix.b.1-2.4" derivedCounter="4.">Calculate q0=SHA512(ZKDF(zkey0, "example")) and initiate GET(q0).</li>
4293 <li pn="section-appendix.b.1-2.5" derivedCounter="5.">Retrieve and decrypt RRBLOCK consisting of a single PKEY record containing zkey1.</li>
4294 <li pn="section-appendix.b.1-2.6" derivedCounter="6.">Calculate q1=SHA512(ZKDF(zkey1, "www")) and initiate GET(q1).</li>
4295 <li pn="section-appendix.b.1-2.7" derivedCounter="7.">Retrieve RRBLOCK consisting of a single AAAA record containing the IPv6 address 2001:db8::1.</li>
4296 <li pn="section-appendix.b.1-2.8" derivedCounter="8.">Return record set to application.</li>
4297 </ol>
4298 </section>
4299 <section numbered="true" removeInRFC="false" toc="include" pn="section-appendix.b.2">
4300 <name slugifiedName="name-redirect-example-resolution">REDIRECT Example Resolution</name>
4301 <figure anchor="figure_resolution_ex_redir" align="left" suppress-title="false" pn="figure-25">
4302 <name slugifiedName="name-example-resolution-of-an-ipv">Example Resolution of an IPv6 Address with Redirect</name>
4303 <artwork name="" type="" alt="" align="left" pn="section-appendix.b.2-1.1">
4304 Local Host | Remote
4305 | Storage
4306 |
4307 | +---------+
4308 | / /|
4309 | +---------+ |
4310+-----------+ (1) +----------+ | | | |
4311| | | | (4,6,8) | | Record | |
4312|Application|----------| Resolver |----------------|-&gt;| Storage | |
4313| |&lt;---------| |&lt;---------------|--| |/
4314+-----------+ (10) +----------+ (5,7,9) | +---------+
4315 A |
4316 | |
4317 (2,3) | |
4318 | |
4319 | |
4320 +---------+ |
4321 / v /| |
4322 +---------+ | |
4323 | | | |
4324 | Start | | |
4325 | Zones | | |
4326 | |/ |
4327 +---------+ |
4328 </artwork>
4329 </figure>
4330 <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-appendix.b.2-2">
4331 <li pn="section-appendix.b.2-2.1" derivedCounter="1.">Look up AAAA record for name: "www.example.tld.gns.alt".</li>
4332 <li pn="section-appendix.b.2-2.2" derivedCounter="2.">Determine Start Zone for "www.example.tld.gns.alt".</li>
4333 <li pn="section-appendix.b.2-2.3" derivedCounter="3.">Start Zone: zkey0 - Remainder: "www.example".</li>
4334 <li pn="section-appendix.b.2-2.4" derivedCounter="4.">Calculate q0=SHA512(ZKDF(zkey0, "example")) and initiate GET(q0).</li>
4335 <li pn="section-appendix.b.2-2.5" derivedCounter="5.">Retrieve and decrypt RRBLOCK consisting of a single PKEY record containing zkey1.</li>
4336 <li pn="section-appendix.b.2-2.6" derivedCounter="6.">Calculate q1=SHA512(ZKDF(zkey1, "www")) and initiate GET(q1).</li>
4337 <li pn="section-appendix.b.2-2.7" derivedCounter="7.">Retrieve and decrypt RRBLOCK consisting of a single REDIRECT record containing "www2.+".</li>
4338 <li pn="section-appendix.b.2-2.8" derivedCounter="8.">Calculate q2=SHA512(ZKDF(zkey1, "www2")) and initiate GET(q2).</li>
4339 <li pn="section-appendix.b.2-2.9" derivedCounter="9.">Retrieve and decrypt RRBLOCK consisting of a single AAAA record containing the IPv6 address 2001:db8::1.</li>
4340 <li pn="section-appendix.b.2-2.10" derivedCounter="10.">Return record set to application.</li>
4341 </ol>
4342 </section>
4343 <section numbered="true" removeInRFC="false" toc="include" pn="section-appendix.b.3">
4344 <name slugifiedName="name-gns2dns-example-resolution">GNS2DNS Example Resolution</name>
4345 <figure anchor="figure_resolution_ex_gnsdns" align="left" suppress-title="false" pn="figure-26">
4346 <name slugifiedName="name-example-resolution-of-an-ipv6">Example Resolution of an IPv6 Address with DNS Handover</name>
4347 <artwork name="" type="" alt="" align="left" pn="section-appendix.b.3-1.1">
4348 Local Host | Remote
4349 | Storage
4350 |
4351 | +---------+
4352 | / /|
4353 | +---------+ |
4354+-----------+ (1) +----------+ | | | |
4355| | | | (4) | | Record | |
4356|Application|----------| Resolver |------------------|-&gt;| Storage | |
4357| |&lt;---------| |&lt;-----------------|--| |/
4358+-----------+ (8) +----------+ (5) | +---------+
4359 A A |
4360 | | (6,7) |
4361 (2,3) | +----------+ |
4362 | | |
4363 | v |
4364 +---------+ +------------+ |
4365 / v /| | System DNS | |
4366 +---------+ | | Resolver | |
4367 | | | +------------+ |
4368 | Start | | |
4369 | Zones | | |
4370 | |/ |
4371 +---------+ |
4372 </artwork>
4373 </figure>
4374 <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-appendix.b.3-2">
4375 <li pn="section-appendix.b.3-2.1" derivedCounter="1.">Look up AAAA record for name: "www.example.gnu.gns.alt".</li>
4376 <li pn="section-appendix.b.3-2.2" derivedCounter="2.">Determine Start Zone for "www.example.gnu.gns.alt".</li>
4377 <li pn="section-appendix.b.3-2.3" derivedCounter="3.">Start Zone: zkey0 - Remainder: "www.example".</li>
4378 <li pn="section-appendix.b.3-2.4" derivedCounter="4.">Calculate q0=SHA512(ZKDF(zkey0, "example")) and initiate GET(q0).</li>
4379 <li pn="section-appendix.b.3-2.5" derivedCounter="5.">Retrieve and decrypt RRBLOCK consisting of a single GNS2DNS record containing the name "example.com" and the DNS server IPv4 address 192.0.2.1.</li>
4380 <li pn="section-appendix.b.3-2.6" derivedCounter="6.">Use system resolver to look up a AAAA record for the DNS name "www.example.com".</li>
4381 <li pn="section-appendix.b.3-2.7" derivedCounter="7.">Retrieve a DNS reply consisting of a single AAAA record containing the IPv6 address 2001:db8::1.</li>
4382 <li pn="section-appendix.b.3-2.8" derivedCounter="8.">Return record set to application.</li>
4383 </ol>
4384 </section>
4385 </section>
4386 <section anchor="app-c" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.c">
4387 <name slugifiedName="name-base32gns">Base32GNS</name>
4388 <t indent="0" pn="section-appendix.c-1">
4389 Encoding converts a byte array into a string of symbols.
4390 Decoding converts a string of symbols into a byte array.
4391 Decoding fails if the input string has symbols outside the defined set.
4392 </t>
4393 <t indent="0" pn="section-appendix.c-2">
4394 <xref target="CrockfordB32Encode" format="default" sectionFormat="of" derivedContent="Table 4"/> defines the encoding and decoding symbols for a given
4395 symbol value.
4396 Each symbol value encodes 5 bits.
4397 It can be used to implement the encoding by reading it as follows:
4398 a symbol "A" or "a" is decoded to a 5-bit value 10 when decoding.
4399 A 5-bit block with a value of 18 is encoded to the character "J" when encoding.
4400 If the bit length of the byte string to encode is not a multiple of 5,
4401 it is padded to the next multiple with zeroes.
4402 In order to further increase tolerance for failures in character
4403 recognition, the letter "U" <bcp14>MUST</bcp14> be decoded to the same value as the
4404 letter "V" in Base32GNS.
4405 </t>
4406 <table anchor="CrockfordB32Encode" align="center" pn="table-4">
4407 <name slugifiedName="name-the-base32gns-alphabet-incl">The Base32GNS Alphabet, Including the Additional Encoding Symbol "U"</name>
4408 <thead>
4409 <tr>
4410 <th align="left" colspan="1" rowspan="1">Symbol Value</th>
4411 <th align="left" colspan="1" rowspan="1">Decoding Symbol</th>
4412 <th align="left" colspan="1" rowspan="1">Encoding Symbol</th>
4413 </tr>
4414 </thead>
4415 <tbody>
4416 <tr>
4417 <td align="left" colspan="1" rowspan="1">0</td>
4418 <td align="left" colspan="1" rowspan="1">0 O o</td>
4419 <td align="left" colspan="1" rowspan="1">0</td>
4420 </tr>
4421 <tr>
4422 <td align="left" colspan="1" rowspan="1">1</td>
4423 <td align="left" colspan="1" rowspan="1">1 I i L l</td>
4424 <td align="left" colspan="1" rowspan="1">1</td>
4425 </tr>
4426 <tr>
4427 <td align="left" colspan="1" rowspan="1">2</td>
4428 <td align="left" colspan="1" rowspan="1">2</td>
4429 <td align="left" colspan="1" rowspan="1">2</td>
4430 </tr>
4431 <tr>
4432 <td align="left" colspan="1" rowspan="1">3</td>
4433 <td align="left" colspan="1" rowspan="1">3</td>
4434 <td align="left" colspan="1" rowspan="1">3</td>
4435 </tr>
4436 <tr>
4437 <td align="left" colspan="1" rowspan="1">4</td>
4438 <td align="left" colspan="1" rowspan="1">4</td>
4439 <td align="left" colspan="1" rowspan="1">4</td>
4440 </tr>
4441 <tr>
4442 <td align="left" colspan="1" rowspan="1">5</td>
4443 <td align="left" colspan="1" rowspan="1">5</td>
4444 <td align="left" colspan="1" rowspan="1">5</td>
4445 </tr>
4446 <tr>
4447 <td align="left" colspan="1" rowspan="1">6</td>
4448 <td align="left" colspan="1" rowspan="1">6</td>
4449 <td align="left" colspan="1" rowspan="1">6</td>
4450 </tr>
4451 <tr>
4452 <td align="left" colspan="1" rowspan="1">7</td>
4453 <td align="left" colspan="1" rowspan="1">7</td>
4454 <td align="left" colspan="1" rowspan="1">7</td>
4455 </tr>
4456 <tr>
4457 <td align="left" colspan="1" rowspan="1">8</td>
4458 <td align="left" colspan="1" rowspan="1">8</td>
4459 <td align="left" colspan="1" rowspan="1">8</td>
4460 </tr>
4461 <tr>
4462 <td align="left" colspan="1" rowspan="1">9</td>
4463 <td align="left" colspan="1" rowspan="1">9</td>
4464 <td align="left" colspan="1" rowspan="1">9</td>
4465 </tr>
4466 <tr>
4467 <td align="left" colspan="1" rowspan="1">10</td>
4468 <td align="left" colspan="1" rowspan="1">A a</td>
4469 <td align="left" colspan="1" rowspan="1">A</td>
4470 </tr>
4471 <tr>
4472 <td align="left" colspan="1" rowspan="1">11</td>
4473 <td align="left" colspan="1" rowspan="1">B b</td>
4474 <td align="left" colspan="1" rowspan="1">B</td>
4475 </tr>
4476 <tr>
4477 <td align="left" colspan="1" rowspan="1">12</td>
4478 <td align="left" colspan="1" rowspan="1">C c</td>
4479 <td align="left" colspan="1" rowspan="1">C</td>
4480 </tr>
4481 <tr>
4482 <td align="left" colspan="1" rowspan="1">13</td>
4483 <td align="left" colspan="1" rowspan="1">D d</td>
4484 <td align="left" colspan="1" rowspan="1">D</td>
4485 </tr>
4486 <tr>
4487 <td align="left" colspan="1" rowspan="1">14</td>
4488 <td align="left" colspan="1" rowspan="1">E e</td>
4489 <td align="left" colspan="1" rowspan="1">E</td>
4490 </tr>
4491 <tr>
4492 <td align="left" colspan="1" rowspan="1">15</td>
4493 <td align="left" colspan="1" rowspan="1">F f</td>
4494 <td align="left" colspan="1" rowspan="1">F</td>
4495 </tr>
4496 <tr>
4497 <td align="left" colspan="1" rowspan="1">16</td>
4498 <td align="left" colspan="1" rowspan="1">G g</td>
4499 <td align="left" colspan="1" rowspan="1">G</td>
4500 </tr>
4501 <tr>
4502 <td align="left" colspan="1" rowspan="1">17</td>
4503 <td align="left" colspan="1" rowspan="1">H h</td>
4504 <td align="left" colspan="1" rowspan="1">H</td>
4505 </tr>
4506 <tr>
4507 <td align="left" colspan="1" rowspan="1">18</td>
4508 <td align="left" colspan="1" rowspan="1">J j</td>
4509 <td align="left" colspan="1" rowspan="1">J</td>
4510 </tr>
4511 <tr>
4512 <td align="left" colspan="1" rowspan="1">19</td>
4513 <td align="left" colspan="1" rowspan="1">K k</td>
4514 <td align="left" colspan="1" rowspan="1">K</td>
4515 </tr>
4516 <tr>
4517 <td align="left" colspan="1" rowspan="1">20</td>
4518 <td align="left" colspan="1" rowspan="1">M m</td>
4519 <td align="left" colspan="1" rowspan="1">M</td>
4520 </tr>
4521 <tr>
4522 <td align="left" colspan="1" rowspan="1">21</td>
4523 <td align="left" colspan="1" rowspan="1">N n</td>
4524 <td align="left" colspan="1" rowspan="1">N</td>
4525 </tr>
4526 <tr>
4527 <td align="left" colspan="1" rowspan="1">22</td>
4528 <td align="left" colspan="1" rowspan="1">P p</td>
4529 <td align="left" colspan="1" rowspan="1">P</td>
4530 </tr>
4531 <tr>
4532 <td align="left" colspan="1" rowspan="1">23</td>
4533 <td align="left" colspan="1" rowspan="1">Q q</td>
4534 <td align="left" colspan="1" rowspan="1">Q</td>
4535 </tr>
4536 <tr>
4537 <td align="left" colspan="1" rowspan="1">24</td>
4538 <td align="left" colspan="1" rowspan="1">R r</td>
4539 <td align="left" colspan="1" rowspan="1">R</td>
4540 </tr>
4541 <tr>
4542 <td align="left" colspan="1" rowspan="1">25</td>
4543 <td align="left" colspan="1" rowspan="1">S s</td>
4544 <td align="left" colspan="1" rowspan="1">S</td>
4545 </tr>
4546 <tr>
4547 <td align="left" colspan="1" rowspan="1">26</td>
4548 <td align="left" colspan="1" rowspan="1">T t</td>
4549 <td align="left" colspan="1" rowspan="1">T</td>
4550 </tr>
4551 <tr>
4552 <td align="left" colspan="1" rowspan="1">27</td>
4553 <td align="left" colspan="1" rowspan="1">V v U u</td>
4554 <td align="left" colspan="1" rowspan="1">V</td>
4555 </tr>
4556 <tr>
4557 <td align="left" colspan="1" rowspan="1">28</td>
4558 <td align="left" colspan="1" rowspan="1">W w</td>
4559 <td align="left" colspan="1" rowspan="1">W</td>
4560 </tr>
4561 <tr>
4562 <td align="left" colspan="1" rowspan="1">29</td>
4563 <td align="left" colspan="1" rowspan="1">X x</td>
4564 <td align="left" colspan="1" rowspan="1">X</td>
4565 </tr>
4566 <tr>
4567 <td align="left" colspan="1" rowspan="1">30</td>
4568 <td align="left" colspan="1" rowspan="1">Y y</td>
4569 <td align="left" colspan="1" rowspan="1">Y</td>
4570 </tr>
4571 <tr>
4572 <td align="left" colspan="1" rowspan="1">31</td>
4573 <td align="left" colspan="1" rowspan="1">Z z</td>
4574 <td align="left" colspan="1" rowspan="1">Z</td>
4575 </tr>
4576 </tbody>
4577 </table>
4578 </section>
4579 <section numbered="true" removeInRFC="false" toc="include" pn="section-appendix.d">
4580 <name slugifiedName="name-test-vectors">Test Vectors</name>
4581 <t indent="0" pn="section-appendix.d-1">
4582 The following test vectors can be used by implementations to test
4583 for conformance with this specification. Unless indicated otherwise,
4584 the test vectors are provided as hexadecimal byte arrays.
4585 </t>
4586 <section numbered="true" removeInRFC="false" toc="include" pn="section-appendix.d.1">
4587 <name slugifiedName="name-base32gns-encoding-decoding">Base32GNS Encoding/Decoding</name>
4588 <t indent="0" pn="section-appendix.d.1-1">
4589 The following are test vectors for the Base32GNS encoding used for zTLDs. The input strings are encoded without the zero terminator.
4590 </t>
4591 <sourcecode name="" type="test-vectors" markers="false" pn="section-appendix.d.1-2">
4592Base32GNS-Encode:
4593 Input string: "Hello World"
4594 Output string: "91JPRV3F41BPYWKCCG"
4595
4596 Input bytes: 474e55204e616d652053797374656d
4597 Output string: "8X75A82EC5PPA82KF5SQ8SBD"
4598
4599Base32GNS-Decode:
4600 Input string: "91JPRV3F41BPYWKCCG"
4601 Output string: "Hello World"
4602
4603 Input string: "91JPRU3F41BPYWKCCG"
4604 Output string: "Hello World"
4605</sourcecode>
4606 </section>
4607 <section numbered="true" removeInRFC="false" toc="include" pn="section-appendix.d.2">
4608 <name slugifiedName="name-record-sets">Record Sets</name>
4609 <t indent="0" pn="section-appendix.d.2-1">
4610 The test vectors include record sets with a variety
4611 of record types and flags for both PKEY and EDKEY zones.
4612 This includes labels with UTF-8 characters to demonstrate
4613 internationalized labels.
4614 </t>
4615 <t indent="0" pn="section-appendix.d.2-2"><strong>(1) PKEY zone with ASCII label and one delegation record</strong></t>
4616 <sourcecode name="" type="test-vectors" markers="false" pn="section-appendix.d.2-3">
4617Zone private key (d, big-endian):
4618 50 d7 b6 52 a4 ef ea df
4619 f3 73 96 90 97 85 e5 95
4620 21 71 a0 21 78 c8 e7 d4
4621 50 fa 90 79 25 fa fd 98
4622
4623Zone identifier (ztype|zkey):
4624 00 01 00 00 67 7c 47 7d
4625 2d 93 09 7c 85 b1 95 c6
4626 f9 6d 84 ff 61 f5 98 2c
4627 2c 4f e0 2d 5a 11 fe df
4628 b0 c2 90 1f
4629
4630zTLD:
4631000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W
4632
4633Label:
4634 74 65 73 74 64 65 6c 65
4635 67 61 74 69 6f 6e
4636
4637Number of records (integer): 1
4638
4639Record #0 := (
4640 EXPIRATION: 8143584694000000 us
4641 00 1c ee 8c 10 e2 59 80
4642
4643 DATA_SIZE:
4644 00 20
4645
4646 TYPE:
4647 00 01 00 00
4648
4649 FLAGS: 00 01
4650
4651 DATA:
4652 21 e3 b3 0f f9 3b c6 d3
4653 5a c8 c6 e0 e1 3a fd ff
4654 79 4c b7 b4 4b bb c7 48
4655 d2 59 d0 a0 28 4d be 84
4656
4657)
4658
4659RDATA:
4660 00 1c ee 8c 10 e2 59 80
4661 00 20 00 01 00 01 00 00
4662 21 e3 b3 0f f9 3b c6 d3
4663 5a c8 c6 e0 e1 3a fd ff
4664 79 4c b7 b4 4b bb c7 48
4665 d2 59 d0 a0 28 4d be 84
4666
4667Encryption NONCE|EXPIRATION|BLOCK COUNTER:
4668 e9 0a 00 61 00 1c ee 8c
4669 10 e2 59 80 00 00 00 01
4670
4671Encryption key (K):
4672 86 4e 71 38 ea e7 fd 91
4673 a3 01 36 89 9c 13 2b 23
4674 ac eb db 2c ef 43 cb 19
4675 f6 bf 55 b6 7d b9 b3 b3
4676
4677Storage key (q):
4678 4a dc 67 c5 ec ee 9f 76
4679 98 6a bd 71 c2 22 4a 3d
4680 ce 2e 91 70 26 c9 a0 9d
4681 fd 44 ce f3 d2 0f 55 a2
4682 73 32 72 5a 6c 8a fb bb
4683 b0 f7 ec 9a f1 cc 42 64
4684 12 99 40 6b 04 fd 9b 5b
4685 57 91 f8 6c 4b 08 d5 f4
4686
4687ZKDF(zkey, label):
4688 18 2b b6 36 ed a7 9f 79
4689 57 11 bc 27 08 ad bb 24
4690 2a 60 44 6a d3 c3 08 03
4691 12 1d 03 d3 48 b7 ce b6
4692
4693Derived private key (d', big-endian):
4694 0a 4c 5e 0f 00 63 df ce
4695 db c8 c7 f2 b2 2c 03 0c
4696 86 28 b2 c2 cb ac 9f a7
4697 29 aa e6 1f 89 db 3e 9c
4698
4699BDATA:
4700 0c 1e da 5c c0 94 a1 c7
4701 a8 88 64 9d 25 fa ee bd
4702 60 da e6 07 3d 57 d8 ae
4703 8d 45 5f 4f 13 92 c0 74
4704 e2 6a c6 69 bd ee c2 34
4705 62 b9 62 95 2c c6 e9 eb
4706
4707RRBLOCK:
4708 00 00 00 a0 00 01 00 00
4709 18 2b b6 36 ed a7 9f 79
4710 57 11 bc 27 08 ad bb 24
4711 2a 60 44 6a d3 c3 08 03
4712 12 1d 03 d3 48 b7 ce b6
4713 0a d1 0b c1 3b 40 3b 5b
4714 25 61 26 b2 14 5a 6f 60
4715 c5 14 f9 51 ff a7 66 f7
4716 a3 fd 4b ac 4a 4e 19 90
4717 05 5c b8 7e 8d 1b fd 19
4718 aa 09 a4 29 f7 29 e9 f5
4719 c6 ee c2 47 0a ce e2 22
4720 07 59 e9 e3 6c 88 6f 35
4721 00 1c ee 8c 10 e2 59 80
4722 0c 1e da 5c c0 94 a1 c7
4723 a8 88 64 9d 25 fa ee bd
4724 60 da e6 07 3d 57 d8 ae
4725 8d 45 5f 4f 13 92 c0 74
4726 e2 6a c6 69 bd ee c2 34
4727 62 b9 62 95 2c c6 e9 eb
4728</sourcecode>
4729 <t indent="0" pn="section-appendix.d.2-4"><strong>(2) PKEY zone with UTF-8 label and three records</strong></t>
4730 <sourcecode name="" type="test-vectors" markers="false" pn="section-appendix.d.2-5">
4731Zone private key (d, big-endian):
4732 50 d7 b6 52 a4 ef ea df
4733 f3 73 96 90 97 85 e5 95
4734 21 71 a0 21 78 c8 e7 d4
4735 50 fa 90 79 25 fa fd 98
4736
4737Zone identifier (ztype|zkey):
4738 00 01 00 00 67 7c 47 7d
4739 2d 93 09 7c 85 b1 95 c6
4740 f9 6d 84 ff 61 f5 98 2c
4741 2c 4f e0 2d 5a 11 fe df
4742 b0 c2 90 1f
4743
4744zTLD:
4745000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W
4746
4747Label:
4748 e5 a4 a9 e4 b8 8b e7 84
4749 a1 e6 95 b5
4750
4751Number of records (integer): 3
4752
4753Record #0 := (
4754 EXPIRATION: 8143584694000000 us
4755 00 1c ee 8c 10 e2 59 80
4756
4757 DATA_SIZE:
4758 00 10
4759
4760 TYPE:
4761 00 00 00 1c
4762
4763 FLAGS: 00 00
4764
4765 DATA:
4766 00 00 00 00 00 00 00 00
4767 00 00 00 00 de ad be ef
4768
4769)
4770
4771Record #1 := (
4772 EXPIRATION: 17999736901000000 us
4773 00 3f f2 aa 54 08 db 40
4774
4775 DATA_SIZE:
4776 00 06
4777
4778 TYPE:
4779 00 01 00 01
4780
4781 FLAGS: 00 00
4782
4783 DATA:
4784 e6 84 9b e7 a7 b0
4785
4786)
4787
4788Record #2 := (
4789 EXPIRATION: 11464693629000000 us
4790 00 28 bb 13 ff 37 19 40
4791
4792 DATA_SIZE:
4793 00 0b
4794
4795 TYPE:
4796 00 00 00 10
4797
4798 FLAGS: 00 04
4799
4800 DATA:
4801 48 65 6c 6c 6f 20 57 6f
4802 72 6c 64
4803
4804)
4805
4806RDATA:
4807 00 1c ee 8c 10 e2 59 80
4808 00 10 00 00 00 00 00 1c
4809 00 00 00 00 00 00 00 00
4810 00 00 00 00 de ad be ef
4811 00 3f f2 aa 54 08 db 40
4812 00 06 00 00 00 01 00 01
4813 e6 84 9b e7 a7 b0 00 28
4814 bb 13 ff 37 19 40 00 0b
4815 00 04 00 00 00 10 48 65
4816 6c 6c 6f 20 57 6f 72 6c
4817 64 00 00 00 00 00 00 00
4818 00 00 00 00 00 00 00 00
4819 00 00 00 00 00 00 00 00
4820 00 00 00 00 00 00 00 00
4821 00 00 00 00 00 00 00 00
4822 00 00 00 00 00 00 00 00
4823
4824Encryption NONCE|EXPIRATION|BLOCK COUNTER:
4825 ee 96 33 c1 00 1c ee 8c
4826 10 e2 59 80 00 00 00 01
4827
4828Encryption key (K):
4829 fb 3a b5 de 23 bd da e1
4830 99 7a af 7b 92 c2 d2 71
4831 51 40 8b 77 af 7a 41 ac
4832 79 05 7c 4d f5 38 3d 01
4833
4834Storage key (q):
4835 af f0 ad 6a 44 09 73 68
4836 42 9a c4 76 df a1 f3 4b
4837 ee 4c 36 e7 47 6d 07 aa
4838 64 63 ff 20 91 5b 10 05
4839 c0 99 1d ef 91 fc 3e 10
4840 90 9f 87 02 c0 be 40 43
4841 67 78 c7 11 f2 ca 47 d5
4842 5c f0 b5 4d 23 5d a9 77
4843
4844ZKDF(zkey, label):
4845 a5 12 96 df 75 7e e2 75
4846 ca 11 8d 4f 07 fa 7a ae
4847 55 08 bc f5 12 aa 41 12
4848 14 29 d4 a0 de 9d 05 7e
4849
4850Derived private key (d', big-endian):
4851 0a be 56 d6 80 68 ab 40
4852 e1 44 79 0c de 9a cf 4d
4853 78 7f 2d 3c 63 b8 53 05
4854 74 6e 68 03 32 15 f2 ab
4855
4856BDATA:
4857 d8 c2 8d 2f d6 96 7d 1a
4858 b7 22 53 f2 10 98 b8 14
4859 a4 10 be 1f 59 98 de 03
4860 f5 8f 7e 7c db 7f 08 a6
4861 16 51 be 4d 0b 6f 8a 61
4862 df 15 30 44 0b d7 47 dc
4863 f0 d7 10 4f 6b 8d 24 c2
4864 ac 9b c1 3d 9c 6f e8 29
4865 05 25 d2 a6 d0 f8 84 42
4866 67 a1 57 0e 8e 29 4d c9
4867 3a 31 9f cf c0 3e a2 70
4868 17 d6 fd a3 47 b4 a7 94
4869 97 d7 f6 b1 42 2d 4e dd
4870 82 1c 19 93 4e 96 c1 aa
4871 87 76 57 25 d4 94 c7 64
4872 b1 55 dc 6d 13 26 91 74
4873
4874RRBLOCK:
4875 00 00 00 f0 00 01 00 00
4876 a5 12 96 df 75 7e e2 75
4877 ca 11 8d 4f 07 fa 7a ae
4878 55 08 bc f5 12 aa 41 12
4879 14 29 d4 a0 de 9d 05 7e
4880 08 5b d6 5f d4 85 10 51
4881 ba ce 2a 45 2a fc 8a 7e
4882 4f 6b 2c 1f 74 f0 20 35
4883 d9 64 1a cd ba a4 66 e0
4884 00 ce d6 f2 d2 3b 63 1c
4885 8e 8a 0b 38 e2 ba e7 9a
4886 22 ca d8 1d 4c 50 d2 25
4887 35 8e bc 17 ac 0f 89 9e
4888 00 1c ee 8c 10 e2 59 80
4889 d8 c2 8d 2f d6 96 7d 1a
4890 b7 22 53 f2 10 98 b8 14
4891 a4 10 be 1f 59 98 de 03
4892 f5 8f 7e 7c db 7f 08 a6
4893 16 51 be 4d 0b 6f 8a 61
4894 df 15 30 44 0b d7 47 dc
4895 f0 d7 10 4f 6b 8d 24 c2
4896 ac 9b c1 3d 9c 6f e8 29
4897 05 25 d2 a6 d0 f8 84 42
4898 67 a1 57 0e 8e 29 4d c9
4899 3a 31 9f cf c0 3e a2 70
4900 17 d6 fd a3 47 b4 a7 94
4901 97 d7 f6 b1 42 2d 4e dd
4902 82 1c 19 93 4e 96 c1 aa
4903 87 76 57 25 d4 94 c7 64
4904 b1 55 dc 6d 13 26 91 74
4905</sourcecode>
4906 <t indent="0" pn="section-appendix.d.2-6"><strong>(3) EDKEY zone with ASCII label and one delegation record</strong></t>
4907 <sourcecode name="" type="test-vectors" markers="false" pn="section-appendix.d.2-7">
4908Zone private key (d):
4909 5a f7 02 0e e1 91 60 32
4910 88 32 35 2b bc 6a 68 a8
4911 d7 1a 7c be 1b 92 99 69
4912 a7 c6 6d 41 5a 0d 8f 65
4913
4914Zone identifier (ztype|zkey):
4915 00 01 00 14 3c f4 b9 24
4916 03 20 22 f0 dc 50 58 14
4917 53 b8 5d 93 b0 47 b6 3d
4918 44 6c 58 45 cb 48 44 5d
4919 db 96 68 8f
4920
4921zTLD:
4922000G051WYJWJ80S04BRDRM2R2H9VGQCKP13VCFA4DHC4BJT88HEXQ5K8HW
4923
4924Label:
4925 74 65 73 74 64 65 6c 65
4926 67 61 74 69 6f 6e
4927
4928Number of records (integer): 1
4929
4930Record #0 := (
4931 EXPIRATION: 8143584694000000 us
4932 00 1c ee 8c 10 e2 59 80
4933
4934 DATA_SIZE:
4935 00 20
4936
4937 TYPE:
4938 00 01 00 00
4939
4940 FLAGS: 00 01
4941
4942 DATA:
4943 21 e3 b3 0f f9 3b c6 d3
4944 5a c8 c6 e0 e1 3a fd ff
4945 79 4c b7 b4 4b bb c7 48
4946 d2 59 d0 a0 28 4d be 84
4947
4948)
4949
4950RDATA:
4951 00 1c ee 8c 10 e2 59 80
4952 00 20 00 01 00 01 00 00
4953 21 e3 b3 0f f9 3b c6 d3
4954 5a c8 c6 e0 e1 3a fd ff
4955 79 4c b7 b4 4b bb c7 48
4956 d2 59 d0 a0 28 4d be 84
4957
4958Encryption NONCE|EXPIRATION:
4959 98 13 2e a8 68 59 d3 5c
4960 88 bf d3 17 fa 99 1b cb
4961 00 1c ee 8c 10 e2 59 80
4962
4963Encryption key (K):
4964 85 c4 29 a9 56 7a a6 33
4965 41 1a 96 91 e9 09 4c 45
4966 28 16 72 be 58 60 34 aa
4967 e4 a2 a2 cc 71 61 59 e2
4968
4969Storage key (q):
4970 ab aa ba c0 e1 24 94 59
4971 75 98 83 95 aa c0 24 1e
4972 55 59 c4 1c 40 74 e2 55
4973 7b 9f e6 d1 54 b6 14 fb
4974 cd d4 7f c7 f5 1d 78 6d
4975 c2 e0 b1 ec e7 60 37 c0
4976 a1 57 8c 38 4e c6 1d 44
4977 56 36 a9 4e 88 03 29 e9
4978
4979ZKDF(zkey, label):
4980 9b f2 33 19 8c 6d 53 bb
4981 db ac 49 5c ab d9 10 49
4982 a6 84 af 3f 40 51 ba ca
4983 b0 dc f2 1c 8c f2 7a 1a
4984
4985nonce := SHA-256(dh[32..63] || h):
4986 14 f2 c0 6b ed c3 aa 2d
4987 f0 71 13 9c 50 39 34 f3
4988 4b fa 63 11 a8 52 f2 11
4989 f7 3a df 2e 07 61 ec 35
4990
4991Derived private key (d', big-endian):
4992 3b 1b 29 d4 23 0b 10 a8
4993 ec 4d a3 c8 6e db 88 ea
4994 cd 54 08 5c 1d db 63 f7
4995 a9 d7 3f 7c cb 2f c3 98
4996
4997BDATA:
4998 57 7c c6 c9 5a 14 e7 04
4999 09 f2 0b 01 67 e6 36 d0
5000 10 80 7c 4f 00 37 2d 69
5001 8c 82 6b d9 2b c2 2b d6
5002 bb 45 e5 27 7c 01 88 1d
5003 6a 43 60 68 e4 dd f1 c6
5004 b7 d1 41 6f af a6 69 7c
5005 25 ed d9 ea e9 91 67 c3
5006
5007RRBLOCK:
5008 00 00 00 b0 00 01 00 14
5009 9b f2 33 19 8c 6d 53 bb
5010 db ac 49 5c ab d9 10 49
5011 a6 84 af 3f 40 51 ba ca
5012 b0 dc f2 1c 8c f2 7a 1a
5013 9f 56 a8 86 ea 73 9d 59
5014 17 50 8f 9b 75 56 39 f3
5015 a9 ac fa ed ed ca 7f bf
5016 a7 94 b1 92 e0 8b f9 ed
5017 4c 7e c8 59 4c 9f 7b 4e
5018 19 77 4f f8 38 ec 38 7a
5019 8f 34 23 da ac 44 9f 59
5020 db 4e 83 94 3f 90 72 00
5021 00 1c ee 8c 10 e2 59 80
5022 57 7c c6 c9 5a 14 e7 04
5023 09 f2 0b 01 67 e6 36 d0
5024 10 80 7c 4f 00 37 2d 69
5025 8c 82 6b d9 2b c2 2b d6
5026 bb 45 e5 27 7c 01 88 1d
5027 6a 43 60 68 e4 dd f1 c6
5028 b7 d1 41 6f af a6 69 7c
5029 25 ed d9 ea e9 91 67 c3
5030</sourcecode>
5031 <t indent="0" pn="section-appendix.d.2-8"><strong>(4) EDKEY zone with UTF-8 label and three records</strong></t>
5032 <sourcecode name="" type="test-vectors" markers="false" pn="section-appendix.d.2-9">
5033Zone private key (d):
5034 5a f7 02 0e e1 91 60 32
5035 88 32 35 2b bc 6a 68 a8
5036 d7 1a 7c be 1b 92 99 69
5037 a7 c6 6d 41 5a 0d 8f 65
5038
5039Zone identifier (ztype|zkey):
5040 00 01 00 14 3c f4 b9 24
5041 03 20 22 f0 dc 50 58 14
5042 53 b8 5d 93 b0 47 b6 3d
5043 44 6c 58 45 cb 48 44 5d
5044 db 96 68 8f
5045
5046zTLD:
5047000G051WYJWJ80S04BRDRM2R2H9VGQCKP13VCFA4DHC4BJT88HEXQ5K8HW
5048
5049Label:
5050 e5 a4 a9 e4 b8 8b e7 84
5051 a1 e6 95 b5
5052
5053Number of records (integer): 3
5054
5055Record #0 := (
5056 EXPIRATION: 8143584694000000 us
5057 00 1c ee 8c 10 e2 59 80
5058
5059 DATA_SIZE:
5060 00 10
5061
5062 TYPE:
5063 00 00 00 1c
5064
5065 FLAGS: 00 00
5066
5067 DATA:
5068 00 00 00 00 00 00 00 00
5069 00 00 00 00 de ad be ef
5070
5071)
5072
5073Record #1 := (
5074 EXPIRATION: 17999736901000000 us
5075 00 3f f2 aa 54 08 db 40
5076
5077 DATA_SIZE:
5078 00 06
5079
5080 TYPE:
5081 00 01 00 01
5082
5083 FLAGS: 00 00
5084
5085 DATA:
5086 e6 84 9b e7 a7 b0
5087
5088)
5089
5090Record #2 := (
5091 EXPIRATION: 11464693629000000 us
5092 00 28 bb 13 ff 37 19 40
5093
5094 DATA_SIZE:
5095 00 0b
5096
5097 TYPE:
5098 00 00 00 10
5099
5100 FLAGS: 00 04
5101
5102 DATA:
5103 48 65 6c 6c 6f 20 57 6f
5104 72 6c 64
5105
5106)
5107
5108RDATA:
5109 00 1c ee 8c 10 e2 59 80
5110 00 10 00 00 00 00 00 1c
5111 00 00 00 00 00 00 00 00
5112 00 00 00 00 de ad be ef
5113 00 3f f2 aa 54 08 db 40
5114 00 06 00 00 00 01 00 01
5115 e6 84 9b e7 a7 b0 00 28
5116 bb 13 ff 37 19 40 00 0b
5117 00 04 00 00 00 10 48 65
5118 6c 6c 6f 20 57 6f 72 6c
5119 64 00 00 00 00 00 00 00
5120 00 00 00 00 00 00 00 00
5121 00 00 00 00 00 00 00 00
5122 00 00 00 00 00 00 00 00
5123 00 00 00 00 00 00 00 00
5124 00 00 00 00 00 00 00 00
5125
5126Encryption NONCE|EXPIRATION:
5127 bb 0d 3f 0f bd 22 42 77
5128 50 da 5d 69 12 16 e6 c9
5129 00 1c ee 8c 10 e2 59 80
5130
5131Encryption key (K):
5132 3d f8 05 bd 66 87 aa 14
5133 20 96 28 c2 44 b1 11 91
5134 88 c3 92 56 37 a4 1e 5d
5135 76 49 6c 29 45 dc 37 7b
5136
5137Storage key (q):
5138 ba f8 21 77 ee c0 81 e0
5139 74 a7 da 47 ff c6 48 77
5140 58 fb 0d f0 1a 6c 7f bb
5141 52 fc 8a 31 be f0 29 af
5142 74 aa 0d c1 5a b8 e2 fa
5143 7a 54 b4 f5 f6 37 f6 15
5144 8f a7 f0 3c 3f ce be 78
5145 d3 f9 d6 40 aa c0 d1 ed
5146
5147ZKDF(zkey, label):
5148 74 f9 00 68 f1 67 69 53
5149 52 a8 a6 c2 eb 98 48 98
5150 c5 3a cc a0 98 04 70 c6
5151 c8 12 64 cb dd 78 ad 11
5152
5153nonce := SHA-256(dh[32..63] || h):
5154 f8 6a b5 33 8a 74 d7 a1
5155 d2 77 ea 11 ff 95 cb e8
5156 3a cf d3 97 3b b4 ab ca
5157 0a 1b 60 62 c3 7a b3 9c
5158
5159Derived private key (d', big-endian):
5160 17 c0 68 a6 c3 f7 20 de
5161 0e 1b 69 ff 3f 53 e0 5d
5162 3f e5 c5 b0 51 25 7a 89
5163 a6 3c 1a d3 5a c4 35 58
5164
5165BDATA:
5166 4e b3 5a 50 d4 0f e1 a4
5167 29 c7 f4 b2 67 a0 59 de
5168 4e 2c 8a 89 a5 ed 53 d3
5169 d4 92 58 59 d2 94 9f 7f
5170 30 d8 a2 0c aa 96 f8 81
5171 45 05 2d 1c da 04 12 49
5172 8f f2 5f f2 81 6e f0 ce
5173 61 fe 69 9b fa c7 2c 15
5174 dc 83 0e a9 b0 36 17 1c
5175 cf ca bb dd a8 de 3c 86
5176 ed e2 95 70 d0 17 4b 82
5177 82 09 48 a9 28 b7 f0 0e
5178 fb 40 1c 10 fe 80 bb bb
5179 02 76 33 1b f7 f5 1b 8d
5180 74 57 9c 14 14 f2 2d 50
5181 1a d2 5a e2 49 f5 bb f2
5182 a6 c3 72 59 d1 75 e4 40
5183 b2 94 39 c6 05 19 cb b1
5184
5185RRBLOCK:
5186 00 00 01 00 00 01 00 14
5187 74 f9 00 68 f1 67 69 53
5188 52 a8 a6 c2 eb 98 48 98
5189 c5 3a cc a0 98 04 70 c6
5190 c8 12 64 cb dd 78 ad 11
5191 75 6d 2c 15 7a d2 ea 4f
5192 c0 b1 b9 1c 08 03 79 44
5193 61 d3 de f2 0d d1 63 6c
5194 fe dc 03 89 c5 49 d1 43
5195 6c c3 5b 4e 1b f8 89 5a
5196 64 6b d9 a6 f4 6b 83 48
5197 1d 9c 0e 91 d4 e1 be bb
5198 6a 83 52 6f b7 25 2a 06
5199 00 1c ee 8c 10 e2 59 80
5200 4e b3 5a 50 d4 0f e1 a4
5201 29 c7 f4 b2 67 a0 59 de
5202 4e 2c 8a 89 a5 ed 53 d3
5203 d4 92 58 59 d2 94 9f 7f
5204 30 d8 a2 0c aa 96 f8 81
5205 45 05 2d 1c da 04 12 49
5206 8f f2 5f f2 81 6e f0 ce
5207 61 fe 69 9b fa c7 2c 15
5208 dc 83 0e a9 b0 36 17 1c
5209 cf ca bb dd a8 de 3c 86
5210 ed e2 95 70 d0 17 4b 82
5211 82 09 48 a9 28 b7 f0 0e
5212 fb 40 1c 10 fe 80 bb bb
5213 02 76 33 1b f7 f5 1b 8d
5214 74 57 9c 14 14 f2 2d 50
5215 1a d2 5a e2 49 f5 bb f2
5216 a6 c3 72 59 d1 75 e4 40
5217 b2 94 39 c6 05 19 cb b1
5218</sourcecode>
5219 </section>
5220 <section numbered="true" removeInRFC="false" toc="include" pn="section-appendix.d.3">
5221 <name slugifiedName="name-zone-revocation-2">Zone Revocation</name>
5222 <t indent="0" pn="section-appendix.d.3-1">
5223 The following is an example revocation for a PKEY zone:
5224 </t>
5225 <sourcecode name="" type="test-vectors" markers="false" pn="section-appendix.d.3-2">
5226Zone private key (d, big-endian):
5227 6f ea 32 c0 5a f5 8b fa
5228 97 95 53 d1 88 60 5f d5
5229 7d 8b f9 cc 26 3b 78 d5
5230 f7 47 8c 07 b9 98 ed 70
5231
5232Zone identifier (ztype|zkey):
5233 00 01 00 00 2c a2 23 e8
5234 79 ec c4 bb de b5 da 17
5235 31 92 81 d6 3b 2e 3b 69
5236 55 f1 c3 77 5c 80 4a 98
5237 d5 f8 dd aa
5238
5239zTLD:
5240000G001CM8HYGYFCRJXXXDET2WRS50EP7CQ3PTANY71QEQ409ACDBY6XN8
5241
5242Difficulty (5 base difficulty + 2 epochs): 7
5243
5244Signed message:
5245 00 00 00 34 00 00 00 03
5246 00 05 ff 1c 56 e4 b2 68
5247 00 01 00 00 2c a2 23 e8
5248 79 ec c4 bb de b5 da 17
5249 31 92 81 d6 3b 2e 3b 69
5250 55 f1 c3 77 5c 80 4a 98
5251 d5 f8 dd aa
5252
5253Proof:
5254 00 05 ff 1c 56 e4 b2 68
5255 00 00 39 5d 18 27 c0 00
5256 38 0b 54 aa 70 16 ac a2
5257 38 0b 54 aa 70 16 ad 62
5258 38 0b 54 aa 70 16 af 3e
5259 38 0b 54 aa 70 16 af 93
5260 38 0b 54 aa 70 16 b0 bf
5261 38 0b 54 aa 70 16 b0 ee
5262 38 0b 54 aa 70 16 b1 c9
5263 38 0b 54 aa 70 16 b1 e5
5264 38 0b 54 aa 70 16 b2 78
5265 38 0b 54 aa 70 16 b2 b2
5266 38 0b 54 aa 70 16 b2 d6
5267 38 0b 54 aa 70 16 b2 e4
5268 38 0b 54 aa 70 16 b3 2c
5269 38 0b 54 aa 70 16 b3 5a
5270 38 0b 54 aa 70 16 b3 9d
5271 38 0b 54 aa 70 16 b3 c0
5272 38 0b 54 aa 70 16 b3 dd
5273 38 0b 54 aa 70 16 b3 f4
5274 38 0b 54 aa 70 16 b4 42
5275 38 0b 54 aa 70 16 b4 76
5276 38 0b 54 aa 70 16 b4 8c
5277 38 0b 54 aa 70 16 b4 a4
5278 38 0b 54 aa 70 16 b4 c9
5279 38 0b 54 aa 70 16 b4 f0
5280 38 0b 54 aa 70 16 b4 f7
5281 38 0b 54 aa 70 16 b5 79
5282 38 0b 54 aa 70 16 b6 34
5283 38 0b 54 aa 70 16 b6 8e
5284 38 0b 54 aa 70 16 b7 b4
5285 38 0b 54 aa 70 16 b8 7e
5286 38 0b 54 aa 70 16 b8 f8
5287 38 0b 54 aa 70 16 b9 2a
5288 00 01 00 00 2c a2 23 e8
5289 79 ec c4 bb de b5 da 17
5290 31 92 81 d6 3b 2e 3b 69
5291 55 f1 c3 77 5c 80 4a 98
5292 d5 f8 dd aa 08 ca ff de
5293 3c 6d f1 45 f7 e0 79 81
5294 15 37 b2 b0 42 2d 5e 1f
5295 b2 01 97 81 ec a2 61 d1
5296 f9 d8 ea 81 0a bc 2f 33
5297 47 7f 04 e3 64 81 11 be
5298 71 c2 48 82 1a d6 04 f4
5299 94 e7 4d 0b f5 11 d2 c1
5300 62 77 2e 81
5301</sourcecode>
5302 <t indent="0" pn="section-appendix.d.3-3">
5303 The following is an example revocation for an EDKEY zone:
5304 </t>
5305 <sourcecode name="" type="test-vectors" markers="false" pn="section-appendix.d.3-4">
5306Zone private key (d):
5307 5a f7 02 0e e1 91 60 32
5308 88 32 35 2b bc 6a 68 a8
5309 d7 1a 7c be 1b 92 99 69
5310 a7 c6 6d 41 5a 0d 8f 65
5311
5312Zone identifier (ztype|zkey):
5313 00 01 00 14 3c f4 b9 24
5314 03 20 22 f0 dc 50 58 14
5315 53 b8 5d 93 b0 47 b6 3d
5316 44 6c 58 45 cb 48 44 5d
5317 db 96 68 8f
5318
5319zTLD:
5320000G051WYJWJ80S04BRDRM2R2H9VGQCKP13VCFA4DHC4BJT88HEXQ5K8HW
5321
5322Difficulty (5 base difficulty + 2 epochs): 7
5323
5324Signed message:
5325 00 00 00 34 00 00 00 03
5326 00 05 ff 1c 57 35 42 bd
5327 00 01 00 14 3c f4 b9 24
5328 03 20 22 f0 dc 50 58 14
5329 53 b8 5d 93 b0 47 b6 3d
5330 44 6c 58 45 cb 48 44 5d
5331 db 96 68 8f
5332
5333Proof:
5334 00 05 ff 1c 57 35 42 bd
5335 00 00 39 5d 18 27 c0 00
5336 58 4c 93 3c b0 99 2a 08
5337 58 4c 93 3c b0 99 2d f7
5338 58 4c 93 3c b0 99 2e 21
5339 58 4c 93 3c b0 99 2e 2a
5340 58 4c 93 3c b0 99 2e 53
5341 58 4c 93 3c b0 99 2e 8e
5342 58 4c 93 3c b0 99 2f 13
5343 58 4c 93 3c b0 99 2f 2d
5344 58 4c 93 3c b0 99 2f 3c
5345 58 4c 93 3c b0 99 2f 41
5346 58 4c 93 3c b0 99 2f fd
5347 58 4c 93 3c b0 99 30 33
5348 58 4c 93 3c b0 99 30 82
5349 58 4c 93 3c b0 99 30 a2
5350 58 4c 93 3c b0 99 30 e1
5351 58 4c 93 3c b0 99 31 ce
5352 58 4c 93 3c b0 99 31 de
5353 58 4c 93 3c b0 99 32 12
5354 58 4c 93 3c b0 99 32 4e
5355 58 4c 93 3c b0 99 32 9f
5356 58 4c 93 3c b0 99 33 31
5357 58 4c 93 3c b0 99 33 87
5358 58 4c 93 3c b0 99 33 8c
5359 58 4c 93 3c b0 99 33 e5
5360 58 4c 93 3c b0 99 33 f3
5361 58 4c 93 3c b0 99 34 26
5362 58 4c 93 3c b0 99 34 30
5363 58 4c 93 3c b0 99 34 68
5364 58 4c 93 3c b0 99 34 88
5365 58 4c 93 3c b0 99 34 8a
5366 58 4c 93 3c b0 99 35 4c
5367 58 4c 93 3c b0 99 35 bd
5368 00 01 00 14 3c f4 b9 24
5369 03 20 22 f0 dc 50 58 14
5370 53 b8 5d 93 b0 47 b6 3d
5371 44 6c 58 45 cb 48 44 5d
5372 db 96 68 8f 04 ae 26 f7
5373 63 56 5a b7 aa ab 01 71
5374 72 4f 3c a8 bc c5 1a 98
5375 b7 d4 c9 2e a3 3c d9 34
5376 4c a8 b6 3e 04 53 3a bf
5377 1a 3c 05 49 16 b3 68 2c
5378 5c a8 cb 4d d0 f8 4c 3b
5379 77 48 7a ac 6e ce 38 48
5380 0b a9 d5 00
5381</sourcecode>
5382 </section>
5383 </section>
5384 <section numbered="false" removeInRFC="false" toc="include" pn="section-appendix.e">
5385 <name slugifiedName="name-acknowledgements">Acknowledgements</name>
5386 <t indent="0" pn="section-appendix.e-1">
5387 The authors thank all reviewers for their comments. In particular,
5388 we thank <contact fullname="D. J. Bernstein"/>, <contact fullname="S. Bortzmeyer"/>, <contact fullname="A. Farrel"/>, <contact fullname="E. Lear"/>, and <contact fullname="R. Salz"/> for their
5389 insightful and detailed technical reviews. We thank <contact fullname="J. Yao"/> and <contact fullname="J. Klensin"/> for the
5390 internationalization reviews. We thank <contact fullname="Dr. J. Appelbaum"/> for suggesting the name "GNU Name System" and <contact fullname="Dr. Richard Stallman"/> for approving its use. We thank <contact fullname="T. Lange"/> and <contact fullname="M. Wachs"/> for their earlier contributions to the design and implementation of GNS. We thank NLnet and NGI DISCOVERY for funding
5391 work on the GNU Name System.
5392 </t>
5393 </section>
5394 <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.f">
5395 <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
5396 <author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach">
5397 <organization showOnFrontPage="true">Fraunhofer AISEC</organization>
5398 <address>
5399 <postal>
5400 <street>Lichtenbergstrasse 11</street>
5401 <city>Garching</city>
5402 <code>85748</code>
5403 <country>Germany</country>
5404 </postal>
5405 <email>martin.schanzenbach@aisec.fraunhofer.de</email>
5406 </address>
5407 </author>
5408 <author fullname="Christian Grothoff" initials="C." surname="Grothoff">
5409 <organization showOnFrontPage="true">Berner Fachhochschule</organization>
5410 <address>
5411 <postal>
5412 <street>Hoeheweg 80</street>
5413 <city>Biel/Bienne</city>
5414 <code>2501</code>
5415 <country>Switzerland</country>
5416 </postal>
5417 <email>christian.grothoff@bfh.ch</email>
5418 </address>
5419 </author>
5420 <author fullname="Bernd Fix" initials="B." surname="Fix">
5421 <organization showOnFrontPage="true">GNUnet e.V.</organization>
5422 <address>
5423 <postal>
5424 <street>Boltzmannstrasse 3</street>
5425 <city>Garching</city>
5426 <code>85748</code>
5427 <country>Germany</country>
5428 </postal>
5429 <email>fix@gnunet.org</email>
5430 </address>
5431 </author>
5432 </section>
5433 </back>
5434</rfc>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-13 09:45:02 +0000