rfc9498.original.xml   rfc9498.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="utf-8"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" cons
ensus="false" docName="draft-schanzen-gns-28" indexInclude="true" ipr="trust2009 <!DOCTYPE rfc [
02" prepTime="2023-07-06T12:50:00" scripts="Common,Latin" sortRefs="false" submi <!ENTITY nbsp "&#160;">
ssionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<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">
<!-- xml2rfc v2v3 conversion 2.26.0 --> <!-- xml2rfc v2v3 conversion 2.26.0 -->
<front> <front>
<title abbrev="The GNU Name System">The GNU Name System</title> <title abbrev="The GNU Name System">The GNU Name System</title>
<seriesInfo name="Internet-Draft" value="draft-schanzen-gns-28" stream="IETF "/> <seriesInfo name="RFC" value="9498"/>
<author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach"> <author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach">
<organization showOnFrontPage="true">Fraunhofer AISEC</organization> <organization>Fraunhofer AISEC</organization>
<address> <address>
<postal> <postal>
<street>Lichtenbergstrasse 11</street> <street>Lichtenbergstrasse 11</street>
<city>Garching</city> <city>Garching</city>
<code>85748</code> <code>85748</code>
<country>DE</country> <country>Germany</country>
</postal> </postal>
<email>martin.schanzenbach@aisec.fraunhofer.de</email> <email>martin.schanzenbach@aisec.fraunhofer.de</email>
</address> </address>
</author> </author>
<author fullname="Christian Grothoff" initials="C." surname="Grothoff"> <author fullname="Christian Grothoff" initials="C." surname="Grothoff">
<organization showOnFrontPage="true">Berner Fachhochschule</organization> <organization>Berner Fachhochschule</organization>
<address> <address>
<postal> <postal>
<street>Hoeheweg 80</street> <street>Hoeheweg 80</street>
<city>Biel/Bienne</city> <city>Biel/Bienne</city>
<code>2501</code> <code>2501</code>
<country>CH</country> <country>Switzerland</country>
</postal> </postal>
<email>christian.grothoff@bfh.ch</email> <email>christian.grothoff@bfh.ch</email>
</address> </address>
</author> </author>
<author fullname="Bernd Fix" initials="B." surname="Fix"> <author fullname="Bernd Fix" initials="B." surname="Fix">
<organization showOnFrontPage="true">GNUnet e.V.</organization> <organization>GNUnet e.V.</organization>
<address> <address>
<postal> <postal>
<street>Boltzmannstrasse 3</street> <street>Boltzmannstrasse 3</street>
<city>Garching</city> <city>Garching</city>
<code>85748</code> <code>85748</code>
<country>DE</country> <country>Germany</country>
</postal> </postal>
<email>fix@gnunet.org</email> <email>fix@gnunet.org</email>
</address> </address>
</author> </author>
<date day="06" month="07" year="2023"/> <date month="November" year="2023"/>
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Independent Stream</workgroup>
<keyword>name systems</keyword> <keyword>name systems</keyword>
<abstract pn="section-abstract">
<t indent="0" pn="section-abstract-1"> <abstract>
This document contains the GNU Name System (GNS) technical <t>
This document provides the GNU Name System (GNS) technical
specification. specification.
GNS is a decentralized and censorship-resistant domain name GNS is a decentralized and censorship-resistant domain name
resolution protocol that provides a privacy-enhancing alternative to the resolution protocol that provides a privacy-enhancing alternative to the
Domain Name System (DNS) protocols. Domain Name System (DNS) protocols.
</t> </t>
<t indent="0" pn="section-abstract-2"> <t>
This document defines the normative wire format of resource records, This document defines the normative wire format of resource records,
resolution processes, cryptographic routines and security resolution processes, cryptographic routines, and security and privacy
considerations for use by implementers. considerations for use by implementers.
</t> </t>
<t indent="0" pn="section-abstract-3"> <t>
This specification was developed outside the IETF and does not have This specification was developed outside the IETF and does not have
IETF consensus. It is published here to inform readers about the IETF consensus. It is published here to inform readers about the
function of GNS, guide future GNS implementations, and ensure function of GNS, guide future GNS implementations, and ensure
interoperability among implementations including with the pre-existing interoperability among implementations (for example, pre-existing
GNUnet implementation. GNUnet implementations).
</t> </t>
</abstract> </abstract>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
>
<t indent="0" pn="section-boilerplate.1-1">
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
</t>
<t indent="0" pn="section-boilerplate.1-2">
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF). Note that other groups may also distribute working
documents as Internet-Drafts. The list of current Internet-Drafts is
at <eref target="https://datatracker.ietf.org/drafts/current/" brackets=
"none"/>.
</t>
<t indent="0" pn="section-boilerplate.1-3">
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
</t>
<t indent="0" pn="section-boilerplate.1-4">
This Internet-Draft will expire on 7 January 2024.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-introduction">
Introduction</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.1.2">
<li pn="section-toc.1-1.1.2.1">
<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-re
quirements-notation">Requirements Notation</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref der
ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-terminology">T
erminology</xref></t>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-overview">Overview</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.3.2">
<li pn="section-toc.1-1.3.2.1">
<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 derived
Content="" format="title" sectionFormat="of" target="name-names-and-zones">Names
and Zones</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2">
<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 derived
Content="" format="title" sectionFormat="of" target="name-publishing-binding-inf
ormat">Publishing Binding Information</xref></t>
</li>
<li pn="section-toc.1-1.3.2.3">
<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 derived
Content="" format="title" sectionFormat="of" target="name-resolving-names">Resol
ving Names</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-zones">Zones</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<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 derived
Content="" format="title" sectionFormat="of" target="name-zone-top-level-domain"
>Zone Top-Level Domain</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2">
<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 derived
Content="" format="title" sectionFormat="of" target="name-zone-revocation">Zone
Revocation</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-resource-records">Resource Records
</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.5.2">
<li pn="section-toc.1-1.5.2.1">
<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 derived
Content="" format="title" sectionFormat="of" target="name-zone-delegation-record
s">Zone Delegation Records</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.5.2.1.2">
<li pn="section-toc.1-1.5.2.1.2.1">
<t indent="0" pn="section-toc.1-1.5.2.1.2.1.1"><xref derived
Content="5.1.1" format="counter" sectionFormat="of" target="section-5.1.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-pkey">PKEY
</xref></t>
</li>
<li pn="section-toc.1-1.5.2.1.2.2">
<t indent="0" pn="section-toc.1-1.5.2.1.2.2.1"><xref derived
Content="5.1.2" format="counter" sectionFormat="of" target="section-5.1.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-edkey">EDK
EY</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5.2.2">
<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 derived
Content="" format="title" sectionFormat="of" target="name-redirection-records">R
edirection Records</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.5.2.2.2">
<li pn="section-toc.1-1.5.2.2.2.1">
<t indent="0" pn="section-toc.1-1.5.2.2.2.1.1"><xref derived
Content="5.2.1" format="counter" sectionFormat="of" target="section-5.2.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-redirect">
REDIRECT</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2.2.2">
<t indent="0" pn="section-toc.1-1.5.2.2.2.2.1"><xref derived
Content="5.2.2" format="counter" sectionFormat="of" target="section-5.2.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-gns2dns">G
NS2DNS</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5.2.3">
<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 derived
Content="" format="title" sectionFormat="of" target="name-auxiliary-records">Aux
iliary Records</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.5.2.3.2">
<li pn="section-toc.1-1.5.2.3.2.1">
<t indent="0" pn="section-toc.1-1.5.2.3.2.1.1"><xref derived
Content="5.3.1" format="counter" sectionFormat="of" target="section-5.3.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-leho">LEHO
</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3.2.2">
<t indent="0" pn="section-toc.1-1.5.2.3.2.2.1"><xref derived
Content="5.3.2" format="counter" sectionFormat="of" target="section-5.3.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-nick">NICK
</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3.2.3">
<t indent="0" pn="section-toc.1-1.5.2.3.2.3.1"><xref derived
Content="5.3.3" format="counter" sectionFormat="of" target="section-5.3.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-box">BOX</
xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-record-encoding-for-remote-">Recor
d Encoding for Remote Storage</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<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 derived
Content="" format="title" sectionFormat="of" target="name-the-storage-key">The S
torage Key</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2">
<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 derived
Content="" format="title" sectionFormat="of" target="name-plaintext-record-data-
rdata">Plaintext Record Data (RDATA)</xref></t>
</li>
<li pn="section-toc.1-1.6.2.3">
<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 derived
Content="" format="title" sectionFormat="of" target="name-the-resource-records-b
lock">The Resource Records Block</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-name-resolution">Name Resolution</
xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.7.2">
<li pn="section-toc.1-1.7.2.1">
<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 derived
Content="" format="title" sectionFormat="of" target="name-start-zones">Start Zon
es</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2">
<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 derived
Content="" format="title" sectionFormat="of" target="name-recursion">Recursion</
xref></t>
</li>
<li pn="section-toc.1-1.7.2.3">
<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 derived
Content="" format="title" sectionFormat="of" target="name-record-processing">Rec
ord Processing</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.7.2.3.2">
<li pn="section-toc.1-1.7.2.3.2.1">
<t indent="0" pn="section-toc.1-1.7.2.3.2.1.1"><xref derived
Content="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>
</li>
<li pn="section-toc.1-1.7.2.3.2.2">
<t indent="0" pn="section-toc.1-1.7.2.3.2.2.1"><xref derived
Content="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>
</li>
<li pn="section-toc.1-1.7.2.3.2.3">
<t indent="0" pn="section-toc.1-1.7.2.3.2.3.1"><xref derived
Content="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>
</li>
<li pn="section-toc.1-1.7.2.3.2.4">
<t indent="0" pn="section-toc.1-1.7.2.3.2.4.1"><xref derived
Content="7.3.4" format="counter" sectionFormat="of" target="section-7.3.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-zone-deleg
ation-records-2">Zone Delegation Records</xref></t>
</li>
<li pn="section-toc.1-1.7.2.3.2.5">
<t indent="0" pn="section-toc.1-1.7.2.3.2.5.1"><xref derived
Content="7.3.5" format="counter" sectionFormat="of" target="section-7.3.5"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-nick-2">NI
CK</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-internationalization-and-ch">Inter
nationalization and Character Encoding</xref></t>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-security-and-privacy-consid">Secur
ity and Privacy Considerations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.9.2">
<li pn="section-toc.1-1.9.2.1">
<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 derived
Content="" format="title" sectionFormat="of" target="name-availability">Availabi
lity</xref></t>
</li>
<li pn="section-toc.1-1.9.2.2">
<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 derived
Content="" format="title" sectionFormat="of" target="name-agility">Agility</xref
></t>
</li>
<li pn="section-toc.1-1.9.2.3">
<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 derived
Content="" format="title" sectionFormat="of" target="name-cryptography">Cryptogr
aphy</xref></t>
</li>
<li pn="section-toc.1-1.9.2.4">
<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 derived
Content="" format="title" sectionFormat="of" target="name-abuse-mitigation">Abus
e Mitigation</xref></t>
</li>
<li pn="section-toc.1-1.9.2.5">
<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 derived
Content="" format="title" sectionFormat="of" target="name-zone-management">Zone
Management</xref></t>
</li>
<li pn="section-toc.1-1.9.2.6">
<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 derived
Content="" format="title" sectionFormat="of" target="name-dhts-as-remote-storage
">DHTs as Remote Storage</xref></t>
</li>
<li pn="section-toc.1-1.9.2.7">
<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 derived
Content="" format="title" sectionFormat="of" target="name-revocations">Revocatio
ns</xref></t>
</li>
<li pn="section-toc.1-1.9.2.8">
<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 derived
Content="" format="title" sectionFormat="of" target="name-zone-privacy">Zone Pri
vacy</xref></t>
</li>
<li pn="section-toc.1-1.9.2.9">
<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 derived
Content="" format="title" sectionFormat="of" target="name-zone-governance">Zone
Governance</xref></t>
</li>
<li pn="section-toc.1-1.9.2.10">
<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 deriv
edContent="" format="title" sectionFormat="of" target="name-namespace-ambiguity"
>Namespace Ambiguity</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" fo
rmat="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-gana-considerations">GANA Consid
erations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.10.2">
<li pn="section-toc.1-1.10.2.1">
<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 deri
vedContent="" format="title" sectionFormat="of" target="name-gns-record-types-re
gistry">GNS Record Types Registry</xref></t>
</li>
<li pn="section-toc.1-1.10.2.2">
<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 deri
vedContent="" format="title" sectionFormat="of" target="name-alt-subdomains-regi
stry">.alt Subdomains Registry</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" fo
rmat="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-iana-considerations">IANA Consid
erations</xref></t>
</li>
<li pn="section-toc.1-1.12">
<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" fo
rmat="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-implementation-and-deployme">Imp
lementation and Deployment Status</xref></t>
</li>
<li pn="section-toc.1-1.13">
<t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="13" fo
rmat="counter" sectionFormat="of" target="section-13"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgemen
ts</xref></t>
</li>
<li pn="section-toc.1-1.14">
<t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="14" fo
rmat="counter" sectionFormat="of" target="section-14"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-normative-references">Normative
References</xref></t>
</li>
<li pn="section-toc.1-1.15">
<t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="15" fo
rmat="counter" sectionFormat="of" target="section-15"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-informative-references">Informat
ive References</xref></t>
</li>
<li pn="section-toc.1-1.16">
<t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="Append
ix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-usage-and-migra
tion">Usage and Migration</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.16.2">
<li pn="section-toc.1-1.16.2.1">
<t indent="0" pn="section-toc.1-1.16.2.1.1"><xref derivedContent
="A.1" format="counter" sectionFormat="of" target="section-a.1"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-zone-dissemination">Z
one Dissemination</xref></t>
</li>
<li pn="section-toc.1-1.16.2.2">
<t indent="0" pn="section-toc.1-1.16.2.2.1"><xref derivedContent
="A.2" format="counter" sectionFormat="of" target="section-a.2"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-start-zone-configurat
ion">Start Zone Configuration</xref></t>
</li>
<li pn="section-toc.1-1.16.2.3">
<t indent="0" pn="section-toc.1-1.16.2.3.1"><xref derivedContent
="A.3" format="counter" sectionFormat="of" target="section-a.3"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-globally-unique-names
-and-t">Globally Unique Names and the Web</xref></t>
</li>
<li pn="section-toc.1-1.16.2.4">
<t indent="0" pn="section-toc.1-1.16.2.4.1"><xref derivedContent
="A.4" format="counter" sectionFormat="of" target="section-a.4"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-migration-paths">Migr
ation Paths</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.17">
<t indent="0" pn="section-toc.1-1.17.1"><xref derivedContent="Append
ix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-example-flows">
Example flows</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.17.2">
<li pn="section-toc.1-1.17.2.1">
<t indent="0" pn="section-toc.1-1.17.2.1.1"><xref derivedContent
="B.1" format="counter" sectionFormat="of" target="section-b.1"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-aaaa-example-resoluti
on">AAAA Example Resolution</xref></t>
</li>
<li pn="section-toc.1-1.17.2.2">
<t indent="0" pn="section-toc.1-1.17.2.2.1"><xref derivedContent
="B.2" format="counter" sectionFormat="of" target="section-b.2"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-redirect-example-reso
lution">REDIRECT Example Resolution</xref></t>
</li>
<li pn="section-toc.1-1.17.2.3">
<t indent="0" pn="section-toc.1-1.17.2.3.1"><xref derivedContent
="B.3" format="counter" sectionFormat="of" target="section-b.3"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-gns2dns-example-resol
ution">GNS2DNS Example Resolution</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.18">
<t indent="0" pn="section-toc.1-1.18.1"><xref derivedContent="Append
ix C" format="default" sectionFormat="of" target="section-appendix.c"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-base32gns">Base
32GNS</xref></t>
</li>
<li pn="section-toc.1-1.19">
<t indent="0" pn="section-toc.1-1.19.1"><xref derivedContent="Append
ix D" format="default" sectionFormat="of" target="section-appendix.d"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-test-vectors">T
est Vectors</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.19.2">
<li pn="section-toc.1-1.19.2.1">
<t indent="0" pn="section-toc.1-1.19.2.1.1"><xref derivedContent
="D.1" format="counter" sectionFormat="of" target="section-d.1"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-base32gns-en-decoding
">Base32GNS en-/decoding</xref></t>
</li>
<li pn="section-toc.1-1.19.2.2">
<t indent="0" pn="section-toc.1-1.19.2.2.1"><xref derivedContent
="D.2" format="counter" sectionFormat="of" target="section-d.2"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-record-sets">Record s
ets</xref></t>
</li>
<li pn="section-toc.1-1.19.2.3">
<t indent="0" pn="section-toc.1-1.19.2.3.1"><xref derivedContent
="D.3" format="counter" sectionFormat="of" target="section-d.3"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-zone-revocation-2">Zo
ne revocation</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.20">
<t indent="0" pn="section-toc.1-1.20.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.e"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="include" removeInRFC="fa <section anchor="introduction">
lse" pn="section-1"> <name>Introduction</name>
<name slugifiedName="name-introduction">Introduction</name> <t>
<t indent="0" pn="section-1-1">
This specification describes the GNU Name System (GNS), a This specification describes the GNU Name System (GNS), a
censorship-resistant, privacy-preserving and decentralized censorship-resistant, privacy-preserving, and decentralized
domain name resolution protocol. GNS cryptographically secures domain name resolution protocol. GNS cryptographically secures
the binding of names to arbitrary tokens, enabling it to double the binding of names to arbitrary tokens, enabling it to double
in some respects as an alternative to some of today's public in some respects as an alternative to some of today's public
key infrastructures. key infrastructures.
</t> </t>
<t indent="0" pn="section-1-2"> <t>
In the terminology of the Domain Name System (DNS) <xref target="RFC1035" Per Domain Name System (DNS) terminology <xref target="RFC1035"/>, GNS ro
format="default" sectionFormat="of" derivedContent="RFC1035"/>, GNS roughly fol ughly follows the idea of a local
lows the idea of a local root zone deployment (see <xref target="RFC8806"/>), with the
root zone deployment (see <xref target="RFC8806" format="default" section
Format="of" derivedContent="RFC8806"/>), with the
difference that the design encourages alternative roots and difference that the design encourages alternative roots and
does not expect all deployments to use the same or any specific does not expect all deployments to use the same or any specific
root zone. In the GNS reference implementation, users can root zone. In the GNS reference implementation, users can
autonomously and freely delegate control of names to zones autonomously and freely delegate control of names to zones
through their local configurations. through their local configurations.
GNS expects each user to be in control of their setup. GNS expects each user to be in control of their setup.
By following <xref target="namespace_ambiguity" format="default" sectionF ormat="of" derivedContent="Section 9.10"/> guidelines, By following the guidelines in <xref target="namespace_ambiguity"/>,
users should manage to avoid any confusion as to how names are users should manage to avoid any confusion as to how names are
resolved. resolved.
</t> </t>
<t indent="0" pn="section-1-3"> <t>
Name resolution and zone dissemination is based on the Name resolution and zone dissemination are based on the
principle of a petname system where users can assign local principle of a petname system where users can assign local
names to zones. The GNS has its roots in ideas from the Simple names to zones. The GNS has its roots in ideas from the Simple
Distributed Security Infrastructure <xref target="SDSI" format="default" sectionFormat="of" derivedContent="SDSI"/>, Distributed Security Infrastructure <xref target="SDSI"/>,
enabling the decentralized mapping of secure identifiers to enabling the decentralized mapping of secure identifiers to
memorable names. A first academic description of the memorable names. One of the first academic descriptions of the
cryptographic ideas behind GNS can be found in <xref target="GNS" format= cryptographic ideas behind GNS can be found in <xref target="GNS"/>.
"default" sectionFormat="of" derivedContent="GNS"/>.
</t> </t>
<t indent="0" pn="section-1-4"> <t>
This document defines the normative wire format of resource This document defines the normative wire format of resource
records, resolution processes, cryptographic routines and records, resolution processes, cryptographic routines, and
security considerations for use by implementers. security and privacy considerations for use by implementers.
</t>
<t indent="0" pn="section-1-5">
This specification was developed outside the IETF and does not have
IETF consensus. It is published here to guide implementers of GNS
and to ensure interoperability among implementations.
</t> </t>
<section numbered="true" toc="include" removeInRFC="false" pn="section-1.1 <section>
"> <name>Requirements Notation</name>
<name slugifiedName="name-requirements-notation">Requirements Notation</ <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
name> "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
<t indent="0" pn="section-1.1-1"> "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "<bcp14>SHOULD NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" deriv are to be interpreted as described in BCP&nbsp;14
edContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>
when, they appear in all capitals, as shown here.
</t>
</section> </section>
</section> </section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-2"> <section>
<name slugifiedName="name-terminology">Terminology</name> <name>Terminology</name>
<dl indent="3" newline="false" spacing="normal" pn="section-2-1"> <dl newline="false">
<dt pn="section-2-1.1">Apex Label</dt> <dt>Apex Label:</dt>
<dd pn="section-2-1.2"> <dd>
This type of label is used to publish resource This type of label is used to publish resource
records in a zone that can be resolved without providing a specific records in a zone that can be resolved without providing a specific
label. It is the GNS method to provide what is the "zone apex" in DNS label. It is the GNS method for providing what is called the "zone apex
<xref target="RFC4033" format="default" sectionFormat="of" derivedConte " in DNS
nt="RFC4033"/>. <xref target="RFC4033"/>.
The apex label is represented using the character U+0040 ("@" without The apex label is represented using the character U+0040 ("@" without t
the quotes). he quotes).
</dd> </dd>
<dt pn="section-2-1.3">Application</dt> <dt>Application:</dt>
<dd pn="section-2-1.4"> <dd>
A component which uses a GNS implementation An application is a component that uses a GNS implementation
to resolve names into records and processes its contents. to resolve names into records and processes its contents.
</dd> </dd>
<dt pn="section-2-1.5">Blinded Zone Key</dt> <dt>Blinded Zone Key:</dt>
<dd pn="section-2-1.6"> <dd>
Key derived from a zone key and a label. A blinded zone key is a key derived from a zone key and a label.
The zone key and any blinded zone key derived from it are unlinkable The zone key and any blinded zone key derived from it are unlinkable
without knowledge of the specific label used for the derivation. without knowledge of the specific label used for the derivation.
</dd> </dd>
<dt pn="section-2-1.7">Extension Label</dt> <dt>Extension Label:</dt>
<dd pn="section-2-1.8"> <dd>
This type of label is used to refer to the authoritative zone that the record is in. This type of label is used to refer to the authoritative zone that the record is in.
The primary use for the extension label is in redirections where the re direction The primary use for the extension label is in redirections where the re direction
target is defined relative to the authoritative zone of the redirection target is defined relative to the authoritative zone of the redirection
record (see <xref target="gnsrecords_redirect" format="default" section record (see <xref target="gnsrecords_redirect"/>).
Format="of" derivedContent="Section 5.2"/>). The extension label is represented using the character U+002B ("+" with
The extension label is represented using the character U+002B ("+" out the quotes).
without the quotes).
</dd> </dd>
<dt pn="section-2-1.9">Label Separator</dt> <dt>Label Separator:</dt>
<dd pn="section-2-1.10"> <dd>
Labels in a name are separated using the label separator U+002E Labels in a name are separated using the label separator U+002E
("." without the quotes). ("." without the quotes).
In GNS, with the exceptions of zone Top-Level Domains In GNS, except for zone Top-Level Domains (zTLDs)
(see below) and boxed records (see <xref target="gnsrecords_box" format (see below) and boxed records (see <xref target="gnsrecords_box"/>),
="default" sectionFormat="of" derivedContent="Section 5.3.3"/>),
every label separator in a name indicates delegation to another zone. every label separator in a name indicates delegation to another zone.
</dd> </dd>
<dt pn="section-2-1.11">Label</dt> <dt>Label:</dt>
<dd pn="section-2-1.12"> <dd>
A GNS label is a label as defined in <xref target="RFC8499" format="def A GNS label is a label as defined in <xref target="RFC8499"/>.
ault" sectionFormat="of" derivedContent="RFC8499"/>.
Labels are UTF-8 strings in Unicode Labels are UTF-8 strings in Unicode
Normalization Form C (NFC) <xref target="Unicode-UAX15" format="default " sectionFormat="of" derivedContent="Unicode-UAX15"/>. Normalization Form C (NFC) <xref target="Unicode-UAX15"/>.
The apex label and the extension label have The apex label and the extension label have
special purposes in the resolution protocol which are defined special purposes in the resolution protocol that are defined
in the rest of the document. in the rest of this document.
Zone administrators <bcp14>MAY</bcp14> disallow certain labels that Zone administrators <bcp14>MAY</bcp14> disallow certain labels that
might be easily confused with other labels through registration policie s might be easily confused with other labels through registration policie s
(see also <xref target="security_abuse" format="default" sectionFormat= "of" derivedContent="Section 9.4"/>). (see also <xref target="security_abuse"/>).
</dd> </dd>
<dt pn="section-2-1.13">Name</dt> <dt>Name:</dt>
<dd pn="section-2-1.14"> <dd>
A name in GNS is a domain name as defined in <xref target="RFC8499" fo A name in GNS is a domain name as defined in <xref target="RFC8499"/>:
rmat="default" sectionFormat="of" derivedContent="RFC8499"/>: names are UTF-8 strings <xref target="RFC3629"/> consisting of an
Names are UTF-8 <xref target="RFC3629" format="default" sectionFormat="
of" derivedContent="RFC3629"/> strings consisting of an
ordered list of labels concatenated with a label separator. ordered list of labels concatenated with a label separator.
Names are resolved starting from the rightmost label. Names are resolved starting from the rightmost label.
GNS does not impose length restrictions on names or labels. GNS does not impose length restrictions on names or labels.
However, applications <bcp14>MAY</bcp14> ensure that name and label len gths are However, applications <bcp14>MAY</bcp14> ensure that name and label len gths are
compatible with DNS and in particular IDNA <xref target="RFC5890" forma compatible with DNS and, in particular, Internationalized Domain Names
t="default" sectionFormat="of" derivedContent="RFC5890"/>. for
In the spirit of <xref target="RFC5895" format="default" sectionFormat= Applications (IDNA) <xref target="RFC5890"/>.
"of" derivedContent="RFC5895"/>, applications <bcp14>MAY</bcp14> preprocess In the spirit of <xref target="RFC5895"/>, applications <bcp14>MAY</bcp
14> preprocess
names and labels to ensure compatibility with DNS or support names and labels to ensure compatibility with DNS or support
specific user expectations, for example according to specific user expectations -- for example, according to
<xref target="Unicode-UTS46" format="default" sectionFormat="of" derive <xref target="Unicode-UTS46"/>.
dContent="Unicode-UTS46"/>. A GNS name may be indistinguishable from a DNS name, and care must
A GNS name may be indistinguishable from a DNS name and care must be taken by applications and implementers when handling GNS names
be taken by applications and implementors when handling GNS names (see <xref target="namespace_ambiguity"/>).
(see <xref target="namespace_ambiguity" format="default" sectionFormat=
"of" derivedContent="Section 9.10"/>).
In order to avoid misinterpretation of example domains with (reserved) In order to avoid misinterpretation of example domains with (reserved)
DNS domains this draft uses the suffix ".gns.alt" in examples which DNS domains, this document uses the suffix ".gns.alt" in compliance wit
is also registered in the GANA ".alt Subdomains" registry h
<xref target="GANA" format="default" sectionFormat="of" derivedContent= <xref target="RFC9476"/>. &nbsp;".gns.alt" is also registered in the GA
"GANA"/> (see also <xref target="I-D.ietf-dnsop-alt-tld" format="default" sectio NA ".alt Subdomains" registry
nFormat="of" derivedContent="I-D.ietf-dnsop-alt-tld"/>). <xref target="GANA"/>.
</dd> </dd>
<dt pn="section-2-1.15">Resolver</dt> <dt>Resolver:</dt>
<dd pn="section-2-1.16"> <dd>
The component of a GNS implementation which provides In this document, a resolver is the component of a GNS implementation t
hat provides
the recursive name resolution logic defined in the recursive name resolution logic defined in
<xref target="resolution" format="default" sectionFormat="of" derivedCo ntent="Section 7"/>. <xref target="resolution"/>.
</dd> </dd>
<dt pn="section-2-1.17">Resource Record</dt> <dt>Resource Record:</dt>
<dd pn="section-2-1.18"> <dd>
A GNS resource record is the information associated with a label in a A GNS resource record is the information associated with a label in a
GNS zone. GNS zone.
A GNS resource record contains information as defined by its A GNS resource record contains information as defined by its
resource record type. resource record type.
</dd> </dd>
<dt pn="section-2-1.19">Start Zone</dt> <dt>Start Zone:</dt>
<dd pn="section-2-1.20"> <dd>
In order to resolve any given GNS name an initial start zone must be In order to resolve any given GNS name, an initial Start Zone must be
determined for this name. determined for this name.
The start zone can be explicitly defined as part of the name using a The Start Zone can be explicitly defined as part of the name using a
zone Top-Level Domain (zTLD). zTLD.
Otherwise, it is determined through a local suffix-to-zone mapping Otherwise, it is determined through a local suffix-to-zone mapping
(see <xref target="governance" format="default" sectionFormat="of" deri vedContent="Section 7.1"/>). (see <xref target="governance"/>).
</dd> </dd>
<dt pn="section-2-1.21">Top-Level Domain</dt> <dt>Top-Level Domain (TLD):</dt>
<dd pn="section-2-1.22"> <dd>
The rightmost part of a GNS name is a GNS Top-Level Domain (TLD). The rightmost part of a GNS name is a GNS TLD.
A GNS TLD can consist of one or more labels. A GNS TLD can consist of one or more labels.
Unlike DNS Top-Level Domains (defined in <xref target="RFC8499" format=" default" sectionFormat="of" derivedContent="RFC8499"/>), Unlike DNS TLDs (defined in <xref target="RFC8499"/>),
GNS does not expect all users to use the same global root zone. Instead, GNS does not expect all users to use the same global root zone. Instead,
with the exception of Zone Top-Level Domains (see <xref target="zTLD" f ormat="default" sectionFormat="of" derivedContent="Section 4.1"/>), with the exception of zTLDs (see <xref target="zTLD"/>),
GNS TLDs are typically part of the configuration of the local resolver GNS TLDs are typically part of the configuration of the local resolver
(see <xref target="governance" format="default" sectionFormat="of" deri vedContent="Section 7.1"/>), and might thus not be globally unique. (see <xref target="governance"/>) and thus might not be globally unique .
</dd> </dd>
<dt pn="section-2-1.23">Zone</dt> <dt>Zone:</dt>
<dd pn="section-2-1.24"> <dd>
A GNS zone contains authoritative information (resource records). A GNS zone contains authoritative information (resource records).
A zone is uniquely identified by its zone key. Unlike DNS zones, A zone is uniquely identified by its zone key. Unlike DNS zones,
a GNS zone does not need to have a SOA record under the apex label. a GNS zone does not need to have an SOA record under the apex label.
</dd> </dd>
<dt pn="section-2-1.25">Zone Key</dt> <dt>Zone Key:</dt>
<dd pn="section-2-1.26"> <dd>
A key which uniquely identifies a zone. The zone key is a key that uniquely identifies a zone.
It is usually a public key of an asymmetric key pair. It is usually a public key of an asymmetric key pair.
However, the established technical term "public key" is misleading, However, the established technical term "public key" is misleading,
as in GNS a zone key may be a shared secret as in GNS a zone key may be a shared secret
that should not be disclosed to unauthorized parties. that should not be disclosed to unauthorized parties.
</dd> </dd>
<dt pn="section-2-1.27">Zone Key Derivation Function</dt> <dt>Zone Key Derivation Function:</dt>
<dd pn="section-2-1.28"> <dd>
The zone key derivation function (ZKDF) blinds a zone key using a label . The zone key derivation function (ZKDF) blinds a zone key using a label .
</dd> </dd>
<dt pn="section-2-1.29">Zone Master</dt> <dt>Zone Publisher:</dt>
<dd pn="section-2-1.30"> <dd>
The component of a GNS implementation which provides The zone publisher is the component of a GNS implementation that provid
es
local zone management and publication as defined in local zone management and publication as defined in
<xref target="publish" format="default" sectionFormat="of" derivedConte nt="Section 6"/>. <xref target="publish"/>.
</dd> </dd>
<dt pn="section-2-1.31">Zone Owner</dt> <dt>Zone Owner:</dt>
<dd pn="section-2-1.32"> <dd>
The holder of the secret (typically a private key) The zone owner is the holder of the secret (typically a private key),
that (together with a label and a value to sign) allows the creation of which (together with a label and a value to sign) allows the creation of
zone zone
signatures that can be validated against the respective blinded zone key . signatures that can be validated against the respective blinded zone key .
</dd> </dd>
<dt pn="section-2-1.33">Zone Top-Level Domain</dt> <dt>Zone Top-Level Domain (zTLD):</dt>
<dd pn="section-2-1.34"> <dd>
A GNS Zone Top-Level Domain (zTLD) is a sequence of GNS labels at A GNS zTLD is a sequence of GNS labels at
the end of a GNS name which encodes a zone type and the end of a GNS name. The zTLD encodes a zone type and
zone key of a zone (see <xref target="zTLD" format="default" sectionFor zone key of a zone (see <xref target="zTLD"/>).
mat="of" derivedContent="Section 4.1"/>).
Due to the statistical uniqueness of zone keys, zTLDs are also globally unique. Due to the statistical uniqueness of zone keys, zTLDs are also globally unique.
A zTLD label sequence can only be distinguished from ordinary TLD label sequences A zTLD label sequence can only be distinguished from ordinary TLD label sequences
by attempting to decode the labels into a zone type and zone key. by attempting to decode the labels into a zone type and zone key.
</dd> </dd>
<dt pn="section-2-1.35">Zone Type</dt> <dt>Zone Type:</dt>
<dd pn="section-2-1.36"> <dd>
The type of a GNS zone determines the cipher system and binary encoding The type of a GNS zone determines the cipher system and binary encoding
format of the zone key, blinded zone keys, and cryptographic signatures. format of the zone key, blinded zone keys, and cryptographic signatures.
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="overview" numbered="true" toc="include" removeInRFC="false" <section anchor="overview">
pn="section-3"> <name>Overview</name>
<name slugifiedName="name-overview">Overview</name> <t>
<t indent="0" pn="section-3-1">
GNS exhibits the three properties that are commonly used to describe GNS exhibits the three properties that are commonly used to describe
a petname system: a petname system:
</t> </t>
<ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-3-2" <dl newline="true">
> <dt>
<li pn="section-3-2.1" derivedCounter="1."> Global names through the concept of zTLDs:</dt><dd>As zones can be un
Global names through the concept of zone top-level iquely identified by their zone keys
domains (zTLDs): As zones can be uniquely identified by their zone ke
y
and are statistically unique, zTLDs are globally unique mappings to z ones. and are statistically unique, zTLDs are globally unique mappings to z ones.
Consequently, GNS domain names with a zTLD suffix are also globally u nique. Consequently, GNS domain names with a zTLD suffix are also globally u nique.
Names with zTLDs suffixes are not human-readable. Names with zTLD suffixes are not memorable.</dd>
</li> <dt>
<li pn="section-3-2.2" derivedCounter="2."> Memorable petnames for zones:</dt>
Memorable petnames for zones: <dd>Users can configure local, memorable references to zones.
Users can configure local, human-readable references to zones. Such petnames serve as zTLD monikers that provide
Such petnames serve as zTLD monikers which provide
convenient names for zones to the local operator. convenient names for zones to the local operator.
The petnames may also be published as suggestions for other The petnames may also be published as suggestions for other
users searching for good label to use when referencing the users searching for a good label to use when referencing the
respective zone. respective zone.</dd>
</li> <dt>
<li pn="section-3-2.3" derivedCounter="3."> A secure mapping from names to records:</dt>
A secure mapping from names to records: <dd>GNS allows zone owners to map labels to resource records or to
GNS allows zone owners to map labels to resource records or to
delegate authority of names in the subdomain induced by a label to ot her zones. delegate authority of names in the subdomain induced by a label to ot her zones.
Zone owners may choose to publish this information to make it Zone owners may choose to publish this information to make it
available to other users. available to other users.
Mappings are encrypted and signed Mappings are encrypted and signed
using keys derived from the respective label before being published t using keys derived from the respective label before being published i
o remote storage. n remote storage.
When names are resolved, signatures on resource records When names are resolved, signatures on resource records,
including delegations are verified by the recursive resolver. including delegations, are verified by the recursive resolver.</dd>
</li> </dl>
</ol> <t>
<t indent="0" pn="section-3-3">
In the remainder of this document, the "implementer" refers to the deve loper building In the remainder of this document, the "implementer" refers to the deve loper building
a GNS implementation including the resolver, zone master, and a GNS implementation that includes the resolver, zone publisher, and
supporting configuration such as start zones (see <xref target="governa supporting configuration such as Start Zones (see <xref target="governa
nce" format="default" sectionFormat="of" derivedContent="Section 7.1"/>). nce"/>).
</t> </t>
<section anchor="names" numbered="true" toc="include" removeInRFC="false" <section anchor="names">
pn="section-3.1"> <name>Names and Zones</name>
<name slugifiedName="name-names-and-zones">Names and Zones</name> <t>
<t indent="0" pn="section-3.1-1"> It follows from the above that GNS does not support names that are
It follows from the above that GNS does not support names which are simultaneously global, secure, and memorable.
simultaneously global, secure and human-readable. Instead, names are either global and not memorable or not globally
Instead, names are either global and not human-readable or not globally unique and memorable.
unique and human-readable.
An example for a global name pointing to the record "example" in An example for a global name pointing to the record "example" in
a zone is: a zone is as follows:
</t> </t>
<sourcecode markers="false" pn="section-3.1-2"> <sourcecode>
example.000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884 example.000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884
</sourcecode> </sourcecode>
<t indent="0" pn="section-3.1-3"> <t>
Now consider the case where a user locally configured the petname Now consider the case where a user locally configured the petname
"pet.gns.alt" for the zone with the "example" record of the name "pet.gns.alt" for the zone with the "example" record of the name
above. above.
The name "example.pet.gns.alt" would then point to the same record as t he The name "example.pet.gns.alt" would then point to the same record as t he
globally unique name above, but name resolution would only globally unique name above, but name resolution would only
work on the local system where the "pet.gns.alt" petname is work on the local system where the "pet.gns.alt" petname is
configured. configured.
</t> </t>
<t indent="0" pn="section-3.1-4"> <t>
The delegation of petnames and subsequent resolution of delegation The delegation of petnames and subsequent resolution of delegation
builds on ideas from the Simple Distributed Security Infrastructure build on ideas from the Simple Distributed Security Infrastructure
<xref target="SDSI" format="default" sectionFormat="of" derivedContent= <xref target="SDSI"/>.
"SDSI"/>.
In GNS, any user can create and manage any number of zones In GNS, any user can create and manage any number of zones
(see <xref target="zones" format="default" sectionFormat="of" derivedCo ntent="Section 4"/>) if their system provides a zone master implementation. (see <xref target="zones"/>) if their system provides a zone publisher implementation.
For each zone, the zone type determines the respective set of cryptogra phic operations For each zone, the zone type determines the respective set of cryptogra phic operations
and the wire formats for encrypted data, public keys and signatures. and the wire formats for encrypted data, public keys, and signatures.
A zone can be populated with mappings from labels to resource records A zone can be populated with mappings from labels to resource records
(see <xref target="rrecords" format="default" sectionFormat="of" derive (see <xref target="rrecords"/>) by its owner.
dContent="Section 5"/>) by its owner. A label can be mapped to a delegation record; this results in the
A label can be mapped to a delegation record which results in the
corresponding subdomain being delegated to another zone. Circular corresponding subdomain being delegated to another zone. Circular
delegations are explicitly allowed, including delegating a subdomain delegations are explicitly allowed, including delegating a subdomain
to its immediate parent zone. In to its immediate parent zone. In
order to support (legacy) applications as well as to facilitate the use order to support (legacy) applications as well as to facilitate the use
of petnames, GNS defines auxiliary record types in addition to of petnames, GNS defines auxiliary record types in addition to
supporting existing DNS records. supporting existing DNS records.
</t> </t>
</section> </section>
<section anchor="publishing" numbered="true" toc="include" removeInRFC="fa <section anchor="publishing">
lse" pn="section-3.2"> <name>Publishing Binding Information</name>
<name slugifiedName="name-publishing-binding-informat">Publishing Bindin <t>
g Information</name>
<t indent="0" pn="section-3.2-1">
Zone contents are encrypted and signed Zone contents are encrypted and signed
before being published in a remote key-value storage (see <xref target= before being published in remote key-value storage (see <xref target="p
"publish" format="default" sectionFormat="of" derivedContent="Section 6"/>) ublish"/>),
as illustrated in <xref target="figure_arch_publish" format="default" s as illustrated in <xref target="figure_arch_publish"/>.
ectionFormat="of" derivedContent="Figure 1"/>.
In this process, unique zone identification is hidden from the network In this process, unique zone identification is hidden from the network
through the use of key blinding. through the use of key blinding.
Key blinding allows the creation of signatures for zone contents Key blinding allows the creation of signatures for zone contents
using a blinded public/private key pair. using a blinded public/private key pair.
This blinding is realized using a deterministic key This blinding is realized using a deterministic key
derivation from derivation from
the original zone key and corresponding private key using record label values the original zone key and corresponding private key using record label values
as inputs from which blinding factors are derived. as inputs from which blinding factors are derived.
Specifically, the zone owner can derive blinded private keys for each r ecord Specifically, the zone owner can derive blinded private keys for each r ecord
set published under a label, and a set published under a label, and a
resolver can derive the corresponding blinded public keys. resolver can derive the corresponding blinded public keys.
It is expected that GNS implementations use decentralized remote It is expected that GNS implementations use decentralized remote
storages such as distributed hash tables (DHT) in order to facilitate storage entities, such as distributed hash tables (DHTs), in order to f acilitate
availability within a network without the need for dedicated infrastruc ture. availability within a network without the need for dedicated infrastruc ture.
Specification of such a distributed or decentralized storage is out of The specification of such a distributed or decentralized storage entity
scope of this document, but possible existing implementations include t is out of
hose scope for this document, but possible existing implementations include
based on <xref target="RFC7363" format="default" sectionFormat="of" der those
ivedContent="RFC7363"/>, <xref target="Kademlia" format="default" sectionFormat= based on <xref target="RFC7363"/>, <xref target="Kademlia"/>, or
"of" derivedContent="Kademlia"/> or <xref target="R5N"/>.
<xref target="R5N" format="default" sectionFormat="of" derivedContent="
R5N"/>.
</t> </t>
<figure anchor="figure_arch_publish" align="left" suppress-title="false" <figure anchor="figure_arch_publish">
pn="figure-1"> <name>An Example Diagram of Two Hosts Publishing GNS Zones</name>
<name slugifiedName="name-an-example-diagram-of-two-h">An example diag <artwork name="" type="" alt="">
ram of two hosts publishing GNS zones.</name> Host A | Remote | Host B
<artwork name="" type="" align="left" alt="" pn="section-3.2-2.1"> | Storage |
Host A | Remote | Host B | |
| Storage | | +---------+ |
| | | / /| |
| +---------+ | Publish | +---------+ | | Publish
| / /| | +-----------+ Records | | | | | Records +-----------+
Publish | +---------+ | | Publish | Zone |----------|-&gt;| Record | |&lt;-|----------| Zone |
+---------+ Records | | | | | Records +---------+ | Publisher | | | Storage | | | | Publisher |
| Zone |----------|-&gt;| Record | |&lt;-|----------| Zone | +-----------+ | | |/ | +-----------+
| Master | | | Storage | | | | Master | A | +---------+ | A
+---------+ | | |/ | +---------+ | | | |
A | +---------+ | A +---------+ | | +---------+
| | | | / | /| | | / | /|
+---------+ | | +---------+ +---------+ | | | +---------+ |
/ | /| | | / | /| | | | | | | | |
+---------+ | | | +---------+ | | Local | | | | | Local | |
| | | | | | | | | Zones | | | | | Zones | |
| Local | | | | | Local | | | |/ | | | |/
| Zones | | | | | Zones | | +---------+ | | +---------+
| |/ | | | |/
+---------+ | | +---------+
</artwork> </artwork>
</figure> </figure>
<t indent="0" pn="section-3.2-3"> <t>
A zone master implementation <bcp14>SHOULD</bcp14> be provided as A zone publisher implementation <bcp14>SHOULD</bcp14> be provided as
part of a GNS implementation to enable users to create and manage zones . part of a GNS implementation to enable users to create and manage zones .
If this functionality is not implemented, names can still be resolved If this functionality is not implemented, names can still be resolved
if zone keys for the initial step in the name resolution have been if zone keys for the initial step in the name resolution have been
configured (see <xref target="resolution" format="default" sectionForma t="of" derivedContent="Section 7"/>) or if the names end with a configured (see <xref target="resolution"/>) or if the names end with a
zTLD suffix. zTLD suffix.
</t> </t>
</section> </section>
<section anchor="resolving" numbered="true" toc="include" removeInRFC="fal <section anchor="resolving">
se" pn="section-3.3"> <name>Resolving Names</name>
<name slugifiedName="name-resolving-names">Resolving Names</name> <t>
<t indent="0" pn="section-3.3-1"> Applications use the resolver to look up GNS names.
Applications use the resolver to lookup GNS names. Starting from a configurable Start Zone, names are resolved by followin
Starting from a configurable start zone, names are resolved by followin g zone
g zone delegations recursively, as illustrated in <xref target="figure_arch_re
delegations recursively as illustrated in <xref target="figure_arch_res solv"/>.
olv" format="default" sectionFormat="of" derivedContent="Figure 2"/>.
For each label in a name, the recursive GNS resolver For each label in a name, the recursive GNS resolver
fetches the respective record set from the storage layer (see <xref tar get="resolution" format="default" sectionFormat="of" derivedContent="Section 7"/ >). fetches the respective record set from the storage layer (see <xref tar get="resolution"/>).
Without knowledge of the label values and the zone keys, the Without knowledge of the label values and the zone keys, the
different derived keys are unlinkable both to the original zone key and to each different derived keys are unlinkable to both the original zone key and each
other. other.
This prevents zone enumeration (except via expensive online brute This prevents zone enumeration (except via expensive online
force attacks): To confirm affiliation of a brute-force attacks): to confirm the affiliation of a
query or the corresponding encrypted record set with a query or the corresponding encrypted record set with a
specific zone requires knowledge of both the zone key and the label, specific zone requires knowledge of both the zone key and the label,
neither of which are disclosed to remote storage by the protocol. neither of which is disclosed to remote storage by the protocol.
At the same time, the blinded zone key and digital signatures At the same time, the blinded zone key and digital signatures
associated with each encrypted record set allow resolvers and oblivious remote associated with each encrypted record set allow resolvers and oblivious remote
storage to verify the integrity of the published information storage to verify the integrity of the published information
without disclosing anything about the originating zone or the record se ts. without disclosing anything about the originating zone or the record se ts.
</t> </t>
<figure anchor="figure_arch_resolv" align="left" suppress-title="false" <figure anchor="figure_arch_resolv">
pn="figure-2"> <name>High-Level View of the GNS Resolution Process</name>
<name slugifiedName="name-high-level-view-of-the-gns-">High-level view <artwork name="" type="" alt="">
of the GNS resolution process.</name>
<artwork name="" type="" align="left" alt="" pn="section-3.3-2.1">
Local Host | Remote Local Host | Remote
| Storage | Storage
| |
| +---------+ | +---------+
| / /| | / /|
| +---------+ | | +---------+ |
+-----------+ Name +----------+ Recursive | | | | +-----------+ Name +----------+ Recursive | | | |
| | Lookup | | Resolution | | Record | | | | Lookup | | Resolution | | Record | |
|Application|----------| Resolver |-------------|-&gt;| Storage | | |Application|---------&gt;| Resolver |-------------|-&gt;| Storage | |
| |&lt;---------| |&lt;------------|--| |/ | |&lt;---------| |&lt;------------|--| |/
+-----------+ Results +----------+ Intermediate| +---------+ +-----------+ Results +----------+ Intermediate| +---------+
A Results | A Results |
| | | |
+---------+ | +---------+ |
/ | /| | / | /| |
+---------+ | | +---------+ | |
| | | | | | | |
| Start | | | | Start | | |
| Zones | | | | Zones | | |
| |/ | | |/ |
+---------+ | +---------+ |
</artwork> </artwork>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="zones" numbered="true" toc="include" removeInRFC="false" pn <section anchor="zones">
="section-4"> <name>Zones</name>
<name slugifiedName="name-zones">Zones</name> <t>
<t indent="0" pn="section-4-1"> A zone in GNS is uniquely identified by its zone type (ztype) and zone ke
A zone in GNS is uniquely identified by its zone type and zone key. y.
Each zone can be referenced by its zone Top-Level Domain (zTLD) string Each zone can be referenced by its zTLD
(see <xref target="zTLD" format="default" sectionFormat="of" derivedConte (see <xref target="zTLD"/>), which is a string that encodes the zone type
nt="Section 4.1"/>) which encodes the zone type and zone key. and zone key.
A zone type (ztype) is a unique 32-bit number which corresponds to The ztype is a unique 32-bit number that corresponds to
a resource record type number identifying a delegation record type a resource record type number identifying a delegation record type
in the GANA "GNS Record Types" registry <xref target="GANA" format="defau lt" sectionFormat="of" derivedContent="GANA"/>. in the GANA "GNS Record Types" registry <xref target="GANA"/>.
The ztype is a unique identifier for the set cryptographic functions The ztype is a unique identifier for the set cryptographic functions
of the zone and the format of the delegation record type. of the zone and the format of the delegation record type.
Any ztype registration <bcp14>MUST</bcp14> define the following set of cr yptographic functions: Any ztype registration <bcp14>MUST</bcp14> define the following set of cr yptographic functions:
</t> </t>
<dl indent="3" newline="false" spacing="normal" pn="section-4-2"> <dl newline="true">
<dt pn="section-4-2.1">KeyGen() -&gt; d, zk</dt> <dt>KeyGen() -&gt; d, zkey</dt>
<dd pn="section-4-2.2"> <dd>
is a function to generate a new private key d and A function for generating a new private key d and
the corresponding public zone key zk. the corresponding public zone key zkey.
</dd> </dd>
<dt pn="section-4-2.3">ZKDF(zk,label) -&gt; zk'</dt> <dt>ZKDF(zkey, label) -&gt; zkey'</dt>
<dd pn="section-4-2.4"> <dd>
is a zone key derivation function which blinds a zone key zk A ZKDF that blinds a zone key zkey
using a label. zk and zk' must be unlinkable. Furthermore, using a label. &nbsp;zkey and zkey' must be unlinkable. Furthermore,
blinding zk with different values for the label must result blinding zkey with different values for the label must result
in different, unlinkable zk' values. in different, unlinkable zkey' values.
</dd> </dd>
<dt pn="section-4-2.5">S-Encrypt(zk,label,expiration,plaintext) -&gt; ci <dt>S-Encrypt(zkey, label, expiration, plaintext) -&gt; ciphertext</dt>
phertext</dt> <dd>
<dd pn="section-4-2.6"> A symmetric encryption function that encrypts the plaintext
is a symmetric encryption function which encrypts the plaintext to derive ciphertext based on key material derived from the zone key zk
to derive ciphertext based on key material derived from the zone key zk ey,
, a label, and an expiration timestamp.
a label and an expiration timestamp.
In order to leverage performance-enhancing caching features of certain In order to leverage performance-enhancing caching features of certain
underlying storages, in particular DHTs, a deterministic encryption underlying storage entities -- in particular, DHTs -- a deterministic e ncryption
scheme is recommended. scheme is recommended.
</dd> </dd>
<dt pn="section-4-2.7">S-Decrypt(zk,label,expiration,ciphertext) -&gt; p <dt>S-Decrypt(zkey, label, expiration, ciphertext) -&gt; plaintext</dt>
laintext</dt> <dd>
<dd pn="section-4-2.8"> A symmetric decryption function that decrypts the ciphertext
is a symmetric decryption function which decrypts the ciphertext
into plaintext based on key material derived from the zone key, into plaintext based on key material derived from the zone key,
a label, and an expiration timestamp. a label, and an expiration timestamp.
</dd> </dd>
<dt pn="section-4-2.9">Sign(d,message) -&gt; signature</dt> <dt>Sign(d, message) -&gt; signature</dt>
<dd pn="section-4-2.10"> <dd>
is a function to sign a message using the private A function for signing a message using the private
key d, yielding an unforgeable cryptographic signature. key d, yielding an unforgeable cryptographic signature.
In order to leverage performance-enhancing caching features of certain In order to leverage performance-enhancing caching features of certain
underlying storages, in particular DHTs, a deterministic signature underlying storage entities -- in particular, DHTs -- a deterministic s ignature
scheme is recommended. scheme is recommended.
</dd> </dd>
<dt pn="section-4-2.11">Verify(zk,message,signature) -&gt; boolean</dt> <dt>Verify(zkey, message, signature) -&gt; boolean</dt>
<dd pn="section-4-2.12"> <dd>
is a function to verify the signature was created using A function for verifying that the signature was created using
the private key d corresponding to the zone key zk the private key d corresponding to the zone key zkey
where d,zk := Keygen(). where d,zkey := KeyGen().
The function returns a boolean value of "TRUE" if the signature is vali The function returns a boolean value of "TRUE" if the signature is vali
d, d
and otherwise "FALSE". and "FALSE" otherwise.
</dd> </dd>
<dt pn="section-4-2.13">SignDerived(d,label,message) -&gt; signature</dt <dt>SignDerived(d, label, message) -&gt; signature</dt>
> <dd>
<dd pn="section-4-2.14"> A function for signing a message (typically encrypted record data) that
is a function to sign a message (typically encrypted record data) that can be verified using the derived zone key zkey' := ZKDF(zkey, label).
can be verified using the derived zone key zk' := ZKDF(zk,label).
In order to leverage performance-enhancing caching features of certain In order to leverage performance-enhancing caching features of certain
underlying storages, in particular DHTs, a deterministic signature underlying storage entities -- in particular, DHTs -- a deterministic s ignature
scheme is recommended. scheme is recommended.
</dd> </dd>
<dt pn="section-4-2.15">VerifyDerived(zk,label,message,signature) -&gt; <dt>VerifyDerived(zkey', message, signature) -&gt; boolean</dt>
boolean</dt> <dd>
<dd pn="section-4-2.16"> A function for verifying the signature using the derived zone key
is function to verify the signature using the derived zone key zkey' := ZKDF(zkey, label). The function returns a boolean value
zk' := ZKDF(zk,label). of "TRUE" if the signature is valid and "FALSE" otherwise. Depending
The function returns a boolean value of "TRUE" if the signature is vali on the signature scheme used, this function can be identical to
d, the Verify() function.
and otherwise "FALSE".
</dd> </dd>
</dl> </dl>
<t indent="0" pn="section-4-3"> <t>
The cryptographic functions of the default ztypes are specified with The cryptographic functions of the default ztypes are specified with
their corresponding delegation records in <xref target="gnsrecords_delega tion" format="default" sectionFormat="of" derivedContent="Section 5.1"/>. their corresponding delegation records as discussed in <xref target="gnsr ecords_delegation"/>.
In order to support cryptographic agility, additional ztypes <bcp14>MAY</ bcp14> In order to support cryptographic agility, additional ztypes <bcp14>MAY</ bcp14>
be defined in the future which replace or update the default ztypes defin ed in this be defined in the future that replace or update the default ztypes define d in this
document. document.
All ztypes <bcp14>MUST</bcp14> be registered as dedicated zone delegation All ztypes <bcp14>MUST</bcp14> be registered as dedicated zone delegation
record types in the GANA "GNS Record Types" registry (see <xref target="G record types in the GANA "GNS Record Types" registry (see <xref target="G
ANA" format="default" sectionFormat="of" derivedContent="GANA"/>). ANA"/>).
When defining new record types the cryptographic security considerations When defining new record types, the cryptographic security considerations
of this document apply, in particular <xref target="security_cryptography of this document -- in particular, <xref target="security_cryptography"/>
" format="default" sectionFormat="of" derivedContent="Section 9.3"/>. -- apply.
</t> </t>
<section anchor="zTLD" numbered="true" toc="include" removeInRFC="false" p <section anchor="zTLD">
n="section-4.1"> <name>Zone Top-Level Domain (zTLD)</name>
<name slugifiedName="name-zone-top-level-domain">Zone Top-Level Domain</ <t>
name> A zTLD is a string that encodes the
<t indent="0" pn="section-4.1-1">
A zone Top-Level Domain (zTLD) is a string which encodes the
zone type and zone key into a domain name suffix. zone type and zone key into a domain name suffix.
A zTLD is used as a globally unique references to a A zTLD is used as a globally unique reference to a
zone in the process of name resolution. zone in the process of name resolution.
It is created by encoding a binary concatenation of the zone type and It is created by encoding a binary concatenation of the zone type and
zone key (see <xref target="figure_zid" format="default" sectionFormat= "of" derivedContent="Figure 3"/>). zone key (see <xref target="figure_zid"/>).
The used encoding is a variation of the Crockford Base32 encoding The used encoding is a variation of the Crockford Base32 encoding
<xref target="CrockfordB32" format="default" sectionFormat="of" derived <xref target="CrockfordB32"/> called Base32GNS.
Content="CrockfordB32"/> called Base32GNS. The encoding and decoding symbols for Base32GNS, including this
The encoding and decoding symbols for Base32GNS including this variation, are defined in <xref target="CrockfordB32Encode"/>, found in
modification are defined in <xref target="CrockfordB32Encode" format="d <xref target="app-c"/>.
efault" sectionFormat="of" derivedContent="Figure 30"/>. The functions for encoding and decoding based on <xref target="Crockfor
The functions for encoding and decoding based on this table are called dB32Encode"/> are called
Base32GNS-Encode and Base32GNS-Decode, respectively. Base32GNS-Encode and Base32GNS-Decode, respectively.
</t> </t>
<figure anchor="figure_zid" align="left" suppress-title="false" pn="figu <figure anchor="figure_zid">
re-3"> <name>The Binary Representation of the zTLD</name>
<name slugifiedName="name-the-binary-representation-o">The binary repr <artwork name="" type="" alt="">
esentation of the zTLD</name>
<artwork name="" type="" align="left" alt="" pn="section-4.1-2.1">
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| ZONE TYPE | ZONE KEY / | ZONE TYPE | ZONE KEY /
+-----+-----+-----+-----+ / +-----+-----+-----+-----+ /
/ / / /
/ / / /
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
</artwork> </artwork>
</figure> </figure>
<t indent="0" pn="section-4.1-3"> <t>
The ZONE TYPE must be encoded in network byte order. The format The ZONE TYPE <bcp14>MUST</bcp14> be encoded in network byte order. Th
e format
of the ZONE KEY depends entirely on the ZONE TYPE. of the ZONE KEY depends entirely on the ZONE TYPE.
</t> </t>
<t indent="0" pn="section-4.1-4"> <t>
Consequently, a zTLD is encoded and decoded as follows: Consequently, a zTLD is encoded and decoded as follows:
</t> </t>
<artwork name="" type="" align="left" alt="" pn="section-4.1-5"> <artwork name="" type="" alt="">
zTLD := Base32GNS-Encode(ztype||zkey) zTLD := Base32GNS-Encode(ztype||zkey)
ztype||zkey := Base32GNS-Decode(zTLD) ztype||zkey := Base32GNS-Decode(zTLD)
</artwork> </artwork>
<t indent="0" pn="section-4.1-6"> <t>
where "||" is the concatenation operator. where "||" is the concatenation operator.
</t> </t>
<t indent="0" pn="section-4.1-7"> <t>
The zTLD can be used as-is as a rightmost label in a GNS name. The zTLD can be used "as is" as a rightmost label in a GNS name.
If an application wants to ensure DNS compatibility of the name, If an application wants to ensure DNS compatibility of the name,
it <bcp14>MAY</bcp14> also represent the zTLD as follows: it <bcp14>MAY</bcp14> also represent the zTLD as follows:
If the zTLD is less than or equal to 63 characters, it can if the zTLD is less than or equal to 63 characters, it can
be used as a zTLD as-is. be used as a zTLD as is.
If the zTLD is longer than 63 characters, the If the zTLD is longer than 63 characters, the
zTLD is divided into smaller labels separated by the label separator. zTLD is divided into smaller labels separated by the label separator.
Here, the most significant bytes of the "ztype||zkey" concatenation Here, the most significant bytes of the "ztype||zkey" concatenation
must be contained in the rightmost label of the resulting string and must be contained in the rightmost label of the resulting string and
the least significant bytes in the leftmost label of the resulting stri ng. This allows the the least significant bytes in the leftmost label of the resulting stri ng. This allows the
resolver to determine the ztype and zTLD length from the rightmost resolver to determine the ztype and zTLD length from the rightmost
label and to subsequently determine how many labels the zTLD should spa n. label and to subsequently determine how many labels the zTLD should spa n.
A GNS implementation <bcp14>MUST</bcp14> support the division of zTLDs A GNS implementation <bcp14>MUST</bcp14> support the division of zTLDs
in DNS compatible label lengths. in DNS-compatible label lengths.
For example, assuming a zTLD of 130 characters, the division is: For example, assuming a zTLD of 130 characters, the division is as foll
ows:
</t> </t>
<!-- FIXME: Is this really really necessary? Really? --> <artwork name="" type="" alt="">
<artwork name="" type="" align="left" alt="" pn="section-4.1-8">
zTLD[126..129].zTLD[63..125].zTLD[0..62] zTLD[126..129].zTLD[63..125].zTLD[0..62]
</artwork> </artwork>
</section> </section>
<section anchor="revocation" numbered="true" toc="include" removeInRFC="fa <section anchor="revocation">
lse" pn="section-4.2"> <name>Zone Revocation</name>
<name slugifiedName="name-zone-revocation">Zone Revocation</name> <t>
<t indent="0" pn="section-4.2-1">
In order to revoke a zone key, a signed revocation message <bcp14>MUST< /bcp14> be In order to revoke a zone key, a signed revocation message <bcp14>MUST< /bcp14> be
published. published.
This message <bcp14>MUST</bcp14> be signed using the private key of the zone. This message <bcp14>MUST</bcp14> be signed using the private key of the zone.
The revocation message is broadcast to the network. The revocation message is broadcast to the network.
The specification of the broadcast mechanism is out of scope for this The specification of the broadcast mechanism is out of scope for this
document. document.
A possible broadcast mechanism for efficient flooding in a distributed A possible broadcast mechanism for efficient flooding in a distributed
network is implemented in <xref target="GNUnet" format="default" sectio nFormat="of" derivedContent="GNUnet"/>. network is implemented in <xref target="GNUnet"/>.
Alternatively, revocation messages could also be distributed via a Alternatively, revocation messages could also be distributed via a
distributed ledger or a trusted central server. distributed ledger or a trusted central server.
To prevent To prevent
flooding attacks, the revocation message <bcp14>MUST</bcp14> contain a proof of work flooding attacks, the revocation message <bcp14>MUST</bcp14> contain a proof of work
(PoW). (PoW).
The revocation message including the PoW <bcp14>MAY</bcp14> be calculat ed The revocation message, including the PoW, <bcp14>MAY</bcp14> be calcul ated
ahead of time to support timely revocation. ahead of time to support timely revocation.
</t> </t>
<t indent="0" pn="section-4.2-2"> <t>
For all occurrences below, "Argon2id" is the Password-based Key For all occurrences below, "Argon2id" is the password-based key
Derivation Function as defined in <xref target="RFC9106" format="defaul derivation function as defined in <xref target="RFC9106"/>. For the
t" sectionFormat="of" derivedContent="RFC9106"/>. For the PoW calculations, the algorithm is instantiated with the
PoW calculations the algorithm is instantiated with the
following parameters: following parameters:
</t> </t>
<dl indent="3" newline="false" spacing="normal" pn="section-4.2-3"> <dl newline="false">
<dt pn="section-4.2-3.1">S</dt> <dt>S:</dt>
<dd pn="section-4.2-3.2">The salt. Fixed 16-byte string: "GnsRevocatio <dd>The salt. Fixed 16-byte string: "GnsRevocationPow"</dd>
nPow".</dd> <dt>t:</dt>
<dt pn="section-4.2-3.3">t</dt> <dd>Number of iterations: 3</dd>
<dd pn="section-4.2-3.4">Number of iterations: 3</dd> <dt>m:</dt>
<dt pn="section-4.2-3.5">m</dt> <dd>Memory size in KiB: 1024</dd>
<dd pn="section-4.2-3.6">Memory size in KiB: 1024</dd> <dt>T:</dt>
<dt pn="section-4.2-3.7">T</dt> <dd>Output length of hash in bytes: 64</dd>
<dd pn="section-4.2-3.8">Output length of hash in bytes: 64</dd> <dt>p:</dt>
<dt pn="section-4.2-3.9">p</dt> <dd>Parallelization parameter: 1</dd>
<dd pn="section-4.2-3.10">Parallelization parameter: 1</dd> <dt>v:</dt>
<dt pn="section-4.2-3.11">v</dt> <dd>Algorithm version: 0x13</dd>
<dd pn="section-4.2-3.12">Algorithm version: 0x13</dd> <dt>y:</dt>
<dt pn="section-4.2-3.13">y</dt> <dd>Algorithm type (Argon2id): 2</dd>
<dd pn="section-4.2-3.14">Algorithm type (Argon2id): 2</dd> <dt>X:</dt>
<dt pn="section-4.2-3.15">X</dt> <dd>Unused</dd>
<dd pn="section-4.2-3.16">Unused</dd> <dt>K:</dt>
<dt pn="section-4.2-3.17">K</dt> <dd>Unused</dd>
<dd pn="section-4.2-3.18">Unused</dd>
</dl> </dl>
<t indent="0" pn="section-4.2-4"> <t>
<xref target="figure_revocation" format="default" sectionFormat="of" de <xref target="figure_revocation"/> illustrates the format
rivedContent="Figure 4"/> illustrates the format
of the data "P" on which the PoW is calculated. of the data "P" on which the PoW is calculated.
</t> </t>
<figure anchor="figure_revocation" align="left" suppress-title="false" p <figure anchor="figure_revocation">
n="figure-4"> <name>The Format of the PoW Data</name>
<name slugifiedName="name-the-format-of-the-pow-data">The Format of th <artwork name="" type="" alt="">
e PoW Data.</name>
<artwork name="" type="" align="left" alt="" pn="section-4.2-5.1">
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| POW | | POW |
+-----------------------------------------------+ +-----------------------------------------------+
| TIMESTAMP | | TIMESTAMP |
+-----------------------------------------------+ +-----------------------------------------------+
| ZONE TYPE | ZONE KEY | | ZONE TYPE | ZONE KEY /
+-----+-----+-----+-----+ | +-----+-----+-----+-----+ /
/ / / /
-----+-----+-----+-----+ <span class="insert">/</span>
/ / / /
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
</artwork> </artwork>
</figure> </figure>
<dl indent="3" newline="false" spacing="normal" pn="section-4.2-6"> <dl newline="false">
<dt pn="section-4.2-6.1">POW</dt> <dt>POW:</dt>
<dd pn="section-4.2-6.2"> <dd>
A 64-bit value that is a solution to the PoW. In network byte order. A 64-bit value that is a solution to the PoW. In network byte order.
</dd> </dd>
<dt pn="section-4.2-6.3">TIMESTAMP</dt> <dt>TIMESTAMP:</dt>
<dd pn="section-4.2-6.4"> <dd>
denotes the absolute 64-bit date when the revocation was computed. Denotes the absolute 64-bit date when the revocation was computed.
In microseconds since midnight (0 hour), January 1, 1970 UTC in netwo rk In microseconds since midnight (0 hour), January 1, 1970 UTC in netwo rk
byte order. byte order.
</dd> </dd>
<dt pn="section-4.2-6.5">ZONE TYPE</dt> <dt>ZONE TYPE:</dt>
<dd pn="section-4.2-6.6"> <dd>
is the 32-bit zone type in network byte order. The 32-bit zone type in network byte order.
</dd> </dd>
<dt pn="section-4.2-6.7">ZONE KEY</dt> <dt>ZONE KEY:</dt>
<dd pn="section-4.2-6.8"> <dd>
is the 256-bit public key zk of the zone which is being revoked. The 256-bit public key zkey of the zone that is being revoked.
The wire format of this value is defined by the ZONE TYPE. The wire format of this value is defined by the ZONE TYPE.
</dd> </dd>
</dl> </dl>
<t indent="0" pn="section-4.2-7"> <t>
Usually, PoW schemes require to find one POW value such that Usually, PoW schemes require that one POW value be found, such that
a specific number of leading zeroes are found in the hash result. a specific number of leading zeroes are found in the hash result.
This number is then referred to as the difficulty of the PoW. This number is then referred to as the difficulty of the PoW.
In order to reduce the variance in time it takes to calculate the In order to reduce the variance in time it takes to calculate the
PoW, a valid GNS revocation requires that a number Z different PoWs PoW, a valid GNS revocation requires that a number of different PoWs (Z
must be found that on average have D leading zeroes. , as defined below)
must be found that on average have at least D leading zeroes.
</t> </t>
<t indent="0" pn="section-4.2-8"> <t>
Given an average difficulty of D, the proofs have an Given an average difficulty of D, the proofs have an
expiration time of EPOCH. Applications <bcp14>MAY</bcp14> calculate pr oofs expiration time of EPOCH. Applications <bcp14>MAY</bcp14> calculate pr oofs
with a difficulty that is higher than D by providing POW with a difficulty that is higher than D by providing POW
values where there are (on average) more than D bits of leading zeros. values where there are (on average) more than D bits of leading zeroes.
With each additional bit of difficulty, the With each additional bit of difficulty, the
lifetime of the proof is prolonged by another EPOCH. lifetime of the proof is prolonged by another EPOCH.
Consequently, by calculating a more difficult PoW, the lifetime of the Consequently, by calculating a more difficult PoW, the lifetime of the
proof and thus the persistence of the revocation message proof -- and thus the persistence of the revocation message --
can be increased on demand by the zone owner. can be increased on demand by the zone owner.
</t> </t>
<t indent="0" pn="section-4.2-9"> <t>
The parameters are defined as follows: The parameters are defined as follows:
</t> </t>
<dl indent="3" newline="false" spacing="normal" pn="section-4.2-10"> <dl newline="false">
<dt pn="section-4.2-10.1">Z</dt> <dt>Z:</dt>
<dd pn="section-4.2-10.2">The number of PoWs that are required. Its va <dd>The number of PoWs that are required. Its value is fixed at 32.</d
lue is fixed at 32.</dd> d>
<dt pn="section-4.2-10.3">D</dt> <dt>D:</dt>
<dd pn="section-4.2-10.4">The lower limit of the average difficulty. I <dd>The lower limit of the average difficulty. Its value is fixed at 2
ts value is fixed at 22.</dd> 2.</dd>
<dt pn="section-4.2-10.5">EPOCH</dt> <dt>EPOCH:</dt>
<dd pn="section-4.2-10.6">A single epoch. Its value is fixed at 365 da <dd>A single epoch. Its value is fixed at 365 days in microseconds.</d
ys in microseconds.</dd> d>
</dl> </dl>
<t indent="0" pn="section-4.2-11"> <t>
The revocation message wire format is illustrated in The revocation message wire format is illustrated in
<xref target="figure_revocationdata" format="default" sectionFormat="of " derivedContent="Figure 5"/>. <xref target="figure_revocationdata"/>.
</t> </t>
<figure anchor="figure_revocationdata" align="left" suppress-title="fals <figure anchor="figure_revocationdata">
e" pn="figure-5"> <name>The Revocation Message Wire Format</name>
<name slugifiedName="name-the-revocation-message-wire">The Revocation <artwork name="" type="" alt="">
Message Wire Format.</name>
<artwork name="" type="" align="left" alt="" pn="section-4.2-12.1">
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| TIMESTAMP | | TIMESTAMP |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| TTL | | TTL |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| POW_0 | | POW_0 |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| ... | | ... |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| POW_Z-1 | | POW_(Z-1) |
+-----------------------------------------------+ +-----------------------------------------------+
| ZONE TYPE | ZONE KEY | | ZONE TYPE | ZONE KEY /
+-----+-----+-----+-----+ | +-----+-----+-----+-----+ /
/ / / /
-----+-----+-----+-----+ <span class="insert">/</span>
/ / / /
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| SIGNATURE | / SIGNATURE /
/ /
/ / / /
/ / / /
| |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
</artwork> </artwork>
</figure> </figure>
<dl indent="3" newline="false" spacing="normal" pn="section-4.2-13"> <dl newline="false">
<dt pn="section-4.2-13.1">TIMESTAMP</dt> <dt>TIMESTAMP:</dt>
<dd pn="section-4.2-13.2"> <dd>
denotes the absolute 64-bit date when the revocation was computed. Denotes the absolute 64-bit date when the revocation was computed.
In microseconds since midnight (0 hour), January 1, 1970 UTC in netwo rk In microseconds since midnight (0 hour), January 1, 1970 UTC in netwo rk
byte order. This is the same value as the time stamp used in the byte order. This is the same value as the timestamp used in the
individual PoW calculations. individual PoW calculations.
</dd> </dd>
<dt pn="section-4.2-13.3">TTL</dt> <dt>TTL:</dt>
<dd pn="section-4.2-13.4"> <dd>
denotes the relative 64-bit time to live of the record in Denotes the relative 64-bit time to live of the record in
microseconds in network byte order. microseconds in network byte order.
The field <bcp14>SHOULD</bcp14> be set to EPOCH * 1.1. The field <bcp14>SHOULD</bcp14> be set to EPOCH * 1.1.
Given an average number of leading zeros D', then the field value Given an average number of leading zeroes D', then the field value
<bcp14>MAY</bcp14> be increased up to (D'-D+1) * EPOCH * 1.1. <bcp14>MAY</bcp14> be increased up to (D'-D+1) * EPOCH * 1.1.
Validators <bcp14>MAY</bcp14> reject messages with lower or higher Validators <bcp14>MAY</bcp14> reject messages with lower or higher
values when received. values when received.
</dd> </dd>
<dt pn="section-4.2-13.5">POW_i</dt> <dt>POW_i:</dt>
<dd pn="section-4.2-13.6"> <dd>
The values calculated as part of the PoW, in network byte order. The values calculated as part of the PoW, in network byte order.
Each POW_i <bcp14>MUST</bcp14> be unique in the set of POW values. Each POW_i <bcp14>MUST</bcp14> be unique in the set of POW values.
To facilitate fast verification To facilitate fast verification
of uniqueness, the POW values must be given in strictly of uniqueness, the POW values <bcp14>MUST</bcp14> be given in strictl y
monotonically increasing order in the message. monotonically increasing order in the message.
</dd> </dd>
<dt pn="section-4.2-13.7">ZONE TYPE</dt> <dt>ZONE TYPE:</dt>
<dd pn="section-4.2-13.8"> <dd>
The 32-bit zone type corresponding to the zone key in network byte or der. The 32-bit zone type corresponding to the zone key in network byte or der.
</dd> </dd>
<dt pn="section-4.2-13.9">ZONE KEY</dt> <dt>ZONE KEY:</dt>
<dd pn="section-4.2-13.10"> <dd>
is the public key zk of the zone which is being revoked and The public key zkey of the zone that is being revoked and
the key to be used to verify SIGNATURE. the key to be used to verify SIGNATURE.
</dd> </dd>
<dt pn="section-4.2-13.11">SIGNATURE</dt> <dt>SIGNATURE:</dt>
<dd pn="section-4.2-13.12"> <dd>
A signature over a time stamp and the zone zk of the zone A signature over a timestamp and the zone zkey of the zone
which is revoked and corresponds to the key used in the PoW. that is revoked and corresponds to the key used in the PoW.
The signature is created using the Sign() function of The signature is created using the Sign() function of
the cryptosystem of the zone and the private key the cryptosystem of the zone and the private key
(see <xref target="zones" format="default" sectionFormat="of" derived Content="Section 4"/>). (see <xref target="zones"/>).
</dd> </dd>
</dl> </dl>
<t indent="0" pn="section-4.2-14"> <t>
The signature over the public key covers a 32-bit header The signature in the revocation message covers a 32-bit header
prefixed to the time stamp and public key fields. prefixed to the TIMESTAMP, ZONE TYPE, and ZONE KEY fields.
The header includes the key length and signature purpose. The header includes the key length and signature purpose.
The wire format is illustrated The wire format is illustrated
in <xref target="figure_revsigwithpseudo" format="default" sectionFormat ="of" derivedContent="Figure 6"/>. in <xref target="figure_revsigwithpseudo"/>.
</t> </t>
<figure anchor="figure_revsigwithpseudo" align="left" suppress-title="fa <figure anchor="figure_revsigwithpseudo">
lse" pn="figure-6"> <name>The Wire Format of the Revocation Data for Signing</name>
<name slugifiedName="name-the-wire-format-of-the-revo">The Wire Format <artwork name="" type="" alt="">
of the Revocation Data for Signing.</name>
<artwork name="" type="" align="left" alt="" pn="section-4.2-15.1">
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| SIZE | PURPOSE (0x03) | | SIZE | PURPOSE (0x03) |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| TIMESTAMP | | TIMESTAMP |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| ZONE TYPE | ZONE KEY | | ZONE TYPE | ZONE KEY /
+-----+-----+-----+-----+ | +-----+-----+-----+-----+ /
/ / / /
-----+-----+-----+-----+ <span class="insert">/</span>
/ / / /
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
</artwork> </artwork>
</figure> </figure>
<dl indent="3" newline="false" spacing="normal" pn="section-4.2-16"> <dl newline="false">
<dt pn="section-4.2-16.1">SIZE</dt> <dt>SIZE:</dt>
<dd pn="section-4.2-16.2"> <dd>
A 32-bit value containing the length of the signed data in bytes A 32-bit value containing the length of the signed data in bytes
in network byte order. in network byte order.
</dd> </dd>
<dt pn="section-4.2-16.3">PURPOSE</dt> <dt>PURPOSE:</dt>
<dd pn="section-4.2-16.4"> <dd>
A 32-bit signature purpose flag. A 32-bit signature purpose flag.
The value of this field <bcp14>MUST</bcp14> be 3. The value of this field <bcp14>MUST</bcp14> be 3.
The value is encoded in network byte order. The value is encoded in network byte order.
It defines the context in which It defines the context in which
the signature is created so that it cannot be reused in other parts the signature is created so that it cannot be reused in other parts
of the protocol including possible future extensions. of the protocol that might include possible future extensions.
The value of this field corresponds to an entry in the The value of this field corresponds to an entry in the
GANA "GNUnet Signature Purpose" registry <xref target="GANA" format=" default" sectionFormat="of" derivedContent="GANA"/>. GANA "GNUnet Signature Purposes" registry <xref target="GANA"/>.
</dd> </dd>
<dt pn="section-4.2-16.5">TIMESTAMP</dt> <dt>TIMESTAMP:</dt>
<dd pn="section-4.2-16.6"> <dd>
Field as defined in the revocation message above. Field as defined in the revocation message above.
</dd> </dd>
<dt pn="section-4.2-16.7">ZONE TYPE</dt> <dt>ZONE TYPE:</dt>
<dd pn="section-4.2-16.8"> <dd>
Field as defined in the revocation message above. Field as defined in the revocation message above.
</dd> </dd>
<dt pn="section-4.2-16.9">ZONE KEY</dt> <dt>ZONE KEY:</dt>
<dd pn="section-4.2-16.10">Field as defined in the revocation message <dd>Field as defined in the revocation message above.</dd>
above.</dd>
</dl> </dl>
<t indent="0" pn="section-4.2-17"> <t>
In order to validate a revocation the following steps <bcp14>MUST</bcp1 In order to validate a revocation, the following steps <bcp14>MUST</bcp
4> be taken: 14> be taken:
</t> </t>
<ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-4. <ol>
2-18"> <li>The signature <bcp14>MUST</bcp14> be verified against the zone key.
<li pn="section-4.2-18.1" derivedCounter="1.">The signature <bcp14>MUST </li>
</bcp14> be verified against the zone key.</li> <li>The set of POW values <bcp14>MUST NOT</bcp14> contain duplicates;
<li pn="section-4.2-18.2" derivedCounter="2.">The set of POW values <b this <bcp14>MUST</bcp14> be checked by verifying that the values are strictly mo
cp14>MUST</bcp14> NOT contain duplicates which <bcp14>MUST</bcp14> be checked by notonically increasing.</li>
verifying that the values are strictly monotonically increasing.</li> <li>The average number of leading zeroes D' resulting from the provide
<li pn="section-4.2-18.3" derivedCounter="3.">The average number of le d
ading zeroes D' resulting from the provided
POW values <bcp14>MUST</bcp14> be greater than or equal to D. Implemen ters POW values <bcp14>MUST</bcp14> be greater than or equal to D. Implemen ters
<bcp14>MUST NOT</bcp14> use an integer data type to calculate or repres ent D'.</li> <bcp14>MUST NOT</bcp14> use an integer data type to calculate or repres ent D'.</li>
</ol> </ol>
<t indent="0" pn="section-4.2-19"> <t>
The TTL field in the revocation message is informational. The TTL field in the revocation message is informational.
A revocation <bcp14>MAY</bcp14> be discarded without checking the POW A revocation <bcp14>MAY</bcp14> be discarded without checking the POW
values or the signature if the TTL (in combination with TIMESTAMP) values or the signature if the TTL (in combination with TIMESTAMP)
indicates that the revocation has already expired. indicates that the revocation has already expired.
The actual validity period of the The actual validity period of the
revocation <bcp14>MUST</bcp14> be determined by examining the leading revocation <bcp14>MUST</bcp14> be determined by examining the leading
zeroes in the POW values. zeroes in the POW values.
</t> </t>
<t indent="0" pn="section-4.2-20"> <t>
The validity period of the revocation is calculated as The validity period of the revocation is calculated as
(D'-D+1) * EPOCH * 1.1. The EPOCH is extended by (D'-D+1) * EPOCH * 1.1. The EPOCH is extended by
10% in order to deal with unsynchronized clocks. 10% in order to deal with poorly synchronized clocks.
The validity period added on top of the TIMESTAMP yields the The validity period added on top of the TIMESTAMP yields the
expiration date. expiration date.
If the current time is after the expiration date, the If the current time is after the expiration date, the
revocation is considered stale. revocation is considered stale.
</t> </t>
<t indent="0" pn="section-4.2-21"> <t>
Verified revocations <bcp14>MUST</bcp14> be stored locally. Verified revocations <bcp14>MUST</bcp14> be stored locally.
The implementation <bcp14>MAY</bcp14> discard stale revocations and The implementation <bcp14>MAY</bcp14> discard stale revocations and
evict then from the local store at any time. evict them from the local store at any time.
</t> </t>
<t indent="0" pn="section-4.2-22"> <t>
Implementations <bcp14>MUST</bcp14> broadcast received revocations It is important that implementations broadcast received revocations
if they are valid and not stale. if they are valid and not stale.
Should the calculated validity period differ from the TTL field value, Should the calculated validity period differ from the TTL field value,
the calculated value <bcp14>MUST</bcp14> be used as TTL field value the calculated value <bcp14>MUST</bcp14> be used as the TTL field value
when forwarding the revocation message. when forwarding the revocation message.
Systems might disagree on the current time, so implementations Systems might disagree on the current time, so implementations
<bcp14>MAY</bcp14> use stale but otherwise valid <bcp14>MAY</bcp14> use stale but otherwise valid
revocations but <bcp14>SHOULD NOT</bcp14> broadcast them. revocations but <bcp14>SHOULD NOT</bcp14> broadcast them.
Forwarded stale revocations <bcp14>MAY</bcp14> be discarded. Forwarded stale revocations <bcp14>MAY</bcp14> be discarded by the rece iver.
</t> </t>
<t indent="0" pn="section-4.2-23"> <t>
Any locally stored revocation <bcp14>MUST</bcp14> be considered during Any locally stored revocation <bcp14>MUST</bcp14> be considered during
delegation record processing (see <xref target="delegation_processing" format="default" sectionFormat="of" derivedContent="Section 7.3.4"/>). delegation record processing (see <xref target="delegation_processing"/ >).
</t> </t>
</section> </section>
</section> </section>
<section anchor="rrecords" numbered="true" toc="include" removeInRFC="false" <section anchor="rrecords">
pn="section-5"> <name>Resource Records</name>
<name slugifiedName="name-resource-records">Resource Records</name> <t>
<t indent="0" pn="section-5-1"> A GNS implementation <bcp14>SHOULD</bcp14> provide a mechanism for creati
A GNS implementation <bcp14>SHOULD</bcp14> provide a mechanism to create ng and managing local
and manage local
zones as well as a persistence mechanism (such as a local database) for r esource zones as well as a persistence mechanism (such as a local database) for r esource
records. records.
A new local zone is established by selecting a zone type and creating a A new local zone is established by selecting a zone type and creating a
zone key pair. zone key pair.
If this mechanism is not implemented, If this mechanism is not implemented,
no zones can be published in the storage (see <xref target="publish" form no zones can be published in storage (see <xref target="publish"/>)
at="default" sectionFormat="of" derivedContent="Section 6"/>) and name resolution is limited to non-local Start Zones
and name resolution is limited to non-local start zones (see <xref target="governance"/>).
(see <xref target="governance" format="default" sectionFormat="of" derive
dContent="Section 7.1"/>).
</t> </t>
<t indent="0" pn="section-5-2"> <t>
A GNS resource record holds the data of a specific record in a zone. A GNS resource record holds the data of a specific record in a zone.
The resource record format is defined in The resource record format is illustrated in
<xref target="figure_gnsrecord" format="default" sectionFormat="of" deriv <xref target="figure_gnsrecord"/>.
edContent="Figure 7"/>.
</t> </t>
<figure anchor="figure_gnsrecord" align="left" suppress-title="false" pn=" <figure anchor="figure_gnsrecord">
figure-7"> <name>The Resource Record Wire Format</name>
<name slugifiedName="name-the-resource-record-wire-fo">The Resource Reco <artwork name="" type="" alt="">
rd Wire Format.</name>
<artwork name="" type="" align="left" alt="" pn="section-5-3.1">
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| EXPIRATION | | EXPIRATION |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| SIZE | FLAGS | TYPE | | SIZE | FLAGS | TYPE |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| DATA / | DATA /
/ / / /
/ / / /
</artwork> </artwork>
</figure> </figure>
<dl indent="3" newline="false" spacing="normal" pn="section-5-4"> <dl newline="false">
<dt pn="section-5-4.1">EXPIRATION</dt> <dt>EXPIRATION:</dt>
<dd pn="section-5-4.2"> <dd>
denotes the absolute 64-bit expiration date of the record. Denotes the absolute 64-bit expiration date of the record.
In microseconds since midnight (0 hour), January 1, 1970 UTC in network In microseconds since midnight (0 hour), January 1, 1970 UTC in network
byte order. byte order.
</dd> </dd>
<dt pn="section-5-4.3">SIZE</dt> <dt>SIZE:</dt>
<dd pn="section-5-4.4"> <dd>
denotes the 16-bit size of the DATA field in bytes in network byte Denotes the 16-bit size of the DATA field in bytes in network byte
order. order.
</dd> </dd>
<dt pn="section-5-4.5">FLAGS</dt> <dt>FLAGS:</dt>
<dd pn="section-5-4.6"> <dd>
is a 16-bit bit field indicating special properties of the resource rec A 16-bit field indicating special properties of the resource record.
ord.
The semantics of the different bits are defined below. The semantics of the different bits are defined below.
</dd> </dd>
<dt pn="section-5-4.7">TYPE</dt> <dt>TYPE:</dt>
<dd pn="section-5-4.8"> <dd>
is the 32-bit resource record type in The 32-bit resource record type in
network byte order. This type can be one of the GNS resource network byte order. This type can be one of the GNS resource
records as defined in <xref target="rrecords" format="default" sectionF records as defined in <xref target="rrecords"/>, a DNS record
ormat="of" derivedContent="Section 5"/> or a DNS record type as defined in <xref target="RFC1035"/>, or any of the
type as defined in <xref target="RFC1035" format="default" sectionForma
t="of" derivedContent="RFC1035"/> or any of the
complementary standardized DNS resource record types. complementary standardized DNS resource record types.
Note that values Note that values
below 2^16 are reserved for 16-bit DNS Resorce Record types allocated b below 2<sup>16</sup> are reserved for 16-bit DNS resource record types
y IANA <xref target="RFC6895" format="default" sectionFormat="of" derivedContent allocated by IANA <xref target="RFC6895"/>.
="RFC6895"/>. Values above 2<sup>16</sup> are allocated by the
Values above 2^16 are allocated by the GANA "GNS Record Types" registry <xref target="GANA"/>.
GANA "GNS Record Types" registry <xref target="GANA" format="default" s
ectionFormat="of" derivedContent="GANA"/>.
</dd> </dd>
<dt pn="section-5-4.9">DATA</dt> <dt>DATA:</dt>
<dd pn="section-5-4.10"> <dd>
the variable-length resource record data payload. The content is define The variable-length resource record data payload. The content is define
d d
by the by the
respective type of the resource record. respective type of the resource record.
</dd> </dd>
</dl> </dl>
<t indent="0" pn="section-5-5"> <t>
The FLAGS field is used to indicate special properties of the resource re cord. The FLAGS field is used to indicate special properties of the resource re cord.
An application creating resource records <bcp14>MUST</bcp14> set all bits An application creating resource records <bcp14>MUST</bcp14> set all bits
in FLAGS to 0 unless it specifically understands and in FLAGS to 0 unless it specifically understands and
wants to set the respective flag. wants to set the respective flag.
As additional flags can be defined in future protocol versions, As additional flags can be defined in future protocol versions,
if an application or implementation encounters a flag which it does not if an application or implementation encounters a flag that it does not
recognize, it <bcp14>MUST</bcp14> be ignored. However, all implementatio recognize, the flag <bcp14>MUST</bcp14> be ignored. However, all impleme
ns ntations
<bcp14>MUST</bcp14> understand the SHADOW and CRITICAL flags defined belo w. <bcp14>MUST</bcp14> understand the SHADOW and CRITICAL flags defined belo w.
Any combination of the flags specified below are valid. Any combination of the flags specified below is valid.
<xref target="figure_flag" format="default" sectionFormat="of" derivedCon <xref target="figure_flag"/>
tent="Figure 8"/>
illustrates the flag distribution in the 16-bit FLAGS field of a illustrates the flag distribution in the 16-bit FLAGS field of a
resource record: resource record:
</t> </t>
<figure anchor="figure_flag" align="left" suppress-title="false" pn="figur <figure anchor="figure_flag">
e-8"> <name>The Resource Record Flag Wire Format</name>
<name slugifiedName="name-the-resource-record-flag-wi">The Resource Reco <artwork name="" type="" alt="">
rd Flag Wire Format.</name>
<artwork name="" type="" align="left" alt="" pn="section-5-6.1">
0 13 14 15 0 13 14 15
+--------...+-------------+-------+---------+ +--------...+-------------+-------+---------+
| Reserved |SUPPLEMENTAL |SHADOW |CRITICAL | | Reserved |SUPPLEMENTAL |SHADOW |CRITICAL |
+--------...+-------------+-------+---------+ +--------...+-------------+-------+---------+
</artwork> </artwork>
</figure> </figure>
<dl indent="3" newline="false" spacing="normal" pn="section-5-7"> <dl newline="false">
<dt pn="section-5-7.1">CRITICAL</dt> <dt>CRITICAL:</dt>
<dd pn="section-5-7.2"> <dd>
If this flag is set, it indicates that processing is critical. If this flag is set, it indicates that processing is critical.
Implementations that do not support the record type or are otherwise Implementations that do not support the record type or are otherwise
unable to process the record <bcp14>MUST</bcp14> abort resolution upon encountering unable to process the record <bcp14>MUST</bcp14> abort resolution upon encountering
the record in the resolution process. the record in the resolution process.
</dd> </dd>
<dt pn="section-5-7.3">SHADOW</dt> <dt>SHADOW:</dt>
<dd pn="section-5-7.4"> <dd>
If this flag is set, this record <bcp14>MUST</bcp14> be ignored by reso lvers unless all (other) If this flag is set, this record <bcp14>MUST</bcp14> be ignored by reso lvers unless all (other)
records of the same record type have expired. Used to allow zone publi shers to records of the same record type have expired. Used to allow zone publi shers to
facilitate good performance when records change by allowing them to put future facilitate good performance when records change by allowing them to put future
values of records into the storage. values of records into storage.
This way, future values can propagate and can be This way, future values can propagate and can be
cached before the transition becomes active. cached before the transition becomes active.
</dd> </dd>
<dt pn="section-5-7.5">SUPPLEMENTAL</dt> <dt>SUPPLEMENTAL:</dt>
<dd pn="section-5-7.6"> <dd>
This is a supplemental record. It is provided in addition to the This is a supplemental record. It is provided in addition to the
other records. This flag indicates that this record is not explicitly other records. This flag indicates that this record is not explicitly
managed alongside the other records under the respective name but managed alongside the other records under the respective name but
might be useful for the application. might be useful for the application.
</dd> </dd>
</dl> </dl>
<section anchor="gnsrecords_delegation" numbered="true" toc="include" remo <section anchor="gnsrecords_delegation">
veInRFC="false" pn="section-5.1"> <name>Zone Delegation Records</name>
<name slugifiedName="name-zone-delegation-records">Zone Delegation Recor <t>
ds</name>
<t indent="0" pn="section-5.1-1">
This section defines the initial set of zone delegation record types. This section defines the initial set of zone delegation record types.
Any implementation <bcp14>SHOULD</bcp14> support all zone types defined h ere and Any implementation <bcp14>SHOULD</bcp14> support all zone types defined h ere and
<bcp14>MAY</bcp14> support any number of additional delegation records de fined in <bcp14>MAY</bcp14> support any number of additional delegation records de fined in
the GANA "GNS Record Types" registry (see <xref target="GANA" format="def the GANA "GNS Record Types" registry (see <xref target="GANA"/>).
ault" sectionFormat="of" derivedContent="GANA"/>). Not supporting some zone types will result in resolution failures if
Not supporting some zone types will result in resolution failures in case
the respective zone type is encountered. the respective zone type is encountered.
This can be a valid choice if some zone delegation record types have been This can be a valid choice if some zone delegation record types have been
determined to be cryptographically insecure. determined to be cryptographically insecure.
Zone delegation records <bcp14>MUST NOT</bcp14> be stored and published Zone delegation records <bcp14>MUST NOT</bcp14> be stored or published
under the apex label. under the apex label.
A zone delegation record type value is the same as the respective ztype A zone delegation record type value is the same as the respective ztype
value. value.
The ztype defines the cryptographic primitives for the zone that is The ztype defines the cryptographic primitives for the zone that is
being delegated to. being delegated to.
A zone delegation record payload contains the public key of A zone delegation record payload contains the public key of
the zone to delegate to. the zone to delegate to.
A zone delegation record <bcp14>MUST</bcp14> have the CRITICAL flag set A zone delegation record <bcp14>MUST</bcp14> have the CRITICAL flag set
and <bcp14>MUST</bcp14> be the only non-supplemental record under a label . and <bcp14>MUST</bcp14> be the only non-supplemental record under a label .
There <bcp14>MAY</bcp14> be inactive records of the same type which have There <bcp14>MAY</bcp14> be inactive records of the same type that have
the SHADOW flag set in order to facilitate smooth key rollovers. the SHADOW flag set in order to facilitate smooth key rollovers.
</t> </t>
<t indent="0" pn="section-5.1-2"> <t>
In the following, "||" is the concatenation operator of two byte strings. In the following, "||" is the concatenation operator of two byte strings.
The algorithm specification uses character strings such as GNS labels or The algorithm specification uses character strings such as GNS labels or
constant values. constant values.
When used in concatenations or as input to functions the When used in concatenations or as input to functions, the
null-terminator of the character strings <bcp14>MUST NOT</bcp14> be zero terminator of the character strings <bcp14>MUST NOT</bcp14> be
included. included.
</t> </t>
<section anchor="gnsrecords_pkey" numbered="true" toc="include" removeIn <section anchor="gnsrecords_pkey">
RFC="false" pn="section-5.1.1"> <name>PKEY</name>
<name slugifiedName="name-pkey">PKEY</name> <t>
<t indent="0" pn="section-5.1.1-1">
In GNS, a delegation of a label to a zone of type "PKEY" is In GNS, a delegation of a label to a zone of type "PKEY" is
represented through a PKEY record. The PKEY DATA entry wire format can be found in <xref target="figure_pkeyrecord" format="default" sectionFormat="of " derivedContent="Figure 9"/>. represented through a PKEY record. The PKEY DATA entry wire format is illustrated in <xref target="figure_pkeyrecord"/>.
</t> </t>
<figure anchor="figure_pkeyrecord" align="left" suppress-title="false" <figure anchor="figure_pkeyrecord">
pn="figure-9"> <name>The PKEY Wire Format</name>
<name slugifiedName="name-the-pkey-wire-format">The PKEY Wire Format <artwork name="" type="" alt="">
.</name>
<artwork name="" type="" align="left" alt="" pn="section-5.1.1-2.1">
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| PUBLIC KEY | | PUBLIC KEY |
| | | |
| | | |
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
</artwork> </artwork>
</figure> </figure>
<dl indent="3" newline="false" spacing="normal" pn="section-5.1.1-3"> <dl newline="false">
<dt pn="section-5.1.1-3.1">PUBLIC KEY</dt> <dt>PUBLIC KEY:</dt>
<dd pn="section-5.1.1-3.2"> <dd>
A 256-bit Ed25519 public key. A 256-bit Ed25519 public key.
</dd> </dd>
</dl> </dl>
<t indent="0" pn="section-5.1.1-4"> <t>
For PKEY zones the zone key material is derived using the For PKEY zones, the zone key material is derived using the
curve parameters of the twisted Edwards representation curve parameters of the twisted Edwards representation
of Curve25519 <xref target="RFC7748" format="default" sectionFormat="of of Curve25519 <xref target="RFC7748"/> (the reasoning behind choosing
" derivedContent="RFC7748"/> (the reasoning behind choosing this curve can be found in <xref target="security_cryptography"/>)
this curve can be found in <xref target="security_cryptography" format= with the ECDSA scheme <xref target="RFC6979"/>.
"default" sectionFormat="of" derivedContent="Section 9.3"/>)
with the ECDSA scheme <xref target="RFC6979" format="default" sectionFo
rmat="of" derivedContent="RFC6979"/>.
The following naming convention is used for the cryptographic primitive s of PKEY zones: The following naming convention is used for the cryptographic primitive s of PKEY zones:
</t> </t>
<dl indent="3" newline="false" spacing="normal" pn="section-5.1.1-5"> <dl newline="false">
<dt pn="section-5.1.1-5.1">d</dt> <dt>d:</dt>
<dd pn="section-5.1.1-5.2"> <dd>
is a 256-bit Ed25519 private key (private scalar). A 256-bit Ed25519 private key (clamped private scalar).
</dd> </dd>
<dt pn="section-5.1.1-5.3">zk</dt> <dt>zkey:</dt>
<dd pn="section-5.1.1-5.4"> <dd>
is the Ed25519 public zone key corresponding to d. The Ed25519 public zone key corresponding to d.
</dd> </dd>
<dt pn="section-5.1.1-5.5">p</dt> <dt>p:</dt>
<dd pn="section-5.1.1-5.6"> <dd>
is the prime of edwards25519 as defined in <xref target="RFC7748" for The prime of edwards25519 as defined in <xref target="RFC7748"/>, i.e
mat="default" sectionFormat="of" derivedContent="RFC7748"/>, i.e. .,
2^255 - 19. 2<sup>255</sup> - 19.
</dd> </dd>
<dt pn="section-5.1.1-5.7">G</dt> <dt>G:</dt>
<dd pn="section-5.1.1-5.8"> <dd>
is the group generator (X(P),Y(P)). With X(P),Y(P) of edwards25519 as The group generator (X(P),Y(P)). With X(P),Y(P) of edwards25519 as de
defined in fined in
<xref target="RFC7748" format="default" sectionFormat="of" derivedCon <xref target="RFC7748"/>.
tent="RFC7748"/>.
</dd> </dd>
<dt pn="section-5.1.1-5.9">L</dt> <dt>L:</dt>
<dd pn="section-5.1.1-5.10"> <dd>
is the order of the prime-order subgroup of edwards25519 in <xref tar The order of the prime-order subgroup of edwards25519 as defined in <
get="RFC7748" format="default" sectionFormat="of" derivedContent="RFC7748"/>. xref target="RFC7748"/>.
</dd> </dd>
<dt pn="section-5.1.1-5.11">KeyGen()</dt> <dt>KeyGen():</dt>
<dd pn="section-5.1.1-5.12">The generation of the private <dd>The generation of the private
scalar d and the curve point zk := d*G (where G is the group generato scalar d and the curve point zkey := d*G (where G is the group genera
r tor
of the elliptic curve) as defined in Section 2.2. of of the elliptic curve) as defined in <xref target="RFC6979" sectionFo
<xref target="RFC6979" format="default" sectionFormat="of" derivedCon rmat="of" section="2.2"/> represents the KeyGen() function.
tent="RFC6979"/> represents the KeyGen() function.
</dd> </dd>
</dl> </dl>
<t indent="0" pn="section-5.1.1-6"> <t>
The zone type and zone key of a PKEY are 4 + 32 bytes in length. This m eans that The zone type and zone key of a PKEY are 4 + 32 bytes in length. This m eans that
a zTLD will always fit into a single label and does a zTLD will always fit into a single label and does
not need any further conversion. not need any further conversion.
Given a label, the output zk' of the ZKDF(zk,label) function is Given a label, the output zkey' of the ZKDF(zkey, label) function is
calculated as follows for PKEY zones: calculated as follows for PKEY zones:
</t> </t>
<artwork name="" type="" align="left" alt="" pn="section-5.1.1-7"> <artwork name="" type="" alt="">
ZKDF(zk,label): ZKDF(zkey, label):
PRK_h := HKDF-Extract ("key-derivation", zk) PRK_h := HKDF-Extract("key-derivation", zkey)
h := HKDF-Expand (PRK_h, label || "gns", 512 / 8) h := HKDF-Expand(PRK_h, label || "gns", 512 / 8)
zk' := (h mod L) * zk zkey' := (h mod L) * zkey
return zk' return zkey'
</artwork> </artwork>
<t indent="0" pn="section-5.1.1-8"> <t>
The PKEY cryptosystem uses a hash-based key derivation function (HKDF) The PKEY cryptosystem uses an HMAC-based key derivation function (HKDF)
as defined in as defined in
<xref target="RFC5869" format="default" sectionFormat="of" derivedConte <xref target="RFC5869"/>, using SHA-512 <xref target="RFC6234"/> for th
nt="RFC5869"/>, using SHA-512 <xref target="RFC6234" format="default" sectionFor e extraction
mat="of" derivedContent="RFC6234"/> for the extraction phase and SHA-256 <xref target="RFC6234"/> for the expansion phase.
phase and SHA-256 <xref target="RFC6234" format="default" sectionFormat PRK_h is key material retrieved using an HKDF that uses the string
="of" derivedContent="RFC6234"/> for the expansion phase. "key-derivation" as the salt and the zone key as the initial
PRK_h is key material retrieved using an HKDF using the string
"key-derivation" as salt and the zone key as initial
keying material. keying material.
h is the 512-bit HKDF expansion result and must be interpreted in h is the 512-bit HKDF expansion result and must be interpreted in
network byte order. The expansion information input is network byte order. The expansion information input is
a concatenation of the label and the string "gns". a concatenation of the label and the string "gns".
The multiplication of zk with h is a point multiplication, The multiplication of zkey with h in ZKDF() is a point multiplication,
while the multiplication of d with h is a scalar multiplication. while the multiplication of d with h in SignDerived() below is a scalar
multiplication.
</t> </t>
<t indent="0" pn="section-5.1.1-9"> <t>
The Sign() and Verify() functions The Sign() and Verify() functions
for PKEY zones are implemented using 512-bit ECDSA deterministic for PKEY zones are implemented using 512-bit ECDSA deterministic
signatures as specified in <xref target="RFC6979" format="default" sect ionFormat="of" derivedContent="RFC6979"/>. signatures as specified in <xref target="RFC6979"/>.
The same functions can be used for derived keys: The same functions can be used for derived keys:
</t> </t>
<artwork name="" type="" align="left" alt="" pn="section-5.1.1-10"> <artwork name="" type="" alt="">
SignDerived(d,label,message): SignDerived(d, label, message):
zk := d * G zkey := d * G
PRK_h := HKDF-Extract ("key-derivation", zk) PRK_h := HKDF-Extract("key-derivation", zkey)
h := HKDF-Expand (PRK_h, label || "gns", 512 / 8) h := HKDF-Expand(PRK_h, label || "gns", 512 / 8)
d' := (h * d) mod L d' := (h * d) mod L
return Sign(d',message) return Sign(d', message)
</artwork> </artwork>
<t indent="0" pn="section-5.1.1-11"> <t>
A signature (R,S) is valid if the following holds: A signature is valid for the derived public key zkey' := ZKDF(zkey, l
abel) if the following holds:
</t> </t>
<artwork name="" type="" align="left" alt="" pn="section-5.1.1-12"> <artwork name="" type="" alt="">
VerifyDerived(zk,label,message,signature): VerifyDerived(zkey', message, signature):
zk' := ZKDF(zk,label) return Verify(zkey', message, signature)
return Verify(zk',message,signature)
</artwork> </artwork>
<t indent="0" pn="section-5.1.1-13"> <t>
The S-Encrypt() and S-Decrypt() functions use AES in counter mode The S-Encrypt() and S-Decrypt() functions use AES in counter mode
as defined in <xref target="MODES" format="default" sectionFormat="of" derivedContent="MODES"/> (CTR-AES-256): as defined in <xref target="MODES"/> (CTR-AES256):
</t> </t>
<artwork name="" type="" align="left" alt="" pn="section-5.1.1-14"> <artwork name="" type="" alt="">
S-Encrypt(zk,label,expiration,plaintext): S-Encrypt(zkey, label, expiration, plaintext):
PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk) PRK_k := HKDF-Extract("gns-aes-ctx-key", zkey)
PRK_n := HKDF-Extract ("gns-aes-ctx-iv", zk) PRK_n := HKDF-Extract("gns-aes-ctx-iv", zkey)
K := HKDF-Expand (PRK_k, label, 256 / 8) K := HKDF-Expand(PRK_k, label, 256 / 8)
NONCE := HKDF-Expand (PRK_n, label, 32 / 8) NONCE := HKDF-Expand(PRK_n, label, 32 / 8)
IV := NONCE || expiration || 0x0000000000000001 BLOCK_COUNTER := 0x0000000000000001
IV := NONCE || expiration || BLOCK_COUNTER
return CTR-AES256(K, IV, plaintext) return CTR-AES256(K, IV, plaintext)
S-Decrypt(zk,label,expiration,ciphertext): S-Decrypt(zkey, label, expiration, ciphertext):
PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk) PRK_k := HKDF-Extract("gns-aes-ctx-key", zkey)
PRK_n := HKDF-Extract ("gns-aes-ctx-iv", zk) PRK_n := HKDF-Extract("gns-aes-ctx-iv", zkey)
K := HKDF-Expand (PRK_k, label, 256 / 8) K := HKDF-Expand(PRK_k, label, 256 / 8)
NONCE := HKDF-Expand (PRK_n, label, 32 / 8) NONCE := HKDF-Expand(PRK_n, label, 32 / 8)
IV := NONCE || expiration || 0x0000000000000001 BLOCK_COUNTER := 0x0000000000000001
IV := NONCE || expiration || BLOCK_COUNTER
return CTR-AES256(K, IV, ciphertext) return CTR-AES256(K, IV, ciphertext)
</artwork> </artwork>
<t indent="0" pn="section-5.1.1-15"> <t>
The key K and counter IV are derived from The key K and counter Initialization Vector (IV) are derived from
the record label and the zone key zk using a hash-based key the record label and the zone key zkey, using an HKDF as defined in <xr
derivation function (HKDF) as defined in <xref target="RFC5869" format= ef target="RFC5869"/>.
"default" sectionFormat="of" derivedContent="RFC5869"/>. SHA-512 <xref target="RFC6234"/> is used for the
SHA-512 <xref target="RFC6234" format="default" sectionFormat="of" deri extraction phase and SHA-256 <xref target="RFC6234"/> for the expansion
vedContent="RFC6234"/> is used for the phase.
extraction phase and SHA-256 <xref target="RFC6234" format="default" se
ctionFormat="of" derivedContent="RFC6234"/> for the expansion phase.
The output keying material is 32 bytes (256 bits) for the symmetric The output keying material is 32 bytes (256 bits) for the symmetric
key and 4 bytes (32 bits) for the nonce. key and 4 bytes (32 bits) for the NONCE.
The symmetric key K is a 256-bit AES <xref target="RFC3826" format="def The symmetric key K is a 256-bit AES key <xref target="RFC3826"/>.
ault" sectionFormat="of" derivedContent="RFC3826"/> key.
</t> </t>
<t indent="0" pn="section-5.1.1-16"> <t>
The nonce is combined with a 64-bit initialization vector and a The nonce is combined with a 64-bit IV and a
32-bit block counter as defined in <xref target="RFC3686" format="defau 32-bit block counter as defined in <xref target="RFC3686"/>.
lt" sectionFormat="of" derivedContent="RFC3686"/>. The block counter begins with a value of 1, and it is incremented
The block counter begins with the value of 1, and it is incremented
to generate subsequent portions of the key stream. to generate subsequent portions of the key stream.
The block counter is a 32-bit integer value in network byte order. The block counter is a 32-bit integer value in network byte order.
The initialization vector is the expiration time of the The format of the counter IV used by the S-Encrypt() and S-Decrypt()
resource record block in network byte order. functions is illustrated in
The resulting counter (IV) wire format can be found in <xref target="figure_hkdf_ivs_pkey"/>.
<xref target="figure_hkdf_ivs_pkey" format="default" sectionFormat="of"
derivedContent="Figure 10"/>.
</t> </t>
<figure anchor="figure_hkdf_ivs_pkey" align="left" suppress-title="fal <figure anchor="figure_hkdf_ivs_pkey">
se" pn="figure-10"> <name>Structure of the Counter IV as Used in S-Encrypt() and
<name slugifiedName="name-the-block-counter-wire-form">The Block Cou S-Decrypt()</name>
nter Wire Format.</name> <artwork name="" type="" alt="">
<artwork name="" type="" align="left" alt="" pn="section-5.1.1-17.1"
>
0 8 16 24 32 0 8 16 24 32
+-----+-----+-----+-----+ +-----+-----+-----+-----+
| NONCE | | NONCE |
+-----+-----+-----+-----+ +-----+-----+-----+-----+
| EXPIRATION | | EXPIRATION |
| | | |
+-----+-----+-----+-----+ +-----+-----+-----+-----+
| BLOCK COUNTER | | BLOCK COUNTER |
+-----+-----+-----+-----+ +-----+-----+-----+-----+
</artwork> </artwork>
</figure> </figure>
</section> </section>
<section anchor="gnsrecords_edkey" numbered="true" toc="include" removeI <section anchor="gnsrecords_edkey">
nRFC="false" pn="section-5.1.2"> <name>EDKEY</name>
<name slugifiedName="name-edkey">EDKEY</name> <t>
<t indent="0" pn="section-5.1.2-1">
In GNS, a delegation of a label to a zone of type "EDKEY" is In GNS, a delegation of a label to a zone of type "EDKEY" is
represented through a EDKEY record. represented through an EDKEY record.
The EDKEY DATA entry wire format The EDKEY DATA entry wire format
is illustrated in <xref target="figure_edkeyrecord" format="default" se ctionFormat="of" derivedContent="Figure 11"/>. is illustrated in <xref target="figure_edkeyrecord"/>.
</t> </t>
<figure anchor="figure_edkeyrecord" align="left" suppress-title="false <figure anchor="figure_edkeyrecord">
" pn="figure-11"> <name>The EDKEY DATA Wire Format</name>
<name slugifiedName="name-the-edkey-data-wire-format">The EDKEY DATA <artwork name="" type="" alt="">
Wire Format.</name>
<artwork name="" type="" align="left" alt="" pn="section-5.1.2-2.1">
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| PUBLIC KEY | | PUBLIC KEY |
| | | |
| | | |
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
</artwork> </artwork>
</figure> </figure>
<dl indent="3" newline="false" spacing="normal" pn="section-5.1.2-3"> <dl newline="false">
<dt pn="section-5.1.2-3.1">PUBLIC KEY</dt> <dt>PUBLIC KEY:</dt>
<dd pn="section-5.1.2-3.2"> <dd>
A 256-bit EdDSA zone key. A 256-bit EdDSA zone key.
</dd> </dd>
</dl> </dl>
<t indent="0" pn="section-5.1.2-4"> <t>
For EDKEY zones the zone key material is derived using the For EDKEY zones, the zone key material is derived using the
curve parameters of the twisted edwards representation curve parameters of the twisted Edwards representation
of Curve25519 <xref target="RFC7748" format="default" sectionFormat=" of Curve25519 <xref target="RFC7748"/> (a.k.a.&nbsp;Ed25519)
of" derivedContent="RFC7748"/> (a.k.a. Ed25519) with the Ed25519 scheme <xref target="ed25519"/> as specified in
with the Ed25519 scheme <xref target="ed25519" format="default" secti <xref target="RFC8032"/>.
onFormat="of" derivedContent="ed25519"/> as specified in
<xref target="RFC8032" format="default" sectionFormat="of" derivedCon
tent="RFC8032"/>.
The following naming convention is used for the The following naming convention is used for the
cryptographic primitives of EDKEY zones: cryptographic primitives of EDKEY zones:
</t> </t>
<!-- Check if we want to use RFC8032 instead of paper ed25519 --> <dl newline="false">
<dl indent="3" newline="false" spacing="normal" pn="section-5.1.2-5"> <dt>d:</dt>
<dt pn="section-5.1.2-5.1">d</dt> <dd>
<dd pn="section-5.1.2-5.2"> A 256-bit EdDSA private key.
is a 256-bit EdDSA private key.
</dd> </dd>
<dt pn="section-5.1.2-5.3">a</dt> <dt>a:</dt>
<dd pn="section-5.1.2-5.4"> <dd>
is is an integer derived from d using the SHA-512 hash function An integer derived from d using the SHA-512 hash function
as defined in <xref target="RFC8032" format="default" sectionFormat as defined in <xref target="RFC8032"/>.
="of" derivedContent="RFC8032"/>.
</dd> </dd>
<dt pn="section-5.1.2-5.5">zk</dt> <dt>zkey:</dt>
<dd pn="section-5.1.2-5.6"> <dd>
is the EdDSA public key corresponding to d. It is defined The EdDSA public key corresponding to d. It is defined
as the curve point a*G where G is the as the curve point a*G where G is the
group generator of the elliptic curve group generator of the elliptic curve
as defined in <xref target="RFC8032" format="default" sectionFormat ="of" derivedContent="RFC8032"/>. as defined in <xref target="RFC8032"/>.
</dd> </dd>
<dt pn="section-5.1.2-5.7">p</dt> <dt>p:</dt>
<dd pn="section-5.1.2-5.8"> <dd>
is the prime of edwards25519 as defined in <xref target="RFC8032" f The prime of edwards25519 as defined in <xref target="RFC8032"/>, i
ormat="default" sectionFormat="of" derivedContent="RFC8032"/>, i.e. .e.,
2^255 - 19. 2<sup>255</sup> - 19.
</dd> </dd>
<dt pn="section-5.1.2-5.9">G</dt> <dt>G:</dt>
<dd pn="section-5.1.2-5.10"> <dd>
is the group generator (X(P),Y(P)). With X(P),Y(P) of edwards25519 The group generator (X(P),Y(P)). With X(P),Y(P) of edwards25519 as
as defined in defined in
<xref target="RFC8032" format="default" sectionFormat="of" derived <xref target="RFC8032"/>.
Content="RFC8032"/>.
</dd> </dd>
<dt pn="section-5.1.2-5.11">L</dt> <dt>L:</dt>
<dd pn="section-5.1.2-5.12"> <dd>
is the order of the prime-order subgroup of edwards25519 in <xref t The order of the prime-order subgroup of edwards25519 as defined in
arget="RFC8032" format="default" sectionFormat="of" derivedContent="RFC8032"/>. <xref target="RFC8032"/>.
</dd> </dd>
<dt pn="section-5.1.2-5.13">KeyGen()</dt> <dt>KeyGen():</dt>
<dd pn="section-5.1.2-5.14"> <dd>
The generation of the private key d and the associated public The generation of the private key d and the associated public
key zk := a*G where G is the key zkey := a*G (where G is the
group generator of the elliptic curve and a is an integer group generator of the elliptic curve and a is an integer
derived from d using the SHA-512 hash function derived from d using the SHA-512 hash function)
as defined as defined
in Section 5.1.5 of <xref target="RFC8032" format="default" section in <xref target="RFC8032" sectionFormat="of" section="5.1.5"/>
Format="of" derivedContent="RFC8032"/> represents the KeyGen() represents the KeyGen()
function. function.
</dd> </dd>
</dl> </dl>
<t indent="0" pn="section-5.1.2-6"> <t>
The zone type and zone key of an EDKEY are 4 + 32 bytes in length. Th is means that The zone type and zone key of an EDKEY are 4 + 32 bytes in length. Th is means that
a zTLD will always fit into a single label and does a zTLD will always fit into a single label and does
not need any further conversion. not need any further conversion.
</t> </t>
<t indent="0" pn="section-5.1.2-7"> <t>
The "EDKEY" ZKDF instantiation is based on <xref target="Tor224" form The "EDKEY" ZKDF instantiation is based on <xref target="Tor224"/>.
at="default" sectionFormat="of" derivedContent="Tor224"/>. As noted above for KeyGen(), a is calculated from d using the
The calculation of a is defined in Section 5.1.5 of <xref target="RFC SHA-512 hash function as defined in <xref target="RFC8032" sectionFor
8032" format="default" sectionFormat="of" derivedContent="RFC8032"/>. mat="of" section="5.1.5"/>.
Given a label, the output of the ZKDF function is Given a label, the output of the ZKDF function is
calculated as follows: calculated as follows:
</t> </t>
<artwork name="" type="" align="left" alt="" pn="section-5.1.2-8"> <artwork name="" type="" alt="">
ZKDF(zk,label): ZKDF(zkey, label):
/* Calculate the blinding factor */ /* Calculate the blinding factor */
PRK_h := HKDF-Extract ("key-derivation", zk) PRK_h := HKDF-Extract("key-derivation", zkey)
h := HKDF-Expand (PRK_h, label || "gns", 512 / 8) h := HKDF-Expand(PRK_h, label || "gns", 512 / 8)
/* Ensure that h == h mod L */ /* Ensure that h == h mod L */
h[31] &amp;= 7 h := h mod L
zk' := h * zk zkey' := h * zkey
return zk' return zkey'
</artwork> </artwork>
<t indent="0" pn="section-5.1.2-9"> <t>
Implementers <bcp14>SHOULD</bcp14> employ a constant time scalar Implementers <bcp14>SHOULD</bcp14> employ a constant-time scalar
multiplication for the constructions above to protect against multiplication for the constructions above to protect against
timing attacks. Otherwise, timing attacks could leak private key timing attacks. Otherwise, timing attacks could leak private key
material if an attacker can predict when a system starts the material if an attacker can predict when a system starts the
publication process. publication process.
<!--Also, implementers
<bcp14>MUST</bcp14> ensure that the private key a is an ed25519 priva
te key
and specifically that "a[0] &#38; 7 == 0" holds.-->
</t> </t>
<t indent="0" pn="section-5.1.2-10"> <t>
The EDKEY cryptosystem uses a The EDKEY cryptosystem uses an HKDF as defined in
hash-based key derivation function (HKDF) as defined in <xref target="RFC5869"/>, using SHA-512 <xref target="RFC6234"/> for
<xref target="RFC5869" format="default" sectionFormat="of" derivedCon the extraction
tent="RFC5869"/>, using SHA-512 <xref target="RFC6234" format="default" sectionF phase and HMAC-SHA-256 <xref target="RFC6234"/> for the expansion pha
ormat="of" derivedContent="RFC6234"/> for the extraction se.
phase and HMAC-SHA256 <xref target="RFC6234" format="default" section PRK_h is key material retrieved using an HKDF that uses the string
Format="of" derivedContent="RFC6234"/> for the expansion phase. "key-derivation" as the salt and the zone key as the initial
PRK_h is key material retrieved using an HKDF using the string
"key-derivation" as salt and the zone key as initial
keying material. keying material.
The blinding factor h is the 512-bit HKDF expansion result. The blinding factor h is the 512-bit HKDF expansion result.
The expansion information input is The expansion information input is
a concatenation of the label and the string "gns". a concatenation of the label and the string "gns".
The result of the HKDF must be clamped and interpreted in network The result of the HKDF must be clamped and interpreted in network
byte order. byte order.
a is the 256-bit integer corresponding to the 256-bit private a is the 256-bit integer corresponding to the 256-bit private
key d. key d.
The multiplication of zk with h is a point multiplication, The multiplication of zkey with h is a point multiplication.
while the division and multiplication of a and a1 with the
co-factor are integer operations.
</t> </t>
<t indent="0" pn="section-5.1.2-11"> <t>
The Sign(d,message) and Verify(zk,message,signature) procedures <bcp1 The Sign(d, message) and Verify(zkey, message, signature) procedures
4>MUST</bcp14> <bcp14>MUST</bcp14>
be implemented as defined in <xref target="RFC8032" format="default" be implemented as defined in <xref target="RFC8032"/>.
sectionFormat="of" derivedContent="RFC8032"/>.
</t> </t>
<t indent="0" pn="section-5.1.2-12"> <t>
Signatures for EDKEY zones use a derived private scalar d' Signatures for EDKEY zones use a derived private scalar d';
which is not compliant with <xref target="RFC8032" format="default" s this is not compliant with <xref target="RFC8032"/>.
ectionFormat="of" derivedContent="RFC8032"/>. As the private key that corresponds to the derived private scalar
As the corresponding private key to the derived private scalar
is not known, it is not possible to deterministically derive the is not known, it is not possible to deterministically derive the
signature part R according to <xref target="RFC8032" format="default" sectionFormat="of" derivedContent="RFC8032"/>. signature part R according to <xref target="RFC8032"/>.
Instead, signatures <bcp14>MUST</bcp14> be generated as follows for a ny given Instead, signatures <bcp14>MUST</bcp14> be generated as follows for a ny given
message and private zone key: message and private zone key:
A nonce is calculated from the highest 32 bytes of the a nonce is calculated from the highest 32 bytes of the
expansion of the private key d and the blinding factor h. expansion of the private key d and the blinding factor h.
The nonce is then hashed with the message to r. The nonce is then hashed with the message to r.
This way, the full derivation path is included in the calculation This way, the full derivation path is included in the calculation
of the R value of the signature, ensuring that it is never reused of the R value of the signature, ensuring that it is never reused
for two different derivation paths or messages. for two different derivation paths or messages.
</t> </t>
<artwork name="" type="" align="left" alt="" pn="section-5.1.2-13"> <artwork name="" type="" alt="">
SignDerived(d,label,message): SignDerived(d, label, message):
/* Key expansion */ /* Key expansion */
dh := SHA-512 (d) dh := SHA-512(d)
/* EdDSA clamping */ /* EdDSA clamping */
a := dh[0..31] a := dh[0..31]
a[0] &amp;= 248 a[0] := a[0] &amp; 248
a[31] &amp;= 127 a[31] := a[31] &amp; 127
a[31] |= 64 a[31] := a[31] | 64
/* Calculate zk corresponding to d */ /* Calculate zkey corresponding to d */
zk := a * G zkey := a * G
/* Calculate blinding factor */ /* Calculate blinding factor */
PRK_h := HKDF-Extract ("key-derivation", zk) PRK_h := HKDF-Extract("key-derivation", zkey)
h := HKDF-Expand (PRK_h, label || "gns", 512 / 8) h := HKDF-Expand(PRK_h, label || "gns", 512 / 8)
/* Ensure that h == h mod L */ /* Ensure that h == h mod L */
h[31] &amp;= 7 h := h mod L
zk' := h * zk d' := (h * a) mod L
a1 := a &gt;&gt; 3 nonce := SHA-256(dh[32..63] || h)
a2 := (h * a1) mod L r := SHA-512(nonce || message)
d' := a2 &lt;&lt; 3
nonce := SHA-256 (dh[32..63] || h)
r := SHA-512 (nonce || message)
R := r * G R := r * G
S := r + SHA-512(R || zk' || message) * d' mod L S := r + SHA-512(R || zkey' || message) * d' mod L
return (R,S) return (R,S)
</artwork> </artwork>
<t indent="0" pn="section-5.1.2-14"> <t>
A signature (R,S) is valid if the following holds: A signature (R,S) is valid for the derived public key zkey' :=
ZKDF(zkey, label) if the following holds:
</t> </t>
<artwork name="" type="" align="left" alt="" pn="section-5.1.2-15"> <artwork name="" type="" alt="">
VerifyDerived(zk,label,message,signature): VerifyDerived(zkey', message, signature):
zk' := ZKDF(zk,label)
(R,S) := signature (R,S) := signature
return S * G == R + SHA-512(R, zk', message) * zk' return S * G == R + SHA-512(R, zkey', message) * zkey'
</artwork> </artwork>
<t indent="0" pn="section-5.1.2-16"> <t>
The S-Encrypt() and S-Decrypt() functions use XSalsa20 The S-Encrypt() and S-Decrypt() functions use XSalsa20
as defined in <xref target="XSalsa20" format="default" sectionFormat= as defined in <xref target="XSalsa20"/>
"of" derivedContent="XSalsa20"/> and use the XSalsa20-Poly1305 encryption function:
(XSalsa20-Poly1305):
</t> </t>
<artwork name="" type="" align="left" alt="" pn="section-5.1.2-17"> <artwork name="" type="" alt="">
S-Encrypt(zk,label,expiration,plaintext): S-Encrypt(zkey, label, expiration, plaintext):
PRK_k := HKDF-Extract ("gns-xsalsa-ctx-key", zk) PRK_k := HKDF-Extract("gns-xsalsa-ctx-key", zkey)
PRK_n := HKDF-Extract ("gns-xsalsa-ctx-iv", zk) PRK_n := HKDF-Extract("gns-xsalsa-ctx-iv", zkey)
K := HKDF-Expand (PRK_k, label, 256 / 8) K := HKDF-Expand(PRK_k, label, 256 / 8)
NONCE := HKDF-Expand (PRK_n, label, 128 / 8) NONCE := HKDF-Expand(PRK_n, label, 128 / 8)
IV := NONCE || expiration IV := NONCE || expiration
return XSalsa20-Poly1305(K, IV, plaintext) return XSalsa20-Poly1305(K, IV, plaintext)
S-Decrypt(zk,label,expiration,ciphertext): S-Decrypt(zkey, label, expiration, ciphertext):
PRK_k := HKDF-Extract ("gns-xsalsa-ctx-key", zk) PRK_k := HKDF-Extract("gns-xsalsa-ctx-key", zkey)
PRK_n := HKDF-Extract ("gns-xsalsa-ctx-iv", zk) PRK_n := HKDF-Extract("gns-xsalsa-ctx-iv", zkey)
K := HKDF-Expand (PRK_k, label, 256 / 8) K := HKDF-Expand(PRK_k, label, 256 / 8)
NONCE := HKDF-Expand (PRK_n, label, 128 / 8) NONCE := HKDF-Expand(PRK_n, label, 128 / 8)
IV := NONCE || expiration IV := NONCE || expiration
return XSalsa20-Poly1305(K, IV, ciphertext) return XSalsa20-Poly1305(K, IV, ciphertext)
</artwork> </artwork>
<t indent="0" pn="section-5.1.2-18"> <t>
The result of the XSalsa20-Poly1305 encryption function is the encryp ted The result of the XSalsa20-Poly1305 encryption function is the encryp ted
ciphertext followed by the 128-bit authentication ciphertext followed by the 128-bit authentication
tag. tag.
Accordingly, the length of encrypted data equals the length of the Accordingly, the length of encrypted data equals the length of the
data plus the 16 bytes of the authentication tag. data plus the 16 bytes of the authentication tag.
</t> </t>
<t indent="0" pn="section-5.1.2-19"> <t>
The key K and counter IV are derived from The key K and counter IV are derived from
the record label and the zone key zk using a hash-based key the record label and the zone key zkey using an HKDF as defined in
derivation function (HKDF) as defined in <xref target="RFC5869"/>.
<xref target="RFC5869" format="default" sectionFormat="of" derivedCon SHA-512 <xref target="RFC6234"/> is used for the
tent="RFC5869"/>. extraction phase and SHA-256 <xref target="RFC6234"/> for the expansi
SHA-512 <xref target="RFC6234" format="default" sectionFormat="of" de on phase.
rivedContent="RFC6234"/> is used for the
extraction phase and SHA-256 <xref target="RFC6234" format="default"
sectionFormat="of" derivedContent="RFC6234"/> for the expansion phase.
The output keying material is 32 bytes (256 bits) for the symmetric The output keying material is 32 bytes (256 bits) for the symmetric
key and 16 bytes (128 bits) for the NONCE. key and 16 bytes (128 bits) for the NONCE.
The symmetric key K is a 256-bit XSalsa20 The symmetric key K is a 256-bit XSalsa20 key
<xref target="XSalsa20" format="default" sectionFormat="of" derivedCo <xref target="XSalsa20"/>.
ntent="XSalsa20"/> key.
No additional authenticated data (AAD) is used. No additional authenticated data (AAD) is used.
</t> </t>
<t indent="0" pn="section-5.1.2-20"> <t>
The nonce is combined with an 8 byte initialization vector. The nonce is combined with an 8-byte IV.
The initialization vector is the expiration time of the The IV is the expiration time of the
resource record block in network byte order. resource record block in network byte order.
The resulting counter (IV) wire format is illustrated in The resulting counter (IV) wire format is illustrated in
<xref target="figure_hkdf_ivs_edkey" format="default" sectionFormat=" of" derivedContent="Figure 12"/>. <xref target="figure_hkdf_ivs_edkey"/>.
</t> </t>
<figure anchor="figure_hkdf_ivs_edkey" align="left" suppress-title="fa <figure anchor="figure_hkdf_ivs_edkey">
lse" pn="figure-12"> <name>The Counter Block Initialization Vector</name>
<name slugifiedName="name-the-counter-block-initializ">The Counter B <artwork name="" type="" alt="">
lock Initialization Vector.</name> 0 8 16 24 32 40 48 56
<artwork name="" type="" align="left" alt="" pn="section-5.1.2-21.1" +-----+-----+-----+-----+-----+-----+-----+-----+
> | NONCE |
0 8 16 24 32 | |
+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| NONCE | | EXPIRATION |
| | +-----+-----+-----+-----+-----+-----+-----+-----+
| |
| |
+-----+-----+-----+-----+
| EXPIRATION |
| |
+-----+-----+-----+-----+
</artwork> </artwork>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="gnsrecords_redirect" numbered="true" toc="include" remove <section anchor="gnsrecords_redirect">
InRFC="false" pn="section-5.2"> <name>Redirection Records</name>
<name slugifiedName="name-redirection-records">Redirection Records</name <t>
> Redirection records are used to redirect resolution.
<t indent="0" pn="section-5.2-1">
Redirect records are used to redirect resolution.
Any implementation <bcp14>SHOULD</bcp14> support all redirection record t ypes defined here Any implementation <bcp14>SHOULD</bcp14> support all redirection record t ypes defined here
and <bcp14>MAY</bcp14> support any number of additional redirection recor ds defined in and <bcp14>MAY</bcp14> support any number of additional redirection recor ds defined in
the GANA "GNS Record Types" registry <xref target="GANA" format="default" sectionFormat="of" derivedContent="GANA"/>. the GANA "GNS Record Types" registry <xref target="GANA"/>.
Redirection records <bcp14>MUST</bcp14> have the CRITICAL flag set. Redirection records <bcp14>MUST</bcp14> have the CRITICAL flag set.
Not supporting some record types can result in resolution failures. Not supporting some record types can result in resolution failures.
This can be a valid choice if some redirection record types have been This can be a valid choice if some redirection record types have been
determined to be insecure, or if an application has reasons to not determined to be insecure, or if an application has reasons to not
support redirection to DNS for reasons such as complexity or security. support redirection to DNS for reasons such as complexity or security.
Redirection records <bcp14>MUST NOT</bcp14> be stored and published under the apex label. Redirection records <bcp14>MUST NOT</bcp14> be stored or published under the apex label.
</t> </t>
<section anchor="gnsrecords_rdr" numbered="true" toc="include" removeInR <section anchor="gnsrecords_rdr">
FC="false" pn="section-5.2.1"> <name>REDIRECT</name>
<name slugifiedName="name-redirect">REDIRECT</name> <t>
<t indent="0" pn="section-5.2.1-1">
A REDIRECT record is the GNS equivalent of a CNAME record in DNS. A REDIRECT record is the GNS equivalent of a CNAME record in DNS.
A REDIRECT record <bcp14>MUST</bcp14> be the only non-supplemental A REDIRECT record <bcp14>MUST</bcp14> be the only non-supplemental
record under a label. record under a label.
There <bcp14>MAY</bcp14> be inactive records of the same type which hav e There <bcp14>MAY</bcp14> be inactive records of the same type that have
the SHADOW flag set in order to facilitate smooth changes of redirectio n the SHADOW flag set in order to facilitate smooth changes of redirectio n
targets. targets.
No other records are allowed. No other records are allowed.
Details on processing of this record is defined in <xref target="redire ct_processing" format="default" sectionFormat="of" derivedContent="Section 7.3.1 "/>. Details on the processing of this record are provided in <xref target=" redirect_processing"/>.
A REDIRECT DATA entry is illustrated in <xref target="figure_redirectre cord" format="default" sectionFormat="of" derivedContent="Figure 13"/>. A REDIRECT DATA entry is illustrated in <xref target="figure_redirectre cord"/>.
</t> </t>
<figure anchor="figure_redirectrecord" align="left" suppress-title="fa <figure anchor="figure_redirectrecord">
lse" pn="figure-13"> <name>The REDIRECT DATA Wire Format</name>
<name slugifiedName="name-the-redirect-data-wire-form">The REDIRECT <artwork name="" type="" alt="">
DATA Wire Format.</name>
<artwork name="" type="" align="left" alt="" pn="section-5.2.1-2.1">
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| REDIRECT NAME | | REDIRECT NAME |
/ / / /
/ / / /
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
</artwork> </artwork>
</figure> </figure>
<dl indent="3" newline="false" spacing="normal" pn="section-5.2.1-3"> <dl newline="false">
<dt pn="section-5.2.1-3.1">REDIRECT NAME</dt> <dt>REDIRECT NAME:</dt>
<dd pn="section-5.2.1-3.2"> <dd>
The name to continue with. The name to continue with.
The value of a redirect record can be a regular name, or a relative This value can be a regular name or a relative
name. name.
Relative GNS names are indicated by an extension label (U+002B, "+") Relative GNS names are indicated by an extension label (U+002B ("+"))
as rightmost label. as the rightmost label.
The string is UTF-8 encoded and 0-terminated. The string is UTF-8 encoded and zero terminated.
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="gnsrecords_gns2dns" numbered="true" toc="include" remov <section anchor="gnsrecords_gns2dns">
eInRFC="false" pn="section-5.2.2"> <name>GNS2DNS</name>
<name slugifiedName="name-gns2dns">GNS2DNS</name> <t>
<t indent="0" pn="section-5.2.2-1">
A GNS2DNS record delegates resolution to DNS. A GNS2DNS record delegates resolution to DNS.
The resource record contains a DNS name for the resolver to continue wi th The resource record contains a DNS name for the resolver to continue wi th
in DNS followed by a DNS server. Both names are in the format defined i n in DNS followed by a DNS server. Both names are in the format defined i n
<xref target="RFC1034" format="default" sectionFormat="of" derivedConte nt="RFC1034"/> for DNS names. <xref target="RFC1034"/> for DNS names.
There <bcp14>MAY</bcp14> be multiple GNS2DNS records under a label. There <bcp14>MAY</bcp14> be multiple GNS2DNS records under a label.
There <bcp14>MAY</bcp14> also be DNSSEC DS records or any other records used to There <bcp14>MAY</bcp14> also be DNSSEC DS records or any other records used to
secure the connection with the DNS servers under the same label. secure the connection with the DNS servers under the same label.
There <bcp14>MAY</bcp14> be inactive records of the same type(s) which have There <bcp14>MAY</bcp14> be inactive records of the same type or types that have
the SHADOW flag set in order to facilitate smooth changes of redirectio n the SHADOW flag set in order to facilitate smooth changes of redirectio n
targets. targets.
No other non-supplemental record types are allowed in the same record s et. No other non-supplemental record types are allowed in the same record s et.
A GNS2DNS DATA entry is illustrated in <xref target="figure_gns2dnsreco A GNS2DNS DATA entry is illustrated in <xref target="figure_gns2dnsreco
rd" format="default" sectionFormat="of" derivedContent="Figure 14"/>.</t> rd"/>.</t>
<figure anchor="figure_gns2dnsrecord" align="left" suppress-title="fal <figure anchor="figure_gns2dnsrecord">
se" pn="figure-14"> <name>The GNS2DNS DATA Wire Format</name>
<name slugifiedName="name-the-gns2dns-data-wire-forma">The GNS2DNS D <artwork name="" type="" alt="">
ATA Wire Format.</name>
<artwork name="" type="" align="left" alt="" pn="section-5.2.2-2.1">
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| NAME | | NAME |
/ / / /
/ / / /
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| DNS SERVER NAME | | DNS SERVER NAME |
/ / / /
/ / / /
| | | |
+-----------------------------------------------+ +-----------------------------------------------+
</artwork> </artwork>
</figure> </figure>
<dl indent="3" newline="false" spacing="normal" pn="section-5.2.2-3"> <dl newline="false">
<dt pn="section-5.2.2-3.1">NAME</dt> <dt>NAME:</dt>
<dd pn="section-5.2.2-3.2"> <dd>
The name to continue with in DNS. The value is UTF-8 encoded and The name to continue with in DNS. The value is UTF-8 encoded and
0-terminated. zero terminated.
</dd> </dd>
<dt pn="section-5.2.2-3.3">DNS SERVER NAME</dt> <dt>DNS SERVER NAME:</dt>
<dd pn="section-5.2.2-3.4"> <dd>
The DNS server to use. This value can be an IPv4 address in dotted-de cimal The DNS server to use. This value can be an IPv4 address in dotted-de cimal
form or an IPv6 address in colon-hexadecimal form or a DNS name. form, an IPv6 address in colon-hexadecimal form, or a DNS name.
It can also be a relative GNS name ending with a It can also be a relative GNS name ending with a
"+" as the rightmost label. "+" as the rightmost label.
The implementation <bcp14>MUST</bcp14> check the string syntactically for The implementation <bcp14>MUST</bcp14> check the string syntactically for
an IP address in the respective notation before checking for a an IP address in the respective notation before checking for a
relative GNS name. relative GNS name.
If all three checks fail, the name <bcp14>MUST</bcp14> be treated as a DNS name. If all three checks fail, the name <bcp14>MUST</bcp14> be treated as a DNS name.
The value is UTF-8 encoded and 0-terminated. The value is UTF-8 encoded and zero terminated.
</dd> </dd>
</dl> </dl>
<t indent="0" pn="section-5.2.2-4"> <t>
NOTE: If an application uses DNS names obtained from GNS2DNS records NOTE: If an application uses DNS names obtained from GNS2DNS records
in a DNS request they <bcp14>MUST</bcp14> first be converted to an IDNA in a DNS request, they <bcp14>MUST</bcp14> first be converted to an IDN
compliant A-compliant
representation <xref target="RFC5890" format="default" sectionFormat="o representation <xref target="RFC5890"/>.
f" derivedContent="RFC5890"/>.
</t> </t>
</section> </section>
</section> </section>
<section anchor="gnsrecords_other" numbered="true" toc="include" removeInR <section anchor="gnsrecords_other">
FC="false" pn="section-5.3"> <name>Auxiliary Records</name>
<name slugifiedName="name-auxiliary-records">Auxiliary Records</name> <t>
<t indent="0" pn="section-5.3-1">
This section defines the initial set of auxiliary GNS record types. Any This section defines the initial set of auxiliary GNS record types. Any
implementation <bcp14>SHOULD</bcp14> be able to process the specified r ecord types implementation <bcp14>SHOULD</bcp14> be able to process the specified r ecord types
according to <xref target="record_processing" format="default" sectionF ormat="of" derivedContent="Section 7.3"/>. according to <xref target="record_processing"/>.
</t> </t>
<section anchor="gnsrecords_leho" numbered="true" toc="include" removeIn <section anchor="gnsrecords_leho">
RFC="false" pn="section-5.3.1"> <name>LEHO</name>
<name slugifiedName="name-leho">LEHO</name> <t>
<t indent="0" pn="section-5.3.1-1"> The LEHO (LEgacy HOstname) record is used to provide a hint for legacy
This record is used to provide a hint for LEgacy HOstnames: hostnames:
Applications can use the GNS to lookup IPv4 or IPv6 addresses of applications can use the GNS to look up IPv4 or IPv6 addresses of
internet services. Internet services.
However, sometimes connecting to such services does not only require However, connecting to such services sometimes not only requires
the knowledge of an address and port, but also requires the canonical the knowledge of an IP address and port but also requires the canonical
DNS name of the service to be transmitted over the transport protocol. DNS name of the service to be transmitted over the transport protocol.
In GNS, legacy host name records provide applications the DNS name that In GNS, legacy hostname records provide applications the DNS name that
is required to establish a connection to such a service. is required to establish a connection to such a service.
The most common use case is HTTP virtual hosting and TLS Server Name The most common use case is HTTP virtual hosting and TLS Server Name
Indication <xref target="RFC6066" format="default" sectionFormat="of" d erivedContent="RFC6066"/>, where a DNS name must Indication <xref target="RFC6066"/>, where a DNS name must
be supplied in the HTTP "Host"-header and the TLS handshake, be supplied in the HTTP "Host"-header and the TLS handshake,
respectively. respectively.
Using a GNS name in those cases might not work as Using a GNS name in those cases might not work, as
it might not be globally unique. Furthermore, even if uniqueness is it might not be globally unique. Furthermore, even if uniqueness is
not an issue, the legacy service might not even be aware of GNS. not an issue, the legacy service might not even be aware of GNS.
</t> </t>
<t indent="0" pn="section-5.3.1-2"> <t>
A LEHO resource record is expected to be found together in a single A LEHO resource record is expected to be found together with A or AAAA
resource record with an IPv4 or IPv6 address. resource records with IPv4 or IPv6 addresses.
A LEHO DATA entry is illustrated in <xref target="figure_lehorecord" A LEHO DATA entry is illustrated in <xref target="figure_lehorecord"/
format="default" sectionFormat="of" derivedContent="Figure 15"/>. >.
</t> </t>
<figure anchor="figure_lehorecord" align="left" suppress-title="false" <figure anchor="figure_lehorecord">
pn="figure-15"> <name>The LEHO DATA Wire Format</name>
<name slugifiedName="name-the-leho-data-wire-format">The LEHO DATA W <artwork name="" type="" alt="">
ire Format.</name>
<artwork name="" type="" align="left" alt="" pn="section-5.3.1-3.1">
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| LEGACY HOSTNAME | | LEGACY HOSTNAME |
/ / / /
/ / / /
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
</artwork> </artwork>
</figure> </figure>
<dl indent="3" newline="false" spacing="normal" pn="section-5.3.1-4"> <dl newline="false">
<dt pn="section-5.3.1-4.1">LEGACY HOSTNAME</dt> <dt>LEGACY HOSTNAME:</dt>
<dd pn="section-5.3.1-4.2"> <dd>
A UTF-8 string (which is not 0-terminated) representing the legacy ho A UTF-8 string (which is not zero terminated) representing the legacy
stname. hostname.
</dd> </dd>
</dl> </dl>
<t indent="0" pn="section-5.3.1-5"> <t>
NOTE: If an application uses a LEHO value in an HTTP request header NOTE: If an application uses a LEHO value in an HTTP request header
(e.g. "Host:" header) it <bcp14>MUST</bcp14> be converted to an IDNA co (e.g., a "Host"-header), it <bcp14>MUST</bcp14> be converted to an IDNA
mpliant representation -compliant representation
<xref target="RFC5890" format="default" sectionFormat="of" derivedConte <xref target="RFC5890"/>.
nt="RFC5890"/>.
</t> </t>
</section> </section>
<section anchor="gnsrecords_nick" numbered="true" toc="include" removeIn <section anchor="gnsrecords_nick">
RFC="false" pn="section-5.3.2"> <name>NICK</name>
<name slugifiedName="name-nick">NICK</name> <t>
<t indent="0" pn="section-5.3.2-1">
Nickname records can be used by zone administrators to publish a Nickname records can be used by zone administrators to publish a
label that a zone prefers to have used when it is referred to. label that a zone prefers to have used when it is referred to.
This is a suggestion to other zones what label to use when creating a This is a suggestion for other zones regarding what label to use when c
delegation record (<xref target="gnsrecords_delegation" format="default reating a
" sectionFormat="of" derivedContent="Section 5.1"/>) containing delegation record (<xref target="gnsrecords_delegation"/>) containing
this zone key. this zone key.
This record <bcp14>SHOULD</bcp14> only be stored locally This record <bcp14>SHOULD</bcp14> only be stored locally
under the apex label "@" but <bcp14>MAY</bcp14> be under the apex label "@" but <bcp14>MAY</bcp14> be
returned with record sets under any label as a supplemental record. returned with record sets under any label as a supplemental record.
<xref target="nick_processing" format="default" sectionFormat="of" deri vedContent="Section 7.3.5"/> details how a resolver must process <xref target="nick_processing"/> details how a resolver must process
supplemental and non-supplemental NICK records. supplemental and non-supplemental NICK records.
A NICK DATA entry is illustrated in <xref target="figure_nickrecord" fo rmat="default" sectionFormat="of" derivedContent="Figure 16"/>. A NICK DATA entry is illustrated in <xref target="figure_nickrecord"/>.
</t> </t>
<figure anchor="figure_nickrecord" align="left" suppress-title="false" <figure anchor="figure_nickrecord">
pn="figure-16"> <name>The NICK DATA Wire Format</name>
<name slugifiedName="name-the-nick-data-wire-format">The NICK DATA W <artwork name="" type="" alt="">
ire Format.</name>
<artwork name="" type="" align="left" alt="" pn="section-5.3.2-2.1">
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| NICKNAME | | NICKNAME |
/ / / /
/ / / /
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
</artwork> </artwork>
</figure> </figure>
<dl indent="3" newline="false" spacing="normal" pn="section-5.3.2-3"> <dl newline="false">
<dt pn="section-5.3.2-3.1">NICKNAME</dt> <dt>NICKNAME:</dt>
<dd pn="section-5.3.2-3.2"> <dd>
A UTF-8 string (which is not 0-terminated) representing the preferred A UTF-8 string (which is not zero terminated) representing the prefer
red
label of the zone. This string <bcp14>MUST</bcp14> be a valid GNS lab el. label of the zone. This string <bcp14>MUST</bcp14> be a valid GNS lab el.
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="gnsrecords_box" numbered="true" toc="include" removeInR <section anchor="gnsrecords_box">
FC="false" pn="section-5.3.3"> <name>BOX</name>
<name slugifiedName="name-box">BOX</name> <t>
<t indent="0" pn="section-5.3.3-1">
GNS lookups are expected to return all of the required useful GNS lookups are expected to return all of the required useful
information in one record set. This avoids unnecessary additional information in one record set. This avoids unnecessary additional
lookups and cryptographically ties together information that belongs lookups and cryptographically ties together information that belongs
together, making it impossible for an adversarial storage to provide together, making it impossible for an adversarial storage entity to pro vide
partial answers that might omit information critical for security. partial answers that might omit information critical for security.
</t> </t>
<t indent="0" pn="section-5.3.3-2"> <t>
This general strategy is incompatible with the This general strategy is incompatible with the
special labels used by DNS for SRV and TLSA records. Thus, GNS special labels used by DNS for SRV and TLSA records. Thus, GNS
defines the BOX record format to box up SRV and TLSA records and defines the BOX record format to box up SRV and TLSA records and
include them in the record set of the label they are associated include them in the record set of the label they are associated
with. For example, a with. For example, a
TLSA record for "_https._tcp.example.org" will be stored in the record set of TLSA record for "_https._tcp.example.org" will be stored in the record set of
"example.org" as a BOX record with service (SVC) 443 (https) and protoc "example.org" as a BOX record with service (SVC) 443 (https), protocol
ol (PROTO) 6 (PROTO) 6
(tcp) and record TYPE "TLSA". (tcp), and record TYPE "TLSA".
For reference, see also <xref target="RFC2782" format="default" section For reference, see also <xref target="RFC2782"/>.
Format="of" derivedContent="RFC2782"/>. A BOX DATA entry is illustrated in <xref target="figure_boxrecord"/>.
A BOX DATA entry is illustrated in <xref target="figure_boxrecord" fo
rmat="default" sectionFormat="of" derivedContent="Figure 17"/>.
</t> </t>
<figure anchor="figure_boxrecord" align="left" suppress-title="false" <figure anchor="figure_boxrecord">
pn="figure-17"> <name>The BOX DATA Wire Format</name>
<name slugifiedName="name-the-box-data-wire-format">The BOX DATA Wir <artwork name="" type="" alt="">
e Format.</name>
<artwork name="" type="" align="left" alt="" pn="section-5.3.3-3.1">
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| PROTO | SVC | TYPE | | PROTO | SVC | TYPE |
+-----------+-----------------------------------+ +-----------+-----------------------------------+
| RECORD DATA | | RECORD DATA |
/ / / /
/ / / /
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
</artwork> </artwork>
</figure> </figure>
<dl indent="3" newline="false" spacing="normal" pn="section-5.3.3-4"> <dl newline="false">
<dt pn="section-5.3.3-4.1">PROTO</dt> <dt>PROTO:</dt>
<dd pn="section-5.3.3-4.2"> <dd>
the 16-bit protocol number in network byte order. The 16-bit protocol number in network byte order.
Values Values
below 2^8 are reserved for 8-bit Internet Protocol numbers allocated below 2<sup>8</sup> are reserved for 8-bit Internet Protocol numbers
by IANA <xref target="RFC5237" format="default" sectionFormat="of" derivedConten allocated by IANA <xref target="RFC5237"/>
t="RFC5237"/> (e.g., 6 for TCP).
(e.g. 6 for TCP). Values above 2<sup>8</sup> are allocated by the
Values above 2^8 are allocated by the GANA "GNUnet Overlay Protocols" registry <xref target="GANA"/>.
GANA "Overlay Protocols" registry <xref target="GANA" format="default
" sectionFormat="of" derivedContent="GANA"/>.
</dd> </dd>
<dt pn="section-5.3.3-4.3">SVC</dt> <dt>SVC:</dt>
<dd pn="section-5.3.3-4.4"> <dd>
the 16-bit service value of the boxed record in network byte order. I The 16-bit service value of the boxed record in network byte order. I
n case of n the case of
TCP and UDP it is the port number. TCP and UDP, it is the port number.
</dd> </dd>
<dt pn="section-5.3.3-4.5">TYPE</dt> <dt>TYPE:</dt>
<dd pn="section-5.3.3-4.6"> <dd>
is the 32-bit record type of the boxed record in network byte order. The 32-bit record type of the boxed record in network byte order.
</dd> </dd>
<dt pn="section-5.3.3-4.7">RECORD DATA</dt> <dt>RECORD DATA:</dt>
<dd pn="section-5.3.3-4.8"> <dd>
is a variable length field containing the "DATA" format of TYPE as A variable-length field containing the "DATA" format of TYPE as
defined for the respective TYPE. Thus, for TYPE values below 2^16, t defined for the respective TYPE. Thus, for TYPE values below 2<sup>1
he 6</sup>, the
format is the same as the respective record type's binary format in D NS. format is the same as the respective record type's binary format in D NS.
</dd> </dd>
</dl> </dl>
</section> </section>
</section> </section>
</section> </section>
<section anchor="publish" numbered="true" toc="include" removeInRFC="false" <section anchor="publish">
pn="section-6"> <name>Record Encoding for Remote Storage</name>
<name slugifiedName="name-record-encoding-for-remote-">Record Encoding for <t>
Remote Storage</name> Any API that allows storing a block under a 512-bit key and retrieving
<t indent="0" pn="section-6-1">
Any API which allows storing a block under a 512-bit key and retrieving
one or more blocks from a key can be used by an implementation for remote storage. one or more blocks from a key can be used by an implementation for remote storage.
To be useful, the API <bcp14>MUST</bcp14> permit storing at least 176 byt To be useful, and to be able to support the defined zone delegation
e blocks record encodings, the API <bcp14>MUST</bcp14> permit storing blocks of si
to be able to support the defined zone delegation record encodings, ze
and <bcp14>SHOULD</bcp14> allow at least 1024 byte blocks. 176 bytes or more and <bcp14>SHOULD</bcp14> allow blocks of size 1024 byt
es
or more.
In the following, it is assumed that an implementation realizes two In the following, it is assumed that an implementation realizes two
procedures on top of a storage: procedures on top of storage:
</t> </t>
<artwork name="" type="" align="left" alt="" pn="section-6-2"> <artwork name="" type="" alt="">
PUT(key,block) PUT(key, block)
GET(key) -&gt; block GET(key) -&gt; block
</artwork> </artwork>
<t indent="0" pn="section-6-3"> <t>
A GNS implementation publishes blocks A GNS implementation publishes blocks
in accordance to the properties and recommendations of the underlying in accordance with the properties and recommendations of the underlying
remote storage. This can include a periodic refresh operation to preserve the remote storage. This can include a periodic refresh operation to preserve the
availability of published blocks. availability of published blocks.
</t> </t>
<t indent="0" pn="section-6-4"> <t>
There is no mechanism to explicitly delete individual blocks from remote There is no mechanism for explicitly deleting individual blocks from remo
storage. te storage.
However, blocks include an EXPIRATION field which guides remote However, blocks include an EXPIRATION field, which guides remote
storage implementations to decide when to delete blocks. Given multiple blocks storage implementations to decide when to delete blocks. Given multiple blocks
for the same key, remote storage implementations <bcp14>SHOULD</bcp14> tr y for the same key, remote storage implementations <bcp14>SHOULD</bcp14> tr y
to preserve and return the block with the largest EXPIRATION value. to preserve and return the block with the largest EXPIRATION value.
</t> </t>
<t indent="0" pn="section-6-5"> <t>
All resource records from the same zone sharing the same label are All resource records from the same zone sharing the same label are
encrypted and published together in a single resource records block encrypted and published together in a single resource record block
(RRBLOCK) in the remote storage under a key q as illustrated (RRBLOCK) in the remote storage under a key q, as illustrated
in <xref target="figure_storage_publish" format="default" sectionFormat=" in <xref target="figure_storage_publish"/>.
of" derivedContent="Figure 18"/>.
A GNS implementation <bcp14>MUST NOT</bcp14> include expired resource A GNS implementation <bcp14>MUST NOT</bcp14> include expired resource
records in blocks. records in blocks.
An implementation <bcp14>MUST</bcp14> use the PUT storage procedure An implementation <bcp14>MUST</bcp14> use the PUT storage procedure
when record sets change to update the zone contents. Implementations when record sets change to update the zone contents. Implementations
<bcp14>MUST</bcp14> ensure that the EXPIRATION fields of RRBLOCKs <bcp14>MUST</bcp14> ensure that the EXPIRATION fields of RRBLOCKs
increases strictly monotonically for every change, even if the smallest increase strictly monotonically for every change, even if the smallest
expiration time of records in the block does not. expiration time of records in the block does not increase.
</t> </t>
<figure anchor="figure_storage_publish" align="left" suppress-title="false <figure anchor="figure_storage_publish">
" pn="figure-18"> <name>Management and Publication of Local Zones in Distributed Storage</
<name slugifiedName="name-management-and-publication-">Management and pu name>
blication of local zones in the distributed storage.</name> <artwork name="" type="" alt="">
<artwork name="" type="" align="left" alt="" pn="section-6-6.1"> Local Host | Remote
Local Host | Remote | Storage
| Storage |
| | +---------+
| +---------+ | / /|
| / /| | +---------+ |
| +---------+ | +-----------+ | | | |
+-----------+ | | | | | | +-----------+PUT(q, RRBLOCK) | | Record | |
| | +---------+PUT(q, RRBLOCK) | | Record | | | User | | Zone |----------------|-&gt;| Storage | |
| User | | Zone |----------------|-&gt;| Storage | | | | | Publisher | | | |/
| | | Master | | | |/ +-----------+ +-----------+ | +---------+
+-----------+ +---------+ | +---------+ | A |
| A | | | Zone records |
| | Zone records | | | grouped by label |
| | grouped by label | | | |
| | | | +---------+ |
| +---------+ | |Create / Delete / | /| |
|Create / Delete / | /| | |and Update +---------+ | |
|and Update +---------+ | | |Local Zones | | | |
|Local Zones | | | | | | Local | | |
| | Local | | | +--------------&gt;| Zones | | |
+--------------&gt;| Zones | | | | |/ |
| |/ | +---------+ |
+---------+ |
</artwork> </artwork>
</figure> </figure>
<t indent="0" pn="section-6-7"> <t>
The storage key derivation and records Storage key derivation and record
block creation is specified in the following sections and block creation are specified in the following sections and
illustrated in <xref target="figure_storage_derivations" format="default" illustrated in <xref target="figure_storage_derivations"/>.
sectionFormat="of" derivedContent="Figure 19"/>.
</t> </t>
<figure anchor="figure_storage_derivations" align="left" suppress-title="f <figure anchor="figure_storage_derivations">
alse" pn="figure-19"> <name>Storage Key and Record Block Creation Overview</name>
<name slugifiedName="name-storage-key-and-records-blo">Storage key and r <artwork name="" type="" alt="">
ecords block creation overview.</name>
<artwork name="" type="" align="left" alt="" pn="section-6-8.1">
+----------+ +-------+ +------------+ +-------------+ +----------+ +-------+ +------------+ +-------------+
| Zone Key | | Label | | Record Set | | Private Key | | Zone Key | | Label | | Record Set | | Private Key |
+----------+ +-------+ +------------+ +-------------+ +----------+ +-------+ +------------+ +-------------+
| | | | | | | |
| | v | | | v |
| | +-----------+ | | | +-----------+ |
| +----------&gt;| S-Encrypt | | | +----------&gt;| S-Encrypt | |
+----------|----------&gt;+-----------+ | +----------|----------&gt;+-----------+ |
| | | | | | | | | |
| | | v v | | | v v
| | | +-------------+ | | | +-------------+
| +---------------|--&gt;| SignDerived | | +---------------|--&gt;| SignDerived |
| | | +-------------+ | | | +-------------+
| | | | | | | |
| v v v | v v v
| +------+ +---------------+ | +------+ +--------------+
+-----&gt;| ZKDF |-------&gt;| Records Block | +-----&gt;| ZKDF |-------&gt;| Record Block |
+------+ +---------------+ +------+ +--------------+
| |
v v
+------+ +-------------+ +------+ +-------------+
| Hash |-------&gt;| Storage Key | | Hash |-------&gt;| Storage Key |
+------+ +-------------+ +------+ +-------------+
</artwork> </artwork>
</figure> </figure>
<section anchor="blinding" numbered="true" toc="include" removeInRFC="fals <section anchor="blinding">
e" pn="section-6.1"> <name>The Storage Key</name>
<name slugifiedName="name-the-storage-key">The Storage Key</name> <t>
<t indent="0" pn="section-6.1-1">
The storage key is derived from the zone key and the respective The storage key is derived from the zone key and the respective
label of the contained records. label of the contained records.
The required knowledge of both zone key and label in combination The required knowledge of both the zone key and the label in combinatio n
with the similarly derived symmetric secret keys and blinded zone keys with the similarly derived symmetric secret keys and blinded zone keys
ensures query privacy (see <xref target="RFC8324" format="default" sect ionFormat="of" derivedContent="RFC8324"/>, Section 3.5). ensures query privacy (see <xref target="RFC8324" sectionFormat="comma" section="3.5"/>).
</t> </t>
<t indent="0" pn="section-6.1-2"> <t>
Given a label, the storage key q is derived as follows: Given a label, the storage key q is derived as follows:
</t> </t>
<artwork name="" type="" align="left" alt="" pn="section-6.1-3"> <artwork name="" type="" alt="">
q := SHA-512 (ZKDF(zk, label)) q := SHA-512(ZKDF(zkey, label))
</artwork> </artwork>
<dl indent="3" newline="false" spacing="normal" pn="section-6.1-4"> <dl newline="false">
<dt pn="section-6.1-4.1">label</dt> <dt>label:</dt>
<dd pn="section-6.1-4.2">is a UTF-8 string under which the resource re <dd>A UTF-8 string under which the resource records are published.
cords are published.
</dd> </dd>
<dt pn="section-6.1-4.3">zk</dt> <dt>zkey:</dt>
<dd pn="section-6.1-4.4"> <dd>
is the zone key. The zone key.
</dd> </dd>
<dt pn="section-6.1-4.5">q</dt> <dt>q:</dt>
<dd pn="section-6.1-4.6"> <dd>
Is the 512-bit storage key under which the resource records block is The 512-bit storage key under which the resource record block is
published. published.
It is the SHA-512 hash <xref target="RFC6234" format="default" sectio nFormat="of" derivedContent="RFC6234"/> over the derived zone key. It is the SHA-512 hash <xref target="RFC6234"/> over the derived zone key.
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="rdata" numbered="true" toc="include" removeInRFC="false" <section anchor="rdata">
pn="section-6.2"> <name>Plaintext Record Data (RDATA)</name>
<name slugifiedName="name-plaintext-record-data-rdata">Plaintext Record <t>
Data (RDATA)</name>
<t indent="0" pn="section-6.2-1">
GNS records from a zone are grouped by their labels such that all GNS records from a zone are grouped by their labels such that all
records under the same label published together as a single records under the same label are published together as a single
block in the storage. Such grouped record sets <bcp14>MAY</bcp14> be pa block in storage. Such grouped record sets <bcp14>MAY</bcp14> be paired
ired with with
supplemental records. supplemental records.
</t> </t>
<t indent="0" pn="section-6.2-2"> <t>
Record data (RDATA) is the format used to encode such a group of GNS re cords. Record data (RDATA) is the format used to encode such a group of GNS re cords.
The binary format of RDATA is illustrated in The binary format of RDATA is illustrated in
<xref target="figure_rdata" format="default" sectionFormat="of" derived Content="Figure 20"/>. <xref target="figure_rdata"/>.
</t> </t>
<figure anchor="figure_rdata" align="left" suppress-title="false" pn="fi <figure anchor="figure_rdata">
gure-20"> <name>The RDATA Wire Format</name>
<name slugifiedName="name-the-rdata-wire-format">The RDATA Wire Format <artwork name="" type="" alt="">
.</name>
<artwork name="" type="" align="left" alt="" pn="section-6.2-3.1">
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| EXPIRATION | | EXPIRATION |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| SIZE | FLAGS | TYPE | | SIZE | FLAGS | TYPE |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| DATA / | DATA /
/ / / /
/ / / /
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| EXPIRATION | | EXPIRATION |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| SIZE | FLAGS | TYPE | | SIZE | FLAGS | TYPE |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| DATA / | DATA /
/ / / /
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
/ PADDING / | PADDING /
/ / / /
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
</artwork> </artwork>
</figure> </figure>
<dl indent="3" newline="false" spacing="normal" pn="section-6.2-4"> <dl newline="false">
<dt pn="section-6.2-4.1">EXPIRATION, SIZE, TYPE, FLAGS and DATA</dt> <dt>EXPIRATION, SIZE, TYPE, FLAGS, and DATA:</dt>
<dd pn="section-6.2-4.2"> <dd>
These fields were defined Definitions for these fields are provided below <xref target="figure_
in the resource record format in <xref target="rrecords" format="defa gnsrecord"/>
ult" sectionFormat="of" derivedContent="Section 5"/>. in <xref target="rrecords"/>.
</dd> </dd>
<dt pn="section-6.2-4.3">PADDING</dt> <dt>PADDING:</dt>
<dd pn="section-6.2-4.4"> <dd>
When serializing records into RDATA, a GNS implementation <bcp14>MUST </bcp14> ensure that When serializing records into RDATA, a GNS implementation <bcp14>MUST </bcp14> ensure that
the size of the RDATA is a power of two the size of the RDATA is a power of two
using the padding field. The field <bcp14>MUST</bcp14> be set to zero and <bcp14>MUST</bcp14> be using this field. The field <bcp14>MUST</bcp14> be set to zero and <b cp14>MUST</bcp14> be
ignored on receipt. ignored on receipt.
As a special exception, record sets with (only) a zone delegation As a special exception, record sets with (only) a zone delegation
record type are never padded. record type are never padded.
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="records_block" numbered="true" toc="include" removeInRFC= <section anchor="records_block">
"false" pn="section-6.3"> <name>The Resource Record Block</name>
<name slugifiedName="name-the-resource-records-block">The Resource Recor <t>
ds Block</name>
<t indent="0" pn="section-6.3-1">
The resource records grouped in an RDATA are encrypted using the S-Encr ypt() The resource records grouped in an RDATA are encrypted using the S-Encr ypt()
function defined by the zone type of the zone to which the resource rec ords belong function defined by the zone type of the zone to which the resource rec ords belong
and prefixed with meta data into a resource record block (RRBLOCK) for remote storage. and prefixed with metadata into a resource record block (RRBLOCK) for r emote storage.
The GNS RRBLOCK wire format is illustrated in The GNS RRBLOCK wire format is illustrated in
<xref target="figure_record_block" format="default" sectionFormat="of" derivedContent="Figure 21"/>. <xref target="figure_record_block"/>.
</t> </t>
<figure anchor="figure_record_block" align="left" suppress-title="false" <figure anchor="figure_record_block">
pn="figure-21"> <name>The RRBLOCK Wire Format</name>
<name slugifiedName="name-the-rrblock-wire-format">The RRBLOCK Wire Fo <artwork name="" type="" alt="">
rmat.</name>
<artwork name="" type="" align="left" alt="" pn="section-6.3-2.1">
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| SIZE | ZONE TYPE | | SIZE | ZONE TYPE |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
/ ZONE KEY / | ZONE KEY /
/ (BLINDED) / / (BLINDED) /
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| SIGNATURE | | SIGNATURE |
/ / / /
/ / / /
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| EXPIRATION | | EXPIRATION |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| BDATA / | BDATA |
/ /
/ / / /
/ |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
</artwork> </artwork>
</figure> </figure>
<dl indent="3" newline="false" spacing="normal" pn="section-6.3-3"> <dl newline="false">
<dt pn="section-6.3-3.1">SIZE</dt> <dt>SIZE:</dt>
<dd pn="section-6.3-3.2"> <dd>
A 32-bit value containing the length of the block in bytes in network byte order. A 32-bit value containing the length of the block in bytes in network byte order.
Despite the message format's use of a 32-bit value, Despite the message format's use of a 32-bit value,
implementations <bcp14>MAY</bcp14> refuse to publish blocks beyond a certain implementations <bcp14>MAY</bcp14> refuse to publish blocks beyond a certain
size significantly below the theoretical block size limit of 4 GB. size significantly below the theoretical block size limit of 4 GB.
</dd> </dd>
<dt pn="section-6.3-3.3">ZONE TYPE</dt> <dt>ZONE TYPE:</dt>
<dd pn="section-6.3-3.4"> <dd>
is the 32-bit ztype in network byte order. The 32-bit ztype in network byte order.
</dd> </dd>
<dt pn="section-6.3-3.5">ZONE KEY (BLINDED)</dt> <dt>ZONE KEY (BLINDED):</dt>
<dd pn="section-6.3-3.6"> <dd>
is the blinded zone key "ZKDF(zk, label)" The blinded zone key "ZKDF(zkey, label)"
to be used to verify SIGNATURE. to be used to verify SIGNATURE.
The length and format of the blinded public key depends on the ztype. The length and format of the blinded public key depend on the ztype.
</dd> </dd>
<dt pn="section-6.3-3.7">SIGNATURE</dt> <dt>SIGNATURE:</dt>
<dd pn="section-6.3-3.8"> <dd>
The signature is computed over the EXPIRATION and BDATA fields The signature is computed over the EXPIRATION and BDATA fields
as detailed in <xref target="figure_rrsigwithpseudo" format="default" as shown in <xref target="figure_rrsigwithpseudo"/>.
sectionFormat="of" derivedContent="Figure 22"/>. The length and format of the signature depend on the ztype.
The length and format of the signature depends on the ztype.
The signature is created using the SignDerived() function of The signature is created using the SignDerived() function of
the cryptosystem of the zone (see <xref target="zones" format="defaul t" sectionFormat="of" derivedContent="Section 4"/>). the cryptosystem of the zone (see <xref target="zones"/>).
</dd> </dd>
<dt pn="section-6.3-3.9">EXPIRATION</dt> <dt>EXPIRATION:</dt>
<dd pn="section-6.3-3.10"> <dd>
Specifies when the RRBLOCK expires and the encrypted block Specifies when the RRBLOCK expires and the encrypted block
<bcp14>SHOULD</bcp14> be removed from the storage and caches as it is likely stale. <bcp14>SHOULD</bcp14> be removed from storage and caches, as it is li kely stale.
However, applications <bcp14>MAY</bcp14> continue to use non-expired individual However, applications <bcp14>MAY</bcp14> continue to use non-expired individual
records until they expire. The value <bcp14>MUST</bcp14> be set to t records until they expire. The RRBLOCK expiration value <bcp14>MUST<
he maximum of /bcp14> be computed by first determining for each record type present in the RRB
the expiration time of the resource record contained within this bloc LOCK the maximum expiration time of all records of that type, including shadow
k with the records. Then, the minimum of all of these expiration times is taken. The final
smallest expiration time and the previous EXPIRATION value (if any) p expiration time is then the larger value of (1) the previous EXPIRATION value of
lus one a previous RRBLOCK for the same storage key plus one (if any) and (2) the compu
to ensure strict monotonicity (see <xref target="security_cryptograph ted minimum expiration time across the contained record types. This ensures stri
y" format="default" sectionFormat="of" derivedContent="Section 9.3"/>). ct monotonicity (see <xref target="security_cryptography"/>).
If the RDATA includes shadow records, then the maximum
expiration time of all shadow records with matching type and the
expiration times of the non-shadow records is considered.
This is a 64-bit absolute date in microseconds since midnight This is a 64-bit absolute date in microseconds since midnight
(0 hour), January 1, 1970 UTC in network byte order. (0 hour), January 1, 1970 UTC in network byte order.
</dd> </dd>
<dt pn="section-6.3-3.11">BDATA</dt> <dt>BDATA:</dt>
<dd pn="section-6.3-3.12"> <dd>
The encrypted RDATA computed using S-Encrypt() with the The encrypted RDATA computed using S-Encrypt() with the
zone key, label and expiration time as additional inputs. zone key, label, and expiration time as additional inputs.
Its ultimate size and content are determined by Its ultimate size and content are determined by
the S-Encrypt() function of the ztype. the S-Encrypt() function of the ztype.
</dd> </dd>
</dl> </dl>
<t indent="0" pn="section-6.3-4"> <t>
The signature over the public key covers a 32-bit pseudo header The signature over the public key covers a 32-bit pseudo header
conceptually prefixed to the EXPIRATION and the BDATA fields. conceptually prefixed to the EXPIRATION and BDATA fields.
The wire format is illustrated The wire format is illustrated
in <xref target="figure_rrsigwithpseudo" format="default" sectionFormat ="of" derivedContent="Figure 22"/>. in <xref target="figure_rrsigwithpseudo"/>.
</t> </t>
<figure anchor="figure_rrsigwithpseudo" align="left" suppress-title="fal <figure anchor="figure_rrsigwithpseudo">
se" pn="figure-22"> <name>The Wire Format Used for Creating the Signature of the RRBLOCK</
<name slugifiedName="name-the-wire-format-used-for-cr">The Wire Format name>
used for creating the signature of the RRBLOCK.</name> <artwork name="" type="" alt="">
<artwork name="" type="" align="left" alt="" pn="section-6.3-5.1">
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| SIZE | PURPOSE (0x0F) | | SIZE | PURPOSE (0x0F) |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| EXPIRATION | | EXPIRATION |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| BDATA | | BDATA |
/ / / /
/ / / /
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
</artwork> </artwork>
</figure> </figure>
<dl indent="3" newline="false" spacing="normal" pn="section-6.3-6"> <dl newline="false">
<dt pn="section-6.3-6.1">SIZE</dt> <dt>SIZE:</dt>
<dd pn="section-6.3-6.2"> <dd>
A 32-bit value containing the length of the signed data in bytes A 32-bit value containing the length of the signed data in bytes
in network byte order. in network byte order.
</dd> </dd>
<dt pn="section-6.3-6.3">PURPOSE</dt> <dt>PURPOSE:</dt>
<dd pn="section-6.3-6.4"> <dd>
A 32-bit signature purpose flag in network byte order. The value of t his A 32-bit signature purpose flag in network byte order. The value of t his
field <bcp14>MUST</bcp14> be 15. It defines the context in which field <bcp14>MUST</bcp14> be 15. It defines the context in which
the signature is created so that it cannot be reused in other parts the signature is created so that it cannot be reused in other parts
of the protocol including possible future extensions. of the protocol that might include possible future extensions.
The value of this field corresponds to an entry in the The value of this field corresponds to an entry in the
GANA "GNUnet Signature Purpose" registry <xref target="GANA" format=" default" sectionFormat="of" derivedContent="GANA"/>. GANA "GNUnet Signature Purposes" registry <xref target="GANA"/>.
</dd> </dd>
<dt pn="section-6.3-6.5">EXPIRATION</dt> <dt>EXPIRATION:</dt>
<dd pn="section-6.3-6.6"> <dd>
Field as defined in the RRBLOCK message above. Field as defined in the RRBLOCK message above.
</dd> </dd>
<dt pn="section-6.3-6.7">BDATA</dt> <dt>BDATA:</dt>
<dd pn="section-6.3-6.8">Field as defined in the RRBLOCK message above <dd>Field as defined in the RRBLOCK message above.</dd>
.</dd>
</dl> </dl>
</section> </section>
</section> </section>
<section anchor="resolution" numbered="true" toc="include" removeInRFC="fals <section anchor="resolution">
e" pn="section-7"> <name>Name Resolution</name>
<name slugifiedName="name-name-resolution">Name Resolution</name> <t>
<t indent="0" pn="section-7-1">
Names in GNS are resolved by recursively querying the record storage. Names in GNS are resolved by recursively querying the record storage.
Recursive in this context means that a resolver does not provide Recursive in this context means that a resolver does not provide
intermediate results for a query to the application. intermediate results for a query to the application.
Instead, it <bcp14>MUST</bcp14> respond to a resolution request with eith er the Instead, it <bcp14>MUST</bcp14> respond to a resolution request with eith er the
requested resource record or an error message in case resolution requested resource record or an error message if resolution
fails. fails.
<xref target="figure_resolution" format="default" sectionFormat="of" deri vedContent="Figure 23"/> illustrates how an application <xref target="figure_resolution"/> illustrates how an application
requests the lookup of a GNS name (1). requests the lookup of a GNS name (1).
The application <bcp14>MAY</bcp14> provide a desired record type to the r esolver. The application <bcp14>MAY</bcp14> provide a desired record type to the r esolver.
Subsequently, a Start Zone is determined (2) and the recursive Subsequently, a Start Zone is determined (2) and the recursive
resolution process started. resolution process started.
This is where the desired record type is used to guide processing. This is where the desired record type is used to guide processing.
For example, if a zone delegation record type is requested, the For example, if a zone delegation record type is requested, the
resolution of the apex label in that zone must be skipped, as resolution of the apex label in that zone must be skipped, as
the desired record is already found. the desired record is already found.
Details on how the resolution process is initiated and each iterative Details on how the resolution process is initiated and each iterative
result (3a,3b) in the resolution is processed are provided in the section s below. result (3a,3b) in the resolution is processed are provided in the section s below.
The results of the lookup are eventually returned to the application (4). The results of the lookup are eventually returned to the application (4).
The implementation <bcp14>MUST NOT</bcp14> filter the returned resource The implementation <bcp14>MUST NOT</bcp14> filter the returned resource
record sets according to the desired record type. record sets according to the desired record type.
Filtering of record sets is typically done by the application. Filtering of record sets is typically done by the application.
</t> </t>
<figure anchor="figure_resolution" align="left" suppress-title="false" pn= <figure anchor="figure_resolution">
"figure-23"> <name>The Recursive GNS Resolution Process</name>
<name slugifiedName="name-the-recursive-gns-resolutio">The recursive GNS <artwork name="" type="" alt="">
resolution process.</name>
<artwork name="" type="" align="left" alt="" pn="section-7-2.1">
Local Host | Remote Local Host | Remote
| Storage | Storage
| |
| +---------+ | +---------+
| / /| | / /|
| +---------+ | | +---------+ |
+-----------+ (1) Name +----------+ | | | | +-----------+ (1) Name +----------+ | | | |
| | Lookup | | (3a) GET(q) | | Record | | | | Lookup | | (3a) GET(q) | | Record | |
|Application|----------| Resolver |---------------|-&gt;| Storage | | |Application|----------| Resolver |---------------|-&gt;| Storage | |
| |&lt;---------| |&lt;--------------|--| |/ | |&lt;---------| |&lt;--------------|--| |/
skipping to change at line 2390 skipping to change at line 2099
+---------+ | +---------+ |
/ | /| | / | /| |
+---------+ | | +---------+ | |
| | | | | | | |
| Start | | | | Start | | |
| Zones | | | | Zones | | |
| |/ | | |/ |
+---------+ | +---------+ |
</artwork> </artwork>
</figure> </figure>
<section anchor="governance" numbered="true" toc="include" removeInRFC="fa <section anchor="governance">
lse" pn="section-7.1"> <name>Start Zones</name>
<name slugifiedName="name-start-zones">Start Zones</name> <t>
<t indent="0" pn="section-7.1-1"> The resolution of a GNS name starts by identifying the Start Zone
The resolution of a GNS name starts by identifying the start zone suffix. Once the Start Zone suffix is identified, recursive resolution
suffix. Once the start zone suffix is identified, recursive resolution of the remainder of the name is initiated (see <xref target="recursion"
of the remainder of the name is initiated (see <xref target="recursion" />).
format="default" sectionFormat="of" derivedContent="Section 7.2"/>). There are two types of Start Zone suffixes: zTLDs and local
There are two types of start zone suffixes: zTLDs and local
suffix-to-zone mappings. suffix-to-zone mappings.
The choice of available suffix-to-zone mappings is at the sole The choice of available suffix-to-zone mappings is at the sole
discretion of the local system administrator or user. discretion of the local system administrator or user.
This property addresses the issue of a single hierarchy with a This property addresses the issue of a single hierarchy with a
centrally controlled root and the related issue of distribution and centrally controlled root and the related issue of distribution and
management of root servers in DNS (see <xref target="RFC8324" format="d management of root servers in DNS (see Sections&nbsp;<xref target="RFC8
efault" sectionFormat="of" derivedContent="RFC8324"/>, Sections 3.10 and 3.12). 324" section="3.12"
sectionFormat="bare"/> and <xref target="RFC8324" section="3.10"
sectionFormat="bare"/> of <xref target="RFC8324"/>, respectively).
</t> </t>
<t indent="0" pn="section-7.1-2"> <t>
For names ending with a zTLD the start zone is explicitly given in the For names ending with a zTLD, the Start Zone is explicitly given in the
suffix of the name to resolve. suffix of the name to resolve.
In order to ensure uniqueness of names with zTLDs any In order to ensure uniqueness of names with zTLDs, any
implementation <bcp14>MUST</bcp14> use the given zone as start zone. implementation <bcp14>MUST</bcp14> use the given zone as the Start Zone
.
An implementation <bcp14>MUST</bcp14> first try to interpret the rightm ost label of An implementation <bcp14>MUST</bcp14> first try to interpret the rightm ost label of
the given name as the beginning of a zTLD (see <xref target="zTLD" form at="default" sectionFormat="of" derivedContent="Section 4.1"/>). the given name as the beginning of a zTLD (see <xref target="zTLD"/>).
If the rightmost label cannot be (partially) decoded or if it does not If the rightmost label cannot be (partially) decoded or if it does not
indicate a supported ztype, the name is treated as a normal name and indicate a supported ztype, the name is treated as a normal name and
start zone discovery <bcp14>MUST</bcp14> continue with finding a local suffix-to-zone Start Zone discovery <bcp14>MUST</bcp14> continue with finding a local suffix-to-zone
mapping. mapping.
If a valid ztype can be found in the rightmost label, the If a valid ztype can be found in the rightmost label, the
implementation <bcp14>MUST</bcp14> try to synthesize and decode the zTL D to retrieve implementation <bcp14>MUST</bcp14> try to synthesize and decode the zTL D to retrieve
the start zone key according to <xref target="zTLD" format="default" se ctionFormat="of" derivedContent="Section 4.1"/>. the Start Zone key according to <xref target="zTLD"/>.
If the zTLD cannot be synthesized or decoded, the resolution of If the zTLD cannot be synthesized or decoded, the resolution of
the name fails and an error is returned to the application. the name fails and an error is returned to the application.
Otherwise, the zone key <bcp14>MUST</bcp14> be used as the start zone: Otherwise, the zone key <bcp14>MUST</bcp14> be used as the Start Zone:
</t> </t>
<artwork name="" type="" align="left" alt="" pn="section-7.1-3"> <artwork name="" type="" alt="">
Example name: www.example.&lt;zTLD&gt; Example name: www.example.&lt;zTLD&gt;
=&gt; Start zone: zk of type ztype =&gt; Start Zone: zkey of type ztype
=&gt; Name to resolve from start zone: www.example =&gt; Name to resolve from Start Zone: www.example
</artwork> </artwork>
<t indent="0" pn="section-7.1-4"> <t>
For names not ending with a zTLD the resolver <bcp14>MUST</bcp14> deter For names not ending with a zTLD, the resolver <bcp14>MUST</bcp14> dete
mine the start rmine the Start
zone through a local suffix-to-zone mapping. Zone through a local suffix-to-zone mapping.
Suffix-to-zone mappings <bcp14>MUST</bcp14> be configurable through a l ocal Suffix-to-zone mappings <bcp14>MUST</bcp14> be configurable through a l ocal
configuration file or database by the user or system administrator. configuration file or database by the user or system administrator.
A suffix <bcp14>MAY</bcp14> consist of multiple GNS labels concatenated with a A suffix <bcp14>MAY</bcp14> consist of multiple GNS labels concatenated with a
label separator. label separator.
If multiple suffixes match the name to resolve, the longest If multiple suffixes match the name to resolve, the longest
matching suffix <bcp14>MUST</bcp14> be used. The suffix length of two r esults matching suffix <bcp14>MUST</bcp14> be used. The suffix length of two r esults
<bcp14>MUST NOT</bcp14> be equal. This indicates a misconfiguration and the <bcp14>MUST NOT</bcp14> be equal. This indicates a misconfiguration, an d the
implementation <bcp14>MUST</bcp14> return an error. implementation <bcp14>MUST</bcp14> return an error.
The following is a non-normative example mapping of start zones: The following is a non-normative example mapping of Start Zones:
</t> </t>
<artwork name="" type="" align="left" alt="" pn="section-7.1-5"> <artwork name="" type="" alt="">
Example name: www.example.xyz.gns.alt Example name: www.example.xyz.gns.alt
Local suffix mappings: Local suffix mappings:
xyz.gns.alt = zTLD0 := Base32GNS(ztype0||zk0) xyz.gns.alt = zTLD0 := Base32GNS(ztype0||zkey0)
example.xyz.gns.alt = zTLD1 := Base32GNS(ztype1||zk1) example.xyz.gns.alt = zTLD1 := Base32GNS(ztype1||zkey1)
example.com.gns.alt = zTLD2 := Base32GNS(ztype2||zk2) example.com.gns.alt = zTLD2 := Base32GNS(ztype2||zkey2)
... ...
=&gt; Start zone: zk1 =&gt; Start Zone: zkey1
=&gt; Name to resolve from start zone: www =&gt; Name to resolve from Start Zone: www
</artwork> </artwork>
<t indent="0" pn="section-7.1-6"> <t>
The process given above <bcp14>MAY</bcp14> be supplemented with other m echanisms if The process given above <bcp14>MAY</bcp14> be supplemented with other m echanisms if
the particular application requires a different process. the particular application requires a different process.
If no start zone can be discovered, resolution <bcp14>MUST</bcp14> fail and an If no Start Zone can be identified, resolution <bcp14>MUST</bcp14> fail and an
error <bcp14>MUST</bcp14> be returned to the application. error <bcp14>MUST</bcp14> be returned to the application.
</t> </t>
</section> </section>
<section anchor="recursion" numbered="true" toc="include" removeInRFC="fal <section anchor="recursion">
se" pn="section-7.2"> <name>Recursion</name>
<name slugifiedName="name-recursion">Recursion</name> <t>
<t indent="0" pn="section-7.2-1">
In each step of the recursive name resolution, there is an In each step of the recursive name resolution, there is an
authoritative zone zk and a name to resolve. authoritative zone zkey and a name to resolve.
The name <bcp14>MAY</bcp14> be empty. The name <bcp14>MAY</bcp14> be empty.
If the name is empty, it is interpreted as the apex label "@". If the name is empty, it is interpreted as the apex label "@".
Initially, the authoritative zone is the start zone. Initially, the authoritative zone is the Start Zone.
</t> </t>
<t indent="0" pn="section-7.2-2"> <t>
From here, the following steps are recursively executed, in order: From here, the following steps are recursively executed, in order:
</t> </t>
<ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-7. <ol>
2-3"> <li>Extract the rightmost label from the name to look up.</li>
<li pn="section-7.2-3.1" derivedCounter="1.">Extract the right-most l <li>Calculate q using the label and zkey as defined in
abel from the name to look up.</li> <xref target="blinding"/>.</li>
<li pn="section-7.2-3.2" derivedCounter="2.">Calculate q using the lab <li>Perform a storage query GET(q) to retrieve the RRBLOCK.</li>
el and zk as defined in <li>Check that (a) the block is not expired, (b) the SHA-512 hash
<xref target="blinding" format="default" sectionFormat="of" derivedCo of the derived authoritative zone key zkey' from the RRBLOCK matche
ntent="Section 6.1"/>.</li> s
<li pn="section-7.2-3.3" derivedCounter="3.">Perform a storage query G
ET(q) to retrieve the RRBLOCK.</li>
<li pn="section-7.2-3.4" derivedCounter="4.">Check that (a) the block
is not expired, (b) the SHA-512 hash
of the derived authoritative zone key zk' from the RRBLOCK matches
the query q, and (c) the signature is valid. If any of these the query q, and (c) the signature is valid. If any of these
tests fail, the RRBLOCK <bcp14>MUST</bcp14> tests fail, the RRBLOCK <bcp14>MUST</bcp14>
be ignored and, if applicable, the storage lookup GET(q) be ignored and, if applicable, the storage lookup GET(q)
<bcp14>MUST</bcp14> continue to look for other RRBLOCKs.</li> <bcp14>MUST</bcp14> continue to look for other RRBLOCKs.</li>
<li pn="section-7.2-3.5" derivedCounter="5.">Obtain the RDATA by decry pting the BDATA contained in the <li>Obtain the RDATA by decrypting the BDATA contained in the
RRBLOCK using S-Decrypt() as defined by the zone type, effectively RRBLOCK using S-Decrypt() as defined by the zone type, effectively
inverting the process described in <xref target="records_block" fo rmat="default" sectionFormat="of" derivedContent="Section 6.3"/>.</li> inverting the process described in <xref target="records_block"/>. </li>
</ol> </ol>
<t indent="0" pn="section-7.2-4"> <t>
Once a well-formed block has been decrypted, the records from Once a well-formed block has been decrypted, the records from
RDATA are subjected to record processing. RDATA are subjected to record processing.
</t> </t>
</section> </section>
<section anchor="record_processing" numbered="true" toc="include" removeIn <section anchor="record_processing">
RFC="false" pn="section-7.3"> <name>Record Processing</name>
<name slugifiedName="name-record-processing">Record Processing</name> <t>
<t indent="0" pn="section-7.3-1">
In record processing, only the valid records obtained are considered. In record processing, only the valid records obtained are considered.
To filter records by validity, the resolver To filter records by validity, the resolver
<bcp14>MUST</bcp14> at least check the expiration time and the FLAGS field of the <bcp14>MUST</bcp14> at least check the expiration time and the FLAGS field of the
respective record. respective record.
Specifically, the resolver <bcp14>MUST</bcp14> disregard expired reco rds. Specifically, the resolver <bcp14>MUST</bcp14> disregard expired reco rds.
Furthermore, SHADOW and Furthermore, SHADOW and
SUPPLEMENTAL flags can also exclude records from being considered. SUPPLEMENTAL flags can also exclude records from being considered.
If the resolver encounters a record with the CRITICAL flag set and If the resolver encounters a record with the CRITICAL flag set and
does not support the record type the resolution <bcp14>MUST</bcp14> b does not support the record type, the resolution <bcp14>MUST</bcp14>
e aborted be aborted
and an error <bcp14>MUST</bcp14> be returned. The information that th and an error <bcp14>MUST</bcp14> be returned. Information indicating
e critical that the critical
record could not be processed <bcp14>SHOULD</bcp14> be returned in th e error record could not be processed <bcp14>SHOULD</bcp14> be returned in th e error
description. The implementation <bcp14>MAY</bcp14> choose not to retu rn the reason for the failure, description. The implementation <bcp14>MAY</bcp14> choose not to retu rn the reason for the failure,
merely complicating troubleshooting for the user. merely complicating troubleshooting for the user.
</t> </t>
<t indent="0" pn="section-7.3-2"> <t>
The next steps depend on the context of the name that is being The next steps depend on the context of the name that is being
resolved: resolved:
</t> </t>
<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-7 <dl newline="false">
.3-3"> <dt>Case 1:</dt>
<li pn="section-7.3-3.1"> <dd>If the filtered record set consists of a single REDIRECT record,
Case 1: the remainder of the name is prepended to the REDIRECT DATA and the
If the filtered record set consists of a single REDIRECT record,
the remainder of the name is prepended to the REDIRECT data and the
recursion is started again from the resulting name. recursion is started again from the resulting name.
Details are described in <xref target="redirect_processing" format="d Details are provided in <xref target="redirect_processing"/>.</dd>
efault" sectionFormat="of" derivedContent="Section 7.3.1"/>. <dt>Case 2:</dt>
</li> <dd>If the filtered record set consists exclusively of one or more GN
<li pn="section-7.3-3.2"> S2DNS records,
Case 2:
If the filtered record set consists exclusively of one or more GNS2DN
S records
resolution continues with DNS. resolution continues with DNS.
Details are described in <xref target="gns2dns_processing" format="de Details are provided in <xref target="gns2dns_processing"/>.</dd>
fault" sectionFormat="of" derivedContent="Section 7.3.2"/>. <dt>Case 3:</dt>
</li> <dd>If the remainder of the name to be resolved is of the format
<li pn="section-7.3-3.3">
Case 3:
If the remainder of the name to be resolved is of the format
"_SERVICE._PROTO" and the record set contains one or more matching BO X "_SERVICE._PROTO" and the record set contains one or more matching BO X
records, the records in the BOX records are the final result and the recursion records, the records in the BOX records are the final result and the recursion
is concluded as described in <xref target="box_processing" format="de is concluded as described in <xref target="box_processing"/>.</dd>
fault" sectionFormat="of" derivedContent="Section 7.3.3"/>. <dt>Case 4:</dt>
</li> <dd>If the current record set
<li pn="section-7.3-3.4"> consists of a single delegation record,
Case 4:
If the current record set
consist of a single delegation record,
resolution of the remainder of the name is delegated to resolution of the remainder of the name is delegated to
the target zone as described in <xref target="delegation_processing" the target zone as described in <xref target="delegation_processing"/
format="default" sectionFormat="of" derivedContent="Section 7.3.4"/>. >.</dd>
</li> <dt>Case 5:</dt>
<li pn="section-7.3-3.5"> <dd>If the remainder of the name to resolve is empty,
Case 5:
If the remainder of the name to resolve is empty
the record set is the final result. the record set is the final result.
If any NICK records are in the final result set, they <bcp14>MUST</bc p14> If any NICK records are in the final result set, they <bcp14>MUST</bc p14>
first be processed according to <xref target="nick_processing" format first be processed according to <xref target="nick_processing"/>.
="default" sectionFormat="of" derivedContent="Section 7.3.5"/>. Otherwise, the record result set is directly returned as the final re
Otherwise, the record result set is directly returned as the final re sult.</dd>
sult. </dl>
</li> <t>Finally, if none of the above cases are applicable, resolution fai
<li pn="section-7.3-3.6"> ls and the
Finally, if none of the above is applicable, resolution fails and the resolver <bcp14>MUST</bcp14> return an empty record set.</t>
resolver <bcp14>MUST</bcp14> return an empty record set.
</li> <section anchor="redirect_processing">
</ul> <name>REDIRECT</name>
<section anchor="redirect_processing" numbered="true" toc="include" remo <t>
veInRFC="false" pn="section-7.3.1">
<name slugifiedName="name-redirect-2">REDIRECT</name>
<t indent="0" pn="section-7.3.1-1">
If the remaining name is empty and the desired record type is If the remaining name is empty and the desired record type is
REDIRECT, in which case the resolution concludes with the REDIRECT REDIRECT, the resolution concludes with the REDIRECT record.
record. If the rightmost label of the REDIRECT NAME is the extension label
If the rightmost label of the redirect name is the extension label (U+002B ("+")),
(U+002B, "+"),
resolution continues in GNS with the new name in the resolution continues in GNS with the new name in the
current zone. current zone.
Otherwise, the resulting name is resolved via the Otherwise, the resulting name is resolved via the
default operating system name resolution process. default operating system name resolution process.
This can in turn trigger a GNS name resolution process depending This can in turn trigger a GNS name resolution process, depending
on the system configuration. on the system configuration.
In case resolution continues in DNS, the name <bcp14>MUST</bcp14> f If resolution continues in DNS, the name <bcp14>MUST</bcp14> first
irst be be
converted to an IDNA compliant representation <xref target="RFC5890 converted to an IDNA-compliant representation <xref target="RFC5890
" format="default" sectionFormat="of" derivedContent="RFC5890"/>. "/>.
</t> </t>
<t indent="0" pn="section-7.3.1-2"> <t>
In order to prevent infinite loops, the resolver <bcp14>MUST</bcp14 > In order to prevent infinite loops, the resolver <bcp14>MUST</bcp14 >
implement loop detection or limit the number of recursive implement loop detection or limit the number of recursive
resolution steps. resolution steps.
The loop detection <bcp14>MUST</bcp14> be effective even The loop detection <bcp14>MUST</bcp14> be effective even
if a REDIRECT found in GNS triggers subsequent GNS lookups via if a REDIRECT found in GNS triggers subsequent GNS lookups via
the default operating system name resolution process. the default operating system name resolution process.
</t> </t>
</section> </section>
<section anchor="gns2dns_processing" numbered="true" toc="include" remov <section anchor="gns2dns_processing">
eInRFC="false" pn="section-7.3.2"> <name>GNS2DNS</name>
<name slugifiedName="name-gns2dns-2">GNS2DNS</name> <t>
<t indent="0" pn="section-7.3.2-1"> A resolver returns GNS2DNS records when all of the following
When a resolver encounters one or more GNS2DNS records and the rema conditions are met:
ining name
is empty and the desired record type is GNS2DNS, the GNS2DNS
records are returned.
</t> </t>
<t indent="0" pn="section-7.3.2-2"> <ol>
<li>The resolver encounters one or more GNS2DNS records;</li>
<li>The remaining name is empty; and</li>
<li>The desired record type is GNS2DNS.</li>
</ol>
<t>
Otherwise, it is expected that the resolver first resolves the Otherwise, it is expected that the resolver first resolves the
IP addresses of the specified DNS name servers. IP addresses of the specified DNS name servers.
The DNS name <bcp14>MUST</bcp14> be converted to an IDNA compliant The DNS name <bcp14>MUST</bcp14> be converted to an IDNA-compliant
representation <xref target="RFC5890" format="default" sectionForma representation <xref target="RFC5890"/> for resolution in DNS.
t="of" derivedContent="RFC5890"/> for resolution in DNS.
GNS2DNS records <bcp14>MAY</bcp14> GNS2DNS records <bcp14>MAY</bcp14>
contain numeric IPv4 or IPv6 addresses, allowing the resolver to contain numeric IPv4 or IPv6 addresses, allowing the resolver to
skip this step. skip this step.
The DNS server names might themselves be names in GNS or DNS. The DNS server names might themselves be names in GNS or DNS.
If the rightmost label of the DNS server name is the extension labe l If the rightmost label of the DNS server name is the extension labe l
(U+002B, "+"), the rest of the name is to be (U+002B ("+")), the rest of the name is to be
interpreted relative to the zone of the GNS2DNS record. interpreted relative to the zone of the GNS2DNS record.
If the DNS server name ends in a label representation of a If the DNS server name ends in a label representation of a
zone key, the DNS server name is to be resolved against zone key, the DNS server name is to be resolved against
the GNS zone zk. the GNS zone zkey.
</t> </t>
<t indent="0" pn="section-7.3.2-3"> <t>
Multiple GNS2DNS records can be stored under the same label, Multiple GNS2DNS records can be stored under the same label,
in which case the resolver <bcp14>MUST</bcp14> try all of them. in which case the resolver <bcp14>MUST</bcp14> try all of them.
The resolver <bcp14>MAY</bcp14> try them in any order or even in pa rallel. The resolver <bcp14>MAY</bcp14> try them in any order or even in pa rallel.
If multiple GNS2DNS records are present, the DNS name <bcp14>MUST</ bcp14> be If multiple GNS2DNS records are present, the DNS name <bcp14>MUST</ bcp14> be
identical for all of them. Otherwise, it is not clear which name identical for all of them. Otherwise, it is not clear which name
the resolver is supposed to follow. If different DNS names are the resolver is supposed to follow. If different DNS names are
present the resolution fails and an present, the resolution fails and an
appropriate error is <bcp14>SHOULD</bcp14> be returned to the appli appropriate error <bcp14>SHOULD</bcp14> be returned to the applicat
cation. ion.
</t> </t>
<t indent="0" pn="section-7.3.2-4"> <t>
If there are DNSSEC DS records or any other records used to If there are DNSSEC DS records or any other records used to
secure the connection with the DNS servers stored under the label, secure the connection with the DNS servers stored under the label,
the DNS resolver <bcp14>SHOULD</bcp14> use them to secure the conne ction with the DNS resolver <bcp14>SHOULD</bcp14> use them to secure the conne ction with
the DNS server. the DNS server.
</t> </t>
<t indent="0" pn="section-7.3.2-5"> <t>
Once the IP addresses of the DNS servers have been determined, Once the IP addresses of the DNS servers have been determined,
the DNS name from the GNS2DNS record is appended the DNS name from the GNS2DNS record is appended
to the remainder of the name to be resolved, and to the remainder of the name to be resolved and is
resolved by querying the DNS name server(s). resolved by querying the DNS name server(s).
The synthesized name has to be converted to an IDNA compliant The synthesized name has to be converted to an IDNA-compliant
representation <xref target="RFC5890" format="default" sectionForma representation <xref target="RFC5890"/> for resolution in DNS.
t="of" derivedContent="RFC5890"/> for resolution in DNS.
If such a conversion is not possible, the resolution <bcp14>MUST</b cp14> be aborted If such a conversion is not possible, the resolution <bcp14>MUST</b cp14> be aborted
and an error <bcp14>MUST</bcp14> be returned. The information that the critical and an error <bcp14>MUST</bcp14> be returned. Information indicatin g that the critical
record could not be processed <bcp14>SHOULD</bcp14> be returned in the error record could not be processed <bcp14>SHOULD</bcp14> be returned in the error
description. The implementation <bcp14>MAY</bcp14> choose not to re turn the reason for the failure, description. The implementation <bcp14>MAY</bcp14> choose not to re turn the reason for the failure,
merely complicating troubleshooting for the user. merely complicating troubleshooting for the user.
</t> </t>
<t indent="0" pn="section-7.3.2-6"> <t>
As the DNS servers As the DNS servers
specified are possibly authoritative DNS servers, the GNS resolver <bcp14>MUST</bcp14> specified are possibly authoritative DNS servers, the GNS resolver <bcp14>MUST</bcp14>
support recursive DNS resolution and <bcp14>MUST NOT</bcp14> delega te this to the support recursive DNS resolution and <bcp14>MUST NOT</bcp14> delega te this to the
authoritative DNS servers. authoritative DNS servers.
The first successful recursive name resolution result The first successful recursive name resolution result
is returned to the application. is returned to the application.
In addition, the resolver <bcp14>SHOULD</bcp14> return the queried DNS name as a In addition, the resolver <bcp14>SHOULD</bcp14> return the queried DNS name as a
supplemental LEHO record (see <xref target="gnsrecords_leho" format ="default" sectionFormat="of" derivedContent="Section 5.3.1"/>) with a supplemental LEHO record (see <xref target="gnsrecords_leho"/>) wit h a
relative expiration time of one hour. relative expiration time of one hour.
</t> </t>
<t indent="0" pn="section-7.3.2-7"> <t>
Once the transition from GNS into DNS is made through a Once the transition from GNS to DNS is made through a
GNS2DNS record, there is no "going back". GNS2DNS record, there is no "going back".
The (possibly recursive) resolution of the DNS name <bcp14>MUST NOT </bcp14> The (possibly recursive) resolution of the DNS name <bcp14>MUST NOT </bcp14>
delegate back into GNS and should only follow the DNS specification s. delegate back into GNS and should only follow the DNS specification s.
For example, names contained in DNS CNAME records <bcp14>MUST NOT</ bcp14> be For example, names contained in DNS CNAME records <bcp14>MUST NOT</ bcp14> be
interpreted by resolvers that support both DNS and GNS as GNS names . interpreted by resolvers that support both DNS and GNS as GNS names .
</t> </t>
<t indent="0" pn="section-7.3.2-8"> <t>
GNS resolvers <bcp14>SHOULD</bcp14> offer a configuration GNS resolvers <bcp14>SHOULD</bcp14> offer a configuration
option to disable DNS processing to avoid information leakage option to disable DNS processing to avoid information leakage
and provide a consistent security profile for all name resolutions. and provide a consistent security profile for all name resolutions.
Such resolvers would return an empty record set upon encountering Such resolvers would return an empty record set upon encountering
a GNS2DNS record during the recursion. However, if GNS2DNS records a GNS2DNS record during the recursion. However, if GNS2DNS records
are encountered in the record set for the apex label and a GNS2DNS record are encountered in the record set for the apex label and a GNS2DNS record
is explicitly requested by the application, such records <bcp14>MUS T</bcp14> is explicitly requested by the application, such records <bcp14>MUS T</bcp14>
still be returned, even if DNS support is disabled by the still be returned, even if DNS support is disabled by the
GNS resolver configuration. GNS resolver configuration.
</t> </t>
</section> </section>
<section anchor="box_processing" numbered="true" toc="include" removeInR <section anchor="box_processing">
FC="false" pn="section-7.3.3"> <name>BOX</name>
<name slugifiedName="name-box-2">BOX</name> <t>
<t indent="0" pn="section-7.3.3-1">
When a BOX record is received, a GNS resolver must unbox it if the When a BOX record is received, a GNS resolver must unbox it if the
name to be resolved continues with "_SERVICE._PROTO". name to be resolved continues with "_SERVICE._PROTO".
Otherwise, the BOX record is to be left untouched. This way, TLSA Otherwise, the BOX record is to be left untouched. This way, TLSA
(and SRV) records do not require a separate network request, and (and SRV) records do not require a separate network request, and
TLSA records become inseparable from the corresponding address TLSA records become inseparable from the corresponding address
records. records.
</t> </t>
</section> </section>
<section anchor="delegation_processing" numbered="true" toc="include" re <section anchor="delegation_processing">
moveInRFC="false" pn="section-7.3.4"> <name>Zone Delegation Records</name>
<name slugifiedName="name-zone-delegation-records-2">Zone Delegation R <t>
ecords</name>
<t indent="0" pn="section-7.3.4-1">
When the resolver encounters a record of a supported When the resolver encounters a record of a supported
zone delegation record type (such as PKEY or EDKEY) zone delegation record type (such as PKEY or EDKEY)
and the remainder of the name is not empty, resolution continues and the remainder of the name is not empty, resolution continues
recursively with the remainder of the name in the recursively with the remainder of the name in the
GNS zone specified in the delegation record. GNS zone specified in the delegation record.
</t> </t>
<t indent="0" pn="section-7.3.4-2"> <t>
Whenever a resolver encounters a new GNS zone, it <bcp14>MUST</bcp1 4> Whenever a resolver encounters a new GNS zone, it <bcp14>MUST</bcp1 4>
check against the local revocation list (see <xref target="revocati on" format="default" sectionFormat="of" derivedContent="Section 4.2"/>) check against the local revocation list (see <xref target="revocati on"/>) to see
whether the respective whether the respective
zone key has been revoked. If the zone key was revoked, the zone key has been revoked. If the zone key was revoked, the
resolution <bcp14>MUST</bcp14> fail with an empty result set. resolution <bcp14>MUST</bcp14> fail with an empty result set.
</t> </t>
<t indent="0" pn="section-7.3.4-3"> <t>
Implementations <bcp14>MUST NOT</bcp14> allow multiple different zo ne Implementations <bcp14>MUST NOT</bcp14> allow multiple different zo ne
delegations under a single label (except if some are shadow records ). delegations under a single label (except if some are shadow records ).
Implementations <bcp14>MAY</bcp14> support any subset of ztypes. Implementations <bcp14>MAY</bcp14> support any subset of ztypes.
Implementations <bcp14>MUST NOT</bcp14> process zone delegation rec ords Implementations <bcp14>MUST NOT</bcp14> process zone delegation rec ords
stored under the apex label ("@"). If a zone delegation record is encountered under stored under the apex label ("@"). If a zone delegation record is encountered under
the apex label, resolution fails and an error <bcp14>MUST</bcp14> b e returned. The the apex label, resolution fails and an error <bcp14>MUST</bcp14> b e returned. The
implementation <bcp14>MAY</bcp14> choose not to return the reason f or the failure, implementation <bcp14>MAY</bcp14> choose not to return the reason f or the failure,
merely impacting troubleshooting information for the user. merely impacting troubleshooting information for the user.
</t> </t>
<t indent="0" pn="section-7.3.4-4"> <t>
If the remainder of the name to resolve is empty and a record set If the remainder of the name to resolve is empty and a record set was
was received containing only a single delegation record, the received containing only a single delegation record, the recursion is
recursion is continued with the record value as authoritative zone continued with the record value as the authoritative zone and the
and the apex label "@" as remaining name. apex label "@" as the remaining name. The exception is the case
Except in the case where the desired record type as specified by where the desired record type as specified by the application is
the application is equal to the ztype, in which case the delegation equal to the ztype, in which case the delegation record is returned.
record is returned.
</t> </t>
</section> </section>
<section anchor="nick_processing" numbered="true" toc="include" removeIn <section anchor="nick_processing">
RFC="false" pn="section-7.3.5"> <name>NICK</name>
<name slugifiedName="name-nick-2">NICK</name> <t>
<t indent="0" pn="section-7.3.5-1">
NICK records are only relevant to the recursive resolver NICK records are only relevant to the recursive resolver
if the record set in question is the final result which is to if the record set in question is the final result, which is to
be returned to the application. The encountered NICK records can ei be returned to the application. The encountered NICK records can be
ther either
be supplemental (see <xref target="rrecords" format="default" secti supplemental (see <xref target="rrecords"/>) or
onFormat="of" derivedContent="Section 5"/>) or
non-supplemental. non-supplemental.
If the NICK record is supplemental, the resolver only returns the If the NICK record is supplemental, the resolver only returns the
record set if one of the non-supplemental records matches the record set if one of the non-supplemental records matches the
queried record type. queried record type.
It is possible that one record set contains both supplemental It is possible that one record set contains both supplemental
and non-supplemental NICK records. and non-supplemental NICK records.
</t> </t>
<t indent="0" pn="section-7.3.5-2"> <t>
The differentiation between a supplemental and non-supplemental The differentiation between a supplemental and non-supplemental
NICK record allows the application to match the record to the NICK record allows the application to match the record to the
authoritative zone. Consider the following example: authoritative zone. Consider the following example:
</t> </t>
<artwork name="" type="" align="left" alt="" pn="section-7.3.5-3"> <artwork name="" type="" alt="">
Query: alice.example.gns.alt (type=A) Query: alice.example.gns.alt (type=A)
Result: Result:
A: 192.0.2.1 A: 192.0.2.1
NICK: eve (non-supplemental) NICK: eve (non-supplemental)
</artwork> </artwork>
<t indent="0" pn="section-7.3.5-4"> <t>
In this example, the returned NICK record is non-supplemental. In this example, the returned NICK record is non-supplemental.
For the application, this means that the NICK belongs to the zone For the application, this means that the NICK belongs to the zone
"alice.example.gns.alt" and is published under the apex label along wi th an A "alice.example.gns.alt" and is published under the apex label along wi th an A
record. The NICK record is interpreted as: The zone defined by record. The NICK record is interpreted as follows: the zone defined by
"alice.example.gns.alt" wants to be referred to as "eve". "alice.example.gns.alt" wants to be referred to as "eve".
In contrast, consider the following: In contrast, consider the following:
</t> </t>
<artwork name="" type="" align="left" alt="" pn="section-7.3.5-5"> <artwork name="" type="" alt="">
Query: alice.example.gns.alt (type=AAAA) Query: alice.example.gns.alt (type=AAAA)
Result: Result:
AAAA: 2001:DB8::1 AAAA: 2001:db8::1
NICK: john (supplemental) NICK: john (supplemental)
</artwork> </artwork>
<t indent="0" pn="section-7.3.5-6"> <t>
In this case, the NICK record is marked as supplemental. This means that In this case, the NICK record is marked as supplemental. This means that
the NICK record belongs to the zone "example.gns.alt" and is published un der the the NICK record belongs to the zone "example.gns.alt" and is published un der the
label "alice" along with an AAAA record. Here, the NICK record should be label "alice" along with a AAAA record. Here, the NICK record should be
interpreted as: The zone defined by "example.gns.alt" wants to be referre interpreted as follows: the zone defined by "example.gns.alt" wants to be
d to as referred to as
"john". This distinction is likely useful for other records published as "john". This distinction is likely useful for other records published as
supplemental. supplemental.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="encoding" numbered="true" toc="include" removeInRFC="false" <section anchor="encoding">
pn="section-8"> <name>Internationalization and Character Encoding</name>
<name slugifiedName="name-internationalization-and-ch">Internationalizatio <t>
n and Character Encoding</name> All names in GNS are encoded in UTF-8 <xref target="RFC3629"/>.
<t indent="0" pn="section-8-1">
All names in GNS are encoded in UTF-8 <xref target="RFC3629" format="de
fault" sectionFormat="of" derivedContent="RFC3629"/>.
Labels <bcp14>MUST</bcp14> be canonicalized using Labels <bcp14>MUST</bcp14> be canonicalized using
Normalization Form C (NFC) <xref target="Unicode-UAX15" format="default " sectionFormat="of" derivedContent="Unicode-UAX15"/>. Normalization Form C (NFC) <xref target="Unicode-UAX15"/>.
This does not include any DNS names found in DNS records, such as CNAME This does not include any DNS names found in DNS records, such as CNAME
record data, which is internationalized through the IDNA specifications record data, which is internationalized through the IDNA specifications
<xref target="RFC5890" format="default" sectionFormat="of" derivedConte ;
nt="RFC5890"/>. see <xref target="RFC5890"/>.
</t> </t>
</section> </section>
<section anchor="security" numbered="true" toc="include" removeInRFC="false" <section anchor="security">
pn="section-9"> <name>Security and Privacy Considerations</name>
<name slugifiedName="name-security-and-privacy-consid">Security and Privac <section anchor="security_availability">
y Considerations</name> <name>Availability</name>
<section anchor="security_availability" numbered="true" toc="include" remo <t>
veInRFC="false" pn="section-9.1">
<name slugifiedName="name-availability">Availability</name>
<t indent="0" pn="section-9.1-1">
In order to ensure availability of records beyond their In order to ensure availability of records beyond their
absolute expiration times, implementations <bcp14>MAY</bcp14> allow t absolute expiration times, implementations <bcp14>MAY</bcp14> allow
o locally relative expiration time values of records to be locally defined.
define relative expiration time values of records.
Records can then be published recurringly with updated Records can then be published recurringly with updated
absolute expiration times by the implementation. absolute expiration times by the implementation.
</t> </t>
<t indent="0" pn="section-9.1-2"> <t>
Implementations <bcp14>MAY</bcp14> allow users to manage private reco rds in Implementations <bcp14>MAY</bcp14> allow users to manage private reco rds in
their zones that are not published in the storage. their zones that are not published in storage.
Private records are considered just like Private records are treated just like
regular records when resolving labels in local zones, regular records when resolving labels in local zones,
but their data is completely unavailable to non-local users. but their data is completely unavailable to non-local users.
</t> </t>
</section> </section>
<section anchor="security_agility" numbered="true" toc="include" removeInR <section anchor="security_agility">
FC="false" pn="section-9.2"> <name>Agility</name>
<name slugifiedName="name-agility">Agility</name> <t>
<t indent="0" pn="section-9.2-1">
The security of cryptographic systems depends on both the strength of The security of cryptographic systems depends on both the strength of
the cryptographic algorithms chosen and the strength of the keys used the cryptographic algorithms chosen and the strength of the keys used
with those algorithms. The security also depends on the engineering with those algorithms. This security also depends on the engineering
of the protocol used by the system to ensure that there are no of the protocol used by the system to ensure that there are no
non-cryptographic ways to bypass the security of the overall system. non-cryptographic ways to bypass the security of the overall system.
This is why developers of applications managing GNS zones <bcp14>SHOU LD</bcp14> This is why developers of applications managing GNS zones <bcp14>SHOU LD</bcp14>
select a default ztype considered secure at the time of select a default ztype considered secure at the time of
releasing the software. releasing the software.
For applications targeting end users that are not expected to For applications targeting end users that are not expected to
understand cryptography, the application developer <bcp14>MUST NOT</b cp14> leave understand cryptography, the application developer <bcp14>MUST NOT</b cp14> leave
the ztype selection of new zones to end users. the ztype selection of new zones to end users.
</t> </t>
<t indent="0" pn="section-9.2-2"> <t>
This document concerns itself with the selection of cryptographic This document concerns itself with the selection of cryptographic
algorithms used in GNS. algorithms used in GNS.
The algorithms identified in this document are not known to be The algorithms identified in this document are not known to be
broken (in the cryptographic sense) at the current time, and broken (in the cryptographic sense) at the current time, and
cryptographic research so far leads us to believe that they are cryptographic research so far leads us to believe that they are
likely to remain secure into the foreseeable future. However, this likely to remain secure into the foreseeable future. However, this
is not necessarily forever, and it is expected that new revisions of is not necessarily forever, and it is expected that new revisions of
this document will be issued from time to time to reflect the current this document will be issued from time to time to reflect the current
best practices in this area. best practices in this area.
</t> </t>
<t indent="0" pn="section-9.2-3"> <t>
In terms of crypto-agility, whenever the need for an updated cryptogr aphic In terms of crypto-agility, whenever the need for an updated cryptogr aphic
scheme arises to, for example, replace ECDSA over Ed25519 for scheme arises to, for example, replace ECDSA over Ed25519 for
PKEY records, it can simply be introduced PKEY records, it can simply be introduced
through a new record type. through a new record type.
Zone administrators can then replace Zone administrators can then replace
the delegation record type for future records. the delegation record type for future records.
The old record type remains The old record type remains,
and zones can iteratively migrate to the updated zone keys. and zones can iteratively migrate to the updated zone keys.
To ensure that implementations correctly generate an error message To ensure that implementations correctly generate an error message
when encountering a ztype that they do not support, when encountering a ztype that they do not support,
current and future delegation records must always have the current and future delegation records must always have the
CRITICAL flag set. CRITICAL flag set.
</t> </t>
</section> </section>
<section anchor="security_cryptography" numbered="true" toc="include" remo <section anchor="security_cryptography">
veInRFC="false" pn="section-9.3"> <name>Cryptography</name>
<name slugifiedName="name-cryptography">Cryptography</name> <t>
<t indent="0" pn="section-9.3-1">
The following considerations provide background on the design choices The following considerations provide background on the design choices
of the ztypes specified in this document. of the ztypes specified in this document.
When specifying new ztypes as per <xref target="zones" format="defaul t" sectionFormat="of" derivedContent="Section 4"/>, the same When specifying new ztypes as per <xref target="zones"/>, the same
considerations apply. considerations apply.
</t> </t>
<t indent="0" pn="section-9.3-2"> <t>
GNS PKEY zone keys use ECDSA over Ed25519. GNS PKEY zone keys use ECDSA over Ed25519.
This is an unconventional choice, This is an unconventional choice,
as ECDSA is usually used with other curves. However, standardized as ECDSA is usually used with other curves. However, standardized
ECDSA curves are problematic for a range of reasons described in ECDSA curves are problematic for a range of reasons, as described in
the Curve25519 and EdDSA papers <xref target="ed25519" format="defaul the Curve25519 and EdDSA papers <xref target="RFC7748"/> <xref target
t" sectionFormat="of" derivedContent="ed25519"/>. ="ed25519"/>.
Using EdDSA directly is also Using EdDSA directly is also
not possible, as a hash function is used on the private key which not possible, as a hash function is used on the private key and
destroys the linearity that the key blinding in GNS depends upon. will destroy the linearity that the key blinding in GNS depends upon.
We are not aware of anyone suggesting that using Ed25519 instead We are not aware of anyone suggesting that using Ed25519 instead
of another common curve of similar size would lower the security of of another common curve of similar size would lower the security of
ECDSA. GNS uses 256-bit curves because that way the encoded (public) ECDSA. GNS uses 256-bit curves; that way, the encoded (public)
keys fit into a single DNS label, which is good for usability. keys fit into a single DNS label, which is good for usability.
</t> </t>
<t indent="0" pn="section-9.3-3"> <t>
In order to ensure ciphertext indistinguishability, care must be In order to ensure ciphertext indistinguishability, care must be
taken with respect to the initialization vector in the counter taken with respect to the IV in the counter
block. In our design, the IV always includes the expiration time of t he block. In our design, the IV always includes the expiration time of t he
record block. record block.
When applications store records with relative expiration times, When applications store records with relative expiration times,
monotonicity is implicitly monotonicity is implicitly
ensured because each time a block is published into the storage, its ensured because each time a block is published in storage, its IV is
IV is unique, as the expiration time is calculated dynamically and increase
unique as the expiration time is calculated dynamically and increases s
monotonically with the system time. Still, monotonically with the system time. Still,
an implementation <bcp14>MUST</bcp14> ensure that when relative expir ation times an implementation <bcp14>MUST</bcp14> ensure that when relative expir ation times
are decreased, the expiration time of the next record block <bcp14>MU ST</bcp14> are decreased, the expiration time of the next record block <bcp14>MU ST</bcp14>
be after the last published block. be after the last published block.
For records where an absolute expiration time is used, the implementa tion For records where an absolute expiration time is used, the implementa tion
<bcp14>MUST</bcp14> ensure that the expiration time is always increas ed when the record <bcp14>MUST</bcp14> ensure that the expiration time is always increas ed when the record
data changes. For example, the expiration time on the wire could be i ncreased data changes. For example, the expiration time on the wire could be i ncreased
by a single microsecond even if the user did not request a change. by a single microsecond even if the user did not request a change.
In case of deletion of all resource records under a label, the In the case of deletion of all resource records under a label, the
implementation <bcp14>MUST</bcp14> keep track of the last absolute ex piration time implementation <bcp14>MUST</bcp14> keep track of the last absolute ex piration time
of the last published resource block. Implementations <bcp14>MAY</bc p14> define of the last published resource block. Implementations <bcp14>MAY</bc p14> define
and use a special record type as a tombstone that preserves the last and use a special record type as a tombstone that preserves the last
absolute expiration time, but then <bcp14>MUST</bcp14> take care to n ot publish a absolute expiration time but then <bcp14>MUST</bcp14> take care to no t publish a
block with such a tombstone record. block with such a tombstone record.
When new records are added under this label later, the implementation When new records are added under this label later, the implementation
<bcp14>MUST</bcp14> ensure that the expiration times are after the la st published <bcp14>MUST</bcp14> ensure that the expiration times are after the la st published
block. block.
Finally, in order to ensure monotonically increasing expiration times Finally, in order to ensure monotonically increasing expiration times ,
the implementation <bcp14>MUST</bcp14> keep a local record of the las t time obtained the implementation <bcp14>MUST</bcp14> keep a local record of the las t time obtained
from the system clock, so as to construct a monotonic clock in case from the system clock, so as to construct a monotonic clock if
the system clock jumps backwards. the system clock jumps backwards.
</t> </t>
</section> </section>
<section anchor="security_abuse" numbered="true" toc="include" removeInRFC <section anchor="security_abuse">
="false" pn="section-9.4"> <name>Abuse Mitigation</name>
<name slugifiedName="name-abuse-mitigation">Abuse Mitigation</name> <t>
<t indent="0" pn="section-9.4-1"> GNS names are UTF-8 strings. Consequently, GNS faces issues
GNS names are UTF-8 strings. Consequently, GNS faces similar issues with respect to name spoofing similar to those for DNS with respect t
with respect to name spoofing as DNS does for internationalized o internationalized
domain names. domain names.
In DNS, attackers can register similar sounding or looking In DNS, attackers can register similar-sounding or similar-looking
names (see above) in order to execute phishing attacks. names (see above) in order to execute phishing attacks.
GNS zone administrators must take into account this attack vector and GNS zone administrators must take into account this attack vector and
incorporate rules in order to mitigate it. incorporate rules in order to mitigate it.
</t> </t>
<t indent="0" pn="section-9.4-2"> <t>
Further, DNS can be used to combat illegal content on the Internet Further, DNS can be used to combat illegal content on the Internet
by having the respective domains seized by authorities. by having the respective domains seized by authorities.
However, the same mechanisms can also be abused in order to impose However, the same mechanisms can also be abused in order to impose
state censorship. state censorship.
Avoiding that possibility is one of the motivations behind GNS. Avoiding that possibility is one of the motivations behind GNS.
In GNS, TLDs are not enumerable. By design, the start zone of In GNS, TLDs are not enumerable. By design, the Start Zone of
the resolver is defined locally and hence such a seizure is the resolver is defined locally, and hence such a seizure is
difficult and ineffective in GNS. difficult and ineffective in GNS.
<!--In particular, GNS does not support WHOIS (<xref target="RFC3912" />).-->
</t> </t>
</section> </section>
<section anchor="security_keymanagement" numbered="true" toc="include" rem <section anchor="security_keymanagement">
oveInRFC="false" pn="section-9.5"> <name>Zone Management</name>
<name slugifiedName="name-zone-management">Zone Management</name> <t>
<t indent="0" pn="section-9.5-1">
In GNS, zone administrators need to manage and protect their zone In GNS, zone administrators need to manage and protect their zone
keys. Once a private zone key is lost, it cannot be recovered and keys. Once a private zone key is lost, it cannot be recovered, and
the zone revocation message cannot be computed anymore. the zone revocation message cannot be computed anymore.
Revocation messages can be pre-calculated if revocation is Revocation messages can be precalculated if revocation is
required in case a private zone key is lost. required in cases where a private zone key is lost.
Zone administrators, and for GNS this includes end-users, are Zone administrators, and for GNS this includes end users, are
required to responsibly and diligently protect their cryptographic required to responsibly and diligently protect their cryptographic
keys. keys.
GNS supports signing records in advance ("offline") in order to GNS supports signing records in advance ("offline") in order to
support processes (such as air gaps) which aim to protect private key support processes (such as air gaps) that aim to protect private keys
s. .
<!-- It does not support separate zone signing and key-signing keys
(as in <xref target="RFC6781" />) in order to provide usable security
. This is not useful for any implementer -->
</t> </t>
<t indent="0" pn="section-9.5-2"> <t>
Similarly, users are required to manage their local start zone config Similarly, users are required to manage their local Start Zone config
uration. uration.
In order to ensure integrity and availability or names, users must In order to ensure the integrity and availability of names, users mus
ensure that their local start zone information is not compromised or t
ensure that their local Start Zone information is not compromised or
outdated. outdated.
It can be expected that the processing of zone revocations and an It can be expected that the processing of zone revocations and an
initial start zone is provided with a GNS implementation initial Start Zone are provided with a GNS implementation
("drop shipping"). ("drop shipping").
Shipping an initial start zone configuration effectively establishes Shipping an initial Start Zone configuration effectively establishes
a root zone. a root zone.
Extension and customization of the zone is at the full discretion of Extension and customization of the zone are at the full discretion of
the user. the user.
</t> </t>
<t indent="0" pn="section-9.5-3"> <t>
While implementations following this specification will be While implementations following this specification will be
interoperable, if two implementations connect to different remote sto rages interoperable, if two implementations connect to different remote sto rage entities,
they are mutually unreachable. they are mutually unreachable.
This can lead to a state where a record exists in the global This can lead to a state where a record exists in the global
namespace for a particular name, but the implementation is not namespace for a particular name, but the implementation is not
communicating with the remote storage that contains the respective communicating with the remote storage entity that contains the respec tive
block and is hence unable to resolve it. block and is hence unable to resolve it.
This situation is similar to a split-horizon DNS configuration. This situation is similar to a split-horizon DNS configuration.
Which remote storages are implemented usually depends on the applicat The remote storage entity used will most likely depend on the specifi
ion c application
it is built for.
The remote storage used will most likely depend on the specific appli
cation
context using GNS resolution. context using GNS resolution.
For example, one application is the resolution of hidden services For example, one application is the resolution of hidden services
within the Tor network, which would suggest using Tor routers for rem within the Tor network <xref target="TorRendSpec"/>, which would sugg
ote storage. est using Tor routers for remote storage.
<!-- FIXME: add non-normative reference to Tor / Tor hidden services Implementations of "aggregated" remote storage entities are conceivab
here? --> le but
Implementations of "aggregated" remote storages are conceivable, but
are expected to be the exception. are expected to be the exception.
</t> </t>
</section> </section>
<section anchor="security_dht" numbered="true" toc="include" removeInRFC=" <section anchor="security_dht">
false" pn="section-9.6"> <name>DHTs as Remote Storage</name>
<name slugifiedName="name-dhts-as-remote-storage">DHTs as Remote Storage <t>
</name>
<t indent="0" pn="section-9.6-1">
This document does not specify the properties of the underlying This document does not specify the properties of the underlying
remote storage which is required by any GNS implementation. remote storage, which is required by any GNS implementation.
It is important to note that the properties of the underlying It is important to note that the properties of the underlying
remote storage are directly inherited by the remote storage are directly inherited by the
GNS implementation. This includes both security as well as GNS implementation. This includes both security and
other non-functional properties such as scalability and performance. other non-functional properties such as scalability and performance.
Implementers should take great care when selecting or implementing Implementers should take great care when selecting or implementing
a DHT for use as remote storage in a GNS implementation. a DHT for use as remote storage in a GNS implementation.
DHTs with reasonable security and performance properties exist DHTs with reasonable security and performance properties exist
<xref target="R5N" format="default" sectionFormat="of" derivedContent ="R5N"/>. <xref target="R5N"/>.
It should also be taken into consideration that GNS implementations It should also be taken into consideration that GNS implementations
which build upon different DHT overlays are unlikely to be that build upon different DHT overlays are unlikely to be
interoperable with each other. mutually reachable.
</t> </t>
</section> </section>
<section anchor="security_rev" numbered="true" toc="include" removeInRFC=" <section anchor="security_rev">
false" pn="section-9.7"> <name>Revocations</name>
<name slugifiedName="name-revocations">Revocations</name> <t>
<t indent="0" pn="section-9.7-1"> Zone administrators are advised to pregenerate zone revocations
Zone administrators are advised to pre-generate zone revocations and to securely store the revocation information if the zone
and to securely store the revocation information in case the zone key is lost, compromised, or replaced in the future.
key is lost, compromised or replaced in the future. Precalculated revocations can cease to be valid due to expirations
Pre-calculated revocations can cease to be valid due to expirations
or protocol changes such as epoch adjustments. or protocol changes such as epoch adjustments.
Consequently, implementers and users must take precautions in order Consequently, implementers and users must take precautions in order
to manage revocations accordingly. to manage revocations accordingly.
</t> </t>
<t indent="0" pn="section-9.7-2"> <t>
Revocation payloads do not include a 'new' key for key replacement. Revocation payloads do not include a "new" key for key replacement.
Inclusion of such a key would have two major disadvantages: Inclusion of such a key would have two major disadvantages:
</t> </t>
<ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-9. <ol>
7-3"> <li>
<li pn="section-9.7-3.1" derivedCounter="1.">
If a revocation is published after a private key was compromised, If a revocation is published after a private key was compromised,
allowing key replacement would be dangerous: if an allowing key replacement would be dangerous: if an
adversary took over the private key, the adversary could then adversary took over the private key, the adversary could then
broadcast a revocation with a key replacement. For the replacement, broadcast a revocation with a key replacement. For the replacement,
the compromised owner would have no chance to issue a the compromised owner would have no chance to issue a
revocation. Thus, allowing a revocation message to replace a private revocation. Thus, allowing a revocation message to replace a private
key makes dealing with key compromise situations worse. key makes dealing with key compromise situations worse.
</li> </li>
<li pn="section-9.7-3.2" derivedCounter="2."> <li>
Sometimes, key revocations are used with the objective of changing Sometimes, key revocations are used with the objective of changing
cryptosystems. Migration to another cryptosystem by replacing keys cryptosystems. Migration to another cryptosystem by replacing keys
via a revocation message would only be secure as long as both via a revocation message would only be secure as long as both
cryptosystems are still secure against forgery. Such a planned, cryptosystems are still secure against forgery. Such a planned,
non-emergency migration to another cryptosystem should be done by non-emergency migration to another cryptosystem should be done by
running zones for both cipher systems in parallel for a while. The running zones for both cipher systems in parallel for a while. The
migration would conclude by revoking the legacy zone key only once migration would conclude by revoking the legacy zone key only when
it is deemed no longer secure, and hopefully after most users have it is deemed no longer secure and, hopefully, after most users have
migrated to the replacement. migrated to the replacement.
</li> </li>
</ol> </ol>
</section> </section>
<section anchor="privacy_labels" numbered="true" toc="include" removeInRFC <section anchor="privacy_labels">
="false" pn="section-9.8"> <name>Zone Privacy</name>
<name slugifiedName="name-zone-privacy">Zone Privacy</name> <t>
<t indent="0" pn="section-9.8-1">
GNS does not support authenticated denial of existence of names GNS does not support authenticated denial of existence of names
within a zone. within a zone.
Record data is published in encrypted form using keys derived from th e Record data is published in encrypted form using keys derived from th e
zone key and record label. Zone administrators should zone key and record label. Zone administrators should
carefully consider if a label and zone key are public, or if carefully consider whether (1) a label and zone key are public or
one or both of these should be used as a shared secret to restrict ac (2) one or both of these should be used as a shared secret to restric
cess t access
to the corresponding record data. to the corresponding record data.
Unlike public zone keys, low-entropy labels can be guessed by an atta cker. If an attacker Unlike public zone keys, low-entropy labels can be guessed by an atta cker. If an attacker
knows the public zone key, the use of well known or guessable knows the public zone key, the use of well-known or guessable
labels effectively threatens the disclosure of the corresponding reco rds. labels effectively threatens the disclosure of the corresponding reco rds.
</t> </t>
<t indent="0" pn="section-9.8-2"> <t>
It should be noted that the guessing attack on labels only applies if the It should be noted that the guessing attack on labels only applies if the
zone key is somehow disclosed to the adversary. GNS itself zone key is somehow disclosed to the adversary. GNS itself
does not disclose it during a lookup or when resource records are does not disclose it during a lookup or when resource records are
published (as only the blinded zone keys are used on the network). published (as only the blinded zone keys are used on the network).
However, zone keys do become public during revocation. However, zone keys do become public during revocation.
</t> </t>
<t indent="0" pn="section-9.8-3"> <t>
It is thus <bcp14>RECOMMENDED</bcp14> to use a It is thus <bcp14>RECOMMENDED</bcp14> to use a
label with sufficient entropy to prevent guessing attacks label with sufficient entropy to prevent guessing attacks
if any data in a resource record set is sensitive. if any data in a resource record set is sensitive.
</t> </t>
</section> </section>
<section anchor="sec_governance" numbered="true" removeInRFC="false" toc=" <section anchor="sec_governance">
include" pn="section-9.9"> <name>Zone Governance</name>
<name slugifiedName="name-zone-governance">Zone Governance</name> <t>
<t indent="0" pn="section-9.9-1">
While DNS is distributed, in practice it While DNS is distributed, in practice it
relies on centralized, trusted registrars to provide globally unique relies on centralized, trusted registrars to provide globally unique
names. As the awareness of the central role DNS plays on the Internet names. As awareness of the central role DNS plays on the Internet
rises, various institutions are using their power (including legal me increases, various institutions are using their power (including lega
ans) l means)
to engage in attacks on the DNS, thus threatening the global availabi lity to engage in attacks on the DNS, thus threatening the global availabi lity
and integrity of information on the Internet. and integrity of information on the Internet.
While a wider discussion of this issue is out of scope for this docum ent, While a wider discussion of this issue is out of scope for this docum ent,
analyses and investigations can be found in recent academic research analyses and investigations can be found in recent academic research
works including <xref target="SecureNS" format="default" sectionForma t="of" derivedContent="SecureNS"/>. works, including <xref target="SecureNS"/>.
</t> </t>
<t indent="0" pn="section-9.9-2"> <t>
GNS is designed to provide a secure, privacy-enhancing alternative to the GNS is designed to provide a secure, privacy-enhancing alternative to the
DNS name resolution protocol, especially when censorship or manipulat ion DNS name resolution protocol, especially when censorship or manipulat ion
is encountered. is encountered.
In particular, it directly addresses concerns in DNS with respect to In particular, it directly addresses concerns in DNS with respect to
query privacy. query privacy.
However, depending on the governance of the root zone, any deployment However, depending on the governance of the root zone, any deployment
will likely suffer from the issues of a will likely suffer from the issue of a
"Single Hierarchy with a Centrally Controlled Root" and single hierarchy with a centrally controlled root and the
"Distribution and Management of Root Servers" as raised in related issue of distribution and management of root servers in DNS,
<xref target="RFC8324" format="default" sectionFormat="of" derivedCon as
tent="RFC8324"/>. raised in Sections&nbsp;<xref target="RFC8324" section="3.12"
In DNS, those issues are a direct result from the centralized root sectionFormat="bare"/> and <xref target="RFC8324" section="3.10"
sectionFormat="bare"/> of <xref target="RFC8324"/>, respectively.
In DNS, those issues directly result from the centralized root
zone governance at the Internet Corporation for Assigned Names and zone governance at the Internet Corporation for Assigned Names and
Numbers (ICANN) which allows it to provide globally unique names. Numbers (ICANN), which allows it to provide globally unique names.
</t> </t>
<t indent="0" pn="section-9.9-3"> <t>
In GNS, start zones give users local authority over their preferred In GNS, Start Zones give users local authority over their preferred
root zone governance. root zone governance.
It enables users to replace or enhance a trusted root zone It enables users to replace or enhance a trusted root zone
configuration provided by a third party (e.g. the implementer or a configuration provided by a third party (e.g., the implementer or a
multi-stakeholder governance body like ICANN) with secure delegation of multi-stakeholder governance body like ICANN) with secure delegation of
authority using local petnames while operating under a authority using local petnames while operating under a
very strong adversary model. very strong adversary model.
In combination with zTLDs, this provides users of GNS with a global, In combination with zTLDs, this provides users of GNS with a global,
secure and memorable mapping without a trusted authority. secure, and memorable mapping without a trusted authority.
</t> </t>
<t indent="0" pn="section-9.9-4"> <t>
Any GNS implementation <bcp14>MAY</bcp14> provide a default Any GNS implementation <bcp14>MAY</bcp14> provide a default
governance model in the form of an initial start zone mapping. governance model in the form of an initial Start Zone mapping.
</t> </t>
</section> </section>
<section anchor="namespace_ambiguity" numbered="true" removeInRFC="false" <section anchor="namespace_ambiguity">
toc="include" pn="section-9.10"> <name>Namespace Ambiguity</name>
<name slugifiedName="name-namespace-ambiguity">Namespace Ambiguity</name <t>
>
<t indent="0" pn="section-9.10-1">
Technically, the GNS protocol can be used to resolve names in the Technically, the GNS protocol can be used to resolve names in the
namespace of the global DNS. namespace of the global DNS.
However, this would require the respective governance bodies and However, this would require the respective governance bodies and
stakeholders (e.g. IETF and ICANN) to standardize the use of GNS for this particular use stakeholders (e.g., the IETF and ICANN) to standardize the use of GNS for this particular use
case. case.
</t> </t>
<t indent="0" pn="section-9.10-2"> <t>
However, this capability implies that GNS names may be This capability implies that GNS names may be
indistinguishable from DNS names in their indistinguishable from DNS names in their
respective common display format <xref target="RFC8499" format="defau respective common display format <xref target="RFC8499"/> or
lt" sectionFormat="of" derivedContent="RFC8499"/> or other special-use domain names <xref target="RFC6761"/> if
other special-use domain names <xref target="RFC6761" format="default a local Start Zone configuration maps suffixes from the
" sectionFormat="of" derivedContent="RFC6761"/> if
a local start zone configuration maps suffixes from the
global DNS to GNS zones. global DNS to GNS zones.
For applications, it is then ambiguous which name system should be For applications, which name system should be
used in order to resolve a given name. used in order to resolve a given name will then be ambiguous.
This poses a risk when trying to resolve a name through DNS when This poses a risk when trying to resolve a name through DNS when
it is actually a GNS name as discussed in <xref target="RFC8244" form at="default" sectionFormat="of" derivedContent="RFC8244"/>. it is actually a GNS name, as discussed in <xref target="RFC8244"/>.
In such a case, the GNS name is likely to be leaked as part of the DN S In such a case, the GNS name is likely to be leaked as part of the DN S
resolution. resolution.
</t> </t>
<t indent="0" pn="section-9.10-3"> <t>
In order to prevent disclosure of queried GNS names it is In order to prevent disclosure of queried GNS names, it is
<bcp14>RECOMMENDED</bcp14> that GNS-aware applications try to resolve <bcp14>RECOMMENDED</bcp14> that GNS-aware applications try to resolve
a given name in GNS before any other method taking into account a given name in GNS before any other method, taking into account
potential suffix-to-zone mappings and zTLDs. potential suffix-to-zone mappings and zTLDs.
Suffix-to-zone mappings are expected to be configured by the user or Suffix-to-zone mappings are expected to be configured by the user or
local administrator and as such the resolution in GNS is local administrator, and as such the resolution in GNS is
in line with user expectations even if the name could also be resolve d in line with user expectations even if the name could also be resolve d
through DNS. through DNS.
If no suffix-to-zone mapping for the name exists and no zTLD is found , If no suffix-to-zone mapping for the name exists and no zTLD is found ,
resolution <bcp14>MAY</bcp14> continue with other methods such as DNS . resolution <bcp14>MAY</bcp14> continue with other methods such as DNS .
If a suffix-to-zone mapping for the name exists or the name ends with If a suffix-to-zone mapping for the name exists or the name ends with
a zTLD, it <bcp14>MUST</bcp14> be resolved using GNS and a zTLD, it <bcp14>MUST</bcp14> be resolved using GNS, and
resolution <bcp14>MUST NOT</bcp14> continue by any other means resolution <bcp14>MUST NOT</bcp14> continue by any other means
independent of the GNS resolution result. independent of the GNS resolution result.
</t> </t>
<t indent="0" pn="section-9.10-4"> <t>
Mechanisms such as the Name Service Switch (NSS) of Unix-like Mechanisms such as the Name Service Switch (NSS) of UNIX-like
operating systems are an example of how such a resolution process operating systems are an example of how such a resolution process
can be implemented and used. can be implemented and used.
It allows system administrators to configure host name resolution The NSS allows system administrators to configure hostname resolution
precedence and is integrated with the system resolver implementation. precedence and is integrated with the system resolver implementation.
</t> </t>
<t indent="0" pn="section-9.10-5"> <t>
For use cases where GNS names may be confused with names For use cases where GNS names may be confused with names
of other name resolution mechanisms (in particular DNS), the of other name resolution mechanisms (in particular, DNS), the
".gns.alt" domain <bcp14>SHOULD</bcp14> be used. ".gns.alt" domain <bcp14>SHOULD</bcp14> be used.
For use cases like implementing sinkholes to block For use cases like implementing sinkholes to block
malware sites or serving DNS domains via GNS to bypass censorship, malware sites or serving DNS domains via GNS to bypass censorship,
GNS <bcp14>MAY</bcp14> be deliberately used in ways that interfere GNS <bcp14>MAY</bcp14> be deliberately used in ways that interfere
with resolution of another name system. with resolution of another name system.
</t> </t>
</section> </section>
</section> </section>
<section anchor="gana" numbered="true" toc="include" removeInRFC="false" pn= <section anchor="gana">
"section-10"> <name>GANA Considerations</name>
<name slugifiedName="name-gana-considerations">GANA Considerations</name> <section anchor="gana_gnunet-sig-purposes">
<t indent="0" pn="section-10-1"> <name>GNUnet Signature Purposes Registry</name>
GANA has assigned signature purposes in its <t>
"GNUnet Signature Purpose" registry as listed in GANA <xref target="GANA"/> has assigned signature purposes in its
<xref target="figure_purposenums" format="default" sectionFormat="of" d "GNUnet Signature Purposes" registry as listed in
erivedContent="Figure 24"/>. <xref target="tab_purposenums"/>.
</t> </t>
<figure anchor="figure_purposenums" align="left" suppress-title="false" pn
="figure-24"> <table anchor="tab_purposenums">
<name slugifiedName="name-requested-changes-in-the-ga">Requested Changes <name>The GANA GNUnet Signature Purposes Registry</name>
in the GANA GNUnet Signature Purpose Registry.</name> <thead>
<artwork name="" type="" align="left" alt="" pn="section-10-2.1"> <tr>
Purpose | Name | References | Comment <th>Purpose</th>
3 | GNS_REVOCATION | [This.I-D] | GNS zone key revocation <th>Name</th>
15 | GNS_RECORD_SIGN | [This.I-D] | GNS record set signature <th>References</th>
</artwork> <th>Comment</th>
</figure> </tr>
<section anchor="gana_gnsrr" numbered="true" removeInRFC="false" toc="incl </thead>
ude" pn="section-10.1"> <tbody>
<name slugifiedName="name-gns-record-types-registry">GNS Record Types Re <tr>
gistry</name> <td>3</td>
<t indent="0" pn="section-10.1-1"> <td>GNS_REVOCATION</td>
GANA <xref target="GANA" format="default" sectionFormat="of" derivedCon <td>RFC 9498</td>
tent="GANA"/> <td>GNS zone key revocation</td>
</tr>
<tr>
<td>15</td>
<td>GNS_RECORD_SIGN</td>
<td>RFC 9498</td>
<td>GNS record set signature</td>
</tr>
</tbody>
</table>
</section>
<section anchor="gana_gnsrr">
<name>GNS Record Types Registry</name>
<t>
GANA <xref target="GANA"/>
manages the "GNS Record Types" registry. manages the "GNS Record Types" registry.
Each entry has the following format: </t>
<t>Each entry has the following format:
</t> </t>
<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-1 <dl newline="false">
0.1-2"> <dt>Name:</dt><dd>The name of the record type (case-insensitive ASCII
<li pn="section-10.1-2.1">Name: The name of the record type (case-inse
nsitive ASCII
string, restricted to alphanumeric characters). For zone delegation string, restricted to alphanumeric characters). For zone delegation
records, the assigned number represents the ztype value of the zone.</li> records, the assigned number represents the ztype value of the zone.</dd>
<li pn="section-10.1-2.2">Number: 32-bit, above 65535</li> <dt>Number:</dt><dd>A 32-bit number above 65535.</dd>
<li pn="section-10.1-2.3">Comment: Optionally, a brief English text de <dt>Comment:</dt><dd>Optionally, brief English text describing the pur
scribing the purpose of pose of
the record type (in UTF-8)</li> the record type (in UTF-8).</dd>
<li pn="section-10.1-2.4">Contact: Optionally, the contact information <dt>Contact:</dt><dd>Optionally, the contact information for a person
of a person to contact for to contact for
further information.</li> further information.</dd>
<li pn="section-10.1-2.5">References: Optionally, references describin <dt>References:</dt><dd>Optionally, references (such as an RFC) descri
g the record type bing the record type.</dd>
(such as an RFC).</li> </dl>
</ul> <t>
<t indent="0" pn="section-10.1-3">
The registration policy for this registry is "First Come First The registration policy for this registry is "First Come First
Served". This policy is modeled on that described in <xref target="RFC8 126" format="default" sectionFormat="of" derivedContent="RFC8126"/>, Served". This policy is modeled on that described in <xref target="RFC8 126"/>
and describes the actions taken by GANA: and describes the actions taken by GANA:
</t> </t>
<t indent="0" pn="section-10.1-4"> <ul>
<li>
Adding new entries is possible after review by any authorized Adding new entries is possible after review by any authorized
GANA contributor, using a GANA contributor, using a
first-come-first-served policy for unique name allocation. first-come-first-served policy for unique name allocation.
Reviewers are responsible to ensure that the chosen "Name" is Reviewers are responsible for ensuring that the chosen "Name" is
appropriate for the record type. appropriate for the record type.
The registry will define a unique number for the entry. The registry will define a unique number for the entry.
</t> </li>
<t indent="0" pn="section-10.1-5"> <li>
Authorized GANA contributors for review of new entries are reachable at Authorized GANA contributors for review of new entries are reachable at
gns-registry@gnunet.org. &lt;gns-registry@gnunet.org&gt;.
</t> </li>
<t indent="0" pn="section-10.1-6"> <li>
Any request <bcp14>MUST</bcp14> contain a unique name and a point of co ntact. Any request <bcp14>MUST</bcp14> contain a unique name and a point of co ntact.
The contact information <bcp14>MAY</bcp14> be added to the registry giv en the consent The contact information <bcp14>MAY</bcp14> be added to the registry, wi th the consent
of the requester. of the requester.
The request <bcp14>MAY</bcp14> optionally also contain relevant referen ces as well The request <bcp14>MAY</bcp14> optionally also contain relevant referen ces as well
as a descriptive comment as defined above. as a descriptive comment, as defined above.
</t> </li>
<t indent="0" pn="section-10.1-7"> </ul>
<t>
GANA has assigned numbers for the record types defined in this GANA has assigned numbers for the record types defined in this
specification in the "GNU Name System Record Types" registry specification in the "GNS Record Types" registry as listed in
as listed in <xref target="figure_rrtypenums" format="default" sectionF <xref target="tab_rrtypenums"/>.
ormat="of" derivedContent="Figure 25"/>.
</t> </t>
<figure anchor="figure_rrtypenums" align="left" suppress-title="false" p
n="figure-25">
<name slugifiedName="name-the-gana-resource-record-re">The GANA Resour
ce Record Registry.</name>
<artwork name="" type="" align="left" alt="" pn="section-10.1-8.1">
Number | Name | Contact | References | Comment
65536 | PKEY | (*) | [This.I-D] | GNS zone delegation (PKEY)
65537 | NICK | (*) | [This.I-D] | GNS zone nickname
65538 | LEHO | (*) | [This.I-D] | GNS legacy hostname
65540 | GNS2DNS | (*) | [This.I-D] | Delegation to DNS
65541 | BOX | (*) | [This.I-D] | Boxed records
65551 | REDIRECT| (*) | [This.I-D] | Redirection record.
65556 | EDKEY | (*) | [This.I-D] | GNS zone delegation (EDKEY)
(*): gns-registry@gnunet.org <table anchor="tab_rrtypenums">
</artwork> <name>The GANA GNS Record Types Registry</name>
</figure> <thead>
<tr>
<th>Number</th>
<th>Name</th>
<th>Contact</th>
<th>References</th>
<th>Comment</th>
</tr>
</thead>
<tbody>
<tr>
<td>65536</td>
<td>PKEY</td>
<td>(*)</td>
<td>RFC 9498</td>
<td>GNS zone delegation (PKEY)</td>
</tr>
<tr>
<td>65537</td>
<td>NICK</td>
<td>(*)</td>
<td>RFC 9498</td>
<td>GNS zone nickname</td>
</tr>
<tr>
<td>65538</td>
<td>LEHO</td>
<td>(*)</td>
<td>RFC 9498</td>
<td>GNS legacy hostname</td>
</tr>
<tr>
<td>65540</td>
<td>GNS2DNS</td>
<td>(*)</td>
<td>RFC 9498</td>
<td>Delegation to DNS</td>
</tr>
<tr>
<td>65541</td>
<td>BOX</td>
<td>(*)</td>
<td>RFC 9498</td>
<td>Box records</td>
</tr>
<tr>
<td>65551</td>
<td>REDIRECT</td>
<td>(*)</td>
<td>RFC 9498</td>
<td>Redirection record</td>
</tr>
<tr>
<td>65556</td>
<td>EDKEY</td>
<td>(*)</td>
<td>RFC 9498</td>
<td>GNS zone delegation (EDKEY)</td>
</tr>
</tbody>
<tfoot>
<tr>
<td align="left" colspan="5">(*): gns-registry@gnunet.org</td>
</tr>
</tfoot>
</table>
</section> </section>
<section anchor="gana_alt" numbered="true" removeInRFC="false" toc="includ <section anchor="gana_alt">
e" pn="section-10.2"> <name>.alt Subdomains Registry</name>
<name slugifiedName="name-alt-subdomains-registry">.alt Subdomains Regis <t>
try</name> GANA <xref target="GANA"/>
<t indent="0" pn="section-10.2-1"> manages the ".alt Subdomains" registry. This GANA-operated .alt registr
GANA <xref target="GANA" format="default" sectionFormat="of" derivedCon y
tent="GANA"/> may or may not be taken into account by any particular implementer, and
manages the ".alt Subdomains" registry. it is not in any way associated with or sanctioned by the IETF or ICANN
Each entry has the following format: .
</t>
<t>Each entry has the following format:
</t> </t>
<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-1 <dl newline="false">
0.2-2"> <dt>Label:</dt><dd>The label of the subdomain (in DNS "letters, digits
<li pn="section-10.2-2.1">Label: The label of the subdomain (in DNS LD , hyphen" (LDH) format as defined in <xref target="RFC5890" sectionFormat="of" s
H format as defined in Section 2.3.1 of <xref target="RFC5890" format="default" ection="2.3.1"/>).</dd>
sectionFormat="of" derivedContent="RFC5890"/>).</li> <dt>Description:</dt><dd>Optionally, brief English text describing the p
<li pn="section-10.2-2.2">Comment: Optionally, a brief English text de urpose of
scribing the purpose of the subdomain (in UTF-8).</dd>
the subdomain (in UTF-8)</li> <dt>Contact:</dt><dd>Optionally, the contact information for a person
<li pn="section-10.2-2.3">Contact: Optionally, the contact information to contact for
of a person to contact for further information.</dd>
further information.</li> <dt>References:</dt><dd>Optionally, references (such as an RFC) descri
<li pn="section-10.2-2.4">References: Optionally, references describin bing the record type.</dd>
g the record type </dl>
(such as an RFC).</li> <t>
</ul>
<t indent="0" pn="section-10.2-3">
The registration policy for this registry is "First Come First The registration policy for this registry is "First Come First
Served". This policy is modeled on that described in <xref target="RFC8 126" format="default" sectionFormat="of" derivedContent="RFC8126"/>, Served". This policy is modeled on that described in <xref target="RFC8 126"/>
and describes the actions taken by GANA: and describes the actions taken by GANA:
</t> </t>
<t indent="0" pn="section-10.2-4"> <ul>
<li>
Adding new entries is possible after review by any authorized Adding new entries is possible after review by any authorized
GANA contributor, using a GANA contributor, using a
first-come-first-served policy for unique subdomain allocation. first-come-first-served policy for unique subdomain allocation.
Reviewers are responsible to ensure that the chosen "Subdomain" is Reviewers are responsible for ensuring that the chosen "Subdomain" is
appropriate for the purpose. appropriate for the purpose.
</t> </li>
<t indent="0" pn="section-10.2-5"> <li>
Authorized GANA contributors for review of new entries are reachable at Authorized GANA contributors for review of new entries are reachable at
alt-registry@gnunet.org. &lt;alt-registry@gnunet.org&gt;.
</t> </li>
<t indent="0" pn="section-10.2-6"> <li>
Any request <bcp14>MUST</bcp14> contain a unique subdomain and a point of contact. Any request <bcp14>MUST</bcp14> contain a unique subdomain and a point of contact.
The contact information <bcp14>MAY</bcp14> be added to the registry giv en the consent The contact information <bcp14>MAY</bcp14> be added to the registry, wi th the consent
of the requester. of the requester.
The request <bcp14>MAY</bcp14> optionally also contain relevant referen ces as well The request <bcp14>MAY</bcp14> optionally also contain relevant referen ces as well
as a descriptive comment as defined above. as a descriptive comment, as defined above.
</t> </li>
<t indent="0" pn="section-10.2-7"> </ul>
<t>
GANA has assigned the subdomain defined in this GANA has assigned the subdomain defined in this
specification in the ".alt subdomains" registry specification in the ".alt Subdomains" registry
as listed in <xref target="figure_altsubdomains" format="default" secti as listed in <xref target="tab_altsubdomains"/>.
onFormat="of" derivedContent="Figure 26"/>.
</t> </t>
<figure anchor="figure_altsubdomains" align="left" suppress-title="false <table anchor="tab_altsubdomains">
" pn="figure-26"> <name>The GANA .alt Subdomains Registry</name>
<name slugifiedName="name-the-gana-alt-subdomains-reg">The GANA .alt S <thead>
ubdomains Registry.</name> <tr>
<artwork name="" type="" align="left" alt="" pn="section-10.2-8.1"> <th>Label</th>
Subdomain | Contact | References | Comment <th>Contact</th>
gns | (*) | [This.I-D] | The .alt subdomain for GNS. <th>References</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>gns</td>
<td>(*)</td>
<td>RFC 9498</td>
<td>The .alt subdomain for GNS</td>
</tr>
</tbody>
<tfoot>
<tr>
<td align="left" colspan="4">(*): alt-registry@gnunet.org</td>
</tr>
</tfoot>
</table>
(*): alt-registry@gnunet.org
</artwork>
</figure>
</section> </section>
</section> </section>
<!-- gana --> <section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-11"> <name>IANA Considerations</name>
<name slugifiedName="name-iana-considerations">IANA Considerations</name> <t>
<t indent="0" pn="section-11-1"> This document has no IANA actions.
This document makes no requests for IANA action.
This section may be removed on publication as an RFC.
</t> </t>
</section> </section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-12"> <section>
<name slugifiedName="name-implementation-and-deployme">Implementation and <name>Implementation and Deployment Status</name>
Deployment Status</name> <t>
<t indent="0" pn="section-12-1"> There are two implementations conforming to this specification, written
There are two implementations conforming to this specification written
in C and Go, respectively. The C implementation as part of GNUnet in C and Go, respectively. The C implementation as part of GNUnet
<xref target="GNUnetGNS" format="default" sectionFormat="of" derivedCon tent="GNUnetGNS"/> represents the original <xref target="GNUnetGNS"/> represents the original
and reference implementation. The Go implementation and reference implementation. The Go implementation
<xref target="GoGNS" format="default" sectionFormat="of" derivedContent ="GoGNS"/> demonstrates how two implementations of GNS are <xref target="GoGNS"/> demonstrates how two implementations of GNS are
interoperable if they are built on top of the same underlying interoperable if they are built on top of the same underlying
DHT storage. DHT storage.
</t> </t>
<t indent="0" pn="section-12-2"> <t>
Currently, the GNUnet peer-to-peer network <xref target="GNUnet" format Currently, the GNUnet peer-to-peer network <xref target="GNUnet"/>
="default" sectionFormat="of" derivedContent="GNUnet"/> is an active deployment of GNS on top of its DHT <xref target="R5N"/>.
is an active deployment of GNS on top of its <xref target="R5N" format= The Go implementation <xref target="GoGNS"/> uses this deployment
"default" sectionFormat="of" derivedContent="R5N"/>
DHT. The <xref target="GoGNS" format="default" sectionFormat="of" deriv
edContent="GoGNS"/> implementation uses this deployment
by building on top of the GNUnet DHT services available on any by building on top of the GNUnet DHT services available on any
GNUnet peer. It shows how GNS implementations GNUnet peer. It shows how GNS implementations
can attach to this existing deployment and participate in name can attach to this existing deployment and participate in name
resolution as well as zone publication. resolution as well as zone publication.
</t> </t>
<t indent="0" pn="section-12-3"> <t>
The self-sovereign identity system re:claimID <xref target="reclaim" fo The self-sovereign identity system re:claimID <xref target="reclaim"/>
rmat="default" sectionFormat="of" derivedContent="reclaim"/>
is using GNS in order to selectively share identity attributes and is using GNS in order to selectively share identity attributes and
attestations with third parties. attestations with third parties.
</t> </t>
<t indent="0" pn="section-12-4"> <t>
The Ascension tool <xref target="Ascension" format="default" sectionFor The Ascension tool <xref target="Ascension"/> facilitates the migration
mat="of" derivedContent="Ascension"/> facilitates the migration of DNS zones to of DNS zones to
GNS zones by translating information retrieved from a DNS zone GNS zones by translating information retrieved from a DNS zone
transfer into a GNS zone. transfer into a GNS zone.
</t> </t>
</section> </section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-13">
<name slugifiedName="name-acknowledgements">Acknowledgements</name>
<t indent="0" pn="section-13-1">
The authors thank all reviewers for their comments. In particular,
we thank D. J. Bernstein, S. Bortzmeyer, A. Farrel, E. Lear and R. Sal
z for their
insightful and detailed technical reviews. We thank J. Yao and J. Klen
sin for the
internationalization reviews. We thank NLnet and NGI DISCOVERY for fun
ding
work on the GNU Name System.
</t>
</section>
</middle> </middle>
<back> <back>
<references pn="section-14"> <references>
<name slugifiedName="name-normative-references">Normative References</name <name>References</name>
> <references>
<reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc103 <name>Normative References</name>
4" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml" quot
eTitle="true" derivedAnchor="RFC1034"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"
<front> />
<title>Domain names - concepts and facilities</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"
<author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/ />
> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2782.xml"
<date month="November" year="1987"/> />
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
<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 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"
and their used for host address look up and electronic mail forwarding. It dis />
cusses the clients and servers in the domain name system and the protocol used b <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3686.xml"
etween them.</t> />
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3826.xml"
</front> />
<seriesInfo name="STD" value="13"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5237.xml"
<seriesInfo name="RFC" value="1034"/> />
<seriesInfo name="DOI" value="10.17487/RFC1034"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5869.xml"
</reference> />
<reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc103 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5890.xml"
5" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml" quot />
eTitle="true" derivedAnchor="RFC1035"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5895.xml"
<front> />
<title>Domain names - implementation and specification</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml"
<author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/ />
> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6895.xml"
<date month="November" year="1987"/> />
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6979.xml"
<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 R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7748.xml"
FC-883. This memo documents the details of the domain name client - server comm />
unication.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8032.xml"
</abstract> />
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"
<seriesInfo name="STD" value="13"/> />
<seriesInfo name="RFC" value="1035"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
<seriesInfo name="DOI" value="10.17487/RFC1035"/> />
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml"
<reference anchor="RFC2782" target="https://www.rfc-editor.org/info/rfc278 />
2" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2782.xml" quot <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9106.xml"
eTitle="true" derivedAnchor="RFC2782"> />
<front>
<title>A DNS RR for specifying the location of services (DNS SRV)</tit <reference anchor="GANA" target="https://gana.gnunet.org/">
le>
<author fullname="A. Gulbrandsen" initials="A." surname="Gulbrandsen"/
>
<author fullname="P. Vixie" initials="P." surname="Vixie"/>
<author fullname="L. Esibov" initials="L." surname="Esibov"/>
<date month="February" year="2000"/>
<abstract>
<t indent="0">This document describes a DNS RR which specifies the l
ocation of the server(s) for a specific protocol and domain. [STANDARDS-TRACK]</
t>
</abstract>
</front>
<seriesInfo name="RFC" value="2782"/>
<seriesInfo name="DOI" value="10.17487/RFC2782"/>
</reference>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc211
9" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml" quot
eTitle="true" derivedAnchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title
>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t indent="0">In many standards track documents several words are us
ed to signify the requirements in the specification. These words are often capi
talized. This document defines these words as they should be interpreted in IET
F documents. This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for improvements.</
t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC3629" target="https://www.rfc-editor.org/info/rfc362
9" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml" quot
eTitle="true" derivedAnchor="RFC3629">
<front>
<title>UTF-8, a transformation format of ISO 10646</title>
<author fullname="F. Yergeau" initials="F." surname="Yergeau"/>
<date month="November" year="2003"/>
<abstract>
<t indent="0">ISO/IEC 10646-1 defines a large character set called t
he Universal Character Set (UCS) which encompasses most of the world's writing s
ystems. The originally proposed encodings of the UCS, however, were not compati
ble with many current applications and protocols, and this has led to the develo
pment of UTF-8, the object of this memo. UTF-8 has the characteristic of preser
ving 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 va
lues. This memo obsoletes and replaces RFC 2279.</t>
</abstract>
</front>
<seriesInfo name="STD" value="63"/>
<seriesInfo name="RFC" value="3629"/>
<seriesInfo name="DOI" value="10.17487/RFC3629"/>
</reference>
<reference anchor="RFC3686" target="https://www.rfc-editor.org/info/rfc368
6" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3686.xml" quot
eTitle="true" derivedAnchor="RFC3686">
<front>
<title>Using Advanced Encryption Standard (AES) Counter Mode With IPse
c Encapsulating Security Payload (ESP)</title>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<date month="January" year="2004"/>
<abstract>
<t indent="0">This document describes the use of Advanced Encryption
Standard (AES) Counter Mode, with an explicit initialization vector, as an IPse
c Encapsulating Security Payload (ESP) confidentiality mechanism.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3686"/>
<seriesInfo name="DOI" value="10.17487/RFC3686"/>
</reference>
<reference anchor="RFC3826" target="https://www.rfc-editor.org/info/rfc382
6" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3826.xml" quot
eTitle="true" derivedAnchor="RFC3826">
<front>
<title>The Advanced Encryption Standard (AES) Cipher Algorithm in the
SNMP User-based Security Model</title>
<author fullname="U. Blumenthal" initials="U." surname="Blumenthal"/>
<author fullname="F. Maino" initials="F." surname="Maino"/>
<author fullname="K. McCloghrie" initials="K." surname="McCloghrie"/>
<date month="June" year="2004"/>
<abstract>
<t indent="0">This document describes a symmetric encryption protoco
l 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 de
scribed in this document is based on the Advanced Encryption Standard (AES) ciph
er algorithm used in Cipher FeedBack Mode (CFB), with a key size of 128 bits. [S
TANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3826"/>
<seriesInfo name="DOI" value="10.17487/RFC3826"/>
</reference>
<reference anchor="RFC5237" target="https://www.rfc-editor.org/info/rfc523
7" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5237.xml" quot
eTitle="true" derivedAnchor="RFC5237">
<front>
<title>IANA Allocation Guidelines for the Protocol Field</title>
<author fullname="J. Arkko" initials="J." surname="Arkko"/>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="February" year="2008"/>
<abstract>
<t indent="0">This document revises the IANA guidelines for allocati
ng 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 Int
ernet Best Current Practices for the Internet Community, and requests discussion
and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="37"/>
<seriesInfo name="RFC" value="5237"/>
<seriesInfo name="DOI" value="10.17487/RFC5237"/>
</reference>
<reference anchor="RFC5869" target="https://www.rfc-editor.org/info/rfc586
9" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5869.xml" quot
eTitle="true" derivedAnchor="RFC5869">
<front>
<title>HMAC-based Extract-and-Expand Key Derivation Function (HKDF)</t
itle>
<author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/>
<author fullname="P. Eronen" initials="P." surname="Eronen"/>
<date month="May" year="2010"/>
<abstract>
<t indent="0">This document specifies a simple Hashed Message Authen
tication Code (HMAC)-based key derivation function (HKDF), which can be used as
a building block in various protocols and applications. The key derivation func
tion (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 informatio
nal purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5869"/>
<seriesInfo name="DOI" value="10.17487/RFC5869"/>
</reference>
<reference anchor="RFC5890" target="https://www.rfc-editor.org/info/rfc589
0" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5890.xml" quot
eTitle="true" derivedAnchor="RFC5890">
<front>
<title>Internationalized Domain Names for Applications (IDNA): Definit
ions and Document Framework</title>
<author fullname="J. Klensin" initials="J." surname="Klensin"/>
<date month="August" year="2010"/>
<abstract>
<t indent="0">This document is one of a collection that, together, d
escribe the protocol and usage context for a revision of Internationalized Domai
n Names for Applications (IDNA), superseding the earlier version. It describes
the document collection and provides definitions and other material that are com
mon to the set. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5890"/>
<seriesInfo name="DOI" value="10.17487/RFC5890"/>
</reference>
<reference anchor="RFC5895" target="https://www.rfc-editor.org/info/rfc589
5" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5895.xml" quot
eTitle="true" derivedAnchor="RFC5895">
<front>
<title>Mapping Characters for Internationalized Domain Names in Applic
ations (IDNA) 2008</title>
<author fullname="P. Resnick" initials="P." surname="Resnick"/>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<date month="September" year="2010"/>
<abstract>
<t indent="0">In the original version of the Internationalized Domai
n 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 (des
cribed in RFCs 5890, 5891, 5892, and 5893) presumes that the input to the protoc
ol 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. Thi
s 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 publishe
d for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5895"/>
<seriesInfo name="DOI" value="10.17487/RFC5895"/>
</reference>
<reference anchor="RFC6234" target="https://www.rfc-editor.org/info/rfc623
4" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml" quot
eTitle="true" derivedAnchor="RFC6234">
<front>
<title>US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)</ti
tle>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd
"/>
<author fullname="T. Hansen" initials="T." surname="Hansen"/>
<date month="May" year="2011"/>
<abstract>
<t indent="0">Federal Information Processing Standard, FIPS</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6234"/>
<seriesInfo name="DOI" value="10.17487/RFC6234"/>
</reference>
<reference anchor="RFC6895" target="https://www.rfc-editor.org/info/rfc689
5" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6895.xml" quot
eTitle="true" derivedAnchor="RFC6895">
<front>
<title>Domain Name System (DNS) IANA Considerations</title>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd
"/>
<date month="April" year="2013"/>
<abstract>
<t indent="0">This document specifies Internet Assigned Numbers Auth
ority (IANA) parameter assignment considerations for the allocation of Domain Na
me System (DNS) resource record types, CLASSes, operation codes, error codes, DN
S protocol message header bits, and AFSDB resource record subtypes. It obsolete
s RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="42"/>
<seriesInfo name="RFC" value="6895"/>
<seriesInfo name="DOI" value="10.17487/RFC6895"/>
</reference>
<reference anchor="RFC6979" target="https://www.rfc-editor.org/info/rfc697
9" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6979.xml" quot
eTitle="true" derivedAnchor="RFC6979">
<front>
<title>Deterministic Usage of the Digital Signature Algorithm (DSA) an
d Elliptic Curve Digital Signature Algorithm (ECDSA)</title>
<author fullname="T. Pornin" initials="T." surname="Pornin"/>
<date month="August" year="2013"/>
<abstract>
<t indent="0">This document defines a deterministic digital signatur
e generation procedure. Such signatures are compatible with standard Digital Si
gnature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) d
igital signatures and can be processed with unmodified verifiers, which need not
be aware of the procedure described therein. Deterministic signatures retain t
he cryptographic security features associated with digital signatures but can be
more easily implemented in various environments, since they do not need access
to a source of high-quality randomness.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6979"/>
<seriesInfo name="DOI" value="10.17487/RFC6979"/>
</reference>
<reference anchor="RFC7748" target="https://www.rfc-editor.org/info/rfc774
8" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7748.xml" quot
eTitle="true" derivedAnchor="RFC7748">
<front>
<title>Elliptic Curves for Security</title>
<author fullname="A. Langley" initials="A." surname="Langley"/>
<author fullname="M. Hamburg" initials="M." surname="Hamburg"/>
<author fullname="S. Turner" initials="S." surname="Turner"/>
<date month="January" year="2016"/>
<abstract>
<t indent="0">This memo specifies two elliptic curves over prime fie
lds 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 de
terministically based on a list of required properties.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7748"/>
<seriesInfo name="DOI" value="10.17487/RFC7748"/>
</reference>
<reference anchor="RFC8032" target="https://www.rfc-editor.org/info/rfc803
2" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8032.xml" quot
eTitle="true" derivedAnchor="RFC8032">
<front>
<title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title>
<author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
<author fullname="I. Liusvaara" initials="I." surname="Liusvaara"/>
<date month="January" year="2017"/>
<abstract>
<t indent="0">This document describes elliptic curve signature schem
e Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantia
ted with recommended parameters for the edwards25519 and edwards448 curves. An
example implementation and test vectors are provided.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8032"/>
<seriesInfo name="DOI" value="10.17487/RFC8032"/>
</reference>
<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc812
6" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml" quot
eTitle="true" derivedAnchor="RFC8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</
title>
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="June" year="2017"/>
<abstract>
<t indent="0">Many protocols make use of points of extensibility tha
t use constants to identify various protocol parameters. To ensure that the valu
es in these fields do not have conflicting uses and to promote interoperability,
their allocations are often coordinated by a central record keeper. For IETF pr
otocols, that role is filled by the Internet Assigned Numbers Authority (IANA).<
/t>
<t indent="0">To make assignments in a given registry prudently, gui
dance describing the conditions under which new values should be assigned, as we
ll 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 speci
fication authors, in order to assure that the provided guidance for the IANA Con
siderations is clear and addresses the various issues that are likely in the ope
ration of a registry.</t>
<t indent="0">This is the third edition of this document; it obsolet
es RFC 5226.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc817
4" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml" quot
eTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</titl
e>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t indent="0">RFC 2119 specifies common key words that may be used i
n protocol specifications. This document aims to reduce the ambiguity by clarif
ying that only UPPERCASE usage of the key words have the defined special meaning
s.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8499" target="https://www.rfc-editor.org/info/rfc849
9" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml" quot
eTitle="true" derivedAnchor="RFC8499">
<front>
<title>DNS Terminology</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<author fullname="A. Sullivan" initials="A." surname="Sullivan"/>
<author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/>
<date month="January" year="2019"/>
<abstract>
<t indent="0">The Domain Name System (DNS) is defined in literally d
ozens of different RFCs. The terminology used by implementers and developers of
DNS protocols, and by operators of DNS systems, has sometimes changed in the dec
ades since the DNS was first defined. This document gives current definitions fo
r many of the terms used in the DNS in a single document.</t>
<t indent="0">This document obsoletes RFC 7719 and updates RFC 2308.
</t>
</abstract>
</front>
<seriesInfo name="BCP" value="219"/>
<seriesInfo name="RFC" value="8499"/>
<seriesInfo name="DOI" value="10.17487/RFC8499"/>
</reference>
<reference anchor="RFC9106" target="https://www.rfc-editor.org/info/rfc910
6" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9106.xml" quot
eTitle="true" derivedAnchor="RFC9106">
<front>
<title>Argon2 Memory-Hard Function for Password Hashing and Proof-of-W
ork Applications</title>
<author fullname="A. Biryukov" initials="A." surname="Biryukov"/>
<author fullname="D. Dinu" initials="D." surname="Dinu"/>
<author fullname="D. Khovratovich" initials="D." surname="Khovratovich
"/>
<author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
<date month="September" year="2021"/>
<abstract>
<t indent="0">This document describes the Argon2 memory-hard functio
n for password hashing and proof-of-work applications. We provide an implemente
r-oriented description with test vectors. The purpose is to simplify adoption o
f Argon2 for Internet protocols. This document is a product of the Crypto Forum
Research Group (CFRG) in the IRTF.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9106"/>
<seriesInfo name="DOI" value="10.17487/RFC9106"/>
</reference>
<reference anchor="GANA" target="https://gana.gnunet.org/" quoteTitle="tru
e" derivedAnchor="GANA">
<front> <front>
<title>GNUnet Assigned Numbers Authority (GANA)</title> <title>GNUnet Assigned Numbers Authority (GANA)</title>
<author> <author>
<organization showOnFrontPage="true">GNUnet e.V.</organization> <organization>GNUnet e.V.</organization>
</author> </author>
<date month="November" year="2022"/> <date year="2023"/>
</front> </front>
</reference> </reference>
<reference anchor="MODES" target="https://doi.org/10.6028/NIST.SP.800-38A"
quoteTitle="true" derivedAnchor="MODES"> <reference anchor="MODES" target="https://doi.org/10.6028/NIST.SP.800-38A"
>
<front> <front>
<title>Recommendation for Block Cipher Modes of Operation: Methods and Techniques</title> <title>Recommendation for Block Cipher Modes of Operation: Methods and Techniques</title>
<author initials="M." surname="Dworkin" fullname="Morris Dworkin"> <author initials="M." surname="Dworkin" fullname="Morris Dworkin">
<organization showOnFrontPage="true">NIST</organization> <organization>NIST</organization>
</author> </author>
<date year="2001" month="December"/> <date year="2001" month="December"/>
<abstract>
<t indent="0">
This recommendation defines five confidentiality modes of operati
on for use with an underlying symmetric key block cipher algorithm: Electronic C
odebook (ECB), Cipher Block Chaining (CBC), Cipher Feedback (CFB), Output Feedba
ck (OFB), and Counter (CTR). Used with an underlying block cipher algorithm that
is approved in a Federal Information Processing Standard (FIPS), these modes ca
n provide cryptographic protection for sensitive, but unclassified, computer dat
a.
</t>
</abstract>
</front> </front>
<refcontent>NIST Special Publication 800-38A</refcontent>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-38A"/>
</reference> </reference>
<!-- <reference anchor="GCM" target="https://doi.org/10.6028/NIST.SP <reference anchor="CrockfordB32" target="https://www.crockford.com/base32
.800-38D"> .html">
<front>
<title>Recommendation for Block Cipher Modes of Operation: Galois/Cou
nter Mode (GCM) and GMAC</title>
<author initials="M." surname="Dworkin" fullname="Morris Dworkin">
<organization>NIST</organization>
</author>
<date year="2007" month="November"/>
<abstract>
<t>
This Recommendation specifies the Galois/Counter Mode (GCM), an a
lgorithm for authenticated encryption with associated data, and its specializati
on, GMAC, for generating a message authentication code (MAC) on data that is not
encrypted. GCM and GMAC are modes of operation for an underlying approved symme
tric key block cipher.
</t>
</abstract>
</front>
</reference>-->
<!-- FIXME replace with RFC -->
<reference anchor="CrockfordB32" target="https://www.crockford.com/base32
.html" quoteTitle="true" derivedAnchor="CrockfordB32">
<front> <front>
<title>Base32</title> <title>Base 32</title>
<author initials="D." surname="Douglas" fullname="Douglas Crockford"> <author initials="D." surname="Crockford" fullname="Douglas Crockford"
>
</author> </author>
<date year="2019" month="March"/> <date year="2019" month="March"/>
</front> </front>
</reference> </reference>
<reference anchor="XSalsa20" target="https://cr.yp.to/snuffle/xsalsa-20110
204.pdf" quoteTitle="true" derivedAnchor="XSalsa20"> <reference anchor="XSalsa20" target="https://cr.yp.to/papers.html#xsalsa">
<front> <front>
<title>Extending the Salsa20 nonce</title> <title>Extending the Salsa20 nonce</title>
<author initials="D." surname="Bernstein" fullname="Daniel Bernstein"> <author initials="D. J." surname="Bernstein" fullname="Daniel Bernstei
<organization showOnFrontPage="true">University of Illinois at Chica n">
go</organization> <organization>University of Illinois at Chicago</organization>
</author> </author>
<date year="2011"/> <date year="2011"/>
</front> </front>
</reference> </reference>
<reference anchor="Unicode-UAX15" target="http://www.unicode.org/reports/t
r15/tr15-31.html" quoteTitle="true" derivedAnchor="Unicode-UAX15"> <reference anchor="Unicode-UAX15" target="https://www.unicode.org/reports/
tr15/tr15-31.html">
<front> <front>
<title>Unicode Standard Annex #15: Unicode Normalization Forms, Revisi <title>Unicode Standard Annex #15: Unicode Normalization Forms</title>
on 31</title> <author initials="M." surname="Davis" fullname="Mark Davis">
<author> <organization/>
<organization showOnFrontPage="true">The Unicode Consortium</organiz </author>
ation> <author initials="K." surname="Whistler" fullname="Ken Whistler">
<organization/>
</author>
<author initials="M." surname="Dürst" fullname="Martin Dürst">
<organization/>
</author> </author>
<date year="2009" month="September"/> <date year="2009" month="September"/>
</front> </front>
<refcontent>Revision 31, The Unicode Consortium, Mountain View</refconte nt>
</reference> </reference>
<reference anchor="Unicode-UTS46" target="https://www.unicode.org/reports/
tr46" quoteTitle="true" derivedAnchor="Unicode-UTS46"> <reference anchor="Unicode-UTS46" target="https://www.unicode.org/reports/
tr46">
<front> <front>
<title>Unicode Technical Standard #46: Unicode IDNA Compatibility Proc <title>Unicode Technical Standard #46: Unicode IDNA Compatibility Proc
essing, Revision 27</title> essing</title>
<author> <author initials="M." surname="Davis" fullname="Mark Davis">
<organization showOnFrontPage="true">The Unicode Consortium</organiz <organization/>
ation>
</author> </author>
<date year="2021" month="August"/> <author initials="M." surname="Suignard" fullname="Michel Suignard">
<organization/>
</author>
<date year="2023" month="September"/>
</front> </front>
<refcontent>Revision 31, The Unicode Consortium, Mountain View</refconte nt>
</reference> </reference>
<!-- <reference anchor="ISO20022">
<front>
<title>ISO 20022 Financial Services - Universal financial industry mess
age scheme</title>
<author>
<organization>International Organization for Standardization</organizat
ion>
<address>
<uri>http://www.iso.ch</uri>
</address>
</author>
<date month="May" year="2013"/>
</front>
</reference>-->
</references> </references>
<references pn="section-15"> <references>
<name slugifiedName="name-informative-references">Informative References</ <name>Informative References</name>
name>
<reference anchor="RFC1928" target="https://www.rfc-editor.org/info/rfc192 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1928.xml"
8" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1928.xml" quot />
eTitle="true" derivedAnchor="RFC1928"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml"
<front> />
<title>SOCKS Protocol Version 5</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml"
<author fullname="M. Leech" initials="M." surname="Leech"/> />
<author fullname="M. Ganis" initials="M." surname="Ganis"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7363.xml"
<author fullname="Y. Lee" initials="Y." surname="Lee"/> />
<author fullname="R. Kuris" initials="R." surname="Kuris"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8324.xml"
<author fullname="D. Koblas" initials="D." surname="Koblas"/> />
<author fullname="L. Jones" initials="L." surname="Jones"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8806.xml"
<date month="March" year="1996"/> />
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6761.xml"
<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 f <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8244.xml"
rom active discussions and prototype implementations. [STANDARDS-TRACK]</t> />
</abstract>
</front> <!-- draft-ietf-dnsop-alt-tld (RFC 9476; published) -->
<seriesInfo name="RFC" value="1928"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9476.xml"
<seriesInfo name="DOI" value="10.17487/RFC1928"/> />
</reference>
<reference anchor="RFC4033" target="https://www.rfc-editor.org/info/rfc403 <reference anchor="TorRendSpec" target="https://github.com/torproject/tors
3" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml" quot pec/blob/main/rend-spec-v3.txt">
eTitle="true" derivedAnchor="RFC4033">
<front>
<title>DNS Security Introduction and Requirements</title>
<author fullname="R. Arends" initials="R." surname="Arends"/>
<author fullname="R. Austein" initials="R." surname="Austein"/>
<author fullname="M. Larson" initials="M." surname="Larson"/>
<author fullname="D. Massey" initials="D." surname="Massey"/>
<author fullname="S. Rose" initials="S." surname="Rose"/>
<date month="March" year="2005"/>
<abstract>
<t indent="0">The Domain Name System Security Extensions (DNSSEC) ad
d data origin authentication and data integrity to the Domain Name System. This
document introduces these extensions and describes their capabilities and limit
ations. This document also discusses the services that the DNS security extensi
ons do and do not provide. Last, this document describes the interrelationships
between the documents that collectively describe DNSSEC. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4033"/>
<seriesInfo name="DOI" value="10.17487/RFC4033"/>
</reference>
<reference anchor="RFC6066" target="https://www.rfc-editor.org/info/rfc606
6" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml" quot
eTitle="true" derivedAnchor="RFC6066">
<front>
<title>Transport Layer Security (TLS) Extensions: Extension Definition
s</title>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd
"/>
<date month="January" year="2011"/>
<abstract>
<t indent="0">This document provides specifications for existing TLS
extensions. It is a companion document for RFC 5246, "The Transport Layer Secu
rity (TLS) Protocol Version 1.2". The extensions specified are server_name, max
_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and s
tatus_request. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6066"/>
<seriesInfo name="DOI" value="10.17487/RFC6066"/>
</reference>
<reference anchor="RFC7363" target="https://www.rfc-editor.org/info/rfc736
3" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7363.xml" quot
eTitle="true" derivedAnchor="RFC7363">
<front>
<title>Self-Tuning Distributed Hash Table (DHT) for REsource LOcation
And Discovery (RELOAD)</title>
<author fullname="J. Maenpaa" initials="J." surname="Maenpaa"/>
<author fullname="G. Camarillo" initials="G." surname="Camarillo"/>
<date month="September" year="2014"/>
<abstract>
<t indent="0">REsource LOcation And Discovery (RELOAD) is a peer-to-
peer (P2P) signaling protocol that provides an overlay network service. Peers i
n a RELOAD overlay network collectively run an overlay algorithm to organize the
overlay and to store and retrieve data. This document describes how the defaul
t 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>
</abstract>
</front>
<seriesInfo name="RFC" value="7363"/>
<seriesInfo name="DOI" value="10.17487/RFC7363"/>
</reference>
<reference anchor="RFC8324" target="https://www.rfc-editor.org/info/rfc832
4" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8324.xml" quot
eTitle="true" derivedAnchor="RFC8324">
<front>
<title>DNS Privacy, Authorization, Special Uses, Encoding, Characters,
Matching, and Root Structure: Time for Another Look?</title>
<author fullname="J. Klensin" initials="J." surname="Klensin"/>
<date month="February" year="2018"/>
<abstract>
<t indent="0">The basic design of the Domain Name System was complet
ed almost 30 years ago. The last half of that period has been characterized by
significant changes in requirements and expectations, some of which either requi
re changes to how the DNS is used or can be accommodated only poorly or not at a
ll. This document asks the question of whether it is time to either redesign an
d replace the DNS to match contemporary requirements and expectations (rather th
an continuing to try to design and implement incremental patches that are not fu
lly satisfactory) or draw some clear lines about functionality that is not reall
y needed or that should be performed in some other way.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8324"/>
<seriesInfo name="DOI" value="10.17487/RFC8324"/>
</reference>
<reference anchor="RFC8806" target="https://www.rfc-editor.org/info/rfc880
6" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8806.xml" quot
eTitle="true" derivedAnchor="RFC8806">
<front>
<title>Running a Root Server Local to a Resolver</title>
<author fullname="W. Kumari" initials="W." surname="Kumari"/>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<date month="June" year="2020"/>
<abstract>
<t indent="0">Some DNS recursive resolvers have longer-than-desired
round-trip times to the closest DNS root server; those resolvers may have diffic
ulty getting responses from the root servers, such as during a network attack. S
ome DNS recursive resolver operators want to prevent snooping by third parties o
f requests sent to DNS root servers. In both cases, resolvers can greatly decrea
se 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 r
esolver software. This document shows how to start and maintain such a copy of t
he root zone that does not cause problems for other users of the DNS, at the cos
t of adding some operational fragility for the operator.</t>
<t indent="0">This document obsoletes RFC 7706.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8806"/>
<seriesInfo name="DOI" value="10.17487/RFC8806"/>
</reference>
<reference anchor="RFC6761" target="https://www.rfc-editor.org/info/rfc676
1" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6761.xml" quot
eTitle="true" derivedAnchor="RFC6761">
<front>
<title>Special-Use Domain Names</title>
<author fullname="S. Cheshire" initials="S." surname="Cheshire"/>
<author fullname="M. Krochmal" initials="M." surname="Krochmal"/>
<date month="February" year="2013"/>
<abstract>
<t indent="0">This document describes what it means to say that a Do
main 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 fo
r such domain names, and seeds it with entries for some of the already establish
ed special domain names.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6761"/>
<seriesInfo name="DOI" value="10.17487/RFC6761"/>
</reference>
<reference anchor="RFC8244" target="https://www.rfc-editor.org/info/rfc824
4" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8244.xml" quot
eTitle="true" derivedAnchor="RFC8244">
<front>
<title>Special-Use Domain Names Problem Statement</title>
<author fullname="T. Lemon" initials="T." surname="Lemon"/>
<author fullname="R. Droms" initials="R." surname="Droms"/>
<author fullname="W. Kumari" initials="W." surname="Kumari"/>
<date month="October" year="2017"/>
<abstract>
<t indent="0">The policy defined in RFC 6761 for IANA registrations
in the "Special-Use Domain Names" registry has been shown, through experience, t
o present challenges that were not anticipated when RFC 6761 was written. This m
emo presents a list, intended to be comprehensive, of the problems that have sin
ce been identified. In addition, it reviews the history of domain names and summ
arizes current IETF publications and some publications from other organizations
relating to Special-Use Domain Names.</t>
<t indent="0">This document should be considered required reading fo
r IETF participants who wish to express an informed opinion on the topic of Spec
ial-Use Domain Names.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8244"/>
<seriesInfo name="DOI" value="10.17487/RFC8244"/>
</reference>
<reference anchor="I-D.ietf-dnsop-alt-tld" target="https://datatracker.iet
f.org/doc/html/draft-ietf-dnsop-alt-tld-25" xml:base="https://bib.ietf.org/publi
c/rfc/bibxml3/reference.I-D.ietf-dnsop-alt-tld.xml" quoteTitle="true" derivedAnc
hor="I-D.ietf-dnsop-alt-tld">
<front> <front>
<title>The ALT Special Use Top Level Domain</title> <title>Tor Rendezvous Specification - Version 3</title>
<author fullname="Warren &quot;Ace&quot; Kumari" initials="W. A." surn <author>
ame="Kumari"> <organization>Tor Project</organization>
<organization showOnFrontPage="true">Google</organization>
</author>
<author fullname="Paul E. Hoffman" initials="P. E." surname="Hoffman">
<organization showOnFrontPage="true">ICANN</organization>
</author> </author>
<date day="4" month="May" year="2023"/> <date month="June" year="2023"/>
<abstract>
<t indent="0">This document reserves a TLD label, "alt" to be used i
n non-DNS contexts. It also provides advice and guidance to developers developin
g alternative namespaces. [ This document is being collaborated on in Github at
&lt;https://github.com/wkumari/draft-wkumari-dnsop-alt-tld&gt;. The most recent
version of the document, open issues, etc should all be available here. The auth
ors (gratefully) accept pull requests. ]</t>
</abstract>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-alt-tld-25"/> <refcontent>commit b345ca0</refcontent>
<refcontent>Work in Progress</refcontent>
</reference> </reference>
<reference anchor="Tor224" target="https://gitweb.torproject.org/torspec.g
it/tree/proposals/224-rend-spec-ng.txt#n2135" quoteTitle="true" derivedAnchor="T <reference anchor="Tor224" target="https://gitweb.torproject.org/torspec.g
or224"> it/tree/proposals/224-rend-spec-ng.txt#n2135">
<front> <front>
<title>Next-Generation Hidden Services in Tor</title> <title>Next-Generation Hidden Services in Tor</title>
<author initials="D." surname="Goulet" fullname="David Goulet"> <author initials="D." surname="Goulet" fullname="David Goulet">
</author> </author>
<author initials="G." surname="Kadianakis" fullname="George Kadianakis "> <author initials="G." surname="Kadianakis" fullname="George Kadianakis ">
</author> </author>
<author initials="N." surname="Mathewson" fullname="Nick Mathewson"> <author initials="N." surname="Mathewson" fullname="Nick Mathewson">
</author> </author>
<date year="2013" month="November"/> <date year="2013" month="November"/>
</front> </front>
<refcontent>Appendix A.2 ("Tor's key derivation scheme")</refcontent>
</reference> </reference>
<reference anchor="SDSI" target="http://people.csail.mit.edu/rivest/Sdsi10
.ps" quoteTitle="true" derivedAnchor="SDSI"> <reference anchor="SDSI" target="https://citeseerx.ist.psu.edu/document?re
pid=rep1&amp;type=pdf&amp;doi=3837e0206bf73e5e8f0ba6db767a2f714ea7c367">
<front> <front>
<title>SDSI - A Simple Distributed Security Infrastructure</title> <title>SDSI - A Simple Distributed Security Infrastructure</title>
<author initials="R." surname="Rivest" fullname="Ron Rivest"> <author initials="R. L." surname="Rivest" fullname="Ron L. Rivest">
</author> </author>
<author initials="B." surname="Lampson" fullname="Butler Lampson"> <author initials="B." surname="Lampson" fullname="Butler Lampson">
</author> </author>
<date year="1996" month="April"/> <date year="1996" month="October"/>
</front> </front>
</reference> </reference>
<reference anchor="Kademlia" target="http://css.csail.mit.edu/6.824/2014/p
apers/kademlia.pdf" quoteTitle="true" derivedAnchor="Kademlia"> <reference anchor="Kademlia" target="https://css.csail.mit.edu/6.824/2014/
papers/kademlia.pdf">
<front> <front>
<title>Kademlia: A peer-to-peer information system based on the xor me tric.</title> <title>Kademlia: A Peer-to-peer Information System Based on the XOR Me tric</title>
<author initials="P." surname="Maymounkov" fullname="Petar Maymounkov" > <author initials="P." surname="Maymounkov" fullname="Petar Maymounkov" >
</author> </author>
<author initials="D." surname="Mazieres" fullname="David Mazieres"> <author initials="D." surname="Mazières" fullname="David Mazières">
</author> </author>
<date year="2002"/> <date year="2002"/>
</front> </front>
<seriesInfo name="DOI" value="10.1007/3-540-45748-8_5"/>
</reference> </reference>
<!--<reference anchor="Ipfs" target="https://arxiv.org/pdf/1407.3561">
<front>
<title>Ipfs-content addressed, versioned, p2p file system.</title>
<author initials="J." surname="Benet" fullname="Juan Benet">
</author>
<date year="2014"/>
</front>
</reference>
-->
<reference anchor="ed25519" target="https://ed25519.cr.yp.to/ed25519-2011 0926.pdf" quoteTitle="true" derivedAnchor="ed25519"> <reference anchor="ed25519" target="https://ed25519.cr.yp.to/ed25519-2011 0926.pdf">
<front> <front>
<title>High-Speed High-Security Signatures</title> <title>High-speed high-security signatures</title>
<author initials="D." surname="Bernstein" fullname="Daniel Bernstein"> <author initials="D. J." surname="Bernstein" fullname="Daniel Bernstei
<organization showOnFrontPage="true">University of Illinois at Chica n">
go</organization> <organization>University of Illinois at Chicago</organization>
</author> </author>
<author initials="N." surname="Duif" fullname="Niels Duif"> <author initials="N." surname="Duif" fullname="Niels Duif">
<organization showOnFrontPage="true">Technische Universiteit Eindhov en</organization> <organization>Technische Universiteit Eindhoven</organization>
</author> </author>
<author initials="T." surname="Lange" fullname="Tanja Lange"> <author initials="T." surname="Lange" fullname="Tanja Lange">
<organization showOnFrontPage="true">Technische Universiteit Eindhov en</organization> <organization>Technische Universiteit Eindhoven</organization>
</author> </author>
<author initials="P." surname="Schwabe" fullname="Peter Schwabe"> <author initials="P." surname="Schwabe" fullname="Peter Schwabe">
<organization showOnFrontPage="true">National Taiwan University</org anization> <organization>National Taiwan University</organization>
</author> </author>
<author initials="B." surname="Yang" fullname="Bo-Yin Yang"> <author initials="B-Y." surname="Yang" fullname="Bo-Yin Yang">
<organization showOnFrontPage="true">Academia Sinica</organization> <organization>Academia Sinica</organization>
</author> </author>
<date year="2011"/> <date year="2011"/>
</front> </front>
<seriesInfo name="DOI" value="10.1007/s13389-012-0027-1"/>
</reference> </reference>
<reference anchor="GNS" target="https://sci-hub.st/10.1007/978-3-319-12280
-9_9" quoteTitle="true" derivedAnchor="GNS"> <reference anchor="GNS" target="https://sci-hub.st/10.1007/978-3-319-12280
-9_9">
<front> <front>
<title>A Censorship-Resistant, Privacy-Enhancing and Fully Decentraliz ed Name System</title> <title>A Censorship-Resistant, Privacy-Enhancing and Fully Decentraliz ed Name System</title>
<author initials="M." surname="Wachs" fullname="Matthias Wachs"> <author initials="M." surname="Wachs" fullname="Matthias Wachs">
<organization showOnFrontPage="true">Technische Universität München< /organization> <organization>Technische Universität München</organization>
</author> </author>
<author initials="M." surname="Schanzenbach" fullname="Martin Schanzen bach"> <author initials="M." surname="Schanzenbach" fullname="Martin Schanzen bach">
<organization showOnFrontPage="true">Technische Universität München< /organization> <organization>Technische Universität München</organization>
</author> </author>
<author initials="C." surname="Grothoff" fullname="Christian Grothoff" > <author initials="C." surname="Grothoff" fullname="Christian Grothoff" >
<organization showOnFrontPage="true">Technische Universität München< /organization> <organization>Technische Universität München</organization>
</author> </author>
<date year="2014"/> <date month="October" year="2014"/>
</front> </front>
<refcontent>13th International Conference on Cryptology and Network Secu
rity (CANS)</refcontent>
<seriesInfo name="DOI" value="10.13140/2.1.4642.3044"/>
</reference> </reference>
<reference anchor="R5N" target="https://sci-hub.st/10.1109/ICNSS.2011.6060 022" quoteTitle="true" derivedAnchor="R5N"> <reference anchor="R5N" target="https://sci-hub.st/10.1109/ICNSS.2011.6060 022">
<front> <front>
<title>R5N: Randomized recursive routing for restricted-route networks </title> <title>R5N: Randomized Recursive Routing for Restricted-Route Networks </title>
<author initials="N. S." surname="Evans" fullname="Nathan S. Evans"> <author initials="N. S." surname="Evans" fullname="Nathan S. Evans">
<organization showOnFrontPage="true">Technische Universität München< /organization> <organization>Technische Universität München</organization>
</author> </author>
<author initials="C." surname="Grothoff" fullname="Christian Grothoff" > <author initials="C." surname="Grothoff" fullname="Christian Grothoff" >
<organization showOnFrontPage="true">Technische Universität München< /organization> <organization>Technische Universität München</organization>
</author> </author>
<date year="2011"/> <date month="September" year="2011"/>
</front> </front>
<refcontent>5th International Conference on Network and System Security
(NSS)</refcontent>
<seriesInfo name="DOI" value="10.1109/ICNSS.2011.6060022"/>
</reference> </reference>
<reference anchor="SecureNS" target="https://sci-hub.st/https://doi.org/10
.1016/j.cose.2018.01.018" quoteTitle="true" derivedAnchor="SecureNS"> <reference anchor="SecureNS" target="https://sci-hub.st/https://doi.org/10
.1016/j.cose.2018.01.018">
<front> <front>
<title>Towards secure name resolution on the Internet</title> <title>Toward secure name resolution on the Internet</title>
<author initials="C." surname="Grothoff" fullname="Christian Grothoff" > <author initials="C." surname="Grothoff" fullname="Christian Grothoff" >
<organization showOnFrontPage="true">Bern University of Applied Scie nces</organization> <organization>Bern University of Applied Sciences</organization>
</author> </author>
<author initials="M." surname="Wachs" fullname="Matthias Wachs"> <author initials="M." surname="Wachs" fullname="Matthias Wachs">
<organization showOnFrontPage="true">Technische Universität München< /organization> <organization>Technische Universität München</organization>
</author> </author>
<author initials="M." surname="Ermert" fullname="Monika Ermert"> <author initials="M." surname="Ermert" fullname="Monika Ermert">
</author> </author>
<author initials="J." surname="Appelbaum" fullname="Jacob Appelbaum"> <author initials="J." surname="Appelbaum" fullname="Jacob Appelbaum">
<organization showOnFrontPage="true">TU Eindhoven</organization> <organization>TU Eindhoven</organization>
</author> </author>
<date year="2018"/> <date month="August" year="2018"/>
</front> </front>
<refcontent>Computers and Security, Volume 77, Issue C, pp. 694-708</ref
content>
<seriesInfo name="DOI" value="10.1016/j.cose.2018.01.018"/>
</reference> </reference>
<reference anchor="GNUnetGNS" target="https://git.gnunet.org/gnunet.git/tr
ee/src/gns" quoteTitle="true" derivedAnchor="GNUnetGNS"> <reference anchor="GNUnetGNS" target="https://git.gnunet.org/gnunet.git">
<front> <front>
<title>The GNUnet GNS Implementation</title> <title>gnunet.git - GNUnet core repository</title>
<author> <author>
<organization showOnFrontPage="true">GNUnet e.V.</organization> <organization>GNUnet e.V.</organization>
</author> </author>
<date year="2023"/>
</front> </front>
</reference> </reference>
<reference anchor="Ascension" target="https://git.gnunet.org/ascension.git
" quoteTitle="true" derivedAnchor="Ascension"> <reference anchor="Ascension" target="https://git.gnunet.org/ascension.git
">
<front> <front>
<title>The Ascension Implementation</title> <title>ascension.git - DNS zones to GNS migrating using incremental zo
ne
transfer (AXFR/IXFR)</title>
<author> <author>
<organization showOnFrontPage="true">GNUnet e.V.</organization> <organization>GNUnet e.V.</organization>
</author> </author>
<date year="2023"/>
</front> </front>
</reference> </reference>
<reference anchor="GNUnet" target="https://gnunet.org" quoteTitle="true" d
erivedAnchor="GNUnet"> <reference anchor="GNUnet" target="https://gnunet.org">
<front> <front>
<title>The GNUnet Project</title> <title>The GNUnet Project (Home Page)</title>
<author> <author>
<organization showOnFrontPage="true">GNUnet e.V.</organization> <organization>GNUnet e.V.</organization>
</author> </author>
<date year="2023"/>
</front> </front>
</reference> </reference>
<reference anchor="reclaim" target="https://reclaim.gnunet.org" quoteTitle
="true" derivedAnchor="reclaim"> <reference anchor="reclaim" target="https://reclaim.gnunet.org">
<front> <front>
<title>re:claimID</title> <title>re:claimID - Self-sovereign, Decentralised Identity Management and Personal Data Sharing</title>
<author> <author>
<organization showOnFrontPage="true">GNUnet e.V.</organization> <organization>GNUnet e.V.</organization>
</author> </author>
<date year="2023"/>
</front> </front>
</reference> </reference>
<reference anchor="GoGNS" target="https://github.com/bfix/gnunet-go/tree/m
aster/src/gnunet/service/gns" quoteTitle="true" derivedAnchor="GoGNS"> <reference anchor="GoGNS" target="https://github.com/bfix/gnunet-go/tree/m
aster/src/gnunet/service/gns">
<front> <front>
<title>The Go GNS Implementation</title> <title>gnunet-go (Go GNS)</title>
<author initials="B." surname="Fix" fullname="Bernd Fix"> <author initials="B." surname="Fix" fullname="Bernd Fix">
</author> </author>
<date month="July" year="2023"/>
</front> </front>
<refcontent>commit 5c815ba</refcontent>
</reference> </reference>
<reference anchor="nsswitch" target="https://www.gnu.org/software/libc/man
ual/html_node/Name-Service-Switch.html" quoteTitle="true" derivedAnchor="nsswitc <reference anchor="nsswitch" target="https://www.gnu.org/software/libc/man
h"> ual/html_node/Name-Service-Switch.html">
<front> <front>
<title>System Databases and Name Service Switch</title> <title>System Databases and Name Service Switch (Section 29)</title>
<author> <author>
<organization showOnFrontPage="true">GNU Project</organization> <organization>GNU Project</organization>
</author> </author>
</front> </front>
</reference> </reference>
</references> </references>
<section numbered="true" removeInRFC="false" toc="include" pn="section-appen </references>
dix.a"> <section>
<name slugifiedName="name-usage-and-migration">Usage and Migration</name> <name>Usage and Migration</name>
<t indent="0" pn="section-appendix.a-1"> <t>
This section outlines a number of specific use cases which may This section outlines a number of specific use cases that may
help readers of the technical specification to understand the protocol help readers of this technical specification better understand the prot
better. ocol.
The considerations below are not meant to be normative for the The considerations below are not meant to be normative for the
GNS protocol in any way. GNS protocol in any way.
Instead, they are provided in order to give context and to provide Instead, they are provided in order to give context and to provide
some background on what the intended use of the protocol is some background on what the intended use of the protocol is
by its designers. by its designers.
Further, this section contains pointers to migration paths. Further, this section provides pointers to migration paths.
</t> </t>
<section anchor="day_in_zoneowner" numbered="true" removeInRFC="false" toc <section anchor="day_in_zoneowner">
="include" pn="section-a.1"> <name>Zone Dissemination</name>
<name slugifiedName="name-zone-dissemination">Zone Dissemination</name> <t>
<t indent="0" pn="section-a.1-1">
In order to become a zone owner, it is sufficient to generate In order to become a zone owner, it is sufficient to generate
a zone key and a corresponding secret key using a GNS implementation. a zone key and a corresponding secret key using a GNS implementation.
At this point, the zone owner can manage GNS resource records in a At this point, the zone owner can manage GNS resource records in a
local zone database. local zone database.
The resource records can then be published by a GNS implementation The resource records can then be published by a GNS implementation
as defined in <xref target="publish" format="default" sectionFormat=" as defined in <xref target="publish"/>.
of" derivedContent="Section 6"/>. For other users to resolve the resource records, the respective
For other users to resolve the resource records, respective
zone information must be disseminated first. zone information must be disseminated first.
The zone owner may decide to make the zone key and labels known The zone owner may decide to make the zone key and labels known
to a selected set of users only or to make this information available to a selected set of users only or to make this information available
to the general public. to the general public.
</t> </t>
<t indent="0" pn="section-a.1-2"> <t>
Sharing zone information directly with specific users not only allows Sharing zone information directly with specific users not only allows
to potentially preserve zone and record privacy, but also allows an implementation to potentially preserve zone and record privacy but also allows
the zone owner and the user to establish strong trust relationships. the zone owner and the user to establish strong trust relationships.
For example, a bank may send a customer letter with a QR code which For example, a bank may send a customer letter with a QR code that
contains the GNS zone of the bank. contains the GNS zone of the bank.
This allows the user to scan the QR code and establish a strong This allows the user to scan the QR code and establish a strong
link to the zone of the bank and with it, for example, the IP address link to the zone of the bank and with it, for example, the IP address
of the online banking web site. of the online banking web site.
</t> </t>
<t indent="0" pn="section-a.1-3"> <t>
Most Internet services likely want to make their zones available Most Internet services likely want to make their zones available
to the general public as efficiently as possible. to the general public in the most efficient way possible.
First, it is reasonable to assume that zones which are commanding First, it is reasonable to assume that zones that are commanding
high levels of reputation and trust are likely included in the high levels of reputation and trust are likely included in the
default suffix-to-zone mappings of implementations. default suffix-to-zone mappings of implementations.
Hence dissemination of a zone through delegation under such zones Hence, dissemination of a zone through delegation under such zones
can be a viable path in order to disseminate a zone publicly. can be a viable path in order to disseminate a zone publicly.
For example, it is conceivable that organizations such as ICANN For example, it is conceivable that organizations such as ICANN
or country-code top-level domain registrars also manage GNS zones or country-code TLD registrars also manage GNS zones
and offer registration or delegation services. and offer registration or delegation services.
</t> </t>
<t indent="0" pn="section-a.1-4"> <t>
Following best practices in particularly those relating to Following best practices, particularly those related to
security and abuse mitigation are methods which allow zone owners security and abuse mitigation, are methods that allow zone owners
and aspiring registrars to gain a good reputation and eventually and aspiring registrars to gain a good reputation and, eventually,
trust. trust.
This includes, of course, diligent protection of private zone key This includes, of course, diligent protection of private zone key
material. material.
Formalizing such best practices is out of scope of this Formalizing such best practices is out of scope for this
specification and should be addressed in a separate document and take specification and should be addressed in a separate document that tak
<xref target="security" format="default" sectionFormat="of" derivedCo es
ntent="Section 9"/> into account. <xref target="security"/> of this document into account.
</t> </t>
</section> </section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-a.2 <section>
"> <name>Start Zone Configuration</name>
<name slugifiedName="name-start-zone-configuration">Start Zone Configura <t>
tion</name>
<t indent="0" pn="section-a.2-1">
A user is expected to install a GNS implementation if it is not alrea dy A user is expected to install a GNS implementation if it is not alrea dy
provided through other means such as the operating system provided through other means such as the operating system
or the browser. or the browser.
It is likely that the implementation ships with a It is likely that the implementation ships with a
default start zone configuration. default Start Zone configuration.
This means that the user is able to resolve GNS names ending on a This means that the user is able to resolve GNS names ending on a
zTLD or ending on any suffix-to-name mapping that is part of the zTLD or ending on any suffix-to-name mapping that is part of the
default start zone configuration. default Start Zone configuration.
At this point the user may delete or otherwise modify the At this point, the user may delete or otherwise modify the
implementation's default configuration: implementation's default configuration:
</t> </t>
<t indent="0" pn="section-a.2-2"> <ul>
Deletion of suffix-to-zone mappings may become necessary of the <li>
Deletion of suffix-to-zone mappings may become necessary if the
zone owner referenced by the mapping has lost the trust of the user. zone owner referenced by the mapping has lost the trust of the user.
For example, this could be due to lax registration policies resultin g For example, this could be due to lax registration policies resultin g
in phishing activities. in phishing activities.
Modification and addition of new mappings are means to heal the Modification and addition of new mappings are means to heal the
namespace perforation which would occur in the case of a deletion namespace perforation that would occur in the case of a deletion
or to simply establish a strong direct trust relationship. or to simply establish a strong direct trust relationship.
However, this requires the user's knowledge of the respective zone However, this requires the user's knowledge of the respective zone
keys. keys.
This information must be retrieved out of band, as illustrated in This information must be retrieved out of band, as illustrated in
<xref target="day_in_zoneowner" format="default" sectionFormat="of" <xref target="day_in_zoneowner"/>:
derivedContent="Appendix A.1"/>: a bank may send the user a letter with a QR code that contains the
A bank may send the user a letter with a QR code which contains the
GNS zone of the bank. GNS zone of the bank.
The user scans the QR code and adds a new suffix-to-name mapping The user scans the QR code and adds a new suffix-to-name mapping
using a chosen local name for his bank. using a chosen local name for their bank.
Other examples include scanning zone information off the device of Other examples include scanning zone information off the device of
a friend, from a storefront, or an advertisement. a friend, from a storefront, or from an advertisement.
The level of trust in the respective zone is contextual and likely The level of trust in the respective zone is contextual and likely
varies from user to user. varies from user to user.
Trust in a zone provided through a letter from a bank which Trust in a zone provided through a letter from a bank that
may also include a credit card is certainly different from a zone may also include a credit card is certainly different from a zone
found on a random advertisement in the streets. found on a random advertisement on the street.
However, this trust is immediately tangible to the user and can However, this trust is immediately tangible to the user and can
be reflected in the local naming as well. be reflected in the local naming as well.
</t> </li>
<t indent="0" pn="section-a.2-3"> <li>
User clients should facilitate the modification of the start zone Users that are also clients should facilitate the modification of th
configuration, for example by providing a QR code reader or other e Start Zone
configuration -- for example, by providing a QR code reader or other
import mechanisms. import mechanisms.
Implementations are ideally implemented Implementations are ideally implemented
according to best practices and addressing applicable points according to best practices and addressing applicable points
from <xref target="security" format="default" sectionFormat="of" der from <xref target="security"/>.
ivedContent="Section 9"/>. Formalizing such best practices is out of scope for this
Formalizing such best practices is out of scope of this
specification. specification.
</t> </li>
</ul>
</section> </section>
<section anchor="uc_virthost" numbered="true" removeInRFC="false" toc="inc <section anchor="uc_virthost">
lude" pn="section-a.3"> <name>Globally Unique Names and the Web</name>
<name slugifiedName="name-globally-unique-names-and-t">Globally Unique N <t>
ames and the Web</name> HTTP virtual hosting and TLS Server Name Indication (SNI) are common
<t indent="0" pn="section-a.3-1">
HTTP virtual hosting and TLS Server Name Indication are common
use cases on the Web. use cases on the Web.
HTTP clients supply a DNS name in the HTTP HTTP clients supply a DNS name in the HTTP
"Host"-header or as part of the TLS handshake, respectively. "Host"-header or as part of the TLS handshake, respectively.
This allows the HTTP server to serve the indicated virtual host This allows the HTTP server to serve the indicated virtual host
with a matching TLS certificate. with a matching TLS certificate.
The global uniqueness of DNS names are a prerequisite of those use ca ses. The global uniqueness of DNS names is a prerequisite of those use cas es.
</t> </t>
<t indent="0" pn="section-a.3-2"> <t>
Not all GNS names are globally unique. Not all GNS names are globally unique.
But, any resource record in GNS can be represented as a However, any resource record in GNS can be represented as a
concatenation of of a GNS label and the zTLD of the zone. concatenation of a GNS label and the zTLD of the zone.
While not human-readable, this globally unique GNS name can be While not memorable, this globally unique GNS name can be
leveraged in order to facilitate the same use cases. leveraged in order to facilitate the same use cases.
Consider the GNS name "www.example.gns" entered in a GNS-aware Consider the GNS name "www.example.gns.alt" entered in a GNS-aware
HTTP client. HTTP client.
At first, "www.example.gns" is resolved using GNS yielding a record At first, "www.example.gns.alt" is resolved using GNS, yielding a rec ord
set. set.
Then, the HTTP client determines the virtual host as follows: Then, the HTTP client determines the virtual host as follows:
</t> </t>
<t indent="0" pn="section-a.3-3"> <t>
If there is a LEHO record (<xref target="gnsrecords_leho" format="de If there is a LEHO record (<xref target="gnsrecords_leho"/>)
fault" sectionFormat="of" derivedContent="Section 5.3.1"/>)
containing "www.example.com" in the record set, then the HTTP containing "www.example.com" in the record set, then the HTTP
client uses this as the value of the client uses this as the value of the
"Host"-header field of the HTTP request: "Host"-header field of the HTTP request:
</t> </t>
<artwork name="" type="" align="left" alt="" pn="section-a.3-4"> <sourcecode name="" type="http-message"><![CDATA[
GET / HTTP/1.1 GET / HTTP/1.1
Host: www.example.com Host: www.example.com
</artwork> ]]></sourcecode>
<t indent="0" pn="section-a.3-5"> <t>
If there is no LEHO record in the record set, In the absence of a LEHO record, an additional GNS resolution is
then the HTTP client tries to find the zone of the record required to check whether "www.example.gns.alt" itself points to a
and translates the GNS name into a globally unique zone delegation record, which implies that the record set that was
zTLD-representation before using it in the "Host"-header field of originally resolved is published under the apex label.
the HTTP request: </t>
<t>
If it does, the unique GNS name is simply the zTLD representation of
the delegated zone:
</t> </t>
<artwork name="" type="" align="left" alt="" pn="section-a.3-6"> <sourcecode name="" type="http-message"><![CDATA[
GET / HTTP/1.1 GET / HTTP/1.1
Host: www.000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W Host: 000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W
</artwork> ]]></sourcecode>
<t indent="0" pn="section-a.3-7"> <t>
In order to determine the canonical representation of the record wit On the other hand, if there is no zone delegation record for
h "www.example.gns.alt", then the unique GNS name is the concatenation of
a zTLD, at most two queries are required: the leftmost label (e.g., "www") and the zTLD representation of the zone:
First, it must be checked whether "www.example.gns.alt" itself point
s to
a zone delegation record which would imply that the record set which
was originally resolved is published under the apex label.
If it does, the unique GNS name is simply the zTLD representation
of the delegated zone:
</t> </t>
<artwork name="" type="" align="left" alt="" pn="section-a.3-8"> <sourcecode name="" type="http-message"><![CDATA[
GET / HTTP/1.1 GET / HTTP/1.1
Host: 000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W Host: www.000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W
</artwork> ]]></sourcecode>
<t indent="0" pn="section-a.3-9"> <t>
If it does not, the unique GNS name is the concatenation of the Note that this second GNS resolution does not require any additional
label "www" and the zTLD representation of the zone as given in the network operation, as only the local record processing differs as per
example above. the exception mentioned in the last sentence of <xref target="delegation_process
In any case, this representation is globally unique. ing"/>.
As such, it can be configured by the HTTP server administrator as a
virtual host name and respective certificates may be issued.
</t> </t>
<t indent="0" pn="section-a.3-10"> <t>
If the HTTP client is a browser, the use of a unique GNS name If the HTTP client is a browser, the use of a unique GNS name
for virtual hosting or TLS SNI does not necessarily have to be for virtual hosting or TLS SNI does not necessarily have to be
shown to the user. shown to the user.
For example, the name in the URL bar may remain as "www.example.gns. alt" For example, the name in the URL bar may remain as "www.example.gns. alt"
even if the used unique name differs. even if the used unique name in the "Host"-header differs.
</t> </t>
</section> </section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-a.4 <section>
"> <name>Migration Paths</name>
<name slugifiedName="name-migration-paths">Migration Paths</name> <t>
<t indent="0" pn="section-a.4-1">
DNS resolution is built into a variety of existing software DNS resolution is built into a variety of existing software
components. components -- most significantly, operating systems and HTTP clients
Most significantly operating systems and HTTP clients. .
This section illustrates possible migration paths for both in order This section illustrates possible migration paths for both in order
to enable "legacy" applications to resolve GNS names. to enable legacy applications to resolve GNS names.
</t> </t>
<t indent="0" pn="section-a.4-2"> <t>
One way to efficiently facilitate the resolution of GNS names One way to efficiently facilitate the resolution of GNS names
are GNS-enabled DNS server implementations. is via GNS-enabled DNS server implementations.
Local DNS queries are thereby either rerouted or explicitly configur ed Local DNS queries are thereby either rerouted or explicitly configur ed
to be resolved by a "DNS-to-GNS" server that runs locally. to be resolved by a "DNS-to-GNS" server that runs locally.
This DNS server tries to interpret any incoming query for a name This DNS server tries to interpret any incoming query for a name
as a GNS resolution request. as a GNS resolution request.
If no start zone can be found for the name and it does not end in If no Start Zone can be found for the name and it does not end in
a zTLD, the server tries to resolve the name in DNS. a zTLD, the server tries to resolve the name in DNS.
Otherwise, the name is resolved in GNS. Otherwise, the name is resolved in GNS.
In the latter case, the resulting record set is converted to a DNS In the latter case, the resulting record set is converted to a DNS
answer packet and is returned accordingly. answer packet and is returned accordingly.
An implementation of a DNS-to-GNS server can be found in An implementation of a DNS-to-GNS server can be found in
<xref target="GNUnet" format="default" sectionFormat="of" derivedCon tent="GNUnet"/>. <xref target="GNUnet"/>.
</t> </t>
<t indent="0" pn="section-a.4-3"> <t>
A similar approach is to use operating systems extensions such as A similar approach is to use operating system extensions such as
the name service switch <xref target="nsswitch" format="default" sec the NSS <xref target="nsswitch"/>.
tionFormat="of" derivedContent="nsswitch"/>.
It allows the system administrator to configure plugins It allows the system administrator to configure plugins
which are used for hostname resolution. that are used for hostname resolution.
A GNS name service switch plugin can be used in a similar fashion as A GNS nsswitch plugin can be used in a fashion similar to
the "DNS-to-GNS" server. that used for the DNS-to-GNS server.
An implementation of a glibc-compatible nsswitch plugin for GNS An implementation of a glibc-compatible nsswitch plugin for GNS
can be found in <xref target="GNUnet" format="default" sectionFormat ="of" derivedContent="GNUnet"/>. can be found in <xref target="GNUnet"/>.
</t> </t>
<t indent="0" pn="section-a.4-4"> <t>
The methods above are usually also effective for HTTP client The methods above are usually also effective for HTTP client
software. software.
However, HTTP clients are commonly used in combination with However, HTTP clients are commonly used in combination with
TLS. TLS.
TLS certificate validation and in particular server name indication TLS certificate validation, and SNI in particular, require additiona
(SNI) requires additional logic in HTTP clients when GNS names are l logic in HTTP clients when GNS names are
in play (<xref target="uc_virthost" format="default" sectionFormat=" in play (<xref target="uc_virthost"/>).
of" derivedContent="Appendix A.3"/>).
In order to transparently enable this functionality for migration In order to transparently enable this functionality for migration
purposes, a local GNS-aware SOCKS5 proxy <xref target="RFC1928" form at="default" sectionFormat="of" derivedContent="RFC1928"/> purposes, a local GNS-aware SOCKS5 proxy <xref target="RFC1928"/>
can be configured to resolve domain names. can be configured to resolve domain names.
The SOCKS5 proxy, similar to the DNS-to-GNS server, is capable The SOCKS5 proxy, similar to the DNS-to-GNS server, is capable
of resolving both GNS and DNS names. of resolving both GNS and DNS names.
In the event of a TLS connection request with a GNS name, the SOCKS5 In the event of a TLS connection request with a GNS name, the SOCKS5
proxy can act as a man-in-the-middle, terminating the TLS connection proxy can terminate the TLS connection
and establishing a secure connection against the requested host. and establish a secure connection against the requested host.
In order to establish a secure connection, the proxy may use LEHO In order to establish a secure connection, the proxy may use LEHO
and TLSA records stored in the record set under the GNS name. and TLSA records stored in the record set under the GNS name.
The proxy must provide a locally trusted certificate for the GNS The proxy must provide a locally trusted certificate for the GNS
name to the HTTP client which usually requires the generation and name to the HTTP client; this usually requires the generation and
configuration of a local trust anchor in the browser. configuration of a local trust anchor in the browser.
An implementation of this SOCKS5 proxy can be found in An implementation of this SOCKS5 proxy can be found in
<xref target="GNUnet" format="default" sectionFormat="of" derivedCon tent="GNUnet"/>. <xref target="GNUnet"/>.
</t> </t>
</section> </section>
</section> </section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-appen <section>
dix.b"> <name>Example Flows</name>
<name slugifiedName="name-example-flows">Example flows</name> <section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-b.1 <name>AAAA Example Resolution</name>
"> <figure anchor="figure_resolution_ex_aaaa">
<name slugifiedName="name-aaaa-example-resolution">AAAA Example Resoluti <name>Example Resolution of an IPv6 Address</name>
on</name> <artwork name="" type="" alt="">
<figure anchor="figure_resolution_ex_aaaa" align="left" suppress-title="
false" pn="figure-27">
<name slugifiedName="name-example-resolution-of-an-ip">Example resolut
ion of an IPv6 address.</name>
<artwork name="" type="" align="left" alt="" pn="section-b.1-1.1">
Local Host | Remote Local Host | Remote
| Storage | Storage
| |
| +---------+ | +---------+
| / /| | / /|
| +---------+ | | +---------+ |
+-----------+ (1) +----------+ | | | | +-----------+ (1) +----------+ | | | |
| | | | (4,6) | | Record | | | | | | (4,6) | | Record | |
|Application|----------| Resolver |---------------|-&gt;| Storage | | |Application|----------| Resolver |---------------|-&gt;| Storage | |
| |&lt;---------| |&lt;--------------|--| |/ | |&lt;---------| |&lt;--------------|--| |/
skipping to change at line 4249 skipping to change at line 3675
+---------+ | +---------+ |
/ v /| | / v /| |
+---------+ | | +---------+ | |
| | | | | | | |
| Start | | | | Start | | |
| Zones | | | | Zones | | |
| |/ | | |/ |
+---------+ | +---------+ |
</artwork> </artwork>
</figure> </figure>
<ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-b. <ol>
1-2"> <li>Look up AAAA record for name: "www.example.gnu.gns.alt".</li>
<li pn="section-b.1-2.1" derivedCounter="1.">Lookup AAAA record for n <li>Determine Start Zone for "www.example.gnu.gns.alt".</li>
ame: www.example.gnu.gns.alt.</li> <li>Start Zone: zkey0 - Remainder: "www.example".</li>
<li pn="section-b.1-2.2" derivedCounter="2.">Determine start zone for <li>Calculate q0=SHA512(ZKDF(zkey0, "example")) and initiate GET(q0).<
www.example.gnu.gns.alt.</li> /li>
<li pn="section-b.1-2.3" derivedCounter="3.">Start zone: zk0 - Remaind <li>Retrieve and decrypt RRBLOCK consisting of a single PKEY record co
er: www.example.</li> ntaining zkey1.</li>
<li pn="section-b.1-2.4" derivedCounter="4.">Calculate q0=SHA512(ZKDF( <li>Calculate q1=SHA512(ZKDF(zkey1, "www")) and initiate GET(q1).</li>
zk0, "example")) and initiate GET(q0).</li> <li>Retrieve RRBLOCK consisting of a single AAAA record containing the
<li pn="section-b.1-2.5" derivedCounter="5.">Retrieve and decrypt RRBL IPv6 address 2001:db8::1.</li>
OCK consisting of a single PKEY record containing zk1.</li> <li>Return record set to application.</li>
<li pn="section-b.1-2.6" derivedCounter="6.">Calculate q1=SHA512(ZKDF(
zk1, "www")) and initiate GET(q1).</li>
<li pn="section-b.1-2.7" derivedCounter="7.">Retrieve RRBLOCK consisti
ng of a single AAAA record containing the IPv6 address 2001:db8::1.</li>
<li pn="section-b.1-2.8" derivedCounter="8.">Return record set to appl
ication</li>
</ol> </ol>
</section> </section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-b.2 <section>
"> <name>REDIRECT Example Resolution</name>
<name slugifiedName="name-redirect-example-resolution">REDIRECT Example <figure anchor="figure_resolution_ex_redir">
Resolution</name> <name>Example Resolution of an IPv6 Address with Redirect</name>
<figure anchor="figure_resolution_ex_redir" align="left" suppress-title= <artwork name="" type="" alt="">
"false" pn="figure-28">
<name slugifiedName="name-example-resolution-of-an-ipv">Example resolu
tion of an IPv6 address with redirect.</name>
<artwork name="" type="" align="left" alt="" pn="section-b.2-1.1">
Local Host | Remote Local Host | Remote
| Storage | Storage
| |
| +---------+ | +---------+
| / /| | / /|
| +---------+ | | +---------+ |
+-----------+ (1) +----------+ | | | | +-----------+ (1) +----------+ | | | |
| | | | (4,6,8) | | Record | | | | | | (4,6,8) | | Record | |
|Application|----------| Resolver |----------------|-&gt;| Storage | | |Application|----------| Resolver |----------------|-&gt;| Storage | |
| |&lt;---------| |&lt;---------------|--| |/ | |&lt;---------| |&lt;---------------|--| |/
skipping to change at line 4291 skipping to change at line 3717
+---------+ | +---------+ |
/ v /| | / v /| |
+---------+ | | +---------+ | |
| | | | | | | |
| Start | | | | Start | | |
| Zones | | | | Zones | | |
| |/ | | |/ |
+---------+ | +---------+ |
</artwork> </artwork>
</figure> </figure>
<ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-b. <ol>
2-2"> <li>Look up AAAA record for name: "www.example.tld.gns.alt".</li>
<li pn="section-b.2-2.1" derivedCounter="1.">Lookup AAAA record for n <li>Determine Start Zone for "www.example.tld.gns.alt".</li>
ame: www.example.tld.gns.alt.</li> <li>Start Zone: zkey0 - Remainder: "www.example".</li>
<li pn="section-b.2-2.2" derivedCounter="2.">Determine start zone for <li>Calculate q0=SHA512(ZKDF(zkey0, "example")) and initiate GET(q0).<
www.example.tld.gns.alt.</li> /li>
<li pn="section-b.2-2.3" derivedCounter="3.">Start zone: zk0 - Remaind <li>Retrieve and decrypt RRBLOCK consisting of a single PKEY record co
er: www.example.</li> ntaining zkey1.</li>
<li pn="section-b.2-2.4" derivedCounter="4.">Calculate q0=SHA512(ZKDF( <li>Calculate q1=SHA512(ZKDF(zkey1, "www")) and initiate GET(q1).</li>
zk0, "example")) and initiate GET(q0).</li> <li>Retrieve and decrypt RRBLOCK consisting of a single REDIRECT recor
<li pn="section-b.2-2.5" derivedCounter="5.">Retrieve and decrypt RRBL d containing "www2.+".</li>
OCK consisting of a single PKEY record containing zk1.</li> <li>Calculate q2=SHA512(ZKDF(zkey1, "www2")) and initiate GET(q2).</li
<li pn="section-b.2-2.6" derivedCounter="6.">Calculate q1=SHA512(ZKDF( >
zk1, "www")) and initiate GET(q1).</li> <li>Retrieve and decrypt RRBLOCK consisting of a single AAAA record co
<li pn="section-b.2-2.7" derivedCounter="7.">Retrieve and decrypt RRBL ntaining the IPv6 address 2001:db8::1.</li>
OCK consisting of a single REDIRECT record containing www2.+.</li> <li>Return record set to application.</li>
<li pn="section-b.2-2.8" derivedCounter="8.">Calculate q2=SHA512(ZKDF(
zk1, "www2")) and initiate GET(q2).</li>
<li pn="section-b.2-2.9" derivedCounter="9.">Retrieve and decrypt RRBL
OCK consisting of a single AAAA record containing the IPv6 address 2001:db8::1.<
/li>
<li pn="section-b.2-2.10" derivedCounter="10.">Return record set to ap
plication.</li>
</ol> </ol>
</section> </section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-b.3 <section>
"> <name>GNS2DNS Example Resolution</name>
<name slugifiedName="name-gns2dns-example-resolution">GNS2DNS Example Re <figure anchor="figure_resolution_ex_gnsdns">
solution</name> <name>Example Resolution of an IPv6 Address with DNS Handover</name>
<figure anchor="figure_resolution_ex_gnsdns" align="left" suppress-title <artwork name="" type="" alt="">
="false" pn="figure-29">
<name slugifiedName="name-example-resolution-of-an-ipv6">Example resol
ution of an IPv6 address with DNS handover.</name>
<artwork name="" type="" align="left" alt="" pn="section-b.3-1.1">
Local Host | Remote Local Host | Remote
| Storage | Storage
| |
| +---------+ | +---------+
| / /| | / /|
| +---------+ | | +---------+ |
+-----------+ (1) +----------+ | | | | +-----------+ (1) +----------+ | | | |
| | | | (4) | | Record | | | | | | (4) | | Record | |
|Application|----------| Resolver |------------------|-&gt;| Storage | | |Application|----------| Resolver |------------------|-&gt;| Storage | |
| |&lt;---------| |&lt;-----------------|--| |/ | |&lt;---------| |&lt;-----------------|--| |/
+-----------+ (8) +----------+ (5) | +---------+ +-----------+ (8) +----------+ (5) | +---------+
A A | A A |
| | (6,7) | | | (6,7) |
(2,3) | +----------+ | (2,3) | +----------+ |
| | | | | |
| v | | v |
+---------+ +------------+ | +---------+ +------------+ |
/ v /| | System DNS | | / v /| | System DNS | |
+---------+ | | resolver | | +---------+ | | Resolver | |
| | | +------------+ | | | | +------------+ |
| Start | | | | Start | | |
| Zones | | | | Zones | | |
| |/ | | |/ |
+---------+ | +---------+ |
</artwork> </artwork>
</figure> </figure>
<ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-b. <ol>
3-2"> <li>Look up AAAA record for name: "www.example.gnu.gns.alt".</li>
<li pn="section-b.3-2.1" derivedCounter="1.">Lookup AAAA record for n <li>Determine Start Zone for "www.example.gnu.gns.alt".</li>
ame: www.example.gnu.gns.alt</li> <li>Start Zone: zkey0 - Remainder: "www.example".</li>
<li pn="section-b.3-2.2" derivedCounter="2.">Determine start zone for <li>Calculate q0=SHA512(ZKDF(zkey0, "example")) and initiate GET(q0).<
www.example.gnu.gns.alt.</li> /li>
<li pn="section-b.3-2.3" derivedCounter="3.">Start zone: zk0 - Remaind <li>Retrieve and decrypt RRBLOCK consisting of a single GNS2DNS record
er: www.example.</li> containing the name "example.com" and the DNS server IPv4 address 192.0.2.1.</l
<li pn="section-b.3-2.4" derivedCounter="4.">Calculate q0=SHA512(ZKDF( i>
zk0, "example")) and initiate GET(q0).</li> <li>Use system resolver to look up a AAAA record for the DNS name "www
<li pn="section-b.3-2.5" derivedCounter="5.">Retrieve and decrypt RRBL .example.com".</li>
OCK consisting of a single GNS2DNS record containing the name example.com and th <li>Retrieve a DNS reply consisting of a single AAAA record containing
e DNS server IPv4 address 192.0.2.1.</li> the IPv6 address 2001:db8::1.</li>
<li pn="section-b.3-2.6" derivedCounter="6.">Use system resolver to lo <li>Return record set to application.</li>
okup an AAAA record for the DNS name www.example.com.</li>
<li pn="section-b.3-2.7" derivedCounter="7.">Retrieve a DNS reply cons
isting of a single AAAA record containing the IPv6 address 2001:db8::1.</li>
<li pn="section-b.3-2.8" derivedCounter="8.">Return record set to appl
ication.</li>
</ol> </ol>
</section> </section>
</section> </section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-appen <section anchor="app-c">
dix.c"> <name>Base32GNS</name>
<name slugifiedName="name-base32gns">Base32GNS</name> <t>
<t indent="0" pn="section-appendix.c-1">
Encoding converts a byte array into a string of symbols. Encoding converts a byte array into a string of symbols.
Decoding converts a string of symbols into a byte array. Decoding converts a string of symbols into a byte array.
Decoding fails if the input string has symbols outside the defined set. Decoding fails if the input string has symbols outside the defined set.
</t> </t>
<t indent="0" pn="section-appendix.c-2"> <t>
This table defines the encode and decode symbols for a given <xref target="CrockfordB32Encode"/> defines the encoding and decoding s
ymbols for a given
symbol value. symbol value.
Each symbol value encodes 5 bits. Each symbol value encodes 5 bits.
It can be used to implement the encoding by reading it as: It can be used to implement the encoding by reading it as follows:
A symbol "A" or "a" is decoded to a 5 bit value 10 when decoding. a symbol "A" or "a" is decoded to a 5-bit value 10 when decoding.
A 5 bit block with a value of 18 is encoded to the character "J" when e A 5-bit block with a value of 18 is encoded to the character "J" when e
ncoding. ncoding.
If the bit length of the byte string to encode is not a multiple of 5 If the bit length of the byte string to encode is not a multiple of 5,
it is padded to the next multiple with zeroes. it is padded to the next multiple with zeroes.
In order to further increase tolerance for failures in character In order to further increase tolerance for failures in character
recognition, the letter "U" <bcp14>MUST</bcp14> be decoded to the same value as the recognition, the letter "U" <bcp14>MUST</bcp14> be decoded to the same value as the
letter "V" in Base32GNS. letter "V" in Base32GNS.
</t> </t>
<figure anchor="CrockfordB32Encode" align="left" suppress-title="false" pn <table anchor="CrockfordB32Encode">
="figure-30"> <name>The Base32GNS Alphabet, Including the Additional Encoding Symbol &quot;U
<name slugifiedName="name-the-base32gns-alphabet-incl">The Base32GNS Alp &quot;</name>
habet Including the Additional U Encode Symbol.</name> <thead>
<artwork name="" type="" align="left" alt="" pn="section-appendix.c-3.1" <tr>
> <th>Symbol Value</th>
Symbol Decode Encode <th>Decoding Symbol</th>
Value Symbol Symbol <th>Encoding Symbol</th>
0 0 O o 0 </tr>
1 1 I i L l 1 </thead>
2 2 2 <tbody>
3 3 3 <tr>
4 4 4 <td>0</td>
5 5 5 <td>0 O o</td>
6 6 6 <td>0</td>
7 7 7 </tr>
8 8 8 <tr>
9 9 9 <td>1</td>
10 A a A <td>1 I i L l</td>
11 B b B <td>1</td>
12 C c C </tr>
13 D d D <tr>
14 E e E <td>2</td>
15 F f F <td>2</td>
16 G g G <td>2</td>
17 H h H </tr>
18 J j J <tr>
19 K k K <td>3</td>
20 M m M <td>3</td>
21 N n N <td>3</td>
22 P p P </tr>
23 Q q Q <tr>
24 R r R <td>4</td>
25 S s S <td>4</td>
26 T t T <td>4</td>
27 V v U u V </tr>
28 W w W <tr>
29 X x X <td>5</td>
30 Y y Y <td>5</td>
31 Z z Z <td>5</td>
</artwork> </tr>
</figure> <tr>
<td>6</td>
<td>6</td>
<td>6</td>
</tr>
<tr>
<td>7</td>
<td>7</td>
<td>7</td>
</tr>
<tr>
<td>8</td>
<td>8</td>
<td>8</td>
</tr>
<tr>
<td>9</td>
<td>9</td>
<td>9</td>
</tr>
<tr>
<td>10</td>
<td>A a</td>
<td>A</td>
</tr>
<tr>
<td>11</td>
<td>B b</td>
<td>B</td>
</tr>
<tr>
<td>12</td>
<td>C c</td>
<td>C</td>
</tr>
<tr>
<td>13</td>
<td>D d</td>
<td>D</td>
</tr>
<tr>
<td>14</td>
<td>E e</td>
<td>E</td>
</tr>
<tr>
<td>15</td>
<td>F f</td>
<td>F</td>
</tr>
<tr>
<td>16</td>
<td>G g</td>
<td>G</td>
</tr>
<tr>
<td>17</td>
<td>H h</td>
<td>H</td>
</tr>
<tr>
<td>18</td>
<td>J j</td>
<td>J</td>
</tr>
<tr>
<td>19</td>
<td>K k</td>
<td>K</td>
</tr>
<tr>
<td>20</td>
<td>M m</td>
<td>M</td>
</tr>
<tr>
<td>21</td>
<td>N n</td>
<td>N</td>
</tr>
<tr>
<td>22</td>
<td>P p</td>
<td>P</td>
</tr>
<tr>
<td>23</td>
<td>Q q</td>
<td>Q</td>
</tr>
<tr>
<td>24</td>
<td>R r</td>
<td>R</td>
</tr>
<tr>
<td>25</td>
<td>S s</td>
<td>S</td>
</tr>
<tr>
<td>26</td>
<td>T t</td>
<td>T</td>
</tr>
<tr>
<td>27</td>
<td>V v U u</td>
<td>V</td>
</tr>
<tr>
<td>28</td>
<td>W w</td>
<td>W</td>
</tr>
<tr>
<td>29</td>
<td>X x</td>
<td>X</td>
</tr>
<tr>
<td>30</td>
<td>Y y</td>
<td>Y</td>
</tr>
<tr>
<td>31</td>
<td>Z z</td>
<td>Z</td>
</tr>
</tbody>
</table>
</section> </section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-appen <section>
dix.d"> <name>Test Vectors</name>
<name slugifiedName="name-test-vectors">Test Vectors</name> <t>
<t indent="0" pn="section-appendix.d-1">
The following test vectors can be used by implementations to test The following test vectors can be used by implementations to test
for conformance with this specification. Unless indicated otherwise, for conformance with this specification. Unless indicated otherwise,
the test vectors are provided as hexadecimal byte arrays. the test vectors are provided as hexadecimal byte arrays.
</t> </t>
<section numbered="true" removeInRFC="false" toc="include" pn="section-d.1 <section>
"> <name>Base32GNS Encoding/Decoding</name>
<name slugifiedName="name-base32gns-en-decoding">Base32GNS en-/decoding< <t>
/name>
<t indent="0" pn="section-d.1-1">
The following are test vectors for the Base32GNS encoding used for zT LDs. The input strings are encoded without the zero terminator. The following are test vectors for the Base32GNS encoding used for zT LDs. The input strings are encoded without the zero terminator.
</t> </t>
<artwork name="" type="" align="left" alt="" pn="section-d.1-2"> <sourcecode name="" type="test-vectors"><![CDATA[
Base32GNS-Encode: Base32GNS-Encode:
Input string: "Hello World" Input string: "Hello World"
Output string: "91JPRV3F41BPYWKCCG" Output string: "91JPRV3F41BPYWKCCG"
Input bytes: 474e55204e616d652053797374656d Input bytes: 474e55204e616d652053797374656d
Output string: "8X75A82EC5PPA82KF5SQ8SBD" Output string: "8X75A82EC5PPA82KF5SQ8SBD"
Base32GNS-Decode: Base32GNS-Decode:
Input string: "91JPRV3F41BPYWKCCG" Input string: "91JPRV3F41BPYWKCCG"
Output string: "Hello World" Output string: "Hello World"
Input string: "91JPRU3F41BPYWKCCG" Input string: "91JPRU3F41BPYWKCCG"
Output string: "Hello World" Output string: "Hello World"
]]></sourcecode>
</artwork>
</section> </section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-d.2 <section>
"> <name>Record Sets</name>
<name slugifiedName="name-record-sets">Record sets</name> <t>
<t indent="0" pn="section-d.2-1">
The test vectors include record sets with a variety The test vectors include record sets with a variety
of record types and flags for both PKEY and EDKEY zones. of record types and flags for both PKEY and EDKEY zones.
This includes labels with UTF-8 characters to demonstrate This includes labels with UTF-8 characters to demonstrate
internationalized labels. internationalized labels.
</t> </t>
<t indent="0" pn="section-d.2-2"><strong>(1) PKEY zone with ASCII label <t><strong>(1) PKEY zone with ASCII label and one delegation record</str
and one delegation record</strong></t> ong></t>
<artwork name="" type="" align="left" alt="" pn="section-d.2-3"> <sourcecode name="" type="test-vectors"><![CDATA[
Zone private key (d, big-endian): Zone private key (d, big-endian):
50 d7 b6 52 a4 ef ea df 50 d7 b6 52 a4 ef ea df
f3 73 96 90 97 85 e5 95 f3 73 96 90 97 85 e5 95
21 71 a0 21 78 c8 e7 d4 21 71 a0 21 78 c8 e7 d4
50 fa 90 79 25 fa fd 98 50 fa 90 79 25 fa fd 98
Zone identifier (ztype|zkey): Zone identifier (ztype|zkey):
00 01 00 00 67 7c 47 7d 00 01 00 00 67 7c 47 7d
2d 93 09 7c 85 b1 95 c6 2d 93 09 7c 85 b1 95 c6
f9 6d 84 ff 61 f5 98 2c f9 6d 84 ff 61 f5 98 2c
skipping to change at line 4518 skipping to change at line 4076
Storage key (q): Storage key (q):
4a dc 67 c5 ec ee 9f 76 4a dc 67 c5 ec ee 9f 76
98 6a bd 71 c2 22 4a 3d 98 6a bd 71 c2 22 4a 3d
ce 2e 91 70 26 c9 a0 9d ce 2e 91 70 26 c9 a0 9d
fd 44 ce f3 d2 0f 55 a2 fd 44 ce f3 d2 0f 55 a2
73 32 72 5a 6c 8a fb bb 73 32 72 5a 6c 8a fb bb
b0 f7 ec 9a f1 cc 42 64 b0 f7 ec 9a f1 cc 42 64
12 99 40 6b 04 fd 9b 5b 12 99 40 6b 04 fd 9b 5b
57 91 f8 6c 4b 08 d5 f4 57 91 f8 6c 4b 08 d5 f4
ZKDF(zkey): ZKDF(zkey, label):
18 2b b6 36 ed a7 9f 79 18 2b b6 36 ed a7 9f 79
57 11 bc 27 08 ad bb 24 57 11 bc 27 08 ad bb 24
2a 60 44 6a d3 c3 08 03 2a 60 44 6a d3 c3 08 03
12 1d 03 d3 48 b7 ce b6 12 1d 03 d3 48 b7 ce b6
Derived private key (d', big-endian): Derived private key (d', big-endian):
0a 4c 5e 0f 00 63 df ce 0a 4c 5e 0f 00 63 df ce
db c8 c7 f2 b2 2c 03 0c db c8 c7 f2 b2 2c 03 0c
86 28 b2 c2 cb ac 9f a7 86 28 b2 c2 cb ac 9f a7
29 aa e6 1f 89 db 3e 9c 29 aa e6 1f 89 db 3e 9c
skipping to change at line 4559 skipping to change at line 4117
aa 09 a4 29 f7 29 e9 f5 aa 09 a4 29 f7 29 e9 f5
c6 ee c2 47 0a ce e2 22 c6 ee c2 47 0a ce e2 22
07 59 e9 e3 6c 88 6f 35 07 59 e9 e3 6c 88 6f 35
00 1c ee 8c 10 e2 59 80 00 1c ee 8c 10 e2 59 80
0c 1e da 5c c0 94 a1 c7 0c 1e da 5c c0 94 a1 c7
a8 88 64 9d 25 fa ee bd a8 88 64 9d 25 fa ee bd
60 da e6 07 3d 57 d8 ae 60 da e6 07 3d 57 d8 ae
8d 45 5f 4f 13 92 c0 74 8d 45 5f 4f 13 92 c0 74
e2 6a c6 69 bd ee c2 34 e2 6a c6 69 bd ee c2 34
62 b9 62 95 2c c6 e9 eb 62 b9 62 95 2c c6 e9 eb
]]></sourcecode>
</artwork> <t><strong>(2) PKEY zone with UTF-8 label and three records</strong></t>
<t indent="0" pn="section-d.2-4"><strong>(2) PKEY zone with UTF-8 label <sourcecode name="" type="test-vectors"><![CDATA[
and three records</strong></t>
<artwork name="" type="" align="left" alt="" pn="section-d.2-5">
Zone private key (d, big-endian): Zone private key (d, big-endian):
50 d7 b6 52 a4 ef ea df 50 d7 b6 52 a4 ef ea df
f3 73 96 90 97 85 e5 95 f3 73 96 90 97 85 e5 95
21 71 a0 21 78 c8 e7 d4 21 71 a0 21 78 c8 e7 d4
50 fa 90 79 25 fa fd 98 50 fa 90 79 25 fa fd 98
Zone identifier (ztype|zkey): Zone identifier (ztype|zkey):
00 01 00 00 67 7c 47 7d 00 01 00 00 67 7c 47 7d
2d 93 09 7c 85 b1 95 c6 2d 93 09 7c 85 b1 95 c6
f9 6d 84 ff 61 f5 98 2c f9 6d 84 ff 61 f5 98 2c
skipping to change at line 4677 skipping to change at line 4233
Storage key (q): Storage key (q):
af f0 ad 6a 44 09 73 68 af f0 ad 6a 44 09 73 68
42 9a c4 76 df a1 f3 4b 42 9a c4 76 df a1 f3 4b
ee 4c 36 e7 47 6d 07 aa ee 4c 36 e7 47 6d 07 aa
64 63 ff 20 91 5b 10 05 64 63 ff 20 91 5b 10 05
c0 99 1d ef 91 fc 3e 10 c0 99 1d ef 91 fc 3e 10
90 9f 87 02 c0 be 40 43 90 9f 87 02 c0 be 40 43
67 78 c7 11 f2 ca 47 d5 67 78 c7 11 f2 ca 47 d5
5c f0 b5 4d 23 5d a9 77 5c f0 b5 4d 23 5d a9 77
ZKDF(zkey): ZKDF(zkey, label):
a5 12 96 df 75 7e e2 75 a5 12 96 df 75 7e e2 75
ca 11 8d 4f 07 fa 7a ae ca 11 8d 4f 07 fa 7a ae
55 08 bc f5 12 aa 41 12 55 08 bc f5 12 aa 41 12
14 29 d4 a0 de 9d 05 7e 14 29 d4 a0 de 9d 05 7e
Derived private key (d', big-endian): Derived private key (d', big-endian):
0a be 56 d6 80 68 ab 40 0a be 56 d6 80 68 ab 40
e1 44 79 0c de 9a cf 4d e1 44 79 0c de 9a cf 4d
78 7f 2d 3c 63 b8 53 05 78 7f 2d 3c 63 b8 53 05
74 6e 68 03 32 15 f2 ab 74 6e 68 03 32 15 f2 ab
skipping to change at line 4738 skipping to change at line 4294
f0 d7 10 4f 6b 8d 24 c2 f0 d7 10 4f 6b 8d 24 c2
ac 9b c1 3d 9c 6f e8 29 ac 9b c1 3d 9c 6f e8 29
05 25 d2 a6 d0 f8 84 42 05 25 d2 a6 d0 f8 84 42
67 a1 57 0e 8e 29 4d c9 67 a1 57 0e 8e 29 4d c9
3a 31 9f cf c0 3e a2 70 3a 31 9f cf c0 3e a2 70
17 d6 fd a3 47 b4 a7 94 17 d6 fd a3 47 b4 a7 94
97 d7 f6 b1 42 2d 4e dd 97 d7 f6 b1 42 2d 4e dd
82 1c 19 93 4e 96 c1 aa 82 1c 19 93 4e 96 c1 aa
87 76 57 25 d4 94 c7 64 87 76 57 25 d4 94 c7 64
b1 55 dc 6d 13 26 91 74 b1 55 dc 6d 13 26 91 74
</artwork> ]]></sourcecode>
<t indent="0" pn="section-d.2-6"><strong>(3) EDKEY zone with ASCII label <t><strong>(3) EDKEY zone with ASCII label and one delegation record</st
and delegation record</strong></t> rong></t>
<artwork name="" type="" align="left" alt="" pn="section-d.2-7"> <sourcecode name="" type="test-vectors"><![CDATA[
Zone private key (d): Zone private key (d):
5a f7 02 0e e1 91 60 32 5a f7 02 0e e1 91 60 32
88 32 35 2b bc 6a 68 a8 88 32 35 2b bc 6a 68 a8
d7 1a 7c be 1b 92 99 69 d7 1a 7c be 1b 92 99 69
a7 c6 6d 41 5a 0d 8f 65 a7 c6 6d 41 5a 0d 8f 65
Zone identifier (ztype|zkey): Zone identifier (ztype|zkey):
00 01 00 14 3c f4 b9 24 00 01 00 14 3c f4 b9 24
03 20 22 f0 dc 50 58 14 03 20 22 f0 dc 50 58 14
53 b8 5d 93 b0 47 b6 3d 53 b8 5d 93 b0 47 b6 3d
skipping to change at line 4813 skipping to change at line 4368
Storage key (q): Storage key (q):
ab aa ba c0 e1 24 94 59 ab aa ba c0 e1 24 94 59
75 98 83 95 aa c0 24 1e 75 98 83 95 aa c0 24 1e
55 59 c4 1c 40 74 e2 55 55 59 c4 1c 40 74 e2 55
7b 9f e6 d1 54 b6 14 fb 7b 9f e6 d1 54 b6 14 fb
cd d4 7f c7 f5 1d 78 6d cd d4 7f c7 f5 1d 78 6d
c2 e0 b1 ec e7 60 37 c0 c2 e0 b1 ec e7 60 37 c0
a1 57 8c 38 4e c6 1d 44 a1 57 8c 38 4e c6 1d 44
56 36 a9 4e 88 03 29 e9 56 36 a9 4e 88 03 29 e9
ZKDF(zkey): ZKDF(zkey, label):
9b f2 33 19 8c 6d 53 bb 9b f2 33 19 8c 6d 53 bb
db ac 49 5c ab d9 10 49 db ac 49 5c ab d9 10 49
a6 84 af 3f 40 51 ba ca a6 84 af 3f 40 51 ba ca
b0 dc f2 1c 8c f2 7a 1a b0 dc f2 1c 8c f2 7a 1a
nonce := SHA-256 (dh[32..63] || h): nonce := SHA-256(dh[32..63] || h):
14 f2 c0 6b ed c3 aa 2d 14 f2 c0 6b ed c3 aa 2d
f0 71 13 9c 50 39 34 f3 f0 71 13 9c 50 39 34 f3
4b fa 63 11 a8 52 f2 11 4b fa 63 11 a8 52 f2 11
f7 3a df 2e 07 61 ec 35 f7 3a df 2e 07 61 ec 35
Derived private key (d', big-endian): Derived private key (d', big-endian):
3b 1b 29 d4 23 0b 10 a8 3b 1b 29 d4 23 0b 10 a8
ec 4d a3 c8 6e db 88 ea ec 4d a3 c8 6e db 88 ea
cd 54 08 5c 1d db 63 f7 cd 54 08 5c 1d db 63 f7
a9 d7 3f 7c cb 2f c3 98 a9 d7 3f 7c cb 2f c3 98
skipping to change at line 4864 skipping to change at line 4419
db 4e 83 94 3f 90 72 00 db 4e 83 94 3f 90 72 00
00 1c ee 8c 10 e2 59 80 00 1c ee 8c 10 e2 59 80
57 7c c6 c9 5a 14 e7 04 57 7c c6 c9 5a 14 e7 04
09 f2 0b 01 67 e6 36 d0 09 f2 0b 01 67 e6 36 d0
10 80 7c 4f 00 37 2d 69 10 80 7c 4f 00 37 2d 69
8c 82 6b d9 2b c2 2b d6 8c 82 6b d9 2b c2 2b d6
bb 45 e5 27 7c 01 88 1d bb 45 e5 27 7c 01 88 1d
6a 43 60 68 e4 dd f1 c6 6a 43 60 68 e4 dd f1 c6
b7 d1 41 6f af a6 69 7c b7 d1 41 6f af a6 69 7c
25 ed d9 ea e9 91 67 c3 25 ed d9 ea e9 91 67 c3
</artwork> ]]></sourcecode>
<t indent="0" pn="section-d.2-8"><strong>(4) EDKEY zone with UTF-8 label <t><strong>(4) EDKEY zone with UTF-8 label and three records</strong></t
and three records</strong></t> >
<artwork name="" type="" align="left" alt="" pn="section-d.2-9"> <sourcecode name="" type="test-vectors"><![CDATA[
Zone private key (d): Zone private key (d):
5a f7 02 0e e1 91 60 32 5a f7 02 0e e1 91 60 32
88 32 35 2b bc 6a 68 a8 88 32 35 2b bc 6a 68 a8
d7 1a 7c be 1b 92 99 69 d7 1a 7c be 1b 92 99 69
a7 c6 6d 41 5a 0d 8f 65 a7 c6 6d 41 5a 0d 8f 65
Zone identifier (ztype|zkey): Zone identifier (ztype|zkey):
00 01 00 14 3c f4 b9 24 00 01 00 14 3c f4 b9 24
03 20 22 f0 dc 50 58 14 03 20 22 f0 dc 50 58 14
53 b8 5d 93 b0 47 b6 3d 53 b8 5d 93 b0 47 b6 3d
skipping to change at line 4982 skipping to change at line 4536
Storage key (q): Storage key (q):
ba f8 21 77 ee c0 81 e0 ba f8 21 77 ee c0 81 e0
74 a7 da 47 ff c6 48 77 74 a7 da 47 ff c6 48 77
58 fb 0d f0 1a 6c 7f bb 58 fb 0d f0 1a 6c 7f bb
52 fc 8a 31 be f0 29 af 52 fc 8a 31 be f0 29 af
74 aa 0d c1 5a b8 e2 fa 74 aa 0d c1 5a b8 e2 fa
7a 54 b4 f5 f6 37 f6 15 7a 54 b4 f5 f6 37 f6 15
8f a7 f0 3c 3f ce be 78 8f a7 f0 3c 3f ce be 78
d3 f9 d6 40 aa c0 d1 ed d3 f9 d6 40 aa c0 d1 ed
ZKDF(zkey): ZKDF(zkey, label):
74 f9 00 68 f1 67 69 53 74 f9 00 68 f1 67 69 53
52 a8 a6 c2 eb 98 48 98 52 a8 a6 c2 eb 98 48 98
c5 3a cc a0 98 04 70 c6 c5 3a cc a0 98 04 70 c6
c8 12 64 cb dd 78 ad 11 c8 12 64 cb dd 78 ad 11
nonce := SHA-256 (dh[32..63] || h): nonce := SHA-256(dh[32..63] || h):
f8 6a b5 33 8a 74 d7 a1 f8 6a b5 33 8a 74 d7 a1
d2 77 ea 11 ff 95 cb e8 d2 77 ea 11 ff 95 cb e8
3a cf d3 97 3b b4 ab ca 3a cf d3 97 3b b4 ab ca
0a 1b 60 62 c3 7a b3 9c 0a 1b 60 62 c3 7a b3 9c
Derived private key (d', big-endian): Derived private key (d', big-endian):
17 c0 68 a6 c3 f7 20 de 17 c0 68 a6 c3 f7 20 de
0e 1b 69 ff 3f 53 e0 5d 0e 1b 69 ff 3f 53 e0 5d
3f e5 c5 b0 51 25 7a 89 3f e5 c5 b0 51 25 7a 89
a6 3c 1a d3 5a c4 35 58 a6 3c 1a d3 5a c4 35 58
skipping to change at line 5053 skipping to change at line 4607
dc 83 0e a9 b0 36 17 1c dc 83 0e a9 b0 36 17 1c
cf ca bb dd a8 de 3c 86 cf ca bb dd a8 de 3c 86
ed e2 95 70 d0 17 4b 82 ed e2 95 70 d0 17 4b 82
82 09 48 a9 28 b7 f0 0e 82 09 48 a9 28 b7 f0 0e
fb 40 1c 10 fe 80 bb bb fb 40 1c 10 fe 80 bb bb
02 76 33 1b f7 f5 1b 8d 02 76 33 1b f7 f5 1b 8d
74 57 9c 14 14 f2 2d 50 74 57 9c 14 14 f2 2d 50
1a d2 5a e2 49 f5 bb f2 1a d2 5a e2 49 f5 bb f2
a6 c3 72 59 d1 75 e4 40 a6 c3 72 59 d1 75 e4 40
b2 94 39 c6 05 19 cb b1 b2 94 39 c6 05 19 cb b1
</artwork> ]]></sourcecode>
</section> </section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-d.3 <section>
"> <name>Zone Revocation</name>
<name slugifiedName="name-zone-revocation-2">Zone revocation</name> <t>
<t indent="0" pn="section-d.3-1">
The following is an example revocation for a PKEY zone: The following is an example revocation for a PKEY zone:
</t> </t>
<artwork name="" type="" align="left" alt="" pn="section-d.3-2"> <sourcecode name="" type="test-vectors"><![CDATA[
Zone private key (d, big-endian): Zone private key (d, big-endian):
6f ea 32 c0 5a f5 8b fa 6f ea 32 c0 5a f5 8b fa
97 95 53 d1 88 60 5f d5 97 95 53 d1 88 60 5f d5
7d 8b f9 cc 26 3b 78 d5 7d 8b f9 cc 26 3b 78 d5
f7 47 8c 07 b9 98 ed 70 f7 47 8c 07 b9 98 ed 70
Zone identifier (ztype|zkey): Zone identifier (ztype|zkey):
00 01 00 00 2c a2 23 e8 00 01 00 00 2c a2 23 e8
79 ec c4 bb de b5 da 17 79 ec c4 bb de b5 da 17
31 92 81 d6 3b 2e 3b 69 31 92 81 d6 3b 2e 3b 69
55 f1 c3 77 5c 80 4a 98 55 f1 c3 77 5c 80 4a 98
d5 f8 dd aa d5 f8 dd aa
Encoded zone identifier (zkl = zTLD): zTLD:
000G001CM8HYGYFCRJXXXDET2WRS50EP7CQ3PTANY71QEQ409ACDBY6XN8 000G001CM8HYGYFCRJXXXDET2WRS50EP7CQ3PTANY71QEQ409ACDBY6XN8
Difficulty (5 base difficulty + 2 epochs): 7 Difficulty (5 base difficulty + 2 epochs): 7
Signed message: Signed message:
00 00 00 34 00 00 00 03 00 00 00 34 00 00 00 03
00 05 ff 1c 56 e4 b2 68 00 05 ff 1c 56 e4 b2 68
00 01 00 00 2c a2 23 e8 00 01 00 00 2c a2 23 e8
79 ec c4 bb de b5 da 17 79 ec c4 bb de b5 da 17
31 92 81 d6 3b 2e 3b 69 31 92 81 d6 3b 2e 3b 69
skipping to change at line 5137 skipping to change at line 4690
55 f1 c3 77 5c 80 4a 98 55 f1 c3 77 5c 80 4a 98
d5 f8 dd aa 08 ca ff de d5 f8 dd aa 08 ca ff de
3c 6d f1 45 f7 e0 79 81 3c 6d f1 45 f7 e0 79 81
15 37 b2 b0 42 2d 5e 1f 15 37 b2 b0 42 2d 5e 1f
b2 01 97 81 ec a2 61 d1 b2 01 97 81 ec a2 61 d1
f9 d8 ea 81 0a bc 2f 33 f9 d8 ea 81 0a bc 2f 33
47 7f 04 e3 64 81 11 be 47 7f 04 e3 64 81 11 be
71 c2 48 82 1a d6 04 f4 71 c2 48 82 1a d6 04 f4
94 e7 4d 0b f5 11 d2 c1 94 e7 4d 0b f5 11 d2 c1
62 77 2e 81 62 77 2e 81
]]></sourcecode>
</artwork> <t>
<t indent="0" pn="section-d.3-3">
The following is an example revocation for an EDKEY zone: The following is an example revocation for an EDKEY zone:
</t> </t>
<artwork name="" type="" align="left" alt="" pn="section-d.3-4"> <sourcecode name="" type="test-vectors"><![CDATA[
Zone private key (d): Zone private key (d):
5a f7 02 0e e1 91 60 32 5a f7 02 0e e1 91 60 32
88 32 35 2b bc 6a 68 a8 88 32 35 2b bc 6a 68 a8
d7 1a 7c be 1b 92 99 69 d7 1a 7c be 1b 92 99 69
a7 c6 6d 41 5a 0d 8f 65 a7 c6 6d 41 5a 0d 8f 65
Zone identifier (ztype|zkey): Zone identifier (ztype|zkey):
00 01 00 14 3c f4 b9 24 00 01 00 14 3c f4 b9 24
03 20 22 f0 dc 50 58 14 03 20 22 f0 dc 50 58 14
53 b8 5d 93 b0 47 b6 3d 53 b8 5d 93 b0 47 b6 3d
44 6c 58 45 cb 48 44 5d 44 6c 58 45 cb 48 44 5d
db 96 68 8f db 96 68 8f
Encoded zone identifier (zkl = zTLD): zTLD:
000G051WYJWJ80S04BRDRM2R2H9VGQCKP13VCFA4DHC4BJT88HEXQ5K8HW 000G051WYJWJ80S04BRDRM2R2H9VGQCKP13VCFA4DHC4BJT88HEXQ5K8HW
Difficulty (5 base difficulty + 2 epochs): 7 Difficulty (5 base difficulty + 2 epochs): 7
Signed message: Signed message:
00 00 00 34 00 00 00 03 00 00 00 34 00 00 00 03
00 05 ff 1c 57 35 42 bd 00 05 ff 1c 57 35 42 bd
00 01 00 14 3c f4 b9 24 00 01 00 14 3c f4 b9 24
03 20 22 f0 dc 50 58 14 03 20 22 f0 dc 50 58 14
53 b8 5d 93 b0 47 b6 3d 53 b8 5d 93 b0 47 b6 3d
skipping to change at line 5219 skipping to change at line 4770
44 6c 58 45 cb 48 44 5d 44 6c 58 45 cb 48 44 5d
db 96 68 8f 04 ae 26 f7 db 96 68 8f 04 ae 26 f7
63 56 5a b7 aa ab 01 71 63 56 5a b7 aa ab 01 71
72 4f 3c a8 bc c5 1a 98 72 4f 3c a8 bc c5 1a 98
b7 d4 c9 2e a3 3c d9 34 b7 d4 c9 2e a3 3c d9 34
4c a8 b6 3e 04 53 3a bf 4c a8 b6 3e 04 53 3a bf
1a 3c 05 49 16 b3 68 2c 1a 3c 05 49 16 b3 68 2c
5c a8 cb 4d d0 f8 4c 3b 5c a8 cb 4d d0 f8 4c 3b
77 48 7a ac 6e ce 38 48 77 48 7a ac 6e ce 38 48
0b a9 d5 00 0b a9 d5 00
]]></sourcecode>
</artwork>
</section> </section>
</section> </section>
<!-- Change Log <section numbered="false">
v00 2017-07-23 MS Initial version <name>Acknowledgements</name>
--> <t>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc= The authors thank all reviewers for their comments. In particular,
"include" pn="section-appendix.e"> we thank <contact fullname="D. J. Bernstein"/>, <contact fullname="S.
<name slugifiedName="name-authors-addresses">Authors' Addresses</name> Bortzmeyer"/>, <contact fullname="A. Farrel"/>, <contact fullname="E. Lear"/>, a
<author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach nd <contact fullname="R. Salz"/> for their
"> insightful and detailed technical reviews. We thank <contact fullname=
<organization showOnFrontPage="true">Fraunhofer AISEC</organization> "J. Yao"/> and <contact fullname="J. Klensin"/> for the
<address> internationalization reviews. We thank <contact fullname="Dr. J. Appel
<postal> baum"/> for suggesting the name "GNU Name System" and <contact fullname="Dr. Ric
<street>Lichtenbergstrasse 11</street> hard Stallman"/> for approving its use. We thank <contact fullname="T. Lange"/>
<city>Garching</city> and <contact fullname="M. Wachs"/> for their earlier contributions to the desig
<code>85748</code> n and implementation of GNS. We thank NLnet and NGI DISCOVERY for funding
<country>DE</country> work on the GNU Name System.
</postal> </t>
<email>martin.schanzenbach@aisec.fraunhofer.de</email>
</address>
</author>
<author fullname="Christian Grothoff" initials="C." surname="Grothoff">
<organization showOnFrontPage="true">Berner Fachhochschule</organization
>
<address>
<postal>
<street>Hoeheweg 80</street>
<city>Biel/Bienne</city>
<code>2501</code>
<country>CH</country>
</postal>
<email>christian.grothoff@bfh.ch</email>
</address>
</author>
<author fullname="Bernd Fix" initials="B." surname="Fix">
<organization showOnFrontPage="true">GNUnet e.V.</organization>
<address>
<postal>
<street>Boltzmannstrasse 3</street>
<city>Garching</city>
<code>85748</code>
<country>DE</country>
</postal>
<email>fix@gnunet.org</email>
</address>
</author>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 769 change blocks. 
3468 lines changed or deleted 2292 lines changed or added

This html diff was produced by rfcdiff 1.48.