<?xmlversion='1.0' encoding='utf-8'?>version="1.0" encoding="utf-8"?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" submissionType="independent" category="info"consensus="false"docName="draft-schanzen-gns-28"indexInclude="true"number="9498" ipr="trust200902"prepTime="2023-07-06T12:50:00" scripts="Common,Latin"sortRefs="false"submissionType="IETF"symRefs="true" tocDepth="3" tocInclude="true" updates="" obsoletes="" xml:lang="en"> <!-- xml2rfc v2v3 conversion 2.26.0 --> <front> <title abbrev="The GNU Name System">The GNU Name System</title> <seriesInfoname="Internet-Draft" value="draft-schanzen-gns-28" stream="IETF"/>name="RFC" value="9498"/> <author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach"><organization showOnFrontPage="true">Fraunhofer<organization>Fraunhofer AISEC</organization> <address> <postal> <street>Lichtenbergstrasse 11</street> <city>Garching</city> <code>85748</code><country>DE</country><country>Germany</country> </postal> <email>martin.schanzenbach@aisec.fraunhofer.de</email> </address> </author> <author fullname="Christian Grothoff" initials="C." surname="Grothoff"><organization showOnFrontPage="true">Berner<organization>Berner Fachhochschule</organization> <address> <postal> <street>Hoeheweg 80</street> <city>Biel/Bienne</city> <code>2501</code><country>CH</country><country>Switzerland</country> </postal> <email>christian.grothoff@bfh.ch</email> </address> </author> <author fullname="Bernd Fix" initials="B." surname="Fix"><organization showOnFrontPage="true">GNUnet<organization>GNUnet e.V.</organization> <address> <postal> <street>Boltzmannstrasse 3</street> <city>Garching</city> <code>85748</code><country>DE</country><country>Germany</country> </postal> <email>fix@gnunet.org</email> </address> </author> <dateday="06" month="07"month="November" year="2023"/><!-- Meta-data Declarations --> <area>General</area> <workgroup>Independent Stream</workgroup><keyword>name systems</keyword><abstract pn="section-abstract"> <t indent="0" pn="section-abstract-1"><abstract> <t> This documentcontainsprovides the GNU Name System (GNS) technical specification. GNS is a decentralized and censorship-resistant domain name resolution protocol that provides a privacy-enhancing alternative to the Domain Name System (DNS) protocols. </t><t indent="0" pn="section-abstract-2"><t> This document defines the normative wire format of resource records, resolution processes, cryptographicroutinesroutines, and security and privacy considerations for use by implementers. </t><t indent="0" pn="section-abstract-3"><t> This specification was developed outside the IETF and does not have IETF consensus. It is published here to inform readers about the function of GNS, guide future GNS implementations, and ensure interoperability among implementationsincluding with the(for example, pre-existing GNUnetimplementation.implementations). </t> </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="exclude" 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" pn="section-toc.1"> <name slugifiedName="name-table-of-contents">Table of Contents</name> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1"> <li pn="section-toc.1-1.1"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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-requirements-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 derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t> </li> <li pn="section-toc.1-1.3"> <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-overview">Overview</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" 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 derivedContent="" format="title" sectionFormat="of" target="name-publishing-binding-informat">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 derivedContent="" format="title" sectionFormat="of" target="name-resolving-names">Resolving 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" format="counter" sectionFormat="of" target="section-4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-zones">Zones</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" 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 derivedContent="" 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" format="counter" sectionFormat="of" target="section-5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-resource-records">Resource Records</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" format="title" sectionFormat="of" target="name-zone-delegation-records">Zone Delegation Records</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="5.1.1" format="counter" sectionFormat="of" target="section-5.1.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-pkey">PKEY</xref></t> </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 derivedContent="5.1.2" format="counter" sectionFormat="of" target="section-5.1.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-edkey">EDKEY</xref></t> </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 derivedContent="" format="title" sectionFormat="of" target="name-redirection-records">Redirection Records</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="5.2.1" format="counter" sectionFormat="of" target="section-5.2.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-redirect">REDIRECT</xref></t> </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 derivedContent="5.2.2" format="counter" sectionFormat="of" target="section-5.2.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-gns2dns">GNS2DNS</xref></t> </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 derivedContent="" format="title" sectionFormat="of" target="name-auxiliary-records">Auxiliary Records</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="5.3.1" format="counter" sectionFormat="of" target="section-5.3.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-leho">LEHO</xref></t> </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 derivedContent="5.3.2" format="counter" sectionFormat="of" target="section-5.3.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-nick">NICK</xref></t> </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 derivedContent="5.3.3" format="counter" sectionFormat="of" target="section-5.3.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-box">BOX</xref></t> </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" format="counter" sectionFormat="of" target="section-6"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-record-encoding-for-remote-">Record Encoding for Remote Storage</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" format="title" sectionFormat="of" target="name-the-storage-key">The Storage 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 derivedContent="" 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 derivedContent="" format="title" sectionFormat="of" target="name-the-resource-records-block">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" format="counter" sectionFormat="of" target="section-7"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-name-resolution">Name Resolution</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" format="title" sectionFormat="of" target="name-start-zones">Start Zones</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 derivedContent="" 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 derivedContent="" format="title" sectionFormat="of" target="name-record-processing">Record Processing</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="7.3.1" format="counter" sectionFormat="of" target="section-7.3.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-redirect-2">REDIRECT</xref></t> </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 derivedContent="7.3.2" format="counter" sectionFormat="of" target="section-7.3.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-gns2dns-2">GNS2DNS</xref></t> </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 derivedContent="7.3.3" format="counter" sectionFormat="of" target="section-7.3.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-box-2">BOX</xref></t> </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 derivedContent="7.3.4" format="counter" sectionFormat="of" target="section-7.3.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-zone-delegation-records-2">Zone Delegation Records</xref></t> </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 derivedContent="7.3.5" format="counter" sectionFormat="of" target="section-7.3.5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-nick-2">NICK</xref></t> </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" format="counter" sectionFormat="of" target="section-8"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-internationalization-and-ch">Internationalization 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" format="counter" sectionFormat="of" target="section-9"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-and-privacy-consid">Security and Privacy Considerations</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" format="title" sectionFormat="of" target="name-availability">Availability</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 derivedContent="" 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 derivedContent="" format="title" sectionFormat="of" target="name-cryptography">Cryptography</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 derivedContent="" format="title" sectionFormat="of" target="name-abuse-mitigation">Abuse 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 derivedContent="" 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 derivedContent="" 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 derivedContent="" format="title" sectionFormat="of" target="name-revocations">Revocations</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 derivedContent="" format="title" sectionFormat="of" target="name-zone-privacy">Zone Privacy</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 derivedContent="" 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 derivedContent="" 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" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-gana-considerations">GANA Considerations</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" format="title" sectionFormat="of" target="name-gns-record-types-registry">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 derivedContent="" format="title" sectionFormat="of" target="name-alt-subdomains-registry">.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" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t> </li> <li pn="section-toc.1-1.12"> <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" format="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-implementation-and-deployme">Implementation and Deployment Status</xref></t> </li> <li pn="section-toc.1-1.13"> <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="13" format="counter" sectionFormat="of" target="section-13"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t> </li> <li pn="section-toc.1-1.14"> <t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="14" format="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" format="counter" sectionFormat="of" target="section-15"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t> </li> <li pn="section-toc.1-1.16"> <t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-usage-and-migration">Usage and Migration</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" format="title" sectionFormat="of" target="name-zone-dissemination">Zone 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 derivedContent="" format="title" sectionFormat="of" target="name-start-zone-configuration">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 derivedContent="" 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 derivedContent="" format="title" sectionFormat="of" target="name-migration-paths">Migration 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="Appendix 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="section-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 derivedContent="" format="title" sectionFormat="of" target="name-aaaa-example-resolution">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 derivedContent="" format="title" sectionFormat="of" target="name-redirect-example-resolution">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 derivedContent="" format="title" sectionFormat="of" target="name-gns2dns-example-resolution">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="Appendix C" format="default" sectionFormat="of" target="section-appendix.c"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-base32gns">Base32GNS</xref></t> </li> <li pn="section-toc.1-1.19"> <t indent="0" pn="section-toc.1-1.19.1"><xref derivedContent="Appendix D" format="default" sectionFormat="of" target="section-appendix.d"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-test-vectors">Test Vectors</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" 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 derivedContent="" format="title" sectionFormat="of" target="name-record-sets">Record sets</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 derivedContent="" format="title" sectionFormat="of" target="name-zone-revocation-2">Zone 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="" format="none" sectionFormat="of" target="section-appendix.e"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t> </li> </ul> </section> </toc></front> <middle> <sectionanchor="introduction" numbered="true" toc="include" removeInRFC="false" pn="section-1"> <name slugifiedName="name-introduction">Introduction</name> <t indent="0" pn="section-1-1">anchor="introduction"> <name>Introduction</name> <t> This specification describes the GNU Name System (GNS), a censorship-resistant,privacy-preservingprivacy-preserving, and decentralized domain name resolution protocol. GNS cryptographically secures the binding of names to arbitrary tokens, enabling it to double in some respects as an alternative to some of today's public key infrastructures. </t><t indent="0" pn="section-1-2"> In the terminology of the<t> Per Domain Name System (DNS) terminology <xreftarget="RFC1035" format="default" sectionFormat="of" derivedContent="RFC1035"/>,target="RFC1035"/>, GNS roughly follows the idea of a local root zone deployment (see <xreftarget="RFC8806" format="default" sectionFormat="of" derivedContent="RFC8806"/>),target="RFC8806"/>), with the difference that the design encourages alternative roots and does not expect all deployments to use the same or any specific root zone. In the GNS reference implementation, users can autonomously and freely delegate control of names to zones through their local configurations. GNS expects each user to be in control of their setup. By following the guidelines in <xreftarget="namespace_ambiguity" format="default" sectionFormat="of" derivedContent="Section 9.10"/> guidelines,target="namespace_ambiguity"/>, users should manage to avoid any confusion as to how names are resolved. </t><t indent="0" pn="section-1-3"><t> Name resolution and zone disseminationisare based on the principle of a petname system where users can assign local names to zones. The GNS has its roots in ideas from the Simple Distributed Security Infrastructure <xreftarget="SDSI" format="default" sectionFormat="of" derivedContent="SDSI"/>,target="SDSI"/>, enabling the decentralized mapping of secure identifiers to memorable names.AOne of the first academicdescriptiondescriptions of the cryptographic ideas behind GNS can be found in <xreftarget="GNS" format="default" sectionFormat="of" derivedContent="GNS"/>.target="GNS"/>. </t><t indent="0" pn="section-1-4"><t> This document defines the normative wire format of resource records, resolution processes, cryptographicroutinesroutines, and 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> <section numbered="true" toc="include" removeInRFC="false" pn="section-1.1"> <name slugifiedName="name-requirements-notation">Requirements<section> <name>Requirements Notation</name><t indent="0" pn="section-1.1-1"> The<t>The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xreftarget="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/>target="RFC2119"/> <xreftarget="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/>target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere. </t>here.</t> </section> </section><section numbered="true" removeInRFC="false" toc="include" pn="section-2"> <name slugifiedName="name-terminology">Terminology</name><section> <name>Terminology</name> <dlindent="3" newline="false" spacing="normal" pn="section-2-1"> <dt pn="section-2-1.1">Apex Label</dt> <dd pn="section-2-1.2">newline="false"> <dt>Apex Label:</dt> <dd> This type of label is used to publish resource records in a zone that can be resolved without providing a specific label. It is the GNS methodto providefor providing what is called the "zone apex" in DNS <xreftarget="RFC4033" format="default" sectionFormat="of" derivedContent="RFC4033"/>.target="RFC4033"/>. The apex label is represented using the character U+0040 ("@" without the quotes). </dd><dt pn="section-2-1.3">Application</dt> <dd pn="section-2-1.4"> A<dt>Application:</dt> <dd> An application is a componentwhichthat uses a GNS implementation to resolve names into records and processes its contents. </dd><dt pn="section-2-1.5">Blinded<dt>Blinded ZoneKey</dt> <dd pn="section-2-1.6"> KeyKey:</dt> <dd> 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 without knowledge of the specific label used for the derivation. </dd><dt pn="section-2-1.7">Extension Label</dt> <dd pn="section-2-1.8"><dt>Extension Label:</dt> <dd> 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 redirection target is defined relative to the authoritative zone of the redirection record (see <xreftarget="gnsrecords_redirect" format="default" sectionFormat="of" derivedContent="Section 5.2"/>).target="gnsrecords_redirect"/>). The extension label is represented using the character U+002B ("+" without the quotes). </dd><dt pn="section-2-1.9">Label Separator</dt> <dd pn="section-2-1.10"><dt>Label Separator:</dt> <dd> Labels in a name are separated using the label separator U+002E ("." without the quotes). In GNS,with the exceptions ofexcept for zone Top-Level Domains (zTLDs) (see below) and boxed records (see <xreftarget="gnsrecords_box" format="default" sectionFormat="of" derivedContent="Section 5.3.3"/>),target="gnsrecords_box"/>), every label separator in a name indicates delegation to another zone. </dd><dt pn="section-2-1.11">Label</dt> <dd pn="section-2-1.12"><dt>Label:</dt> <dd> A GNS label is a label as defined in <xreftarget="RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/>.target="RFC8499"/>. Labels are UTF-8 strings in Unicode Normalization Form C (NFC) <xreftarget="Unicode-UAX15" format="default" sectionFormat="of" derivedContent="Unicode-UAX15"/>.target="Unicode-UAX15"/>. The apex label and the extension label have special purposes in the resolution protocolwhichthat are defined in the rest ofthethis document. Zone administrators <bcp14>MAY</bcp14> disallow certain labels that might be easily confused with other labels through registration policies (see also <xreftarget="security_abuse" format="default" sectionFormat="of" derivedContent="Section 9.4"/>).target="security_abuse"/>). </dd><dt pn="section-2-1.13">Name</dt> <dd pn="section-2-1.14"><dt>Name:</dt> <dd> A name in GNS is a domain name as defined in <xreftarget="RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/>: Namestarget="RFC8499"/>: names are UTF-8<xref target="RFC3629" format="default" sectionFormat="of" derivedContent="RFC3629"/>strings <xref target="RFC3629"/> consisting of an ordered list of labels concatenated with a label separator. Names are resolved starting from the rightmost label. GNS does not impose length restrictions on names or labels. However, applications <bcp14>MAY</bcp14> ensure that name and label lengths are compatible with DNSandand, inparticular IDNAparticular, Internationalized Domain Names for Applications (IDNA) <xreftarget="RFC5890" format="default" sectionFormat="of" derivedContent="RFC5890"/>.target="RFC5890"/>. In the spirit of <xreftarget="RFC5895" format="default" sectionFormat="of" derivedContent="RFC5895"/>,target="RFC5895"/>, applications <bcp14>MAY</bcp14> preprocess names and labels to ensure compatibility with DNS or support specific userexpectations,expectations -- forexampleexample, according to <xreftarget="Unicode-UTS46" format="default" sectionFormat="of" derivedContent="Unicode-UTS46"/>.target="Unicode-UTS46"/>. A GNS name may be indistinguishable from a DNSnamename, and care must be taken by applications andimplementorsimplementers when handling GNS names (see <xreftarget="namespace_ambiguity" format="default" sectionFormat="of" derivedContent="Section 9.10"/>).target="namespace_ambiguity"/>). In order to avoid misinterpretation of example domains with (reserved) DNSdomainsdomains, thisdraftdocument uses the suffix ".gns.alt" inexamples whichcompliance with <xref target="RFC9476"/>. ".gns.alt" is also registered in the GANA ".alt Subdomains" registry <xreftarget="GANA" format="default" sectionFormat="of" derivedContent="GANA"/> (see also <xref target="I-D.ietf-dnsop-alt-tld" format="default" sectionFormat="of" derivedContent="I-D.ietf-dnsop-alt-tld"/>).target="GANA"/>. </dd><dt pn="section-2-1.15">Resolver</dt> <dd pn="section-2-1.16"> The<dt>Resolver:</dt> <dd> In this document, a resolver is the component of a GNS implementationwhichthat provides the recursive name resolution logic defined in <xreftarget="resolution" format="default" sectionFormat="of" derivedContent="Section 7"/>.target="resolution"/>. </dd><dt pn="section-2-1.17">Resource Record</dt> <dd pn="section-2-1.18"><dt>Resource Record:</dt> <dd> A GNS resource record is the information associated with a label in a GNS zone. A GNS resource record contains information as defined by its resource record type. </dd><dt pn="section-2-1.19">Start Zone</dt> <dd pn="section-2-1.20"><dt>Start Zone:</dt> <dd> In order to resolve any given GNSnamename, an initialstart zoneStart Zone must be determined for this name. Thestart zoneStart Zone can be explicitly defined as part of the name using azone Top-Level Domain (zTLD).zTLD. Otherwise, it is determined through a local suffix-to-zone mapping (see <xreftarget="governance" format="default" sectionFormat="of" derivedContent="Section 7.1"/>).target="governance"/>). </dd><dt pn="section-2-1.21">Top-Level Domain</dt> <dd pn="section-2-1.22"><dt>Top-Level Domain (TLD):</dt> <dd> The rightmost part of a GNS name is a GNSTop-Level Domain (TLD).TLD. A GNS TLD can consist of one or more labels. Unlike DNSTop-Level DomainsTLDs (defined in <xreftarget="RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/>),target="RFC8499"/>), GNS does not expect all users to use the same global root zone. Instead, with the exception ofZone Top-Level DomainszTLDs (see <xreftarget="zTLD" format="default" sectionFormat="of" derivedContent="Section 4.1"/>),target="zTLD"/>), GNS TLDs are typically part of the configuration of the local resolver (see <xreftarget="governance" format="default" sectionFormat="of" derivedContent="Section 7.1"/>),target="governance"/>) andmightthus might not be globally unique. </dd><dt pn="section-2-1.23">Zone</dt> <dd pn="section-2-1.24"><dt>Zone:</dt> <dd> A GNS zone contains authoritative information (resource records). A zone is uniquely identified by its zone key. Unlike DNS zones, a GNS zone does not need to haveaan SOA record under the apex label. </dd><dt pn="section-2-1.25">Zone Key</dt> <dd pn="section-2-1.26"> A<dt>Zone Key:</dt> <dd> The zone keywhichis a key that uniquely identifies a zone. It is usually a public key of an asymmetric key pair. However, the established technical term "public key" is misleading, as in GNS a zone key may be a shared secret that should not be disclosed to unauthorized parties. </dd><dt pn="section-2-1.27">Zone<dt>Zone Key DerivationFunction</dt> <dd pn="section-2-1.28">Function:</dt> <dd> The zone key derivation function (ZKDF) blinds a zone key using a label. </dd><dt pn="section-2-1.29">Zone Master</dt> <dd pn="section-2-1.30"><dt>Zone Publisher:</dt> <dd> The zone publisher is the component of a GNS implementationwhichthat provides local zone management and publication as defined in <xreftarget="publish" format="default" sectionFormat="of" derivedContent="Section 6"/>.target="publish"/>. </dd><dt pn="section-2-1.31">Zone Owner</dt> <dd pn="section-2-1.32"><dt>Zone Owner:</dt> <dd> The zone owner is the holder of the secret (typically a privatekey) thatkey), which (together with a label and a value to sign) allows the creation of zone signatures that can be validated against the respective blinded zone key. </dd><dt pn="section-2-1.33">Zone<dt>Zone Top-LevelDomain</dt> <dd pn="section-2-1.34">Domain (zTLD):</dt> <dd> A GNSZone Top-Level Domain (zTLD)zTLD is a sequence of GNS labels at the end of a GNSname whichname. The zTLD encodes a zone type and zone key of a zone (see <xreftarget="zTLD" format="default" sectionFormat="of" derivedContent="Section 4.1"/>).target="zTLD"/>). 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 by attempting to decode the labels into a zone type and zone key. </dd><dt pn="section-2-1.35">Zone Type</dt> <dd pn="section-2-1.36"><dt>Zone Type:</dt> <dd> The type of a GNS zone determines the cipher system and binary encoding format of the zone key, blinded zone keys, and cryptographic signatures. </dd> </dl> </section> <sectionanchor="overview" numbered="true" toc="include" removeInRFC="false" pn="section-3"> <name slugifiedName="name-overview">Overview</name> <t indent="0" pn="section-3-1">anchor="overview"> <name>Overview</name> <t> GNS exhibits the three properties that are commonly used to describe a petname system: </t><ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-3-2"> <li pn="section-3-2.1" derivedCounter="1."><dl newline="true"> <dt> Global names through the concept ofzone top-level domains (zTLDs): AszTLDs:</dt><dd>As zones can be uniquely identified by their zonekeykeys and are statistically unique, zTLDs are globally unique mappings to zones. Consequently, GNS domain names with a zTLD suffix are also globally unique. Names withzTLDszTLD suffixes are nothuman-readable. </li> <li pn="section-3-2.2" derivedCounter="2.">memorable.</dd> <dt> Memorable petnames forzones: Userszones:</dt> <dd>Users can configure local,human-readablememorable references to zones. Such petnames serve as zTLD monikerswhichthat provide convenient names for zones to the local operator. The petnames may also be published as suggestions for other users searching for a good label to use when referencing the respectivezone. </li> <li pn="section-3-2.3" derivedCounter="3.">zone.</dd> <dt> A secure mapping from names torecords: GNSrecords:</dt> <dd>GNS allows zone owners to map labels to resource records or to delegate authority of names in the subdomain induced by a label to other zones. Zone owners may choose to publish this information to make it available to other users. Mappings are encrypted and signed using keys derived from the respective label before being publishedtoin remote storage. When names are resolved, signatures on resourcerecordsrecords, includingdelegationsdelegations, are verified by the recursiveresolver. </li> </ol> <t indent="0" pn="section-3-3">resolver.</dd> </dl> <t> In the remainder of this document, the "implementer" refers to the developer building a GNS implementationincludingthat includes the resolver, zonemaster,publisher, and supporting configuration such asstart zonesStart Zones (see <xreftarget="governance" format="default" sectionFormat="of" derivedContent="Section 7.1"/>).target="governance"/>). </t> <sectionanchor="names" numbered="true" toc="include" removeInRFC="false" pn="section-3.1"> <name slugifiedName="name-names-and-zones">Namesanchor="names"> <name>Names and Zones</name><t indent="0" pn="section-3.1-1"><t> It follows from the above that GNS does not support nameswhichthat are simultaneously global,securesecure, andhuman-readable.memorable. Instead, names are either global and nothuman-readablememorable or not globally unique andhuman-readable.memorable. An example for a global name pointing to the record "example" in a zoneis:is as follows: </t><sourcecode markers="false" pn="section-3.1-2"><sourcecode> example.000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884 </sourcecode><t indent="0" pn="section-3.1-3"><t> Now consider the case where a user locally configured the petname "pet.gns.alt" for the zone with the "example" record of the name above. The name "example.pet.gns.alt" would then point to the same record as the globally unique name above, but name resolution would only work on the local system where the "pet.gns.alt" petname is configured. </t><t indent="0" pn="section-3.1-4"><t> The delegation of petnames and subsequent resolution of delegationbuildsbuild on ideas from the Simple Distributed Security Infrastructure <xreftarget="SDSI" format="default" sectionFormat="of" derivedContent="SDSI"/>.target="SDSI"/>. In GNS, any user can create and manage any number of zones (see <xreftarget="zones" format="default" sectionFormat="of" derivedContent="Section 4"/>)target="zones"/>) if their system provides a zonemasterpublisher implementation. For each zone, the zone type determines the respective set of cryptographic operations and the wire formats for encrypted data, publickeyskeys, and signatures. A zone can be populated with mappings from labels to resource records (see <xreftarget="rrecords" format="default" sectionFormat="of" derivedContent="Section 5"/>)target="rrecords"/>) by its owner. A label can be mapped to a delegationrecord whichrecord; this results in the corresponding subdomain being delegated to another zone. Circular delegations are explicitly allowed, including delegating a subdomain to its immediate parent zone. In order to support (legacy) applications as well as to facilitate the use of petnames, GNS defines auxiliary record types in addition to supporting existing DNS records. </t> </section> <sectionanchor="publishing" numbered="true" toc="include" removeInRFC="false" pn="section-3.2"> <name slugifiedName="name-publishing-binding-informat">Publishinganchor="publishing"> <name>Publishing Binding Information</name><t indent="0" pn="section-3.2-1"><t> Zone contents are encrypted and signed before being published inaremote key-value storage (see <xreftarget="publish" format="default" sectionFormat="of" derivedContent="Section 6"/>)target="publish"/>), as illustrated in <xreftarget="figure_arch_publish" format="default" sectionFormat="of" derivedContent="Figure 1"/>.target="figure_arch_publish"/>. In this process, unique zone identification is hidden from the network through the use of key blinding. Key blinding allows the creation of signatures for zone contents using a blinded public/private key pair. This blinding is realized using a deterministic key derivation from the original zone key and corresponding private key using record label values as inputs from which blinding factors are derived. Specifically, the zone owner can derive blinded private keys for each record set published under a label, and a resolver can derive the corresponding blinded public keys. It is expected that GNS implementations use decentralized remotestoragesstorage entities, such as distributed hash tables(DHT)(DHTs), in order to facilitate availability within a network without the need for dedicated infrastructure.SpecificationThe specification of such a distributed or decentralized storage entity is out of scopeoffor this document, but possible existing implementations include those based on <xreftarget="RFC7363" format="default" sectionFormat="of" derivedContent="RFC7363"/>,target="RFC7363"/>, <xreftarget="Kademlia" format="default" sectionFormat="of" derivedContent="Kademlia"/>target="Kademlia"/>, or <xreftarget="R5N" format="default" sectionFormat="of" derivedContent="R5N"/>.target="R5N"/>. </t> <figureanchor="figure_arch_publish" align="left" suppress-title="false" pn="figure-1"> <name slugifiedName="name-an-example-diagram-of-two-h">An example diagramanchor="figure_arch_publish"> <name>An Example Diagram oftwo hosts publishingTwo Hosts Publishing GNSzones.</name>Zones</name> <artwork name="" type=""align="left" alt="" pn="section-3.2-2.1">alt=""> Host A | Remote | Host B | Storage | | | | +---------+ | | / /| | Publish | +---------+ | | Publish+---------++-----------+ Records | | | | | Records+---------++-----------+ | Zone |----------|->| Record | |<-|----------| Zone | |MasterPublisher | | | Storage | | | |MasterPublisher |+---------++-----------+ | | |/ |+---------++-----------+ A | +---------+ | A | | | | +---------+ | | +---------+ / | /| | | / | /| +---------+ | | | +---------+ | | | | | | | | | | Local | | | | | Local | | | Zones | | | | | Zones | | | |/ | | | |/ +---------+ | | +---------+ </artwork> </figure><t indent="0" pn="section-3.2-3"><t> A zonemasterpublisher implementation <bcp14>SHOULD</bcp14> be provided as 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 zone keys for the initial step in the name resolution have been configured (see <xreftarget="resolution" format="default" sectionFormat="of" derivedContent="Section 7"/>)target="resolution"/>) or if the names end with a zTLD suffix. </t> </section> <sectionanchor="resolving" numbered="true" toc="include" removeInRFC="false" pn="section-3.3"> <name slugifiedName="name-resolving-names">Resolvinganchor="resolving"> <name>Resolving Names</name><t indent="0" pn="section-3.3-1"><t> Applications use the resolver tolookuplook up GNS names. Starting from a configurablestart zone,Start Zone, names are resolved by following zone delegationsrecursivelyrecursively, as illustrated in <xreftarget="figure_arch_resolv" format="default" sectionFormat="of" derivedContent="Figure 2"/>.target="figure_arch_resolv"/>. For each label in a name, the recursive GNS resolver fetches the respective record set from the storage layer (see <xreftarget="resolution" format="default" sectionFormat="of" derivedContent="Section 7"/>).target="resolution"/>). Without knowledge of the label values and the zone keys, the different derived keys are unlinkablebothto both the original zone key andtoeach other. This prevents zone enumeration (except via expensive onlinebrute forcebrute-force attacks):Toto confirm the affiliation of a query or the corresponding encrypted record set with a specific zone requires knowledge of both the zone key and the label, neither of whichareis disclosed to remote storage by the protocol. At the same time, the blinded zone key and digital signatures associated with each encrypted record set allow resolvers and oblivious remote storage to verify the integrity of the published information without disclosing anything about the originating zone or the record sets. </t> <figureanchor="figure_arch_resolv" align="left" suppress-title="false" pn="figure-2"> <name slugifiedName="name-high-level-view-of-the-gns-">High-level viewanchor="figure_arch_resolv"> <name>High-Level View of the GNSresolution process.</name>Resolution Process</name> <artwork name="" type=""align="left" alt="" pn="section-3.3-2.1">alt=""> Local Host | Remote | Storage | | +---------+ | / /| | +---------+ | +-----------+ Name +----------+ Recursive | | | | | | Lookup | | Resolution | | Record | ||Application|----------||Application|--------->| Resolver |-------------|->| Storage | | | |<---------| |<------------|--| |/ +-----------+ Results +----------+ Intermediate| +---------+ A Results | | | +---------+ | / | /| | +---------+ | | | | | | | Start | | | | Zones | | | | |/ | +---------+ | </artwork> </figure> </section> </section> <sectionanchor="zones" numbered="true" toc="include" removeInRFC="false" pn="section-4"> <name slugifiedName="name-zones">Zones</name> <t indent="0" pn="section-4-1">anchor="zones"> <name>Zones</name> <t> A zone in GNS is uniquely identified by its zone type (ztype) and zone key. Each zone can be referenced by itszone Top-Level Domain (zTLD) stringzTLD (see <xreftarget="zTLD" format="default" sectionFormat="of" derivedContent="Section 4.1"/>)target="zTLD"/>), which is a string that encodes the zone type and zone key.A zone type (ztype)The ztype is a unique 32-bit numberwhichthat corresponds to a resource record type number identifying a delegation record type in the GANA "GNS Record Types" registry <xreftarget="GANA" format="default" sectionFormat="of" derivedContent="GANA"/>.target="GANA"/>. The ztype is a unique identifier for the set cryptographic functions of the zone and the format of the delegation record type. Any ztype registration <bcp14>MUST</bcp14> define the following set of cryptographic functions: </t> <dlindent="3" newline="false" spacing="normal" pn="section-4-2"> <dt pn="section-4-2.1">KeyGen()newline="true"> <dt>KeyGen() -> d,zk</dt> <dd pn="section-4-2.2"> is azkey</dt> <dd> A functionto generatefor generating a new private key d and the corresponding public zone keyzk.zkey. </dd><dt pn="section-4-2.3">ZKDF(zk,label)<dt>ZKDF(zkey, label) ->zk'</dt> <dd pn="section-4-2.4"> is a zone key derivation function whichzkey'</dt> <dd> A ZKDF that blinds a zone keyzkzkey using a label.zk zkey andzk'zkey' must be unlinkable. Furthermore, blindingzkzkey with different values for the label must result in different, unlinkablezk'zkey' values. </dd><dt pn="section-4-2.5">S-Encrypt(zk,label,expiration,plaintext)<dt>S-Encrypt(zkey, label, expiration, plaintext) -> ciphertext</dt><dd pn="section-4-2.6"> is a<dd> A symmetric encryption functionwhichthat encrypts the plaintext to derive ciphertext based on key material derived from the zone keyzk,zkey, alabellabel, and an expiration timestamp. In order to leverage performance-enhancing caching features of certain underlyingstorages,storage entities -- inparticular DHTs,particular, DHTs -- a deterministic encryption scheme is recommended. </dd><dt pn="section-4-2.7">S-Decrypt(zk,label,expiration,ciphertext)<dt>S-Decrypt(zkey, label, expiration, ciphertext) -> plaintext</dt><dd pn="section-4-2.8"> is a<dd> A symmetric decryption functionwhichthat decrypts the ciphertext into plaintext based on key material derived from the zone key, a label, and an expiration timestamp. </dd><dt pn="section-4-2.9">Sign(d,message)<dt>Sign(d, message) -> signature</dt><dd pn="section-4-2.10"> is a<dd> A functionto signfor signing a message using the private key d, yielding an unforgeable cryptographic signature. In order to leverage performance-enhancing caching features of certain underlyingstorages,storage entities -- inparticular DHTs,particular, DHTs -- a deterministic signature scheme is recommended. </dd><dt pn="section-4-2.11">Verify(zk,message,signature)<dt>Verify(zkey, message, signature) -> boolean</dt><dd pn="section-4-2.12"> is a<dd> A functionto verifyfor verifying that the signature was created using the private key d corresponding to the zone keyzkzkey whered,zkd,zkey :=Keygen().KeyGen(). The function returns a boolean value of "TRUE" if the signature isvalid,valid andotherwise "FALSE"."FALSE" otherwise. </dd><dt pn="section-4-2.13">SignDerived(d,label,message)<dt>SignDerived(d, label, message) -> signature</dt><dd pn="section-4-2.14"> is a<dd> A functionto signfor signing a message (typically encrypted record data) that can be verified using the derived zone keyzk'zkey' :=ZKDF(zk,label).ZKDF(zkey, label). In order to leverage performance-enhancing caching features of certain underlyingstorages,storage entities -- inparticular DHTs,particular, DHTs -- a deterministic signature scheme is recommended. </dd><dt pn="section-4-2.15">VerifyDerived(zk,label,message,signature)<dt>VerifyDerived(zkey', message, signature) -> boolean</dt><dd pn="section-4-2.16"> is<dd> A functionto verifyfor verifying the signature using the derived zone keyzk'zkey' :=ZKDF(zk,label).ZKDF(zkey, label). The function returns a boolean value of "TRUE" if the signature isvalid,valid andotherwise "FALSE"."FALSE" otherwise. Depending on the signature scheme used, this function can be identical to the Verify() function. </dd> </dl><t indent="0" pn="section-4-3"><t> The cryptographic functions of the default ztypes are specified with their corresponding delegation records as discussed in <xreftarget="gnsrecords_delegation" format="default" sectionFormat="of" derivedContent="Section 5.1"/>.target="gnsrecords_delegation"/>. In order to support cryptographic agility, additional ztypes <bcp14>MAY</bcp14> be defined in the futurewhichthat replace or update the default ztypes defined in this document. All ztypes <bcp14>MUST</bcp14> be registered as dedicated zone delegation record types in the GANA "GNS Record Types" registry (see <xreftarget="GANA" format="default" sectionFormat="of" derivedContent="GANA"/>).target="GANA"/>). When defining new recordtypestypes, the cryptographic security considerations of this documentapply,-- inparticularparticular, <xreftarget="security_cryptography" format="default" sectionFormat="of" derivedContent="Section 9.3"/>.target="security_cryptography"/> -- apply. </t> <sectionanchor="zTLD" numbered="true" toc="include" removeInRFC="false" pn="section-4.1"> <name slugifiedName="name-zone-top-level-domain">Zone Top-Level Domain</name> <t indent="0" pn="section-4.1-1"> A zoneanchor="zTLD"> <name>Zone Top-Level Domain(zTLD)(zTLD)</name> <t> A zTLD is a stringwhichthat encodes the zone type and zone key into a domain name suffix. A zTLD is used as a globally uniquereferencesreference to a zone in the process of name resolution. It is created by encoding a binary concatenation of the zone type and zone key (see <xreftarget="figure_zid" format="default" sectionFormat="of" derivedContent="Figure 3"/>).target="figure_zid"/>). The used encoding is a variation of the Crockford Base32 encoding <xreftarget="CrockfordB32" format="default" sectionFormat="of" derivedContent="CrockfordB32"/>target="CrockfordB32"/> called Base32GNS. The encoding and decoding symbols forBase32GNSBase32GNS, including thismodificationvariation, are defined in <xreftarget="CrockfordB32Encode" format="default" sectionFormat="of" derivedContent="Figure 30"/>.target="CrockfordB32Encode"/>, found in <xref target="app-c"/>. The functions for encoding and decoding based onthis table<xref target="CrockfordB32Encode"/> are called Base32GNS-Encode and Base32GNS-Decode, respectively. </t> <figureanchor="figure_zid" align="left" suppress-title="false" pn="figure-3"> <name slugifiedName="name-the-binary-representation-o">The binary representationanchor="figure_zid"> <name>The Binary Representation of the zTLD</name> <artwork name="" type=""align="left" alt="" pn="section-4.1-2.1">alt=""> 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | ZONE TYPE | ZONE KEY / +-----+-----+-----+-----+ / / / / / +-----+-----+-----+-----+-----+-----+-----+-----+ </artwork> </figure><t indent="0" pn="section-4.1-3"><t> The ZONE TYPEmust<bcp14>MUST</bcp14> be encoded in network byte order. The format of the ZONE KEY depends entirely on the ZONE TYPE. </t><t indent="0" pn="section-4.1-4"><t> Consequently, a zTLD is encoded and decoded as follows: </t> <artwork name="" type=""align="left" alt="" pn="section-4.1-5">alt=""> zTLD := Base32GNS-Encode(ztype||zkey) ztype||zkey := Base32GNS-Decode(zTLD) </artwork><t indent="0" pn="section-4.1-6"><t> where "||" is the concatenation operator. </t><t indent="0" pn="section-4.1-7"><t> The zTLD can be usedas-is"as is" as a rightmost label in a GNS name. If an application wants to ensure DNS compatibility of the name, it <bcp14>MAY</bcp14> also represent the zTLD as follows:Ifif the zTLD is less than or equal to 63 characters, it can be used as a zTLDas-is.as is. If the zTLD is longer than 63 characters, the zTLD is divided into smaller labels separated by the label separator. Here, the most significant bytes of the "ztype||zkey" concatenation must be contained in the rightmost label of the resulting string and the least significant bytes in the leftmost label of the resulting string. This allows the resolver to determine the ztype and zTLD length from the rightmost label and to subsequently determine how many labels the zTLD should span. A GNS implementation <bcp14>MUST</bcp14> support the division of zTLDs inDNS compatibleDNS-compatible label lengths. For example, assuming a zTLD of 130 characters, the divisionis:is as follows: </t><!-- FIXME: Is this really really necessary? Really? --><artwork name="" type=""align="left" alt="" pn="section-4.1-8">alt=""> zTLD[126..129].zTLD[63..125].zTLD[0..62] </artwork> </section> <sectionanchor="revocation" numbered="true" toc="include" removeInRFC="false" pn="section-4.2"> <name slugifiedName="name-zone-revocation">Zoneanchor="revocation"> <name>Zone Revocation</name><t indent="0" pn="section-4.2-1"><t> In order to revoke a zone key, a signed revocation message <bcp14>MUST</bcp14> be published. This message <bcp14>MUST</bcp14> be signed using the private key of the zone. The revocation message is broadcast to the network. The specification of the broadcast mechanism is out of scope for this document. A possible broadcast mechanism for efficient flooding in a distributed network is implemented in <xreftarget="GNUnet" format="default" sectionFormat="of" derivedContent="GNUnet"/>.target="GNUnet"/>. Alternatively, revocation messages could also be distributed via a distributed ledger or a trusted central server. To prevent flooding attacks, the revocation message <bcp14>MUST</bcp14> contain a proof of work (PoW). The revocationmessagemessage, including thePoWPoW, <bcp14>MAY</bcp14> be calculated ahead of time to support timely revocation. </t><t indent="0" pn="section-4.2-2"><t> For all occurrences below, "Argon2id" is thePassword-based Key Derivation Functionpassword-based key derivation function as defined in <xreftarget="RFC9106" format="default" sectionFormat="of" derivedContent="RFC9106"/>.target="RFC9106"/>. For the PoWcalculationscalculations, the algorithm is instantiated with the following parameters: </t> <dlindent="3" newline="false" spacing="normal" pn="section-4.2-3"> <dt pn="section-4.2-3.1">S</dt> <dd pn="section-4.2-3.2">Thenewline="false"> <dt>S:</dt> <dd>The salt. Fixed 16-byte string:"GnsRevocationPow".</dd> <dt pn="section-4.2-3.3">t</dt> <dd pn="section-4.2-3.4">Number"GnsRevocationPow"</dd> <dt>t:</dt> <dd>Number of iterations: 3</dd><dt pn="section-4.2-3.5">m</dt> <dd pn="section-4.2-3.6">Memory<dt>m:</dt> <dd>Memory size in KiB: 1024</dd><dt pn="section-4.2-3.7">T</dt> <dd pn="section-4.2-3.8">Output<dt>T:</dt> <dd>Output length of hash in bytes: 64</dd><dt pn="section-4.2-3.9">p</dt> <dd pn="section-4.2-3.10">Parallelization<dt>p:</dt> <dd>Parallelization parameter: 1</dd><dt pn="section-4.2-3.11">v</dt> <dd pn="section-4.2-3.12">Algorithm<dt>v:</dt> <dd>Algorithm version: 0x13</dd><dt pn="section-4.2-3.13">y</dt> <dd pn="section-4.2-3.14">Algorithm<dt>y:</dt> <dd>Algorithm type (Argon2id): 2</dd><dt pn="section-4.2-3.15">X</dt> <dd pn="section-4.2-3.16">Unused</dd> <dt pn="section-4.2-3.17">K</dt> <dd pn="section-4.2-3.18">Unused</dd><dt>X:</dt> <dd>Unused</dd> <dt>K:</dt> <dd>Unused</dd> </dl><t indent="0" pn="section-4.2-4"><t> <xreftarget="figure_revocation" format="default" sectionFormat="of" derivedContent="Figure 4"/>target="figure_revocation"/> illustrates the format of the data "P" on which the PoW is calculated. </t> <figureanchor="figure_revocation" align="left" suppress-title="false" pn="figure-4"> <name slugifiedName="name-the-format-of-the-pow-data">Theanchor="figure_revocation"> <name>The Format of the PoWData.</name>Data</name> <artwork name="" type=""align="left" alt="" pn="section-4.2-5.1">alt=""> 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | POW | +-----------------------------------------------+ | TIMESTAMP | +-----------------------------------------------+ | ZONE TYPE | ZONE KEY|/ +-----+-----+-----+-----+|/ / / / / +-----+-----+-----+-----+-----+-----+-----+-----+ </artwork> </figure> <dlindent="3" newline="false" spacing="normal" pn="section-4.2-6"> <dt pn="section-4.2-6.1">POW</dt> <dd pn="section-4.2-6.2">newline="false"> <dt>POW:</dt> <dd> A 64-bit value that is a solution to the PoW. In network byte order. </dd><dt pn="section-4.2-6.3">TIMESTAMP</dt> <dd pn="section-4.2-6.4"> denotes<dt>TIMESTAMP:</dt> <dd> Denotes the absolute 64-bit date when the revocation was computed. In microseconds since midnight (0 hour), January 1, 1970 UTC in network byte order. </dd><dt pn="section-4.2-6.5">ZONE TYPE</dt> <dd pn="section-4.2-6.6"> is the<dt>ZONE TYPE:</dt> <dd> The 32-bit zone type in network byte order. </dd><dt pn="section-4.2-6.7">ZONE KEY</dt> <dd pn="section-4.2-6.8"> is the<dt>ZONE KEY:</dt> <dd> The 256-bit public keyzkzkey of the zonewhichthat is being revoked. The wire format of this value is defined by the ZONE TYPE. </dd> </dl><t indent="0" pn="section-4.2-7"><t> Usually, PoW schemes requireto findthat one POW value be found, such that a specific number of leading zeroes are found in the hash result. 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 PoW, a valid GNS revocation requires that a numberZof different PoWs (Z, as defined below) must be found that on average have at least D leading zeroes. </t><t indent="0" pn="section-4.2-8"><t> Given an average difficulty of D, the proofs have an expiration time of EPOCH. Applications <bcp14>MAY</bcp14> calculate proofs with a difficulty that is higher than D by providing POW values where there are (on average) more than D bits of leadingzeros.zeroes. With each additional bit of difficulty, the lifetime of the proof is prolonged by another EPOCH. Consequently, by calculating a more difficult PoW, the lifetime of the proof -- and thus the persistence of the revocation message -- can be increased on demand by the zone owner. </t><t indent="0" pn="section-4.2-9"><t> The parameters are defined as follows: </t> <dlindent="3" newline="false" spacing="normal" pn="section-4.2-10"> <dt pn="section-4.2-10.1">Z</dt> <dd pn="section-4.2-10.2">Thenewline="false"> <dt>Z:</dt> <dd>The number of PoWs that are required. Its value is fixed at 32.</dd><dt pn="section-4.2-10.3">D</dt> <dd pn="section-4.2-10.4">The<dt>D:</dt> <dd>The lower limit of the average difficulty. Its value is fixed at 22.</dd><dt pn="section-4.2-10.5">EPOCH</dt> <dd pn="section-4.2-10.6">A<dt>EPOCH:</dt> <dd>A single epoch. Its value is fixed at 365 days in microseconds.</dd> </dl><t indent="0" pn="section-4.2-11"><t> The revocation message wire format is illustrated in <xreftarget="figure_revocationdata" format="default" sectionFormat="of" derivedContent="Figure 5"/>.target="figure_revocationdata"/>. </t> <figureanchor="figure_revocationdata" align="left" suppress-title="false" pn="figure-5"> <name slugifiedName="name-the-revocation-message-wire">Theanchor="figure_revocationdata"> <name>The Revocation Message WireFormat.</name>Format</name> <artwork name="" type=""align="left" alt="" pn="section-4.2-12.1">alt=""> 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | TIMESTAMP | +-----+-----+-----+-----+-----+-----+-----+-----+ | TTL | +-----+-----+-----+-----+-----+-----+-----+-----+ | POW_0 | +-----+-----+-----+-----+-----+-----+-----+-----+ | ... | +-----+-----+-----+-----+-----+-----+-----+-----+ |POW_Z-1POW_(Z-1) | +-----------------------------------------------+ | ZONE TYPE | ZONE KEY|/ +-----+-----+-----+-----+|/ / / / / +-----+-----+-----+-----+-----+-----+-----+-----+|/ SIGNATURE|/ / / /| |/ / / +-----+-----+-----+-----+-----+-----+-----+-----+ </artwork> </figure> <dlindent="3" newline="false" spacing="normal" pn="section-4.2-13"> <dt pn="section-4.2-13.1">TIMESTAMP</dt> <dd pn="section-4.2-13.2"> denotesnewline="false"> <dt>TIMESTAMP:</dt> <dd> Denotes the absolute 64-bit date when the revocation was computed. In microseconds since midnight (0 hour), January 1, 1970 UTC in network byte order. This is the same value as thetime stamptimestamp used in the individual PoW calculations. </dd><dt pn="section-4.2-13.3">TTL</dt> <dd pn="section-4.2-13.4"> denotes<dt>TTL:</dt> <dd> Denotes the relative 64-bit time to live of the record in microseconds in network byte order. The field <bcp14>SHOULD</bcp14> be set to EPOCH * 1.1. Given an average number of leadingzeroszeroes D', then the field value <bcp14>MAY</bcp14> be increased up to (D'-D+1) * EPOCH * 1.1. Validators <bcp14>MAY</bcp14> reject messages with lower or higher values when received. </dd><dt pn="section-4.2-13.5">POW_i</dt> <dd pn="section-4.2-13.6"><dt>POW_i:</dt> <dd> 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. To facilitate fast verification of uniqueness, the POW valuesmust<bcp14>MUST</bcp14> be given in strictly monotonically increasing order in the message. </dd><dt pn="section-4.2-13.7">ZONE TYPE</dt> <dd pn="section-4.2-13.8"><dt>ZONE TYPE:</dt> <dd> The 32-bit zone type corresponding to the zone key in network byte order. </dd><dt pn="section-4.2-13.9">ZONE KEY</dt> <dd pn="section-4.2-13.10"> is the<dt>ZONE KEY:</dt> <dd> The public keyzkzkey of the zonewhichthat is being revoked and the key to be used to verify SIGNATURE. </dd><dt pn="section-4.2-13.11">SIGNATURE</dt> <dd pn="section-4.2-13.12"><dt>SIGNATURE:</dt> <dd> A signature over atime stamptimestamp and the zonezkzkey of the zonewhichthat is revoked and corresponds to the key used in the PoW. The signature is created using the Sign() function of the cryptosystem of the zone and the private key (see <xreftarget="zones" format="default" sectionFormat="of" derivedContent="Section 4"/>).target="zones"/>). </dd> </dl><t indent="0" pn="section-4.2-14"><t> The signatureoverin thepublic keyrevocation message covers a 32-bit header prefixed to thetime stampTIMESTAMP, ZONE TYPE, andpublic keyZONE KEY fields. The header includes the key length and signature purpose. The wire format is illustrated in <xreftarget="figure_revsigwithpseudo" format="default" sectionFormat="of" derivedContent="Figure 6"/>.target="figure_revsigwithpseudo"/>. </t> <figureanchor="figure_revsigwithpseudo" align="left" suppress-title="false" pn="figure-6"> <name slugifiedName="name-the-wire-format-of-the-revo">Theanchor="figure_revsigwithpseudo"> <name>The Wire Format of the Revocation Data forSigning.</name>Signing</name> <artwork name="" type=""align="left" alt="" pn="section-4.2-15.1">alt=""> 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | SIZE | PURPOSE (0x03) | +-----+-----+-----+-----+-----+-----+-----+-----+ | TIMESTAMP | +-----+-----+-----+-----+-----+-----+-----+-----+ | ZONE TYPE | ZONE KEY|/ +-----+-----+-----+-----+|/ / / / / +-----+-----+-----+-----+-----+-----+-----+-----+ </artwork> </figure> <dlindent="3" newline="false" spacing="normal" pn="section-4.2-16"> <dt pn="section-4.2-16.1">SIZE</dt> <dd pn="section-4.2-16.2">newline="false"> <dt>SIZE:</dt> <dd> A 32-bit value containing the length of the signed data in bytes in network byte order. </dd><dt pn="section-4.2-16.3">PURPOSE</dt> <dd pn="section-4.2-16.4"><dt>PURPOSE:</dt> <dd> A 32-bit signature purpose flag. The value of this field <bcp14>MUST</bcp14> be 3. The value is encoded in network byte order. It defines the context in which the signature is created so that it cannot be reused in other parts of the protocolincludingthat might include possible future extensions. The value of this field corresponds to an entry in the GANA "GNUnet SignaturePurpose"Purposes" registry <xreftarget="GANA" format="default" sectionFormat="of" derivedContent="GANA"/>.target="GANA"/>. </dd><dt pn="section-4.2-16.5">TIMESTAMP</dt> <dd pn="section-4.2-16.6"><dt>TIMESTAMP:</dt> <dd> Field as defined in the revocation message above. </dd><dt pn="section-4.2-16.7">ZONE TYPE</dt> <dd pn="section-4.2-16.8"><dt>ZONE TYPE:</dt> <dd> Field as defined in the revocation message above. </dd><dt pn="section-4.2-16.9">ZONE KEY</dt> <dd pn="section-4.2-16.10">Field<dt>ZONE KEY:</dt> <dd>Field as defined in the revocation message above.</dd> </dl><t indent="0" pn="section-4.2-17"><t> In order to validate arevocationrevocation, the following steps <bcp14>MUST</bcp14> be taken: </t><ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-4.2-18"> <li pn="section-4.2-18.1" derivedCounter="1.">The<ol> <li>The signature <bcp14>MUST</bcp14> be verified against the zone key.</li><li pn="section-4.2-18.2" derivedCounter="2.">The<li>The set of POW values<bcp14>MUST</bcp14> NOT<bcp14>MUST NOT</bcp14> containduplicates whichduplicates; this <bcp14>MUST</bcp14> be checked by verifying that the values are strictly monotonically increasing.</li><li pn="section-4.2-18.3" derivedCounter="3.">The<li>The average number of leading zeroes D' resulting from the provided POW values <bcp14>MUST</bcp14> be greater than or equal to D. Implementers <bcp14>MUST NOT</bcp14> use an integer data type to calculate or represent D'.</li> </ol><t indent="0" pn="section-4.2-19"><t> The TTL field in the revocation message is informational. A revocation <bcp14>MAY</bcp14> be discarded without checking the POW values or the signature if the TTL (in combination with TIMESTAMP) indicates that the revocation has already expired. The actual validity period of the revocation <bcp14>MUST</bcp14> be determined by examining the leading zeroes in the POW values. </t><t indent="0" pn="section-4.2-20"><t> The validity period of the revocation is calculated as (D'-D+1) * EPOCH * 1.1. The EPOCH is extended by 10% in order to deal withunsynchronizedpoorly synchronized clocks. The validity period added on top of the TIMESTAMP yields the expiration date. If the current time is after the expiration date, the revocation is considered stale. </t><t indent="0" pn="section-4.2-21"><t> Verified revocations <bcp14>MUST</bcp14> be stored locally. The implementation <bcp14>MAY</bcp14> discard stale revocations and evictthenthem from the local store at any time. </t><t indent="0" pn="section-4.2-22"> Implementations <bcp14>MUST</bcp14><t> It is important that implementations broadcast received revocations if they are valid and not stale. Should the calculated validity period differ from the TTL field value, the calculated value <bcp14>MUST</bcp14> be used as the TTL field value when forwarding the revocation message. Systems might disagree on the current time, so implementations <bcp14>MAY</bcp14> use stale but otherwise valid revocations but <bcp14>SHOULD NOT</bcp14> broadcast them. Forwarded stale revocations <bcp14>MAY</bcp14> bediscarded.discarded by the receiver. </t><t indent="0" pn="section-4.2-23"><t> Any locally stored revocation <bcp14>MUST</bcp14> be considered during delegation record processing (see <xreftarget="delegation_processing" format="default" sectionFormat="of" derivedContent="Section 7.3.4"/>).target="delegation_processing"/>). </t> </section> </section> <sectionanchor="rrecords" numbered="true" toc="include" removeInRFC="false" pn="section-5"> <name slugifiedName="name-resource-records">Resourceanchor="rrecords"> <name>Resource Records</name><t indent="0" pn="section-5-1"><t> A GNS implementation <bcp14>SHOULD</bcp14> provide a mechanismto createfor creating andmanagemanaging local zones as well as a persistence mechanism (such as a local database) for resource records. A new local zone is established by selecting a zone type and creating a zone key pair. If this mechanism is not implemented, no zones can be published inthestorage (see <xreftarget="publish" format="default" sectionFormat="of" derivedContent="Section 6"/>)target="publish"/>) and name resolution is limited to non-localstart zonesStart Zones (see <xreftarget="governance" format="default" sectionFormat="of" derivedContent="Section 7.1"/>).target="governance"/>). </t><t indent="0" pn="section-5-2"><t> A GNS resource record holds the data of a specific record in a zone. The resource record format isdefinedillustrated in <xreftarget="figure_gnsrecord" format="default" sectionFormat="of" derivedContent="Figure 7"/>.target="figure_gnsrecord"/>. </t> <figureanchor="figure_gnsrecord" align="left" suppress-title="false" pn="figure-7"> <name slugifiedName="name-the-resource-record-wire-fo">Theanchor="figure_gnsrecord"> <name>The Resource Record WireFormat.</name>Format</name> <artwork name="" type=""align="left" alt="" pn="section-5-3.1">alt=""> 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | EXPIRATION | +-----+-----+-----+-----+-----+-----+-----+-----+ | SIZE | FLAGS | TYPE | +-----+-----+-----+-----+-----+-----+-----+-----+ | DATA / / / / / </artwork> </figure> <dlindent="3" newline="false" spacing="normal" pn="section-5-4"> <dt pn="section-5-4.1">EXPIRATION</dt> <dd pn="section-5-4.2"> denotesnewline="false"> <dt>EXPIRATION:</dt> <dd> Denotes the absolute 64-bit expiration date of the record. In microseconds since midnight (0 hour), January 1, 1970 UTC in network byte order. </dd><dt pn="section-5-4.3">SIZE</dt> <dd pn="section-5-4.4"> denotes<dt>SIZE:</dt> <dd> Denotes the 16-bit size of the DATA field in bytes in network byte order. </dd><dt pn="section-5-4.5">FLAGS</dt> <dd pn="section-5-4.6"> is a<dt>FLAGS:</dt> <dd> A 16-bitbitfield indicating special properties of the resource record. The semantics of the different bits are defined below. </dd><dt pn="section-5-4.7">TYPE</dt> <dd pn="section-5-4.8"> is the<dt>TYPE:</dt> <dd> The 32-bit resource record type in network byte order. This type can be one of the GNS resource records as defined in <xreftarget="rrecords" format="default" sectionFormat="of" derivedContent="Section 5"/> ortarget="rrecords"/>, a DNS record type as defined in <xreftarget="RFC1035" format="default" sectionFormat="of" derivedContent="RFC1035"/>target="RFC1035"/>, or any of the complementary standardized DNS resource record types. Note that values below2^162<sup>16</sup> are reserved for 16-bit DNSResorce Recordresource record types allocated by IANA <xreftarget="RFC6895" format="default" sectionFormat="of" derivedContent="RFC6895"/>.target="RFC6895"/>. Values above2^162<sup>16</sup> are allocated by the GANA "GNS Record Types" registry <xreftarget="GANA" format="default" sectionFormat="of" derivedContent="GANA"/>.target="GANA"/>. </dd><dt pn="section-5-4.9">DATA</dt> <dd pn="section-5-4.10"> the<dt>DATA:</dt> <dd> The variable-length resource record data payload. The content is defined by the respective type of the resource record. </dd> </dl><t indent="0" pn="section-5-5"><t> The FLAGS field is used to indicate special properties of the resource record. An application creating resource records <bcp14>MUST</bcp14> set all bits in FLAGS to 0 unless it specifically understands and wants to set the respective flag. As additional flags can be defined in future protocol versions, if an application or implementation encounters a flagwhichthat it does not recognize,itthe flag <bcp14>MUST</bcp14> be ignored. However, all implementations <bcp14>MUST</bcp14> understand the SHADOW and CRITICAL flags defined below. Any combination of the flags specified belowareis valid. <xreftarget="figure_flag" format="default" sectionFormat="of" derivedContent="Figure 8"/>target="figure_flag"/> illustrates the flag distribution in the 16-bit FLAGS field of a resource record: </t> <figureanchor="figure_flag" align="left" suppress-title="false" pn="figure-8"> <name slugifiedName="name-the-resource-record-flag-wi">Theanchor="figure_flag"> <name>The Resource Record Flag WireFormat.</name>Format</name> <artwork name="" type=""align="left" alt="" pn="section-5-6.1">alt=""> 0 13 14 15 +--------...+-------------+-------+---------+ | Reserved |SUPPLEMENTAL |SHADOW |CRITICAL | +--------...+-------------+-------+---------+ </artwork> </figure> <dlindent="3" newline="false" spacing="normal" pn="section-5-7"> <dt pn="section-5-7.1">CRITICAL</dt> <dd pn="section-5-7.2">newline="false"> <dt>CRITICAL:</dt> <dd> If this flag is set, it indicates that processing is critical. Implementations that do not support the record type or are otherwise unable to process the record <bcp14>MUST</bcp14> abort resolution upon encountering the record in the resolution process. </dd><dt pn="section-5-7.3">SHADOW</dt> <dd pn="section-5-7.4"><dt>SHADOW:</dt> <dd> If this flag is set, this record <bcp14>MUST</bcp14> be ignored by resolvers unless all (other) records of the same record type have expired. Used to allow zone publishers to facilitate good performance when records change by allowing them to put future values of records intothestorage. This way, future values can propagate and can be cached before the transition becomes active. </dd><dt pn="section-5-7.5">SUPPLEMENTAL</dt> <dd pn="section-5-7.6"><dt>SUPPLEMENTAL:</dt> <dd> This is a supplemental record. It is provided in addition to the other records. This flag indicates that this record is not explicitly managed alongside the other records under the respective name but might be useful for the application. </dd> </dl> <sectionanchor="gnsrecords_delegation" numbered="true" toc="include" removeInRFC="false" pn="section-5.1"> <name slugifiedName="name-zone-delegation-records">Zoneanchor="gnsrecords_delegation"> <name>Zone Delegation Records</name><t indent="0" pn="section-5.1-1"><t> This section defines the initial set of zone delegation record types. Any implementation <bcp14>SHOULD</bcp14> support all zone types defined here and <bcp14>MAY</bcp14> support any number of additional delegation records defined in the GANA "GNS Record Types" registry (see <xreftarget="GANA" format="default" sectionFormat="of" derivedContent="GANA"/>).target="GANA"/>). Not supporting some zone types will result in resolution failuresin caseif the respective zone type is encountered. This can be a valid choice if some zone delegation record types have been determined to be cryptographically insecure. Zone delegation records <bcp14>MUST NOT</bcp14> be storedandor published under the apex label. A zone delegation record type value is the same as the respective ztype value. The ztype defines the cryptographic primitives for the zone that is being delegated to. A zone delegation record payload contains the public key of the zone to delegate to. 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. There <bcp14>MAY</bcp14> be inactive records of the same typewhichthat have the SHADOW flag set in order to facilitate smooth key rollovers. </t><t indent="0" pn="section-5.1-2"><t> In the following, "||" is the concatenation operator of two byte strings. The algorithm specification uses character strings such as GNS labels or constant values. When used in concatenations or as input tofunctionsfunctions, thenull-terminatorzero terminator of the character strings <bcp14>MUST NOT</bcp14> be included. </t> <sectionanchor="gnsrecords_pkey" numbered="true" toc="include" removeInRFC="false" pn="section-5.1.1"> <name slugifiedName="name-pkey">PKEY</name> <t indent="0" pn="section-5.1.1-1">anchor="gnsrecords_pkey"> <name>PKEY</name> <t> In GNS, a delegation of a label to a zone of type "PKEY" is represented through a PKEY record. The PKEY DATA entry wire formatcan be foundis illustrated in <xreftarget="figure_pkeyrecord" format="default" sectionFormat="of" derivedContent="Figure 9"/>.target="figure_pkeyrecord"/>. </t> <figureanchor="figure_pkeyrecord" align="left" suppress-title="false" pn="figure-9"> <name slugifiedName="name-the-pkey-wire-format">Theanchor="figure_pkeyrecord"> <name>The PKEY WireFormat.</name>Format</name> <artwork name="" type=""align="left" alt="" pn="section-5.1.1-2.1">alt=""> 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | PUBLIC KEY | | | | | | | +-----+-----+-----+-----+-----+-----+-----+-----+ </artwork> </figure> <dlindent="3" newline="false" spacing="normal" pn="section-5.1.1-3"> <dt pn="section-5.1.1-3.1">PUBLIC KEY</dt> <dd pn="section-5.1.1-3.2">newline="false"> <dt>PUBLIC KEY:</dt> <dd> A 256-bit Ed25519 public key. </dd> </dl><t indent="0" pn="section-5.1.1-4"><t> For PKEYzoneszones, the zone key material is derived using the curve parameters of the twisted Edwards representation of Curve25519 <xreftarget="RFC7748" format="default" sectionFormat="of" derivedContent="RFC7748"/>target="RFC7748"/> (the reasoning behind choosing this curve can be found in <xreftarget="security_cryptography" format="default" sectionFormat="of" derivedContent="Section 9.3"/>)target="security_cryptography"/>) with the ECDSA scheme <xreftarget="RFC6979" format="default" sectionFormat="of" derivedContent="RFC6979"/>.target="RFC6979"/>. The following naming convention is used for the cryptographic primitives of PKEY zones: </t> <dlindent="3" newline="false" spacing="normal" pn="section-5.1.1-5"> <dt pn="section-5.1.1-5.1">d</dt> <dd pn="section-5.1.1-5.2"> is anewline="false"> <dt>d:</dt> <dd> A 256-bit Ed25519 private key(private(clamped private scalar). </dd><dt pn="section-5.1.1-5.3">zk</dt> <dd pn="section-5.1.1-5.4"> is the<dt>zkey:</dt> <dd> The Ed25519 public zone key corresponding to d. </dd><dt pn="section-5.1.1-5.5">p</dt> <dd pn="section-5.1.1-5.6"> is the<dt>p:</dt> <dd> The prime of edwards25519 as defined in <xreftarget="RFC7748" format="default" sectionFormat="of" derivedContent="RFC7748"/>, i.e. 2^255target="RFC7748"/>, i.e., 2<sup>255</sup> - 19. </dd><dt pn="section-5.1.1-5.7">G</dt> <dd pn="section-5.1.1-5.8"> is the<dt>G:</dt> <dd> The group generator (X(P),Y(P)). With X(P),Y(P) of edwards25519 as defined in <xreftarget="RFC7748" format="default" sectionFormat="of" derivedContent="RFC7748"/>.target="RFC7748"/>. </dd><dt pn="section-5.1.1-5.9">L</dt> <dd pn="section-5.1.1-5.10"> is the<dt>L:</dt> <dd> The order of the prime-order subgroup of edwards25519 as defined in <xreftarget="RFC7748" format="default" sectionFormat="of" derivedContent="RFC7748"/>.target="RFC7748"/>. </dd><dt pn="section-5.1.1-5.11">KeyGen()</dt> <dd pn="section-5.1.1-5.12">The<dt>KeyGen():</dt> <dd>The generation of the private scalar d and the curve pointzkzkey := d*G (where G is the group generator of the elliptic curve) as defined inSection 2.2. of<xref target="RFC6979"format="default"sectionFormat="of"derivedContent="RFC6979"/>section="2.2"/> represents the KeyGen() function. </dd> </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 means that a zTLD will always fit into a single label and does not need any further conversion. Given a label, the outputzk'zkey' of theZKDF(zk,label)ZKDF(zkey, label) function is calculated as follows for PKEY zones: </t> <artwork name="" type=""align="left" alt="" pn="section-5.1.1-7"> ZKDF(zk,label):alt=""> ZKDF(zkey, label): PRK_h :=HKDF-Extract ("key-derivation", zk)HKDF-Extract("key-derivation", zkey) h :=HKDF-Expand (PRK_h,HKDF-Expand(PRK_h, label || "gns", 512 / 8)zk'zkey' := (h mod L) *zkzkey returnzk'zkey' </artwork><t indent="0" pn="section-5.1.1-8"><t> The PKEY cryptosystem usesa hash-basedan HMAC-based key derivation function (HKDF) as defined in <xreftarget="RFC5869" format="default" sectionFormat="of" derivedContent="RFC5869"/>,target="RFC5869"/>, using SHA-512 <xreftarget="RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/>target="RFC6234"/> for the extraction phase and SHA-256 <xreftarget="RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/>target="RFC6234"/> for the expansion phase. PRK_h is key material retrieved using an HKDFusingthat uses the string "key-derivation" as the salt and the zone key as the initial keying material. h is the 512-bit HKDF expansion result and must be interpreted in network byte order. The expansion information input is a concatenation of the label and the string "gns". The multiplication ofzkzkey with h in ZKDF() is a point multiplication, while the multiplication of d with h in SignDerived() below is a scalar multiplication. </t><t indent="0" pn="section-5.1.1-9"><t> The Sign() and Verify() functions for PKEY zones are implemented using 512-bit ECDSA deterministic signatures as specified in <xreftarget="RFC6979" format="default" sectionFormat="of" derivedContent="RFC6979"/>.target="RFC6979"/>. The same functions can be used for derived keys: </t> <artwork name="" type=""align="left" alt="" pn="section-5.1.1-10"> SignDerived(d,label,message): zkalt=""> SignDerived(d, label, message): zkey := d * G PRK_h :=HKDF-Extract ("key-derivation", zk)HKDF-Extract("key-derivation", zkey) h :=HKDF-Expand (PRK_h,HKDF-Expand(PRK_h, label || "gns", 512 / 8) d' := (h * d) mod L returnSign(d',message)Sign(d', message) </artwork><t indent="0" pn="section-5.1.1-11"><t> A signature(R,S)is valid for the derived public key zkey' := ZKDF(zkey, label) if the following holds: </t> <artwork name="" type=""align="left" alt="" pn="section-5.1.1-12"> VerifyDerived(zk,label,message,signature): zk' := ZKDF(zk,label)alt=""> VerifyDerived(zkey', message, signature): returnVerify(zk',message,signature)Verify(zkey', message, signature) </artwork><t indent="0" pn="section-5.1.1-13"><t> The S-Encrypt() and S-Decrypt() functions use AES in counter mode as defined in <xreftarget="MODES" format="default" sectionFormat="of" derivedContent="MODES"/> (CTR-AES-256):target="MODES"/> (CTR-AES256): </t> <artwork name="" type=""align="left" alt="" pn="section-5.1.1-14"> S-Encrypt(zk,label,expiration,plaintext):alt=""> S-Encrypt(zkey, label, expiration, plaintext): PRK_k :=HKDF-Extract ("gns-aes-ctx-key", zk)HKDF-Extract("gns-aes-ctx-key", zkey) PRK_n :=HKDF-Extract ("gns-aes-ctx-iv", zk)HKDF-Extract("gns-aes-ctx-iv", zkey) K :=HKDF-Expand (PRK_k,HKDF-Expand(PRK_k, label, 256 / 8) NONCE :=HKDF-Expand (PRK_n,HKDF-Expand(PRK_n, label, 32 / 8) BLOCK_COUNTER := 0x0000000000000001 IV := NONCE || expiration ||0x0000000000000001BLOCK_COUNTER 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)HKDF-Extract("gns-aes-ctx-key", zkey) PRK_n :=HKDF-Extract ("gns-aes-ctx-iv", zk)HKDF-Extract("gns-aes-ctx-iv", zkey) K :=HKDF-Expand (PRK_k,HKDF-Expand(PRK_k, label, 256 / 8) NONCE :=HKDF-Expand (PRK_n,HKDF-Expand(PRK_n, label, 32 / 8) BLOCK_COUNTER := 0x0000000000000001 IV := NONCE || expiration ||0x0000000000000001BLOCK_COUNTER return CTR-AES256(K, IV, ciphertext) </artwork><t indent="0" pn="section-5.1.1-15"><t> The key K and counterIVInitialization Vector (IV) are derived from the record label and the zone keyzkzkey, usinga hash-based key derivation function (HKDF)an HKDF as defined in <xreftarget="RFC5869" format="default" sectionFormat="of" derivedContent="RFC5869"/>.target="RFC5869"/>. SHA-512 <xreftarget="RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/>target="RFC6234"/> is used for the extraction phase and SHA-256 <xreftarget="RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/>target="RFC6234"/> for the expansion phase. The output keying material is 32 bytes (256 bits) for the symmetric key and 4 bytes (32 bits) for thenonce.NONCE. The symmetric key K is a 256-bit AES key <xreftarget="RFC3826" format="default" sectionFormat="of" derivedContent="RFC3826"/> key.target="RFC3826"/>. </t><t indent="0" pn="section-5.1.1-16"><t> The nonce is combined with a 64-bitinitialization vectorIV and a 32-bit block counter as defined in <xreftarget="RFC3686" format="default" sectionFormat="of" derivedContent="RFC3686"/>.target="RFC3686"/>. The block counter begins withthea value of 1, and it is incremented to generate subsequent portions of the key stream. The block counter is a 32-bit integer value in network byte order. Theinitialization vector is the expiration timeformat of theresource record block in network byte order. The resultingcounter(IV) wire format can be foundIV used by the S-Encrypt() and S-Decrypt() functions is illustrated in <xreftarget="figure_hkdf_ivs_pkey" format="default" sectionFormat="of" derivedContent="Figure 10"/>.target="figure_hkdf_ivs_pkey"/>. </t> <figureanchor="figure_hkdf_ivs_pkey" align="left" suppress-title="false" pn="figure-10"> <name slugifiedName="name-the-block-counter-wire-form">The Blockanchor="figure_hkdf_ivs_pkey"> <name>Structure of the CounterWire Format.</name>IV as Used in S-Encrypt() and S-Decrypt()</name> <artwork name="" type=""align="left" alt="" pn="section-5.1.1-17.1">alt=""> 0 8 16 24 32 +-----+-----+-----+-----+ | NONCE | +-----+-----+-----+-----+ | EXPIRATION | | | +-----+-----+-----+-----+ | BLOCK COUNTER | +-----+-----+-----+-----+ </artwork> </figure> </section> <sectionanchor="gnsrecords_edkey" numbered="true" toc="include" removeInRFC="false" pn="section-5.1.2"> <name slugifiedName="name-edkey">EDKEY</name> <t indent="0" pn="section-5.1.2-1">anchor="gnsrecords_edkey"> <name>EDKEY</name> <t> In GNS, a delegation of a label to a zone of type "EDKEY" is represented throughaan EDKEY record. The EDKEY DATA entry wire format is illustrated in <xreftarget="figure_edkeyrecord" format="default" sectionFormat="of" derivedContent="Figure 11"/>.target="figure_edkeyrecord"/>. </t> <figureanchor="figure_edkeyrecord" align="left" suppress-title="false" pn="figure-11"> <name slugifiedName="name-the-edkey-data-wire-format">Theanchor="figure_edkeyrecord"> <name>The EDKEY DATA WireFormat.</name>Format</name> <artwork name="" type=""align="left" alt="" pn="section-5.1.2-2.1">alt=""> 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | PUBLIC KEY | | | | | | | +-----+-----+-----+-----+-----+-----+-----+-----+ </artwork> </figure> <dlindent="3" newline="false" spacing="normal" pn="section-5.1.2-3"> <dt pn="section-5.1.2-3.1">PUBLIC KEY</dt> <dd pn="section-5.1.2-3.2">newline="false"> <dt>PUBLIC KEY:</dt> <dd> A 256-bit EdDSA zone key. </dd> </dl><t indent="0" pn="section-5.1.2-4"><t> For EDKEYzoneszones, the zone key material is derived using the curve parameters of the twistededwardsEdwards representation of Curve25519 <xreftarget="RFC7748" format="default" sectionFormat="of" derivedContent="RFC7748"/> (a.k.a. Ed25519)target="RFC7748"/> (a.k.a. Ed25519) with the Ed25519 scheme <xreftarget="ed25519" format="default" sectionFormat="of" derivedContent="ed25519"/>target="ed25519"/> as specified in <xreftarget="RFC8032" format="default" sectionFormat="of" derivedContent="RFC8032"/>.target="RFC8032"/>. The following naming convention is used for the cryptographic primitives of EDKEY zones: </t><!-- Check if we want to use RFC8032 instead of paper ed25519 --><dlindent="3" newline="false" spacing="normal" pn="section-5.1.2-5"> <dt pn="section-5.1.2-5.1">d</dt> <dd pn="section-5.1.2-5.2"> is anewline="false"> <dt>d:</dt> <dd> A 256-bit EdDSA private key. </dd><dt pn="section-5.1.2-5.3">a</dt> <dd pn="section-5.1.2-5.4"> is is an<dt>a:</dt> <dd> An integer derived from d using the SHA-512 hash function as defined in <xreftarget="RFC8032" format="default" sectionFormat="of" derivedContent="RFC8032"/>.target="RFC8032"/>. </dd><dt pn="section-5.1.2-5.5">zk</dt> <dd pn="section-5.1.2-5.6"> is the<dt>zkey:</dt> <dd> The EdDSA public key corresponding to d. It is defined as the curve point a*G where G is the group generator of the elliptic curve as defined in <xreftarget="RFC8032" format="default" sectionFormat="of" derivedContent="RFC8032"/>.target="RFC8032"/>. </dd><dt pn="section-5.1.2-5.7">p</dt> <dd pn="section-5.1.2-5.8"> is the<dt>p:</dt> <dd> The prime of edwards25519 as defined in <xreftarget="RFC8032" format="default" sectionFormat="of" derivedContent="RFC8032"/>, i.e. 2^255target="RFC8032"/>, i.e., 2<sup>255</sup> - 19. </dd><dt pn="section-5.1.2-5.9">G</dt> <dd pn="section-5.1.2-5.10"> is the<dt>G:</dt> <dd> The group generator (X(P),Y(P)). With X(P),Y(P) of edwards25519 as defined in <xreftarget="RFC8032" format="default" sectionFormat="of" derivedContent="RFC8032"/>.target="RFC8032"/>. </dd><dt pn="section-5.1.2-5.11">L</dt> <dd pn="section-5.1.2-5.12"> is the<dt>L:</dt> <dd> The order of the prime-order subgroup of edwards25519 as defined in <xreftarget="RFC8032" format="default" sectionFormat="of" derivedContent="RFC8032"/>.target="RFC8032"/>. </dd><dt pn="section-5.1.2-5.13">KeyGen()</dt> <dd pn="section-5.1.2-5.14"><dt>KeyGen():</dt> <dd> The generation of the private key d and the associated public keyzkzkey := a*Gwhere(where G is the group generator of the elliptic curve and a is an integer derived from d using the SHA-512 hashfunctionfunction) as defined inSection 5.1.5 of<xref target="RFC8032"format="default"sectionFormat="of"derivedContent="RFC8032"/>section="5.1.5"/> represents the KeyGen() function. </dd> </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. This means that a zTLD will always fit into a single label and does not need any further conversion. </t><t indent="0" pn="section-5.1.2-7"><t> The "EDKEY" ZKDF instantiation is based on <xreftarget="Tor224" format="default" sectionFormat="of" derivedContent="Tor224"/>. The calculation oftarget="Tor224"/>. As noted above for KeyGen(), a is calculated from d using the SHA-512 hash function as defined inSection 5.1.5 of<xref target="RFC8032"format="default"sectionFormat="of"derivedContent="RFC8032"/>.section="5.1.5"/>. Given a label, the output of the ZKDF function is calculated as follows: </t> <artwork name="" type=""align="left" alt="" pn="section-5.1.2-8"> ZKDF(zk,label):alt=""> ZKDF(zkey, label): /* Calculate the blinding factor */ PRK_h :=HKDF-Extract ("key-derivation", zk)HKDF-Extract("key-derivation", zkey) h :=HKDF-Expand (PRK_h,HKDF-Expand(PRK_h, label || "gns", 512 / 8) /* Ensure that h == h mod L */h[31] &= 7 zk'h := h mod L zkey' := h *zkzkey returnzk'zkey' </artwork><t indent="0" pn="section-5.1.2-9"><t> Implementers <bcp14>SHOULD</bcp14> employ aconstant timeconstant-time scalar multiplication for the constructions above to protect against timing attacks. Otherwise, timing attacks could leak private key material if an attacker can predict when a system starts the publication process.<!--Also, implementers <bcp14>MUST</bcp14> ensure that the private key a is an ed25519 private key and specifically that "a[0] & 7 == 0" holds.--></t><t indent="0" pn="section-5.1.2-10"><t> The EDKEY cryptosystem usesa hash-based key derivation function (HKDF)an HKDF as defined in <xreftarget="RFC5869" format="default" sectionFormat="of" derivedContent="RFC5869"/>,target="RFC5869"/>, using SHA-512 <xreftarget="RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/>target="RFC6234"/> for the extraction phase andHMAC-SHA256HMAC-SHA-256 <xreftarget="RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/>target="RFC6234"/> for the expansion phase. PRK_h is key material retrieved using an HKDFusingthat uses the string "key-derivation" as the salt and the zone key as the initial keying material. The blinding factor h is the 512-bit HKDF expansion result. The expansion information input is a concatenation of the label and the string "gns". The result of the HKDF must be clamped and interpreted in network byte order. a is the 256-bit integer corresponding to the 256-bit private key d. The multiplication ofzkzkey with h is a pointmultiplication, while the division and multiplication of a and a1 with the co-factor are integer operations.multiplication. </t><t indent="0" pn="section-5.1.2-11"><t> TheSign(d,message)Sign(d, message) andVerify(zk,message,signature)Verify(zkey, message, signature) procedures <bcp14>MUST</bcp14> be implemented as defined in <xreftarget="RFC8032" format="default" sectionFormat="of" derivedContent="RFC8032"/>.target="RFC8032"/>. </t><t indent="0" pn="section-5.1.2-12"><t> Signatures for EDKEY zones use a derived private scalard' whichd'; this is not compliant with <xreftarget="RFC8032" format="default" sectionFormat="of" derivedContent="RFC8032"/>.target="RFC8032"/>. As thecorrespondingprivate key that corresponds to the derived private scalar is not known, it is not possible to deterministically derive the signature part R according to <xreftarget="RFC8032" format="default" sectionFormat="of" derivedContent="RFC8032"/>.target="RFC8032"/>. Instead, signatures <bcp14>MUST</bcp14> be generated as follows for any given message and private zone key:Aa nonce is calculated from the highest 32 bytes of the expansion of the private key d and the blinding factor h. The nonce is then hashed with the message to r. This way, the full derivation path is included in the calculation of the R value of the signature, ensuring that it is never reused for two different derivation paths or messages. </t> <artwork name="" type=""align="left" alt="" pn="section-5.1.2-13"> SignDerived(d,label,message):alt=""> SignDerived(d, label, message): /* Key expansion */ dh :=SHA-512 (d)SHA-512(d) /* EdDSA clamping */ a := dh[0..31] a[0]&=:= a[0] & 248 a[31]&=:= a[31] & 127 a[31]|=:= a[31] | 64 /* Calculatezkzkey corresponding to d */zkzkey := a * G /* Calculate blinding factor */ PRK_h :=HKDF-Extract ("key-derivation", zk)HKDF-Extract("key-derivation", zkey) h :=HKDF-Expand (PRK_h,HKDF-Expand(PRK_h, label || "gns", 512 / 8) /* Ensure that h == h mod L */h[31] &= 7 zk' :=h* zk a1:=a >> 3 a2h mod L d' := (h *a1)a) mod Ld' := a2 << 3nonce :=SHA-256 (dh[32..63]SHA-256(dh[32..63] || h) r :=SHA-512 (nonceSHA-512(nonce || message) R := r * G S := r + SHA-512(R ||zk'zkey' || message) * d' mod L return (R,S) </artwork><t indent="0" pn="section-5.1.2-14"><t> A signature (R,S) is valid for the derived public key zkey' := ZKDF(zkey, label) if the following holds: </t> <artwork name="" type=""align="left" alt="" pn="section-5.1.2-15"> VerifyDerived(zk,label,message,signature): zk' := ZKDF(zk,label)alt=""> VerifyDerived(zkey', message, signature): (R,S) := signature return S * G == R + SHA-512(R,zk',zkey', message) *zk'zkey' </artwork><t indent="0" pn="section-5.1.2-16"><t> The S-Encrypt() and S-Decrypt() functions use XSalsa20 as defined in <xreftarget="XSalsa20" format="default" sectionFormat="of" derivedContent="XSalsa20"/> (XSalsa20-Poly1305):target="XSalsa20"/> and use the XSalsa20-Poly1305 encryption function: </t> <artwork name="" type=""align="left" alt="" pn="section-5.1.2-17"> S-Encrypt(zk,label,expiration,plaintext):alt=""> S-Encrypt(zkey, label, expiration, plaintext): PRK_k :=HKDF-Extract ("gns-xsalsa-ctx-key", zk)HKDF-Extract("gns-xsalsa-ctx-key", zkey) PRK_n :=HKDF-Extract ("gns-xsalsa-ctx-iv", zk)HKDF-Extract("gns-xsalsa-ctx-iv", zkey) K :=HKDF-Expand (PRK_k,HKDF-Expand(PRK_k, label, 256 / 8) NONCE :=HKDF-Expand (PRK_n,HKDF-Expand(PRK_n, label, 128 / 8) IV := NONCE || expiration 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)HKDF-Extract("gns-xsalsa-ctx-key", zkey) PRK_n :=HKDF-Extract ("gns-xsalsa-ctx-iv", zk)HKDF-Extract("gns-xsalsa-ctx-iv", zkey) K :=HKDF-Expand (PRK_k,HKDF-Expand(PRK_k, label, 256 / 8) NONCE :=HKDF-Expand (PRK_n,HKDF-Expand(PRK_n, label, 128 / 8) IV := NONCE || expiration return XSalsa20-Poly1305(K, IV, ciphertext) </artwork><t indent="0" pn="section-5.1.2-18"><t> The result of the XSalsa20-Poly1305 encryption function is the encrypted ciphertext followed by the 128-bit authentication tag. Accordingly, the length of encrypted data equals the length of the data plus the 16 bytes of the authentication tag. </t><t indent="0" pn="section-5.1.2-19"><t> The key K and counter IV are derived from the record label and the zone keyzkzkey usinga hash-based key derivation function (HKDF)an HKDF as defined in <xreftarget="RFC5869" format="default" sectionFormat="of" derivedContent="RFC5869"/>.target="RFC5869"/>. SHA-512 <xreftarget="RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/>target="RFC6234"/> is used for the extraction phase and SHA-256 <xreftarget="RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/>target="RFC6234"/> for the expansion phase. The output keying material is 32 bytes (256 bits) for the symmetric key and 16 bytes (128 bits) for the NONCE. The symmetric key K is a 256-bit XSalsa20 key <xreftarget="XSalsa20" format="default" sectionFormat="of" derivedContent="XSalsa20"/> key.target="XSalsa20"/>. No additional authenticated data (AAD) is used. </t><t indent="0" pn="section-5.1.2-20"><t> The nonce is combined with an8 byte initialization vector.8-byte IV. Theinitialization vectorIV is the expiration time of the resource record block in network byte order. The resulting counter (IV) wire format is illustrated in <xreftarget="figure_hkdf_ivs_edkey" format="default" sectionFormat="of" derivedContent="Figure 12"/>.target="figure_hkdf_ivs_edkey"/>. </t> <figureanchor="figure_hkdf_ivs_edkey" align="left" suppress-title="false" pn="figure-12"> <name slugifiedName="name-the-counter-block-initializ">Theanchor="figure_hkdf_ivs_edkey"> <name>The Counter Block InitializationVector.</name>Vector</name> <artwork name="" type=""align="left" alt="" pn="section-5.1.2-21.1">alt=""> 0 8 16 24 32+-----+-----+-----+-----+40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | NONCE | | || | | | +-----+-----+-----+-----++-----+-----+-----+-----+-----+-----+-----+-----+ | EXPIRATION || | +-----+-----+-----+-----++-----+-----+-----+-----+-----+-----+-----+-----+ </artwork> </figure> </section> </section> <sectionanchor="gnsrecords_redirect" numbered="true" toc="include" removeInRFC="false" pn="section-5.2"> <name slugifiedName="name-redirection-records">Redirectionanchor="gnsrecords_redirect"> <name>Redirection Records</name><t indent="0" pn="section-5.2-1"> Redirect<t> Redirection records are used to redirect resolution. Any implementation <bcp14>SHOULD</bcp14> support all redirection record types defined here and <bcp14>MAY</bcp14> support any number of additional redirection records defined in the GANA "GNS Record Types" registry <xreftarget="GANA" format="default" sectionFormat="of" derivedContent="GANA"/>.target="GANA"/>. Redirection records <bcp14>MUST</bcp14> have the CRITICAL flag set. Not supporting some record types can result in resolution failures. 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 support redirection to DNS for reasons such as complexity or security. Redirection records <bcp14>MUST NOT</bcp14> be storedandor published under the apex label. </t> <sectionanchor="gnsrecords_rdr" numbered="true" toc="include" removeInRFC="false" pn="section-5.2.1"> <name slugifiedName="name-redirect">REDIRECT</name> <t indent="0" pn="section-5.2.1-1">anchor="gnsrecords_rdr"> <name>REDIRECT</name> <t> A REDIRECT record is the GNS equivalent of a CNAME record in DNS. A REDIRECT record <bcp14>MUST</bcp14> be the only non-supplemental record under a label. There <bcp14>MAY</bcp14> be inactive records of the same typewhichthat have the SHADOW flag set in order to facilitate smooth changes of redirection targets. No other records are allowed. Details on the processing of this recordis definedare provided in <xreftarget="redirect_processing" format="default" sectionFormat="of" derivedContent="Section 7.3.1"/>.target="redirect_processing"/>. A REDIRECT DATA entry is illustrated in <xreftarget="figure_redirectrecord" format="default" sectionFormat="of" derivedContent="Figure 13"/>.target="figure_redirectrecord"/>. </t> <figureanchor="figure_redirectrecord" align="left" suppress-title="false" pn="figure-13"> <name slugifiedName="name-the-redirect-data-wire-form">Theanchor="figure_redirectrecord"> <name>The REDIRECT DATA WireFormat.</name>Format</name> <artwork name="" type=""align="left" alt="" pn="section-5.2.1-2.1">alt=""> 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | REDIRECT NAME | / / / / | | +-----+-----+-----+-----+-----+-----+-----+-----+ </artwork> </figure> <dlindent="3" newline="false" spacing="normal" pn="section-5.2.1-3"> <dt pn="section-5.2.1-3.1">REDIRECT NAME</dt> <dd pn="section-5.2.1-3.2">newline="false"> <dt>REDIRECT NAME:</dt> <dd> The name to continue with.TheThis valueof a redirect recordcan be a regularname,name or a relative name. Relative GNS names are indicated by an extension label(U+002B, "+")(U+002B ("+")) as the rightmost label. The string is UTF-8 encoded and0-terminated.zero terminated. </dd> </dl> </section> <sectionanchor="gnsrecords_gns2dns" numbered="true" toc="include" removeInRFC="false" pn="section-5.2.2"> <name slugifiedName="name-gns2dns">GNS2DNS</name> <t indent="0" pn="section-5.2.2-1">anchor="gnsrecords_gns2dns"> <name>GNS2DNS</name> <t> A GNS2DNS record delegates resolution to DNS. The resource record contains a DNS name for the resolver to continue with in DNS followed by a DNS server. Both names are in the format defined in <xreftarget="RFC1034" format="default" sectionFormat="of" derivedContent="RFC1034"/>target="RFC1034"/> for DNS names. 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 secure the connection with the DNS servers under the same label. There <bcp14>MAY</bcp14> be inactive records of the sametype(s) whichtype or types that have the SHADOW flag set in order to facilitate smooth changes of redirection targets. No other non-supplemental record types are allowed in the same record set. A GNS2DNS DATA entry is illustrated in <xreftarget="figure_gns2dnsrecord" format="default" sectionFormat="of" derivedContent="Figure 14"/>.</t>target="figure_gns2dnsrecord"/>.</t> <figureanchor="figure_gns2dnsrecord" align="left" suppress-title="false" pn="figure-14"> <name slugifiedName="name-the-gns2dns-data-wire-forma">Theanchor="figure_gns2dnsrecord"> <name>The GNS2DNS DATA WireFormat.</name>Format</name> <artwork name="" type=""align="left" alt="" pn="section-5.2.2-2.1">alt=""> 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | NAME | / / / / | | +-----+-----+-----+-----+-----+-----+-----+-----+ | DNS SERVER NAME | / / / / | | +-----------------------------------------------+ </artwork> </figure> <dlindent="3" newline="false" spacing="normal" pn="section-5.2.2-3"> <dt pn="section-5.2.2-3.1">NAME</dt> <dd pn="section-5.2.2-3.2">newline="false"> <dt>NAME:</dt> <dd> The name to continue with in DNS. The value is UTF-8 encoded and0-terminated.zero terminated. </dd><dt pn="section-5.2.2-3.3">DNS<dt>DNS SERVERNAME</dt> <dd pn="section-5.2.2-3.4">NAME:</dt> <dd> The DNS server to use. This value can be an IPv4 address in dotted-decimalform orform, an IPv6 address in colon-hexadecimalformform, or a DNS name. It can also be a relative GNS name ending with a "+" as the rightmost label. The implementation <bcp14>MUST</bcp14> check the string syntactically for an IP address in the respective notation before checking for a relative GNS name. If all three checks fail, the name <bcp14>MUST</bcp14> be treated as a DNS name. The value is UTF-8 encoded and0-terminated.zero terminated. </dd> </dl><t indent="0" pn="section-5.2.2-4"><t> NOTE: If an application uses DNS names obtained from GNS2DNS records in a DNSrequestrequest, they <bcp14>MUST</bcp14> first be converted to anIDNA compliantIDNA-compliant representation <xreftarget="RFC5890" format="default" sectionFormat="of" derivedContent="RFC5890"/>.target="RFC5890"/>. </t> </section> </section> <sectionanchor="gnsrecords_other" numbered="true" toc="include" removeInRFC="false" pn="section-5.3"> <name slugifiedName="name-auxiliary-records">Auxiliaryanchor="gnsrecords_other"> <name>Auxiliary Records</name><t indent="0" pn="section-5.3-1"><t> This section defines the initial set of auxiliary GNS record types. Any implementation <bcp14>SHOULD</bcp14> be able to process the specified record types according to <xreftarget="record_processing" format="default" sectionFormat="of" derivedContent="Section 7.3"/>.target="record_processing"/>. </t> <sectionanchor="gnsrecords_leho" numbered="true" toc="include" removeInRFC="false" pn="section-5.3.1"> <name slugifiedName="name-leho">LEHO</name> <t indent="0" pn="section-5.3.1-1"> Thisanchor="gnsrecords_leho"> <name>LEHO</name> <t> The LEHO (LEgacy HOstname) record is used to provide a hint forLEgacy HOstnames: Applicationslegacy hostnames: applications can use the GNS tolookuplook up IPv4 or IPv6 addresses ofinternetInternet services. However,sometimesconnecting to such servicesdoessometimes not onlyrequirerequires the knowledge of an IP address andport,port but also requires the canonical DNS name of the service to be transmitted over the transport protocol. In GNS, legacyhost namehostname records provide applications the DNS name that is required to establish a connection to such a service. The most common use case is HTTP virtual hosting and TLS Server Name Indication <xreftarget="RFC6066" format="default" sectionFormat="of" derivedContent="RFC6066"/>,target="RFC6066"/>, where a DNS name must be supplied in the HTTP "Host"-header and the TLS handshake, respectively. Using a GNS name in those cases might notworkwork, as it might not be globally unique. Furthermore, even if uniqueness is not an issue, the legacy service might not even be aware of GNS. </t><t indent="0" pn="section-5.3.1-2"><t> A LEHO resource record is expected to be found togetherin a singlewith A or AAAA resourcerecordrecords withanIPv4 or IPv6address.addresses. A LEHO DATA entry is illustrated in <xreftarget="figure_lehorecord" format="default" sectionFormat="of" derivedContent="Figure 15"/>.target="figure_lehorecord"/>. </t> <figureanchor="figure_lehorecord" align="left" suppress-title="false" pn="figure-15"> <name slugifiedName="name-the-leho-data-wire-format">Theanchor="figure_lehorecord"> <name>The LEHO DATA WireFormat.</name>Format</name> <artwork name="" type=""align="left" alt="" pn="section-5.3.1-3.1">alt=""> 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | LEGACY HOSTNAME | / / / / | | +-----+-----+-----+-----+-----+-----+-----+-----+ </artwork> </figure> <dlindent="3" newline="false" spacing="normal" pn="section-5.3.1-4"> <dt pn="section-5.3.1-4.1">LEGACY HOSTNAME</dt> <dd pn="section-5.3.1-4.2">newline="false"> <dt>LEGACY HOSTNAME:</dt> <dd> A UTF-8 string (which is not0-terminated)zero terminated) representing the legacy hostname. </dd> </dl><t indent="0" pn="section-5.3.1-5"><t> NOTE: If an application uses a LEHO value in an HTTP request header(e.g. "Host:" header)(e.g., a "Host"-header), it <bcp14>MUST</bcp14> be converted to anIDNA compliantIDNA-compliant representation <xreftarget="RFC5890" format="default" sectionFormat="of" derivedContent="RFC5890"/>.target="RFC5890"/>. </t> </section> <sectionanchor="gnsrecords_nick" numbered="true" toc="include" removeInRFC="false" pn="section-5.3.2"> <name slugifiedName="name-nick">NICK</name> <t indent="0" pn="section-5.3.2-1">anchor="gnsrecords_nick"> <name>NICK</name> <t> Nickname records can be used by zone administrators to publish a label that a zone prefers to have used when it is referred to. This is a suggestiontofor other zones regarding what label to use when creating a delegation record (<xreftarget="gnsrecords_delegation" format="default" sectionFormat="of" derivedContent="Section 5.1"/>)target="gnsrecords_delegation"/>) containing this zone key. This record <bcp14>SHOULD</bcp14> only be stored locally under the apex label "@" but <bcp14>MAY</bcp14> be returned with record sets under any label as a supplemental record. <xreftarget="nick_processing" format="default" sectionFormat="of" derivedContent="Section 7.3.5"/>target="nick_processing"/> details how a resolver must process supplemental and non-supplemental NICK records. A NICK DATA entry is illustrated in <xreftarget="figure_nickrecord" format="default" sectionFormat="of" derivedContent="Figure 16"/>.target="figure_nickrecord"/>. </t> <figureanchor="figure_nickrecord" align="left" suppress-title="false" pn="figure-16"> <name slugifiedName="name-the-nick-data-wire-format">Theanchor="figure_nickrecord"> <name>The NICK DATA WireFormat.</name>Format</name> <artwork name="" type=""align="left" alt="" pn="section-5.3.2-2.1">alt=""> 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | NICKNAME | / / / / | | +-----+-----+-----+-----+-----+-----+-----+-----+ </artwork> </figure> <dlindent="3" newline="false" spacing="normal" pn="section-5.3.2-3"> <dt pn="section-5.3.2-3.1">NICKNAME</dt> <dd pn="section-5.3.2-3.2">newline="false"> <dt>NICKNAME:</dt> <dd> A UTF-8 string (which is not0-terminated)zero terminated) representing the preferred label of the zone. This string <bcp14>MUST</bcp14> be a valid GNS label. </dd> </dl> </section> <sectionanchor="gnsrecords_box" numbered="true" toc="include" removeInRFC="false" pn="section-5.3.3"> <name slugifiedName="name-box">BOX</name> <t indent="0" pn="section-5.3.3-1">anchor="gnsrecords_box"> <name>BOX</name> <t> GNS lookups are expected to return all of the required useful information in one record set. This avoids unnecessary additional lookups and cryptographically ties together information that belongs together, making it impossible for an adversarial storage entity to provide partial answers that might omit information critical for security. </t><t indent="0" pn="section-5.3.3-2"><t> This general strategy is incompatible with the 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 include them in the record set of the label they are associated with. For example, a 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(https), protocol (PROTO) 6(tcp)(tcp), and record TYPE "TLSA". For reference, see also <xreftarget="RFC2782" format="default" sectionFormat="of" derivedContent="RFC2782"/>.target="RFC2782"/>. A BOX DATA entry is illustrated in <xreftarget="figure_boxrecord" format="default" sectionFormat="of" derivedContent="Figure 17"/>.target="figure_boxrecord"/>. </t> <figureanchor="figure_boxrecord" align="left" suppress-title="false" pn="figure-17"> <name slugifiedName="name-the-box-data-wire-format">Theanchor="figure_boxrecord"> <name>The BOX DATA WireFormat.</name>Format</name> <artwork name="" type=""align="left" alt="" pn="section-5.3.3-3.1">alt=""> 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | PROTO | SVC | TYPE | +-----------+-----------------------------------+ | RECORD DATA | / / / / | | +-----+-----+-----+-----+-----+-----+-----+-----+ </artwork> </figure> <dlindent="3" newline="false" spacing="normal" pn="section-5.3.3-4"> <dt pn="section-5.3.3-4.1">PROTO</dt> <dd pn="section-5.3.3-4.2"> thenewline="false"> <dt>PROTO:</dt> <dd> The 16-bit protocol number in network byte order. Values below2^82<sup>8</sup> are reserved for 8-bit Internet Protocol numbers allocated by IANA <xreftarget="RFC5237" format="default" sectionFormat="of" derivedContent="RFC5237"/> (e.g.target="RFC5237"/> (e.g., 6 for TCP). Values above2^82<sup>8</sup> are allocated by the GANA"Overlay"GNUnet Overlay Protocols" registry <xreftarget="GANA" format="default" sectionFormat="of" derivedContent="GANA"/>.target="GANA"/>. </dd><dt pn="section-5.3.3-4.3">SVC</dt> <dd pn="section-5.3.3-4.4"> the<dt>SVC:</dt> <dd> The 16-bit service value of the boxed record in network byte order. In the case of TCP andUDPUDP, it is the port number. </dd><dt pn="section-5.3.3-4.5">TYPE</dt> <dd pn="section-5.3.3-4.6"> is the<dt>TYPE:</dt> <dd> The 32-bit record type of the boxed record in network byte order. </dd><dt pn="section-5.3.3-4.7">RECORD DATA</dt> <dd pn="section-5.3.3-4.8"> is a variable length<dt>RECORD DATA:</dt> <dd> A variable-length field containing the "DATA" format of TYPE as defined for the respective TYPE. Thus, for TYPE values below2^16,2<sup>16</sup>, the format is the same as the respective record type's binary format in DNS. </dd> </dl> </section> </section> </section> <sectionanchor="publish" numbered="true" toc="include" removeInRFC="false" pn="section-6"> <name slugifiedName="name-record-encoding-for-remote-">Recordanchor="publish"> <name>Record Encoding for Remote Storage</name><t indent="0" pn="section-6-1"><t> Any APIwhichthat 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. To be useful,the API <bcp14>MUST</bcp14> permit storing at least 176 byte blocksand to be able to support the defined zone delegation record encodings, the API <bcp14>MUST</bcp14> permit storing blocks of size 176 bytes or more and <bcp14>SHOULD</bcp14> allowat leastblocks of size 1024byte blocks.bytes or more. In the following, it is assumed that an implementation realizes two procedures on top ofastorage: </t> <artwork name="" type=""align="left" alt="" pn="section-6-2"> PUT(key,block)alt=""> PUT(key, block) GET(key) -> block </artwork><t indent="0" pn="section-6-3"><t> A GNS implementation publishes blocks in accordancetowith the properties and recommendations of the underlying remote storage. This can include a periodic refresh operation to preserve the availability of published blocks. </t><t indent="0" pn="section-6-4"><t> There is no mechanismtofor explicitlydeletedeleting individual blocks from remote storage. However, blocks include an EXPIRATIONfieldfield, which guides remote storage implementations to decide when to delete blocks. Given multiple blocks for the same key, remote storage implementations <bcp14>SHOULD</bcp14> try to preserve and return the block with the largest EXPIRATION value. </t><t indent="0" pn="section-6-5"><t> All resource records from the same zone sharing the same label are encrypted and published together in a single resourcerecordsrecord block (RRBLOCK) in the remote storage under a keyqq, as illustrated in <xreftarget="figure_storage_publish" format="default" sectionFormat="of" derivedContent="Figure 18"/>.target="figure_storage_publish"/>. A GNS implementation <bcp14>MUST NOT</bcp14> include expired resource records in blocks. An implementation <bcp14>MUST</bcp14> use the PUT storage procedure when record sets change to update the zone contents. Implementations <bcp14>MUST</bcp14> ensure that the EXPIRATION fields of RRBLOCKsincreasesincrease strictly monotonically for every change, even if the smallest expiration time of records in the block doesnot.not increase. </t> <figureanchor="figure_storage_publish" align="left" suppress-title="false" pn="figure-18"> <name slugifiedName="name-management-and-publication-">Managementanchor="figure_storage_publish"> <name>Management andpublicationPublication oflocal zonesLocal Zones inthe distributed storage.</name>Distributed Storage</name> <artwork name="" type=""align="left" alt="" pn="section-6-6.1">alt=""> Local Host | Remote | Storage | | +---------+ | / /| | +---------+ | +-----------+ | | | | | |+---------+PUT(q,+-----------+PUT(q, RRBLOCK) | | Record | | | User | | Zone |----------------|->| Storage | | | | |MasterPublisher | | | |/ +-----------++---------++-----------+ | +---------+ | A | | | Zone records | | | grouped by label | | | | | +---------+ | |Create / Delete / | /| | |and Update +---------+ | | |Local Zones | | | | | | Local | | | +-------------->| Zones | | | | |/ | +---------+ | </artwork> </figure><t indent="0" pn="section-6-7"> The storage<t> Storage key derivation andrecordsrecord block creationisare specified in the following sections and illustrated in <xreftarget="figure_storage_derivations" format="default" sectionFormat="of" derivedContent="Figure 19"/>.target="figure_storage_derivations"/>. </t> <figureanchor="figure_storage_derivations" align="left" suppress-title="false" pn="figure-19"> <name slugifiedName="name-storage-key-and-records-blo">Storage keyanchor="figure_storage_derivations"> <name>Storage Key andrecords block creation overview.</name>Record Block Creation Overview</name> <artwork name="" type=""align="left" alt="" pn="section-6-8.1">alt=""> +----------+ +-------+ +------------+ +-------------+ | Zone Key | | Label | | Record Set | | Private Key | +----------+ +-------+ +------------+ +-------------+ | | | | | | v | | | +-----------+ | | +---------->| S-Encrypt | | +----------|---------->+-----------+ | | | | | | | | | v v | | | +-------------+ | +---------------|-->| SignDerived | | | | +-------------+ | | | | | v v v | +------++---------------++--------------+ +----->| ZKDF |------->|RecordsRecord Block | +------++---------------++--------------+ | v +------+ +-------------+ | Hash |------->| Storage Key | +------+ +-------------+ </artwork> </figure> <sectionanchor="blinding" numbered="true" toc="include" removeInRFC="false" pn="section-6.1"> <name slugifiedName="name-the-storage-key">Theanchor="blinding"> <name>The Storage Key</name><t indent="0" pn="section-6.1-1"><t> The storage key is derived from the zone key and the respective label of the contained records. The required knowledge of both the zone key and the label in combination with the similarly derived symmetric secret keys and blinded zone keys ensures query privacy (see <xref target="RFC8324"format="default" sectionFormat="of" derivedContent="RFC8324"/>, Section 3.5). </t> <t indent="0" pn="section-6.1-2">sectionFormat="comma" section="3.5"/>). </t> <t> Given a label, the storage key q is derived as follows: </t> <artwork name="" type=""align="left" alt="" pn="section-6.1-3">alt=""> q :=SHA-512 (ZKDF(zk,SHA-512(ZKDF(zkey, label)) </artwork> <dlindent="3" newline="false" spacing="normal" pn="section-6.1-4"> <dt pn="section-6.1-4.1">label</dt> <dd pn="section-6.1-4.2">is anewline="false"> <dt>label:</dt> <dd>A UTF-8 string under which the resource records are published. </dd><dt pn="section-6.1-4.3">zk</dt> <dd pn="section-6.1-4.4"> is the<dt>zkey:</dt> <dd> The zone key. </dd><dt pn="section-6.1-4.5">q</dt> <dd pn="section-6.1-4.6"> Is the<dt>q:</dt> <dd> The 512-bit storage key under which the resourcerecordsrecord block is published. It is the SHA-512 hash <xreftarget="RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/>target="RFC6234"/> over the derived zone key. </dd> </dl> </section> <sectionanchor="rdata" numbered="true" toc="include" removeInRFC="false" pn="section-6.2"> <name slugifiedName="name-plaintext-record-data-rdata">Plaintextanchor="rdata"> <name>Plaintext Record Data (RDATA)</name><t indent="0" pn="section-6.2-1"><t> GNS records from a zone are grouped by their labels such that all records under the same label are published together as a single block inthestorage. Such grouped record sets <bcp14>MAY</bcp14> be paired with supplemental records. </t><t indent="0" pn="section-6.2-2"><t> Record data (RDATA) is the format used to encode such a group of GNS records. The binary format of RDATA is illustrated in <xreftarget="figure_rdata" format="default" sectionFormat="of" derivedContent="Figure 20"/>.target="figure_rdata"/>. </t> <figureanchor="figure_rdata" align="left" suppress-title="false" pn="figure-20"> <name slugifiedName="name-the-rdata-wire-format">Theanchor="figure_rdata"> <name>The RDATA WireFormat.</name>Format</name> <artwork name="" type=""align="left" alt="" pn="section-6.2-3.1">alt=""> 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | EXPIRATION | +-----+-----+-----+-----+-----+-----+-----+-----+ | SIZE | FLAGS | TYPE | +-----+-----+-----+-----+-----+-----+-----+-----+ | DATA / / / / / +-----+-----+-----+-----+-----+-----+-----+-----+ | EXPIRATION | +-----+-----+-----+-----+-----+-----+-----+-----+ | SIZE | FLAGS | TYPE | +-----+-----+-----+-----+-----+-----+-----+-----+ | DATA / / / +-----+-----+-----+-----+-----+-----+-----+-----+/| PADDING / / / +-----+-----+-----+-----+-----+-----+-----+-----+ </artwork> </figure> <dlindent="3" newline="false" spacing="normal" pn="section-6.2-4"> <dt pn="section-6.2-4.1">EXPIRATION,newline="false"> <dt>EXPIRATION, SIZE, TYPE,FLAGSFLAGS, andDATA</dt> <dd pn="section-6.2-4.2"> TheseDATA:</dt> <dd> Definitions for these fieldswere defined in the resource record formatare provided below <xref target="figure_gnsrecord"/> in <xreftarget="rrecords" format="default" sectionFormat="of" derivedContent="Section 5"/>.target="rrecords"/>. </dd><dt pn="section-6.2-4.3">PADDING</dt> <dd pn="section-6.2-4.4"><dt>PADDING:</dt> <dd> When serializing records into RDATA, a GNS implementation <bcp14>MUST</bcp14> ensure that the size of the RDATA is a power of two usingthe paddingthis field. The field <bcp14>MUST</bcp14> be set to zero and <bcp14>MUST</bcp14> be ignored on receipt. As a special exception, record sets with (only) a zone delegation record type are never padded. </dd> </dl> </section> <sectionanchor="records_block" numbered="true" toc="include" removeInRFC="false" pn="section-6.3"> <name slugifiedName="name-the-resource-records-block">Theanchor="records_block"> <name>The ResourceRecordsRecord Block</name><t indent="0" pn="section-6.3-1"><t> The resource records grouped in an RDATA are encrypted using the S-Encrypt() function defined by the zone type of the zone to which the resource records belong and prefixed withmeta datametadata into a resource record block (RRBLOCK) for remote storage. The GNS RRBLOCK wire format is illustrated in <xreftarget="figure_record_block" format="default" sectionFormat="of" derivedContent="Figure 21"/>.target="figure_record_block"/>. </t> <figureanchor="figure_record_block" align="left" suppress-title="false" pn="figure-21"> <name slugifiedName="name-the-rrblock-wire-format">Theanchor="figure_record_block"> <name>The RRBLOCK WireFormat.</name>Format</name> <artwork name="" type=""align="left" alt="" pn="section-6.3-2.1">alt=""> 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | SIZE | ZONE TYPE | +-----+-----+-----+-----+-----+-----+-----+-----+/| ZONE KEY / / (BLINDED) / | | +-----+-----+-----+-----+-----+-----+-----+-----+ | SIGNATURE | / / / / | | +-----+-----+-----+-----+-----+-----+-----+-----+ | EXPIRATION | +-----+-----+-----+-----+-----+-----+-----+-----+ | BDATA | / / / /|+-----+-----+-----+-----+-----+-----+-----+-----+ </artwork> </figure> <dlindent="3" newline="false" spacing="normal" pn="section-6.3-3"> <dt pn="section-6.3-3.1">SIZE</dt> <dd pn="section-6.3-3.2">newline="false"> <dt>SIZE:</dt> <dd> 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, implementations <bcp14>MAY</bcp14> refuse to publish blocks beyond a certain size significantly below the theoretical block size limit of 4 GB. </dd><dt pn="section-6.3-3.3">ZONE TYPE</dt> <dd pn="section-6.3-3.4"> is the<dt>ZONE TYPE:</dt> <dd> The 32-bit ztype in network byte order. </dd><dt pn="section-6.3-3.5">ZONE<dt>ZONE KEY(BLINDED)</dt> <dd pn="section-6.3-3.6"> is the(BLINDED):</dt> <dd> The blinded zone key"ZKDF(zk,"ZKDF(zkey, label)" to be used to verify SIGNATURE. The length and format of the blinded public keydependsdepend on the ztype. </dd><dt pn="section-6.3-3.7">SIGNATURE</dt> <dd pn="section-6.3-3.8"><dt>SIGNATURE:</dt> <dd> The signature is computed over the EXPIRATION and BDATA fields asdetailedshown in <xreftarget="figure_rrsigwithpseudo" format="default" sectionFormat="of" derivedContent="Figure 22"/>.target="figure_rrsigwithpseudo"/>. The length and format of the signaturedependsdepend on the ztype. The signature is created using the SignDerived() function of the cryptosystem of the zone (see <xreftarget="zones" format="default" sectionFormat="of" derivedContent="Section 4"/>).target="zones"/>). </dd><dt pn="section-6.3-3.9">EXPIRATION</dt> <dd pn="section-6.3-3.10"><dt>EXPIRATION:</dt> <dd> Specifies when the RRBLOCK expires and the encrypted block <bcp14>SHOULD</bcp14> be removed fromthestorage andcachescaches, as it is likely stale. However, applications <bcp14>MAY</bcp14> continue to use non-expired individual records until they expire. The RRBLOCK expiration value <bcp14>MUST</bcp14> beset tocomputed by first determining for each record type present in themaximum ofRRBLOCK the maximum expiration time of all records of that type, including shadow records. Then, theresource record contained within this block with the smallestminimum of all of these expiration times is taken. The final expiration timeandis then the larger value of (1) the previous EXPIRATION value(if any)of a previous RRBLOCK for the same storage key plus oneto ensure strict monotonicity (see <xref target="security_cryptography" format="default" sectionFormat="of" derivedContent="Section 9.3"/>). If the RDATA includes shadow records, then the maximum expiration time of all shadow records with matching type(if any) and (2) the computed minimum expirationtimes oftime across thenon-shadow records is considered.contained record types. This ensures strict monotonicity (see <xref target="security_cryptography"/>). This is a 64-bit absolute date in microseconds since midnight (0 hour), January 1, 1970 UTC in network byte order. </dd><dt pn="section-6.3-3.11">BDATA</dt> <dd pn="section-6.3-3.12"><dt>BDATA:</dt> <dd> The encrypted RDATA computed using S-Encrypt() with the zone key,labellabel, and expiration time as additional inputs. Its ultimate size and content are determined by the S-Encrypt() function of the ztype. </dd> </dl><t indent="0" pn="section-6.3-4"><t> The signature over the public key covers a 32-bit pseudo header conceptually prefixed to the EXPIRATION andtheBDATA fields. The wire format is illustrated in <xreftarget="figure_rrsigwithpseudo" format="default" sectionFormat="of" derivedContent="Figure 22"/>.target="figure_rrsigwithpseudo"/>. </t> <figureanchor="figure_rrsigwithpseudo" align="left" suppress-title="false" pn="figure-22"> <name slugifiedName="name-the-wire-format-used-for-cr">Theanchor="figure_rrsigwithpseudo"> <name>The Wire FormatusedUsed forcreatingCreating thesignatureSignature of theRRBLOCK.</name>RRBLOCK</name> <artwork name="" type=""align="left" alt="" pn="section-6.3-5.1">alt=""> 0 8 16 24 32 40 48 56 +-----+-----+-----+-----+-----+-----+-----+-----+ | SIZE | PURPOSE (0x0F) | +-----+-----+-----+-----+-----+-----+-----+-----+ | EXPIRATION | +-----+-----+-----+-----+-----+-----+-----+-----+ | BDATA | / / / / +-----+-----+-----+-----+-----+-----+-----+-----+ </artwork> </figure> <dlindent="3" newline="false" spacing="normal" pn="section-6.3-6"> <dt pn="section-6.3-6.1">SIZE</dt> <dd pn="section-6.3-6.2">newline="false"> <dt>SIZE:</dt> <dd> A 32-bit value containing the length of the signed data in bytes in network byte order. </dd><dt pn="section-6.3-6.3">PURPOSE</dt> <dd pn="section-6.3-6.4"><dt>PURPOSE:</dt> <dd> A 32-bit signature purpose flag in network byte order. The value of this 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 of the protocolincludingthat might include possible future extensions. The value of this field corresponds to an entry in the GANA "GNUnet SignaturePurpose"Purposes" registry <xreftarget="GANA" format="default" sectionFormat="of" derivedContent="GANA"/>.target="GANA"/>. </dd><dt pn="section-6.3-6.5">EXPIRATION</dt> <dd pn="section-6.3-6.6"><dt>EXPIRATION:</dt> <dd> Field as defined in the RRBLOCK message above. </dd><dt pn="section-6.3-6.7">BDATA</dt> <dd pn="section-6.3-6.8">Field<dt>BDATA:</dt> <dd>Field as defined in the RRBLOCK message above.</dd> </dl> </section> </section> <sectionanchor="resolution" numbered="true" toc="include" removeInRFC="false" pn="section-7"> <name slugifiedName="name-name-resolution">Nameanchor="resolution"> <name>Name Resolution</name><t indent="0" pn="section-7-1"><t> Names in GNS are resolved by recursively querying the record storage. Recursive in this context means that a resolver does not provide intermediate results for a query to the application. Instead, it <bcp14>MUST</bcp14> respond to a resolution request with either the requested resource record or an error messagein caseif resolution fails. <xreftarget="figure_resolution" format="default" sectionFormat="of" derivedContent="Figure 23"/>target="figure_resolution"/> illustrates how an application requests the lookup of a GNS name (1). The application <bcp14>MAY</bcp14> provide a desired record type to the resolver. Subsequently, a Start Zone is determined (2) and the recursive resolution process started. This is where the desired record type is used to guide processing. For example, if a zone delegation record type is requested, the resolution of the apex label in that zone must be skipped, as the desired record is already found. Details on how the resolution process is initiated and each iterative result (3a,3b) in the resolution is processed are provided in the sections below. The results of the lookup are eventually returned to the application (4). The implementation <bcp14>MUST NOT</bcp14> filter the returned resource record sets according to the desired record type. Filtering of record sets is typically done by the application. </t> <figureanchor="figure_resolution" align="left" suppress-title="false" pn="figure-23"> <name slugifiedName="name-the-recursive-gns-resolutio">The recursiveanchor="figure_resolution"> <name>The Recursive GNSresolution process.</name>Resolution Process</name> <artwork name="" type=""align="left" alt="" pn="section-7-2.1">alt=""> Local Host | Remote | Storage | | +---------+ | / /| | +---------+ | +-----------+ (1) Name +----------+ | | | | | | Lookup | | (3a) GET(q) | | Record | | |Application|----------| Resolver |---------------|->| Storage | | | |<---------| |<--------------|--| |/ +-----------+ (4) +----------+ (3b) RRBLOCK | +---------+ Records A | | | (2) Determination of | | Start Zone | | | | +---------+ | / | /| | +---------+ | | | | | | | Start | | | | Zones | | | | |/ | +---------+ | </artwork> </figure> <sectionanchor="governance" numbered="true" toc="include" removeInRFC="false" pn="section-7.1"> <name slugifiedName="name-start-zones">Startanchor="governance"> <name>Start Zones</name><t indent="0" pn="section-7.1-1"><t> The resolution of a GNS name starts by identifying thestart zoneStart Zone suffix. Once thestart zoneStart Zone suffix is identified, recursive resolution of the remainder of the name is initiated (see <xreftarget="recursion" format="default" sectionFormat="of" derivedContent="Section 7.2"/>).target="recursion"/>). There are two types ofstart zoneStart Zone suffixes: zTLDs and local suffix-to-zone mappings. The choice of available suffix-to-zone mappings is at the sole discretion of the local system administrator or user. This property addresses the issue of a single hierarchy with a centrally controlled root and the related issue of distribution and management of root servers in DNS (see Sections <xref target="RFC8324" section="3.12" sectionFormat="bare"/> and <xref target="RFC8324"format="default" sectionFormat="of" derivedContent="RFC8324"/>, Sections 3.10 and 3.12). </t> <t indent="0" pn="section-7.1-2">section="3.10" sectionFormat="bare"/> of <xref target="RFC8324"/>, respectively). </t> <t> For names ending with azTLDzTLD, thestart zoneStart Zone is explicitly given in the suffix of the name to resolve. In order to ensure uniqueness of names withzTLDszTLDs, any implementation <bcp14>MUST</bcp14> use the given zone asstart zone.the Start Zone. An implementation <bcp14>MUST</bcp14> first try to interpret the rightmost label of the given name as the beginning of a zTLD (see <xreftarget="zTLD" format="default" sectionFormat="of" derivedContent="Section 4.1"/>).target="zTLD"/>). 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 andstart zoneStart Zone discovery <bcp14>MUST</bcp14> continue with finding a local suffix-to-zone mapping. If a valid ztype can be found in the rightmost label, the implementation <bcp14>MUST</bcp14> try to synthesize and decode the zTLD to retrieve thestart zoneStart Zone key according to <xreftarget="zTLD" format="default" sectionFormat="of" derivedContent="Section 4.1"/>.target="zTLD"/>. If the zTLD cannot be synthesized or decoded, the resolution of the name fails and an error is returned to the application. Otherwise, the zone key <bcp14>MUST</bcp14> be used as thestart zone:Start Zone: </t> <artwork name="" type=""align="left" alt="" pn="section-7.1-3">alt=""> Example name: www.example.<zTLD> => Startzone: zkZone: zkey of type ztype => Name to resolve fromstart zone:Start Zone: www.example </artwork><t indent="0" pn="section-7.1-4"><t> For names not ending with azTLDzTLD, the resolver <bcp14>MUST</bcp14> determine thestart zoneStart Zone through a local suffix-to-zone mapping. Suffix-to-zone mappings <bcp14>MUST</bcp14> be configurable through a local configuration file or database by the user or system administrator. A suffix <bcp14>MAY</bcp14> consist of multiple GNS labels concatenated with a label separator. If multiple suffixes match the name to resolve, the longest matching suffix <bcp14>MUST</bcp14> be used. The suffix length of two results <bcp14>MUST NOT</bcp14> be equal. This indicates amisconfigurationmisconfiguration, and the implementation <bcp14>MUST</bcp14> return an error. The following is a non-normative example mapping ofstart zones:Start Zones: </t> <artwork name="" type=""align="left" alt="" pn="section-7.1-5">alt=""> Example name: www.example.xyz.gns.alt Local suffix mappings: xyz.gns.alt = zTLD0 :=Base32GNS(ztype0||zk0)Base32GNS(ztype0||zkey0) example.xyz.gns.alt = zTLD1 :=Base32GNS(ztype1||zk1)Base32GNS(ztype1||zkey1) example.com.gns.alt = zTLD2 :=Base32GNS(ztype2||zk2)Base32GNS(ztype2||zkey2) ... => Startzone: zk1Zone: zkey1 => Name to resolve fromstart zone:Start Zone: www </artwork><t indent="0" pn="section-7.1-6"><t> The process given above <bcp14>MAY</bcp14> be supplemented with other mechanisms if the particular application requires a different process. If nostart zoneStart Zone can bediscovered,identified, resolution <bcp14>MUST</bcp14> fail and an error <bcp14>MUST</bcp14> be returned to the application. </t> </section> <sectionanchor="recursion" numbered="true" toc="include" removeInRFC="false" pn="section-7.2"> <name slugifiedName="name-recursion">Recursion</name> <t indent="0" pn="section-7.2-1">anchor="recursion"> <name>Recursion</name> <t> In each step of the recursive name resolution, there is an authoritative zonezkzkey and a name to resolve. The name <bcp14>MAY</bcp14> be empty. If the name is empty, it is interpreted as the apex label "@". Initially, the authoritative zone is thestart zone.Start Zone. </t><t indent="0" pn="section-7.2-2"><t> From here, the following steps are recursively executed, in order: </t><ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-7.2-3"> <li pn="section-7.2-3.1" derivedCounter="1.">Extract<ol> <li>Extract theright-mostrightmost label from the name to look up.</li><li pn="section-7.2-3.2" derivedCounter="2.">Calculate<li>Calculate q using the label andzkzkey as defined in <xreftarget="blinding" format="default" sectionFormat="of" derivedContent="Section 6.1"/>.</li> <li pn="section-7.2-3.3" derivedCounter="3.">Performtarget="blinding"/>.</li> <li>Perform a storage query GET(q) to retrieve the RRBLOCK.</li><li pn="section-7.2-3.4" derivedCounter="4.">Check<li>Check that (a) the block is not expired, (b) the SHA-512 hash of the derived authoritative zone keyzk'zkey' from the RRBLOCK matches the query q, and (c) the signature is valid. If any of these tests fail, the RRBLOCK <bcp14>MUST</bcp14> be ignored and, if applicable, the storage lookup GET(q) <bcp14>MUST</bcp14> continue to look for other RRBLOCKs.</li><li pn="section-7.2-3.5" derivedCounter="5.">Obtain<li>Obtain the RDATA by decrypting the BDATA contained in the RRBLOCK using S-Decrypt() as defined by the zone type, effectively inverting the process described in <xreftarget="records_block" format="default" sectionFormat="of" derivedContent="Section 6.3"/>.</li>target="records_block"/>.</li> </ol><t indent="0" pn="section-7.2-4"><t> Once a well-formed block has been decrypted, the records from RDATA are subjected to record processing. </t> </section> <sectionanchor="record_processing" numbered="true" toc="include" removeInRFC="false" pn="section-7.3"> <name slugifiedName="name-record-processing">Recordanchor="record_processing"> <name>Record Processing</name><t indent="0" pn="section-7.3-1"><t> In record processing, only the valid records obtained are considered. To filter records by validity, the resolver <bcp14>MUST</bcp14> at least check the expiration time and the FLAGS field of the respective record. Specifically, the resolver <bcp14>MUST</bcp14> disregard expired records. Furthermore, SHADOW and SUPPLEMENTAL flags can also exclude records from being considered. If the resolver encounters a record with the CRITICAL flag set and does not support the recordtypetype, the resolution <bcp14>MUST</bcp14> be aborted and an error <bcp14>MUST</bcp14> be returned.The informationInformation indicating that the critical record could not be processed <bcp14>SHOULD</bcp14> be returned in the error description. The implementation <bcp14>MAY</bcp14> choose not to return the reason for the failure, merely complicating troubleshooting for the user. </t><t indent="0" pn="section-7.3-2"><t> The next steps depend on the context of the name that is being resolved: </t><ul bare="false" empty="false" indent="3" spacing="normal" pn="section-7.3-3"> <li pn="section-7.3-3.1"> Case 1: If<dl newline="false"> <dt>Case 1:</dt> <dd>If the filtered record set consists of a single REDIRECT record, the remainder of the name is prepended to the REDIRECTdataDATA and the recursion is started again from the resulting name. Details aredescribedprovided in <xreftarget="redirect_processing" format="default" sectionFormat="of" derivedContent="Section 7.3.1"/>. </li> <li pn="section-7.3-3.2"> Case 2: Iftarget="redirect_processing"/>.</dd> <dt>Case 2:</dt> <dd>If the filtered record set consists exclusively of one or more GNS2DNSrecordsrecords, resolution continues with DNS. Details aredescribedprovided in <xreftarget="gns2dns_processing" format="default" sectionFormat="of" derivedContent="Section 7.3.2"/>. </li> <li pn="section-7.3-3.3"> Case 3: Iftarget="gns2dns_processing"/>.</dd> <dt>Case 3:</dt> <dd>If the remainder of the name to be resolved is of the format "_SERVICE._PROTO" and the record set contains one or more matching BOX records, the records in the BOX records are the final result and the recursion is concluded as described in <xreftarget="box_processing" format="default" sectionFormat="of" derivedContent="Section 7.3.3"/>. </li> <li pn="section-7.3-3.4"> Case 4: Iftarget="box_processing"/>.</dd> <dt>Case 4:</dt> <dd>If the current record setconsistconsists of a single delegation record, resolution of the remainder of the name is delegated to the target zone as described in <xreftarget="delegation_processing" format="default" sectionFormat="of" derivedContent="Section 7.3.4"/>. </li> <li pn="section-7.3-3.5"> Case 5: Iftarget="delegation_processing"/>.</dd> <dt>Case 5:</dt> <dd>If the remainder of the name to resolve isemptyempty, the record set is the final result. If any NICK records are in the final result set, they <bcp14>MUST</bcp14> first be processed according to <xreftarget="nick_processing" format="default" sectionFormat="of" derivedContent="Section 7.3.5"/>.target="nick_processing"/>. Otherwise, the record result set is directly returned as the finalresult. </li> <li pn="section-7.3-3.6"> Finally,result.</dd> </dl> <t>Finally, if none of the aboveiscases are applicable, resolution fails and the resolver <bcp14>MUST</bcp14> return an empty recordset. </li> </ul>set.</t> <sectionanchor="redirect_processing" numbered="true" toc="include" removeInRFC="false" pn="section-7.3.1"> <name slugifiedName="name-redirect-2">REDIRECT</name> <t indent="0" pn="section-7.3.1-1">anchor="redirect_processing"> <name>REDIRECT</name> <t> If the remaining name is empty and the desired record type is REDIRECT,in which casethe resolution concludes with the REDIRECT record. If the rightmost label of theredirect nameREDIRECT NAME is the extension label(U+002B, "+"),(U+002B ("+")), resolution continues in GNS with the new name in the current zone. Otherwise, the resulting name is resolved via the default operating system name resolution process. This can in turn trigger a GNS name resolutionprocessprocess, depending on the system configuration.In caseIf resolution continues in DNS, the name <bcp14>MUST</bcp14> first be converted to anIDNA compliantIDNA-compliant representation <xreftarget="RFC5890" format="default" sectionFormat="of" derivedContent="RFC5890"/>.target="RFC5890"/>. </t><t indent="0" pn="section-7.3.1-2"><t> In order to prevent infinite loops, the resolver <bcp14>MUST</bcp14> implement loop detection or limit the number of recursive resolution steps. The loop detection <bcp14>MUST</bcp14> be effective even if a REDIRECT found in GNS triggers subsequent GNS lookups via the default operating system name resolution process. </t> </section> <sectionanchor="gns2dns_processing" numbered="true" toc="include" removeInRFC="false" pn="section-7.3.2"> <name slugifiedName="name-gns2dns-2">GNS2DNS</name> <t indent="0" pn="section-7.3.2-1"> When aanchor="gns2dns_processing"> <name>GNS2DNS</name> <t> A resolver returns GNS2DNS records when all of the following conditions are met: </t> <ol> <li>The resolver encounters one or more GNS2DNSrecords and therecords;</li> <li>The remaining name isempty and theempty; and</li> <li>The desired record type isGNS2DNS, the GNS2DNS records are returned. </t> <t indent="0" pn="section-7.3.2-2">GNS2DNS.</li> </ol> <t> Otherwise, it is expected that the resolver first resolves the IP addresses of the specified DNS name servers. The DNS name <bcp14>MUST</bcp14> be converted to anIDNA compliantIDNA-compliant representation <xreftarget="RFC5890" format="default" sectionFormat="of" derivedContent="RFC5890"/>target="RFC5890"/> for resolution in DNS. GNS2DNS records <bcp14>MAY</bcp14> contain numeric IPv4 or IPv6 addresses, allowing the resolver to skip this step. The DNS server names might themselves be names in GNS or DNS. If the rightmost label of the DNS server name is the extension label(U+002B, "+"),(U+002B ("+")), the rest of the name is to be interpreted relative to the zone of the GNS2DNS record. If the DNS server name ends in a label representation of a zone key, the DNS server name is to be resolved against the GNS zonezk.zkey. </t><t indent="0" pn="section-7.3.2-3"><t> Multiple GNS2DNS records can be stored under the same label, 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 parallel. 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 the resolver is supposed to follow. If different DNS names arepresentpresent, the resolution fails and an appropriate erroris<bcp14>SHOULD</bcp14> be returned to the application. </t><t indent="0" pn="section-7.3.2-4"><t> If there are DNSSEC DS records or any other records used to secure the connection with the DNS servers stored under the label, the DNS resolver <bcp14>SHOULD</bcp14> use them to secure the connection with the DNS server. </t><t indent="0" pn="section-7.3.2-5"><t> Once the IP addresses of the DNS servers have been determined, the DNS name from the GNS2DNS record is appended to the remainder of the name to beresolved,resolved and is resolved by querying the DNS name server(s). The synthesized name has to be converted to anIDNA compliantIDNA-compliant representation <xreftarget="RFC5890" format="default" sectionFormat="of" derivedContent="RFC5890"/>target="RFC5890"/> for resolution in DNS. If such a conversion is not possible, the resolution <bcp14>MUST</bcp14> be aborted and an error <bcp14>MUST</bcp14> be returned.The informationInformation indicating that the critical record could not be processed <bcp14>SHOULD</bcp14> be returned in the error description. The implementation <bcp14>MAY</bcp14> choose not to return the reason for the failure, merely complicating troubleshooting for the user. </t><t indent="0" pn="section-7.3.2-6"><t> As the DNS servers specified are possibly authoritative DNS servers, the GNS resolver <bcp14>MUST</bcp14> support recursive DNS resolution and <bcp14>MUST NOT</bcp14> delegate this to the authoritative DNS servers. The first successful recursive name resolution result is returned to the application. In addition, the resolver <bcp14>SHOULD</bcp14> return the queried DNS name as a supplemental LEHO record (see <xreftarget="gnsrecords_leho" format="default" sectionFormat="of" derivedContent="Section 5.3.1"/>)target="gnsrecords_leho"/>) with a relative expiration time of one hour. </t><t indent="0" pn="section-7.3.2-7"><t> Once the transition from GNSintoto DNS is made through a GNS2DNS record, there is no "going back". The (possibly recursive) resolution of the DNS name <bcp14>MUST NOT</bcp14> delegate back into GNS and should only follow the DNS specifications. 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. </t><t indent="0" pn="section-7.3.2-8"><t> GNS resolvers <bcp14>SHOULD</bcp14> offer a configuration option to disable DNS processing to avoid information leakage and provide a consistent security profile for all name resolutions. Such resolvers would return an empty record set upon encountering a GNS2DNS record during the recursion. However, if GNS2DNS records are encountered in the record set for the apex label and a GNS2DNS record is explicitly requested by the application, such records <bcp14>MUST</bcp14> still be returned, even if DNS support is disabled by the GNS resolver configuration. </t> </section> <sectionanchor="box_processing" numbered="true" toc="include" removeInRFC="false" pn="section-7.3.3"> <name slugifiedName="name-box-2">BOX</name> <t indent="0" pn="section-7.3.3-1">anchor="box_processing"> <name>BOX</name> <t> When a BOX record is received, a GNS resolver must unbox it if the name to be resolved continues with "_SERVICE._PROTO". Otherwise, the BOX record is to be left untouched. This way, TLSA (and SRV) records do not require a separate network request, and TLSA records become inseparable from the corresponding address records. </t> </section> <sectionanchor="delegation_processing" numbered="true" toc="include" removeInRFC="false" pn="section-7.3.4"> <name slugifiedName="name-zone-delegation-records-2">Zoneanchor="delegation_processing"> <name>Zone Delegation Records</name><t indent="0" pn="section-7.3.4-1"><t> When the resolver encounters a record of a supported zone delegation record type (such as PKEY or EDKEY) and the remainder of the name is not empty, resolution continues recursively with the remainder of the name in the GNS zone specified in the delegation record. </t><t indent="0" pn="section-7.3.4-2"><t> Whenever a resolver encounters a new GNS zone, it <bcp14>MUST</bcp14> check against the local revocation list (see <xreftarget="revocation" format="default" sectionFormat="of" derivedContent="Section 4.2"/>)target="revocation"/>) to see whether the respective zone key has been revoked. If the zone key was revoked, the resolution <bcp14>MUST</bcp14> fail with an empty result set. </t><t indent="0" pn="section-7.3.4-3"><t> Implementations <bcp14>MUST NOT</bcp14> allow multiple different zone delegations under a single label (except if some are shadow records). Implementations <bcp14>MAY</bcp14> support any subset of ztypes. Implementations <bcp14>MUST NOT</bcp14> process zone delegation records stored under the apex label ("@"). If a zone delegation record is encountered under the apex label, resolution fails and an error <bcp14>MUST</bcp14> be returned. The implementation <bcp14>MAY</bcp14> choose not to return the reason for the failure, merely impacting troubleshooting information for the user. </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 was received containing only a single delegation record, the recursion is continued with the record value as the authoritative zone and the apex label "@" as the remaining name.Except inThe exception is the case where the desired record type as specified by the application is equal to the ztype, in which case the delegation record is returned. </t> </section> <sectionanchor="nick_processing" numbered="true" toc="include" removeInRFC="false" pn="section-7.3.5"> <name slugifiedName="name-nick-2">NICK</name> <t indent="0" pn="section-7.3.5-1">anchor="nick_processing"> <name>NICK</name> <t> NICK records are only relevant to the recursive resolver if the record set in question is the finalresultresult, which is to be returned to the application. The encountered NICK records caneitherbe either supplemental (see <xreftarget="rrecords" format="default" sectionFormat="of" derivedContent="Section 5"/>)target="rrecords"/>) or non-supplemental. If the NICK record is supplemental, the resolver only returns the record set if one of the non-supplemental records matches the queried record type. It is possible that one record set contains both supplemental and non-supplemental NICK records. </t><t indent="0" pn="section-7.3.5-2"><t> The differentiation between a supplemental and non-supplemental NICK record allows the application to match the record to the authoritative zone. Consider the following example: </t> <artwork name="" type=""align="left" alt="" pn="section-7.3.5-3">alt=""> Query: alice.example.gns.alt (type=A) Result: A: 192.0.2.1 NICK: eve (non-supplemental) </artwork><t indent="0" pn="section-7.3.5-4"><t> In this example, the returned NICK record is non-supplemental. For the application, this means that the NICK belongs to the zone "alice.example.gns.alt" and is published under the apex label along with an A record. The NICK record is interpretedas: Theas follows: the zone defined by "alice.example.gns.alt" wants to be referred to as "eve". In contrast, consider the following: </t> <artwork name="" type=""align="left" alt="" pn="section-7.3.5-5">alt=""> Query: alice.example.gns.alt (type=AAAA) Result: AAAA:2001:DB8::12001:db8::1 NICK: john (supplemental) </artwork><t indent="0" pn="section-7.3.5-6"><t> 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 under the label "alice" along withana AAAA record. Here, the NICK record should be interpretedas: Theas follows: the zone defined by "example.gns.alt" wants to be referred to as "john". This distinction is likely useful for other records published as supplemental. </t> </section> </section> </section> <sectionanchor="encoding" numbered="true" toc="include" removeInRFC="false" pn="section-8"> <name slugifiedName="name-internationalization-and-ch">Internationalizationanchor="encoding"> <name>Internationalization and Character Encoding</name><t indent="0" pn="section-8-1"><t> All names in GNS are encoded in UTF-8 <xreftarget="RFC3629" format="default" sectionFormat="of" derivedContent="RFC3629"/>.target="RFC3629"/>. Labels <bcp14>MUST</bcp14> be canonicalized using Normalization Form C (NFC) <xreftarget="Unicode-UAX15" format="default" sectionFormat="of" derivedContent="Unicode-UAX15"/>.target="Unicode-UAX15"/>. This does not include any DNS names found in DNS records, such as CNAME record data, which is internationalized through the IDNAspecificationsspecifications; see <xreftarget="RFC5890" format="default" sectionFormat="of" derivedContent="RFC5890"/>.target="RFC5890"/>. </t> </section> <sectionanchor="security" numbered="true" toc="include" removeInRFC="false" pn="section-9"> <name slugifiedName="name-security-and-privacy-consid">Securityanchor="security"> <name>Security and Privacy Considerations</name> <sectionanchor="security_availability" numbered="true" toc="include" removeInRFC="false" pn="section-9.1"> <name slugifiedName="name-availability">Availability</name> <t indent="0" pn="section-9.1-1">anchor="security_availability"> <name>Availability</name> <t> In order to ensure availability of records beyond their absolute expiration times, implementations <bcp14>MAY</bcp14> allowto locally definerelative expiration time values ofrecords.records to be locally defined. Records can then be published recurringly with updated absolute expiration times by the implementation. </t><t indent="0" pn="section-9.1-2"><t> Implementations <bcp14>MAY</bcp14> allow users to manage private records in their zones that are not published inthestorage. Private records areconsideredtreated just like regular records when resolving labels in local zones, but their data is completely unavailable to non-local users. </t> </section> <sectionanchor="security_agility" numbered="true" toc="include" removeInRFC="false" pn="section-9.2"> <name slugifiedName="name-agility">Agility</name> <t indent="0" pn="section-9.2-1">anchor="security_agility"> <name>Agility</name> <t> The security of cryptographic systems depends on both the strength of the cryptographic algorithms chosen and the strength of the keys used with those algorithms.TheThis security also depends on the engineering of the protocol used by the system to ensure that there are no non-cryptographic ways to bypass the security of the overall system. This is why developers of applications managing GNS zones <bcp14>SHOULD</bcp14> select a default ztype considered secure at the time of releasing the software. For applications targeting end users that are not expected to understand cryptography, the application developer <bcp14>MUST NOT</bcp14> leave the ztype selection of new zones to end users. </t><t indent="0" pn="section-9.2-2"><t> This document concerns itself with the selection of cryptographic algorithms used in GNS. The algorithms identified in this document are not known to be broken (in the cryptographic sense) at the current time, and cryptographic research so far leads us to believe that they are likely to remain secure into the foreseeable future. However, this 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 best practices in this area. </t><t indent="0" pn="section-9.2-3"><t> In terms of crypto-agility, whenever the need for an updated cryptographic scheme arises to, for example, replace ECDSA over Ed25519 for PKEY records, it can simply be introduced through a new record type. Zone administrators can then replace the delegation record type for future records. The old record typeremainsremains, and zones can iteratively migrate to the updated zone keys. To ensure that implementations correctly generate an error message when encountering a ztype that they do not support, current and future delegation records must always have the CRITICAL flag set. </t> </section> <sectionanchor="security_cryptography" numbered="true" toc="include" removeInRFC="false" pn="section-9.3"> <name slugifiedName="name-cryptography">Cryptography</name> <t indent="0" pn="section-9.3-1">anchor="security_cryptography"> <name>Cryptography</name> <t> The following considerations provide background on the design choices of the ztypes specified in this document. When specifying new ztypes as per <xreftarget="zones" format="default" sectionFormat="of" derivedContent="Section 4"/>,target="zones"/>, the same considerations apply. </t><t indent="0" pn="section-9.3-2"><t> GNS PKEY zone keys use ECDSA over Ed25519. This is an unconventional choice, as ECDSA is usually used with other curves. However, standardized ECDSA curves are problematic for a range ofreasonsreasons, as described in the Curve25519 and EdDSA papers <xreftarget="ed25519" format="default" sectionFormat="of" derivedContent="ed25519"/>.target="RFC7748"/> <xref target="ed25519"/>. Using EdDSA directly is also not possible, as a hash function is used on the private keywhich destroysand will destroy the linearity that the key blinding in GNS depends upon. We are not aware of anyone suggesting that using Ed25519 instead of another common curve of similar size would lower the security of ECDSA. GNS uses 256-bitcurves becausecurves; thatwayway, the encoded (public) keys fit into a single DNS label, which is good for usability. </t><t indent="0" pn="section-9.3-3"><t> In order to ensure ciphertext indistinguishability, care must be taken with respect to theinitialization vectorIV in the counter block. In our design, the IV always includes the expiration time of the record block. When applications store records with relative expiration times, monotonicity is implicitly ensured because each time a block is publishedinto thein storage, its IV isuniqueunique, as the expiration time is calculated dynamically and increases monotonically with the system time. Still, an implementation <bcp14>MUST</bcp14> ensure that when relative expiration times are decreased, the expiration time of the next record block <bcp14>MUST</bcp14> be after the last published block. For records where an absolute expiration time is used, the implementation <bcp14>MUST</bcp14> ensure that the expiration time is always increased when the record data changes. For example, the expiration time on the wire could be increased by a single microsecond even if the user did not request a change. In the case of deletion of all resource records under a label, the implementation <bcp14>MUST</bcp14> keep track of the last absolute expiration time of the last published resource block. Implementations <bcp14>MAY</bcp14> define and use a special record type as a tombstone that preserves the last absolute expirationtime,time but then <bcp14>MUST</bcp14> take care to not publish a block with such a tombstone record. When new records are added under this label later, the implementation <bcp14>MUST</bcp14> ensure that the expiration times are after the last published block. Finally, in order to ensure monotonically increasing expirationtimestimes, the implementation <bcp14>MUST</bcp14> keep a local record of the last time obtained from the system clock, so as to construct a monotonic clockin caseif the system clock jumps backwards. </t> </section> <sectionanchor="security_abuse" numbered="true" toc="include" removeInRFC="false" pn="section-9.4"> <name slugifiedName="name-abuse-mitigation">Abuseanchor="security_abuse"> <name>Abuse Mitigation</name><t indent="0" pn="section-9.4-1"><t> GNS names are UTF-8 strings. Consequently, GNS facessimilarissues with respect to name spoofingas DNS doessimilar to those for DNS with respect to internationalized domain names. In DNS, attackers can registersimilar soundingsimilar-sounding orlookingsimilar-looking names (see above) in order to execute phishing attacks. GNS zone administrators must take into account this attack vector and incorporate rules in order to mitigate it. </t><t indent="0" pn="section-9.4-2"><t> Further, DNS can be used to combat illegal content on the Internet by having the respective domains seized by authorities. However, the same mechanisms can also be abused in order to impose state censorship. Avoiding that possibility is one of the motivations behind GNS. In GNS, TLDs are not enumerable. By design, thestart zoneStart Zone of the resolver is definedlocallylocally, and hence such a seizure is difficult and ineffective in GNS.<!--In particular, GNS does not support WHOIS (<xref target="RFC3912" />).--></t> </section> <sectionanchor="security_keymanagement" numbered="true" toc="include" removeInRFC="false" pn="section-9.5"> <name slugifiedName="name-zone-management">Zoneanchor="security_keymanagement"> <name>Zone Management</name><t indent="0" pn="section-9.5-1"><t> In GNS, zone administrators need to manage and protect their zone keys. Once a private zone key is lost, it cannot berecoveredrecovered, and the zone revocation message cannot be computed anymore. Revocation messages can bepre-calculatedprecalculated if revocation is required incasecases where a private zone key is lost. Zone administrators, and for GNS this includesend-users,end users, are required to responsibly and diligently protect their cryptographic keys. GNS supports signing records in advance ("offline") in order to support processes (such as air gaps)whichthat aim to protect private keys.<!-- 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 indent="0" pn="section-9.5-2"><t> Similarly, users are required to manage their localstart zoneStart Zone configuration. In order to ensure the integrity and availabilityorof names, users must ensure that their localstart zoneStart Zone information is not compromised or outdated. It can be expected that the processing of zone revocations and an initialstart zone isStart Zone are provided with a GNS implementation ("drop shipping"). Shipping an initialstart zoneStart Zone configuration effectively establishes a root zone. Extension and customization of the zoneisare at the full discretion of the user. </t><t indent="0" pn="section-9.5-3"><t> While implementations following this specification will be interoperable, if two implementations connect to different remotestoragesstorage entities, they are mutually unreachable. This can lead to a state where a record exists in the global namespace for a particular name, but the implementation is not communicating with the remote storage entity that contains the respective block and is hence unable to resolve it. This situation is similar to a split-horizon DNS configuration.Which remote storages are implemented usually depends on the application it is built for.The remote storage entity used will most likely depend on the specific application context using GNS resolution. For example, one application is the resolution of hidden services within the Tornetwork,network <xref target="TorRendSpec"/>, which would suggest using Tor routers for remote storage.<!-- FIXME: add non-normative reference to Tor / Tor hidden services here? -->Implementations of "aggregated" remotestoragesstorage entities areconceivable,conceivable but are expected to be the exception. </t> </section> <sectionanchor="security_dht" numbered="true" toc="include" removeInRFC="false" pn="section-9.6"> <name slugifiedName="name-dhts-as-remote-storage">DHTsanchor="security_dht"> <name>DHTs as Remote Storage</name><t indent="0" pn="section-9.6-1"><t> This document does not specify the properties of the underlying remotestoragestorage, which is required by any GNS implementation. It is important to note that the properties of the underlying remote storage are directly inherited by the GNS implementation. This includes both securityas well asand other non-functional properties such as scalability and performance. Implementers should take great care when selecting or implementing a DHT for use as remote storage in a GNS implementation. DHTs with reasonable security and performance properties exist <xreftarget="R5N" format="default" sectionFormat="of" derivedContent="R5N"/>.target="R5N"/>. It should also be taken into consideration that GNS implementationswhichthat build upon different DHT overlays are unlikely to beinteroperable with each other.mutually reachable. </t> </section> <sectionanchor="security_rev" numbered="true" toc="include" removeInRFC="false" pn="section-9.7"> <name slugifiedName="name-revocations">Revocations</name> <t indent="0" pn="section-9.7-1">anchor="security_rev"> <name>Revocations</name> <t> Zone administrators are advised topre-generatepregenerate zone revocations and to securely store the revocation informationin caseif the zone key is lost,compromisedcompromised, or replaced in the future.Pre-calculatedPrecalculated revocations can cease to be valid due to expirations or protocol changes such as epoch adjustments. Consequently, implementers and users must take precautions in order to manage revocations accordingly. </t><t indent="0" pn="section-9.7-2"><t> Revocation payloads do not include a'new'"new" key for key replacement. Inclusion of such a key would have two major disadvantages: </t><ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-9.7-3"> <li pn="section-9.7-3.1" derivedCounter="1."><ol> <li> If a revocation is published after a private key was compromised, allowing key replacement would be dangerous: if an adversary took over the private key, the adversary could then broadcast a revocation with a key replacement. For the replacement, the compromised owner would have no chance to issue a revocation. Thus, allowing a revocation message to replace a private key makes dealing with key compromise situations worse. </li><li pn="section-9.7-3.2" derivedCounter="2."><li> Sometimes, key revocations are used with the objective of changing cryptosystems. Migration to another cryptosystem by replacing keys via a revocation message would only be secure as long as both cryptosystems are still secure against forgery. Such a planned, non-emergency migration to another cryptosystem should be done by running zones for both cipher systems in parallel for a while. The migration would conclude by revoking the legacy zone key onlyoncewhen it is deemed no longersecure, and hopefullysecure and, hopefully, after most users have migrated to the replacement. </li> </ol> </section> <sectionanchor="privacy_labels" numbered="true" toc="include" removeInRFC="false" pn="section-9.8"> <name slugifiedName="name-zone-privacy">Zoneanchor="privacy_labels"> <name>Zone Privacy</name><t indent="0" pn="section-9.8-1"><t> GNS does not support authenticated denial of existence of names within a zone. Record data is published in encrypted form using keys derived from the zone key and record label. Zone administrators should carefully considerifwhether (1) a label and zone key arepublic,public orif(2) one or both of these should be used as a shared secret to restrict access to the corresponding record data. Unlike public zone keys, low-entropy labels can be guessed by an attacker. If an attacker knows the public zone key, the use ofwell knownwell-known or guessable labels effectively threatens the disclosure of the corresponding records. </t><t indent="0" pn="section-9.8-2"><t> It should be noted that the guessing attack on labels only applies if the zone key is somehow disclosed to the adversary. GNS itself does not disclose it during a lookup or when resource records are published (as only the blinded zone keys are used on the network). However, zone keys do become public during revocation. </t><t indent="0" pn="section-9.8-3"><t> It is thus <bcp14>RECOMMENDED</bcp14> to use a label with sufficient entropy to prevent guessing attacks if any data in a resource record set is sensitive. </t> </section> <sectionanchor="sec_governance" numbered="true" removeInRFC="false" toc="include" pn="section-9.9"> <name slugifiedName="name-zone-governance">Zoneanchor="sec_governance"> <name>Zone Governance</name><t indent="0" pn="section-9.9-1"><t> While DNS is distributed, in practice it relies on centralized, trusted registrars to provide globally unique names. Astheawareness of the central role DNS plays on the Internetrises,increases, various institutions are using their power (including legal means) to engage in attacks on the DNS, thus threatening the global availability and integrity of information on the Internet. While a wider discussion of this issue is out of scope for this document, analyses and investigations can be found in recent academic researchworksworks, including <xreftarget="SecureNS" format="default" sectionFormat="of" derivedContent="SecureNS"/>.target="SecureNS"/>. </t><t indent="0" pn="section-9.9-2"><t> GNS is designed to provide a secure, privacy-enhancing alternative to the DNS name resolution protocol, especially when censorship or manipulation is encountered. In particular, it directly addresses concerns in DNS with respect to query privacy. However, depending on the governance of the root zone, any deployment will likely suffer from theissuesissue of a"Single Hierarchysingle hierarchy with aCentrally Controlled Root"centrally controlled root and"Distributionthe related issue of distribution andManagementmanagement ofRoot Servers"root servers in DNS, as raised in Sections <xref target="RFC8324" section="3.12" sectionFormat="bare"/> and <xref target="RFC8324"format="default" sectionFormat="of" derivedContent="RFC8324"/>.section="3.10" sectionFormat="bare"/> of <xref target="RFC8324"/>, respectively. In DNS, those issuesare a directdirectly result from the centralized root zone governance at the Internet Corporation for Assigned Names and Numbers(ICANN)(ICANN), which allows it to provide globally unique names. </t><t indent="0" pn="section-9.9-3"><t> In GNS,start zonesStart Zones give users local authority over their preferred root zone governance. It enables users to replace or enhance a trusted root zone configuration provided by a third party(e.g.(e.g., the implementer or a multi-stakeholder governance body like ICANN) with secure delegation of authority using local petnames while operating under a very strong adversary model. In combination with zTLDs, this provides users of GNS with a global,securesecure, and memorable mapping without a trusted authority. </t><t indent="0" pn="section-9.9-4"><t> Any GNS implementation <bcp14>MAY</bcp14> provide a default governance model in the form of an initialstart zoneStart Zone mapping. </t> </section> <sectionanchor="namespace_ambiguity" numbered="true" removeInRFC="false" toc="include" pn="section-9.10"> <name slugifiedName="name-namespace-ambiguity">Namespaceanchor="namespace_ambiguity"> <name>Namespace Ambiguity</name><t indent="0" pn="section-9.10-1"><t> Technically, the GNS protocol can be used to resolve names in the namespace of the global DNS. However, this would require the respective governance bodies and stakeholders(e.g.(e.g., the IETF and ICANN) to standardize the use of GNS for this particular use case. </t><t indent="0" pn="section-9.10-2"> However, this<t> This capability implies that GNS names may be indistinguishable from DNS names in their respective common display format <xreftarget="RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/>target="RFC8499"/> or other special-use domain names <xreftarget="RFC6761" format="default" sectionFormat="of" derivedContent="RFC6761"/>target="RFC6761"/> if a localstart zoneStart Zone configuration maps suffixes from the global DNS to GNS zones. For applications,it is then ambiguouswhich name system should be used in order to resolve a givenname.name will then be ambiguous. This poses a risk when trying to resolve a name through DNS when it is actually a GNSnamename, as discussed in <xreftarget="RFC8244" format="default" sectionFormat="of" derivedContent="RFC8244"/>.target="RFC8244"/>. In such a case, the GNS name is likely to be leaked as part of the DNS resolution. </t><t indent="0" pn="section-9.10-3"><t> In order to prevent disclosure of queried GNSnamesnames, it is <bcp14>RECOMMENDED</bcp14> that GNS-aware applications try to resolve a given name in GNS before any othermethodmethod, taking into account potential suffix-to-zone mappings and zTLDs. Suffix-to-zone mappings are expected to be configured by the user or localadministratoradministrator, and as such the resolution in GNS is in line with user expectations even if the name could also be resolved through DNS. 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. If a suffix-to-zone mapping for the name exists or the name ends with a zTLD, it <bcp14>MUST</bcp14> be resolved usingGNSGNS, and resolution <bcp14>MUST NOT</bcp14> continue by any other means independent of the GNS resolution result. </t><t indent="0" pn="section-9.10-4"><t> Mechanisms such as the Name Service Switch (NSS) ofUnix-likeUNIX-like operating systems are an example of how such a resolution process can be implemented and used.ItThe NSS allows system administrators to configurehost namehostname resolution precedence and is integrated with the system resolver implementation. </t><t indent="0" pn="section-9.10-5"><t> For use cases where GNS names may be confused with names of other name resolution mechanisms (inparticularparticular, DNS), the ".gns.alt" domain <bcp14>SHOULD</bcp14> be used. For use cases like implementing sinkholes to block malware sites or serving DNS domains via GNS to bypass censorship, GNS <bcp14>MAY</bcp14> be deliberately used in ways that interfere with resolution of another name system. </t> </section> </section> <sectionanchor="gana" numbered="true" toc="include" removeInRFC="false" pn="section-10"> <name slugifiedName="name-gana-considerations">GANAanchor="gana"> <name>GANA Considerations</name><t indent="0" pn="section-10-1"><section anchor="gana_gnunet-sig-purposes"> <name>GNUnet Signature Purposes Registry</name> <t> GANA <xref target="GANA"/> has assigned signature purposes in its "GNUnet SignaturePurpose"Purposes" registry as listed in <xreftarget="figure_purposenums" format="default" sectionFormat="of" derivedContent="Figure 24"/>.target="tab_purposenums"/>. </t><figure anchor="figure_purposenums" align="left" suppress-title="false" pn="figure-24"> <name slugifiedName="name-requested-changes-in-the-ga">Requested Changes in the<table anchor="tab_purposenums"> <name>The GANA GNUnet SignaturePurpose Registry.</name> <artwork name="" type="" align="left" alt="" pn="section-10-2.1"> Purpose | Name | References | Comment --------+-----------------+------------+-------------------------- 3 | GNS_REVOCATION | [This.I-D] | GNS zone key revocation 15 | GNS_RECORD_SIGN | [This.I-D] | GNSPurposes Registry</name> <thead> <tr> <th>Purpose</th> <th>Name</th> <th>References</th> <th>Comment</th> </tr> </thead> <tbody> <tr> <td>3</td> <td>GNS_REVOCATION</td> <td>RFC 9498</td> <td>GNS zone key revocation</td> </tr> <tr> <td>15</td> <td>GNS_RECORD_SIGN</td> <td>RFC 9498</td> <td>GNS record setsignature </artwork> </figure>signature</td> </tr> </tbody> </table> </section> <sectionanchor="gana_gnsrr" numbered="true" removeInRFC="false" toc="include" pn="section-10.1"> <name slugifiedName="name-gns-record-types-registry">GNSanchor="gana_gnsrr"> <name>GNS Record Types Registry</name><t indent="0" pn="section-10.1-1"><t> GANA <xreftarget="GANA" format="default" sectionFormat="of" derivedContent="GANA"/>target="GANA"/> manages the "GNS Record Types" registry.Each</t> <t>Each entry has the following format: </t><ul bare="false" empty="false" indent="3" spacing="normal" pn="section-10.1-2"> <li pn="section-10.1-2.1">Name: The<dl newline="false"> <dt>Name:</dt><dd>The name of the record type (case-insensitive ASCII string, restricted to alphanumeric characters). For zone delegation records, the assigned number represents the ztype value of thezone.</li> <li pn="section-10.1-2.2">Number: 32-bit,zone.</dd> <dt>Number:</dt><dd>A 32-bit number above65535</li> <li pn="section-10.1-2.3">Comment: Optionally, a65535.</dd> <dt>Comment:</dt><dd>Optionally, brief English text describing the purpose of the record type (inUTF-8)</li> <li pn="section-10.1-2.4">Contact: Optionally,UTF-8).</dd> <dt>Contact:</dt><dd>Optionally, the contact informationoffor a person to contact for furtherinformation.</li> <li pn="section-10.1-2.5">References: Optionally,information.</dd> <dt>References:</dt><dd>Optionally, referencesdescribing the record type(such as anRFC).</li> </ul> <t indent="0" pn="section-10.1-3">RFC) describing the record type.</dd> </dl> <t> The registration policy for this registry is "First Come First Served". This policy is modeled on that described in <xreftarget="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>,target="RFC8126"/> and describes the actions taken by GANA: </t><t indent="0" pn="section-10.1-4"><ul> <li> Adding new entries is possible after review by any authorized GANA contributor, using a first-come-first-served policy for unique name allocation. Reviewers are responsibleto ensurefor ensuring that the chosen "Name" is appropriate for the record type. The registry will define a unique number for the entry.</t> <t indent="0" pn="section-10.1-5"></li> <li> Authorized GANA contributors for review of new entries are reachable atgns-registry@gnunet.org. </t> <t indent="0" pn="section-10.1-6"><gns-registry@gnunet.org>. </li> <li> Any request <bcp14>MUST</bcp14> contain a unique name and a point of contact. The contact information <bcp14>MAY</bcp14> be added to theregistry givenregistry, with the consent of the requester. The request <bcp14>MAY</bcp14> optionally also contain relevant references as well as a descriptivecommentcomment, as defined above.</t> <t indent="0" pn="section-10.1-7"></li> </ul> <t> GANA has assigned numbers for the record types defined in this specification in the"GNU Name System"GNS Record Types" registry as listed in <xreftarget="figure_rrtypenums" format="default" sectionFormat="of" derivedContent="Figure 25"/>.target="tab_rrtypenums"/>. </t><figure anchor="figure_rrtypenums" align="left" suppress-title="false" pn="figure-25"> <name slugifiedName="name-the-gana-resource-record-re">The<table anchor="tab_rrtypenums"> <name>The GANAResource 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 Record Types Registry</name> <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) 65537 | NICK | (*) | [This.I-D] | GNS zone nickname 65538 | LEHO | (*) | [This.I-D] | GNS(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 legacyhostname 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] | GNShostname</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) (*): gns-registry@gnunet.org </artwork> </figure>(EDKEY)</td> </tr> </tbody> <tfoot> <tr> <td align="left" colspan="5">(*): gns-registry@gnunet.org</td> </tr> </tfoot> </table> </section> <sectionanchor="gana_alt" numbered="true" removeInRFC="false" toc="include" pn="section-10.2"> <name slugifiedName="name-alt-subdomains-registry">.altanchor="gana_alt"> <name>.alt Subdomains Registry</name><t indent="0" pn="section-10.2-1"><t> GANA <xreftarget="GANA" format="default" sectionFormat="of" derivedContent="GANA"/>target="GANA"/> manages the ".alt Subdomains" registry.EachThis GANA-operated .alt registry may or may not be taken into account by any particular implementer, and it is not in any way associated with or sanctioned by the IETF or ICANN. </t> <t>Each entry has the following format: </t><ul bare="false" empty="false" indent="3" spacing="normal" pn="section-10.2-2"> <li pn="section-10.2-2.1">Label: The<dl newline="false"> <dt>Label:</dt><dd>The label of the subdomain (in DNSLDH"letters, digits, hyphen" (LDH) format as defined inSection 2.3.1 of<xref target="RFC5890"format="default"sectionFormat="of"derivedContent="RFC5890"/>).</li> <li pn="section-10.2-2.2">Comment: Optionally, asection="2.3.1"/>).</dd> <dt>Description:</dt><dd>Optionally, brief English text describing the purpose of the subdomain (inUTF-8)</li> <li pn="section-10.2-2.3">Contact: Optionally,UTF-8).</dd> <dt>Contact:</dt><dd>Optionally, the contact informationoffor a person to contact for furtherinformation.</li> <li pn="section-10.2-2.4">References: Optionally,information.</dd> <dt>References:</dt><dd>Optionally, referencesdescribing the record type(such as anRFC).</li> </ul> <t indent="0" pn="section-10.2-3">RFC) describing the record type.</dd> </dl> <t> The registration policy for this registry is "First Come First Served". This policy is modeled on that described in <xreftarget="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>,target="RFC8126"/> and describes the actions taken by GANA: </t><t indent="0" pn="section-10.2-4"><ul> <li> Adding new entries is possible after review by any authorized GANA contributor, using a first-come-first-served policy for unique subdomain allocation. Reviewers are responsibleto ensurefor ensuring that the chosen "Subdomain" is appropriate for the purpose.</t> <t indent="0" pn="section-10.2-5"></li> <li> Authorized GANA contributors for review of new entries are reachable atalt-registry@gnunet.org. </t> <t indent="0" pn="section-10.2-6"><alt-registry@gnunet.org>. </li> <li> Any request <bcp14>MUST</bcp14> contain a unique subdomain and a point of contact. The contact information <bcp14>MAY</bcp14> be added to theregistry givenregistry, with the consent of the requester. The request <bcp14>MAY</bcp14> optionally also contain relevant references as well as a descriptivecommentcomment, as defined above.</t> <t indent="0" pn="section-10.2-7"></li> </ul> <t> GANA has assigned the subdomain defined in this specification in the ".altsubdomains"Subdomains" registry as listed in <xreftarget="figure_altsubdomains" format="default" sectionFormat="of" derivedContent="Figure 26"/>.target="tab_altsubdomains"/>. </t><figure anchor="figure_altsubdomains" align="left" suppress-title="false" pn="figure-26"> <name slugifiedName="name-the-gana-alt-subdomains-reg">The<table anchor="tab_altsubdomains"> <name>The GANA .alt SubdomainsRegistry.</name> <artwork name="" type="" align="left" alt="" pn="section-10.2-8.1"> Subdomain | Contact | References | Comment ----------+---------+------------+---------------------------- gns | (*) | [This.I-D] | TheRegistry</name> <thead> <tr> <th>Label</th> <th>Contact</th> <th>References</th> <th>Description</th> </tr> </thead> <tbody> <tr> <td>gns</td> <td>(*)</td> <td>RFC 9498</td> <td>The .alt subdomain forGNS. (*): alt-registry@gnunet.org </artwork> </figure>GNS</td> </tr> </tbody> <tfoot> <tr> <td align="left" colspan="4">(*): alt-registry@gnunet.org</td> </tr> </tfoot> </table> </section> </section><!-- gana --> <section numbered="true" removeInRFC="false" toc="include" pn="section-11"> <name slugifiedName="name-iana-considerations">IANA<section> <name>IANA Considerations</name><t indent="0" pn="section-11-1"><t> This documentmakeshas norequests forIANAaction. This section may be removed on publication as an RFC.actions. </t> </section><section numbered="true" removeInRFC="false" toc="include" pn="section-12"> <name slugifiedName="name-implementation-and-deployme">Implementation<section> <name>Implementation and Deployment Status</name><t indent="0" pn="section-12-1"><t> There are two implementations conforming to thisspecificationspecification, written in C and Go, respectively. The C implementation as part of GNUnet <xreftarget="GNUnetGNS" format="default" sectionFormat="of" derivedContent="GNUnetGNS"/>target="GNUnetGNS"/> represents the original and reference implementation. The Go implementation <xreftarget="GoGNS" format="default" sectionFormat="of" derivedContent="GoGNS"/>target="GoGNS"/> demonstrates how two implementations of GNS are interoperable if they are built on top of the same underlying DHT storage. </t><t indent="0" pn="section-12-2"><t> Currently, the GNUnet peer-to-peer network <xreftarget="GNUnet" format="default" sectionFormat="of" derivedContent="GNUnet"/>target="GNUnet"/> is an active deployment of GNS on top of its DHT <xreftarget="R5N" format="default" sectionFormat="of" derivedContent="R5N"/> DHT.target="R5N"/>. The<xref target="GoGNS" format="default" sectionFormat="of" derivedContent="GoGNS"/>Go implementation <xref target="GoGNS"/> uses this deployment by building on top of the GNUnet DHT services available on any GNUnet peer. It shows how GNS implementations can attach to this existing deployment and participate in name resolution as well as zone publication. </t><t indent="0" pn="section-12-3"><t> The self-sovereign identity system re:claimID <xreftarget="reclaim" format="default" sectionFormat="of" derivedContent="reclaim"/>target="reclaim"/> is using GNS in order to selectively share identity attributes and attestations with third parties. </t><t indent="0" pn="section-12-4"><t> The Ascension tool <xreftarget="Ascension" format="default" sectionFormat="of" derivedContent="Ascension"/>target="Ascension"/> facilitates the migration of DNS zones to GNS zones by translating information retrieved from a DNS zone transfer into a GNS zone. </t> </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. Salz for their insightful and detailed technical reviews. We thank J. Yao and J. Klensin for the internationalization reviews. We thank NLnet and NGI DISCOVERY for funding work on the GNU Name System. </t> </section></middle> <back><references pn="section-14"> <name slugifiedName="name-normative-references">Normative<references> <name>References</name> <references> <name>Normative References</name><reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc1034" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml" quoteTitle="true" derivedAnchor="RFC1034"> <front> <title>Domain names - concepts and facilities</title> <author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/> <date month="November" year="1987"/> <abstract> <t indent="0">This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them.</t> </abstract> </front> <seriesInfo name="STD" value="13"/> <seriesInfo name="RFC" value="1034"/> <seriesInfo name="DOI" value="10.17487/RFC1034"/> </reference> <reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1035" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml" quoteTitle="true" derivedAnchor="RFC1035"> <front> <title>Domain names - implementation and specification</title> <author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/> <date month="November" year="1987"/> <abstract> <t indent="0">This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.</t> </abstract> </front> <seriesInfo name="STD" value="13"/> <seriesInfo name="RFC" value="1035"/> <seriesInfo name="DOI" value="10.17487/RFC1035"/> </reference> <reference anchor="RFC2782" target="https://www.rfc-editor.org/info/rfc2782" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2782.xml" quoteTitle="true" derivedAnchor="RFC2782"> <front> <title>A DNS RR for specifying the location of services (DNS SRV)</title> <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 location of the server(s) for a specific protocol and domain. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="2782"/> <seriesInfo name="DOI" value="10.17487/RFC2782"/> </reference> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml" quoteTitle="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 used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </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/rfc3629" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml" quoteTitle="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 the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.</t> </abstract> </front> <seriesInfo name="STD" value="63"/> <seriesInfo name="RFC" value="3629"/> <seriesInfo name="DOI" value="10.17487/RFC3629"/> </reference> <reference anchor="RFC3686" target="https://www.rfc-editor.org/info/rfc3686" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3686.xml" quoteTitle="true" derivedAnchor="RFC3686"> <front> <title>Using Advanced Encryption Standard (AES) Counter Mode With IPsec 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 IPsec 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/rfc3826" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3826.xml" quoteTitle="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 protocol that supplements the protocols described in the User-based Security Model (USM), which is a Security Subsystem for version 3 of the Simple Network Management Protocol for use in the SNMP Architecture. The symmetric encryption protocol described in this document is based on the Advanced Encryption Standard (AES) cipher algorithm used in Cipher FeedBack Mode (CFB), with a key size of 128 bits. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="3826"/> <seriesInfo name="DOI" value="10.17487/RFC3826"/> </reference> <reference anchor="RFC5237" target="https://www.rfc-editor.org/info/rfc5237" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5237.xml" quoteTitle="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 allocating new Protocol field values in IPv4 header. It modifies the rules specified in RFC 2780 by removing the Expert Review option. The change will also affect the allocation of Next Header field values in IPv6. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </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/rfc5869" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5869.xml" quoteTitle="true" derivedAnchor="RFC5869"> <front> <title>HMAC-based Extract-and-Expand Key Derivation Function (HKDF)</title> <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 Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.</t> </abstract> </front> <seriesInfo name="RFC" value="5869"/> <seriesInfo name="DOI" value="10.17487/RFC5869"/> </reference> <reference anchor="RFC5890" target="https://www.rfc-editor.org/info/rfc5890" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5890.xml" quoteTitle="true" derivedAnchor="RFC5890"> <front> <title>Internationalized Domain Names for Applications (IDNA): Definitions 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, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5890"/> <seriesInfo name="DOI" value="10.17487/RFC5890"/> </reference> <reference anchor="RFC5895" target="https://www.rfc-editor.org/info/rfc5895" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5895.xml" quoteTitle="true" derivedAnchor="RFC5895"> <front> <title>Mapping Characters for Internationalized Domain Names in Applications (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 Domain Names in Applications (IDNA) protocol, any Unicode code points taken from user input were mapped into a set of Unicode code points that "made sense", and then encoded and passed to the domain name system (DNS). The IDNA2008 protocol (described in RFCs 5890, 5891, 5892, and 5893) presumes that the input to the protocol comes from a set of "permitted" code points, which it then encodes and passes to the DNS, but does not specify what to do with the result of user input. This document describes the actions that can be taken by an implementation between receiving user input and passing permitted code points to the new IDNA protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.</t> </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/rfc6234" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml" quoteTitle="true" derivedAnchor="RFC6234"> <front> <title>US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)</title> <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/rfc6895" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6895.xml" quoteTitle="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 Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597.</t> </abstract> </front> <seriesInfo name="BCP" value="42"/> <seriesInfo name="RFC" value="6895"/> <seriesInfo name="DOI" value="10.17487/RFC6895"/> </reference> <reference anchor="RFC6979" target="https://www.rfc-editor.org/info/rfc6979" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6979.xml" quoteTitle="true" derivedAnchor="RFC6979"> <front> <title>Deterministic Usage of the Digital Signature Algorithm (DSA) and 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 signature generation procedure. Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein. Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness.</t> </abstract> </front> <seriesInfo name="RFC" value="6979"/> <seriesInfo name="DOI" value="10.17487/RFC6979"/> </reference> <reference anchor="RFC7748" target="https://www.rfc-editor.org/info/rfc7748" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7748.xml" quoteTitle="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 fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.</t> </abstract> </front> <seriesInfo name="RFC" value="7748"/> <seriesInfo name="DOI" value="10.17487/RFC7748"/> </reference> <reference anchor="RFC8032" target="https://www.rfc-editor.org/info/rfc8032" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8032.xml" quoteTitle="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 scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.</t> </abstract> </front> <seriesInfo name="RFC" value="8032"/> <seriesInfo name="DOI" value="10.17487/RFC8032"/> </reference> <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml" quoteTitle="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 that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t> <t indent="0">To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t> <t indent="0">This is the third edition of this document; it obsoletes 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/rfc8174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml" quoteTitle="true" derivedAnchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <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 in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </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/rfc8499" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml" quoteTitle="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 dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.</t> <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/rfc9106" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9106.xml" quoteTitle="true" derivedAnchor="RFC9106"> <front> <title>Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work 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 function for password hashing and proof-of-work applications. We provide an implementer-oriented description with test vectors. The purpose is to simplify adoption of Argon2 for Internet protocols. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</t> </abstract> </front> <seriesInfo name="RFC" value="9106"/> <seriesInfo name="DOI" value="10.17487/RFC9106"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2782.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3686.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3826.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5237.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5869.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5890.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5895.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6895.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6979.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7748.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8032.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9106.xml"/> <reference anchor="GANA"target="https://gana.gnunet.org/" quoteTitle="true" derivedAnchor="GANA">target="https://gana.gnunet.org/"> <front> <title>GNUnet Assigned Numbers Authority (GANA)</title> <author><organization showOnFrontPage="true">GNUnet<organization>GNUnet e.V.</organization> </author> <datemonth="November" year="2022"/>year="2023"/> </front> </reference> <reference anchor="MODES"target="https://doi.org/10.6028/NIST.SP.800-38A" quoteTitle="true" derivedAnchor="MODES">target="https://doi.org/10.6028/NIST.SP.800-38A"> <front> <title>Recommendation for Block Cipher Modes of Operation: Methods and Techniques</title> <author initials="M." surname="Dworkin" fullname="Morris Dworkin"><organization showOnFrontPage="true">NIST</organization><organization>NIST</organization> </author> <date year="2001" month="December"/><abstract> <t indent="0"> This recommendation defines five confidentiality modes of operation for use with an underlying symmetric key block cipher algorithm: Electronic Codebook (ECB), Cipher Block Chaining (CBC), Cipher Feedback (CFB), Output Feedback (OFB), and Counter (CTR). Used with an underlying block cipher algorithm that is approved in a Federal Information Processing Standard (FIPS), these modes can provide cryptographic protection for sensitive, but unclassified, computer data. </t> </abstract></front> <refcontent>NIST Special Publication 800-38A</refcontent> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-38A"/> </reference><!-- <reference anchor="GCM" target="https://doi.org/10.6028/NIST.SP.800-38D"> <front> <title>Recommendation for Block Cipher Modes of Operation: Galois/Counter 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 algorithm for authenticated encryption with associated data, and its specialization, 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 symmetric 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">target="https://www.crockford.com/base32.html"> <front><title>Base32</title><title>Base 32</title> <author initials="D."surname="Douglas"surname="Crockford" fullname="Douglas Crockford"> </author> <date year="2019" month="March"/> </front> </reference> <reference anchor="XSalsa20"target="https://cr.yp.to/snuffle/xsalsa-20110204.pdf" quoteTitle="true" derivedAnchor="XSalsa20">target="https://cr.yp.to/papers.html#xsalsa"> <front> <title>Extending the Salsa20 nonce</title> <authorinitials="D."initials="D. J." surname="Bernstein" fullname="Daniel Bernstein"><organization showOnFrontPage="true">University<organization>University of Illinois at Chicago</organization> </author> <date year="2011"/> </front> </reference> <reference anchor="Unicode-UAX15"target="http://www.unicode.org/reports/tr15/tr15-31.html" quoteTitle="true" derivedAnchor="Unicode-UAX15">target="https://www.unicode.org/reports/tr15/tr15-31.html"> <front> <title>Unicode Standard Annex #15: Unicode NormalizationForms, Revision 31</title> <author> <organization showOnFrontPage="true">The Unicode Consortium</organization>Forms</title> <author initials="M." surname="Davis" fullname="Mark Davis"> <organization/> </author> <author initials="K." surname="Whistler" fullname="Ken Whistler"> <organization/> </author> <author initials="M." surname="Dürst" fullname="Martin Dürst"> <organization/> </author> <date year="2009" month="September"/> </front> <refcontent>Revision 31, The Unicode Consortium, Mountain View</refcontent> </reference> <reference anchor="Unicode-UTS46"target="https://www.unicode.org/reports/tr46" quoteTitle="true" derivedAnchor="Unicode-UTS46">target="https://www.unicode.org/reports/tr46"> <front> <title>Unicode Technical Standard #46: Unicode IDNA CompatibilityProcessing, Revision 27</title> <author> <organization showOnFrontPage="true">The Unicode Consortium</organization> </author> <date year="2021" month="August"/> </front> </reference> <!-- <reference anchor="ISO20022"> <front> <title>ISO 20022 Financial Services - Universal financial industry message scheme</title> <author> <organization>International Organization for Standardization</organization> <address> <uri>http://www.iso.ch</uri> </address> </author> <date month="May" year="2013"/> </front> </reference>--> </references> <references pn="section-15"> <name slugifiedName="name-informative-references">Informative References</name> <reference anchor="RFC1928" target="https://www.rfc-editor.org/info/rfc1928" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1928.xml" quoteTitle="true" derivedAnchor="RFC1928"> <front> <title>SOCKS Protocol Version 5</title>Processing</title> <authorfullname="M. Leech"initials="M."surname="Leech"/> <author fullname="M. Ganis" initials="M." surname="Ganis"/> <author fullname="Y. Lee" initials="Y." surname="Lee"/> <author fullname="R. Kuris" initials="R." surname="Kuris"/> <author fullname="D. Koblas" initials="D." surname="Koblas"/> <author fullname="L. Jones" initials="L." surname="Jones"/> <date month="March" year="1996"/> <abstract> <t indent="0">This memo describes a protocol that is an evolution of the previous version of the protocol, version 4 [1]. This new protocol stems from active discussions and prototype implementations. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="1928"/> <seriesInfo name="DOI" value="10.17487/RFC1928"/> </reference> <reference anchor="RFC4033" target="https://www.rfc-editor.org/info/rfc4033" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml" quoteTitle="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"/>surname="Davis" fullname="Mark Davis"> <organization/> </author> <authorfullname="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) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK]</t> </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/rfc6066" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml" quoteTitle="true" derivedAnchor="RFC6066"> <front> <title>Transport Layer Security (TLS) Extensions: Extension Definitions</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 Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK]</t> </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/rfc7363" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7363.xml" quoteTitle="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"/>surname="Suignard" fullname="Michel Suignard"> <organization/> </author> <datemonth="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 in a RELOAD overlay network collectively run an overlay algorithm to organize the overlay and to store and retrieve data. This document describes how the default topology plugin of RELOAD can be extended to support self-tuning, that is, to adapt to changing operating conditions such as churn and network size.</t> </abstract>year="2023" month="September"/> </front><seriesInfo name="RFC" value="7363"/> <seriesInfo name="DOI" value="10.17487/RFC7363"/> </reference> <reference anchor="RFC8324" target="https://www.rfc-editor.org/info/rfc8324" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8324.xml" quoteTitle="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 completed almost 30 years ago.<refcontent>Revision 31, Thelast half of that period has been characterized by significant changes in requirements and expectations, some of which either require changes to how the DNS is used or can be accommodated only poorly or not at all. This document asks the question of whether it is time to either redesign and replace the DNS to match contemporary requirements and expectations (rather than continuing to try to design and implement incremental patches that are not fully satisfactory) or draw some clear lines about functionality that is not really needed or that should be performed in some other way.</t> </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/rfc8806" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8806.xml" quoteTitle="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 difficulty getting responses from the root servers, such as during a network attack. Some DNS recursive resolver operators want to prevent snooping by third parties of requests sent to DNS root servers. In both cases, resolvers can greatly decrease the round-trip time and prevent observation of requests by serving a copy of the full root zone on the same server, such as on a loopback address or in the resolver software. This document shows how to start and maintain such a copy of the root zone that does not cause problems for other users of the DNS, at the cost of adding some operational fragility for the operator.</t> <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/rfc6761" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6761.xml" quoteTitle="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 Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names.</t> </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/rfc8244" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8244.xml" quoteTitle="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, to present challenges that were not anticipated when RFC 6761 was written. This memo presents a list, intended to be comprehensive, of the problems that have since been identified. In addition, it reviews the history of domain names and summarizes current IETF publications and some publications from other organizations relating to Special-Use Domain Names.</t> <t indent="0">This document should be considered required reading for IETF participants who wish to express an informed opinion on the topic of Special-Use Domain Names.</t> </abstract> </front> <seriesInfo name="RFC" value="8244"/> <seriesInfo name="DOI" value="10.17487/RFC8244"/>Unicode Consortium, Mountain View</refcontent> </reference> </references> <references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1928.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7363.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8324.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8806.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6761.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8244.xml"/> <!-- draft-ietf-dnsop-alt-tld (RFC 9476; published) --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9476.xml"/> <referenceanchor="I-D.ietf-dnsop-alt-tld" target="https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-alt-tld-25" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dnsop-alt-tld.xml" quoteTitle="true" derivedAnchor="I-D.ietf-dnsop-alt-tld">anchor="TorRendSpec" target="https://github.com/torproject/torspec/blob/main/rend-spec-v3.txt"> <front><title>The ALT Special Use Top Level Domain</title> <author fullname="Warren "Ace" Kumari" initials="W. A." surname="Kumari"> <organization showOnFrontPage="true">Google</organization> </author> <author fullname="Paul E. Hoffman" initials="P. E." surname="Hoffman"> <organization showOnFrontPage="true">ICANN</organization><title>Tor Rendezvous Specification - Version 3</title> <author> <organization>Tor Project</organization> </author> <dateday="4" month="May"month="June" year="2023"/><abstract> <t indent="0">This document reserves a TLD label, "alt" to be used in non-DNS contexts. It also provides advice and guidance to developers developing alternative namespaces. [ This document is being collaborated on in Github at <https://github.com/wkumari/draft-wkumari-dnsop-alt-tld>. The most recent version of the document, open issues, etc should all be available here. The authors (gratefully) accept pull requests. ]</t> </abstract></front><seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-alt-tld-25"/> <refcontent>Work in Progress</refcontent><refcontent>commit b345ca0</refcontent> </reference> <reference anchor="Tor224"target="https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n2135" quoteTitle="true" derivedAnchor="Tor224">target="https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n2135"> <front> <title>Next-Generation Hidden Services in Tor</title> <author initials="D." surname="Goulet" fullname="David Goulet"> </author> <author initials="G." surname="Kadianakis" fullname="George Kadianakis"> </author> <author initials="N." surname="Mathewson" fullname="Nick Mathewson"> </author> <date year="2013" month="November"/> </front> <refcontent>Appendix A.2 ("Tor's key derivation scheme")</refcontent> </reference> <reference anchor="SDSI"target="http://people.csail.mit.edu/rivest/Sdsi10.ps" quoteTitle="true" derivedAnchor="SDSI">target="https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=3837e0206bf73e5e8f0ba6db767a2f714ea7c367"> <front> <title>SDSI - A Simple Distributed Security Infrastructure</title> <authorinitials="R."initials="R. L." surname="Rivest" fullname="Ron L. Rivest"> </author> <author initials="B." surname="Lampson" fullname="Butler Lampson"> </author> <date year="1996"month="April"/>month="October"/> </front> </reference> <reference anchor="Kademlia"target="http://css.csail.mit.edu/6.824/2014/papers/kademlia.pdf" quoteTitle="true" derivedAnchor="Kademlia">target="https://css.csail.mit.edu/6.824/2014/papers/kademlia.pdf"> <front> <title>Kademlia: Apeer-to-peer information system basedPeer-to-peer Information System Based on thexor metric.</title>XOR Metric</title> <author initials="P." surname="Maymounkov" fullname="Petar Maymounkov"> </author> <author initials="D."surname="Mazieres"surname="Mazières" fullname="DavidMazieres">Mazières"> </author> <date year="2002"/> </front> <seriesInfo name="DOI" value="10.1007/3-540-45748-8_5"/> </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-20110926.pdf" quoteTitle="true" derivedAnchor="ed25519">target="https://ed25519.cr.yp.to/ed25519-20110926.pdf"> <front><title>High-Speed High-Security Signatures</title><title>High-speed high-security signatures</title> <authorinitials="D."initials="D. J." surname="Bernstein" fullname="Daniel Bernstein"><organization showOnFrontPage="true">University<organization>University of Illinois at Chicago</organization> </author> <author initials="N." surname="Duif" fullname="Niels Duif"><organization showOnFrontPage="true">Technische<organization>Technische Universiteit Eindhoven</organization> </author> <author initials="T." surname="Lange" fullname="Tanja Lange"><organization showOnFrontPage="true">Technische<organization>Technische Universiteit Eindhoven</organization> </author> <author initials="P." surname="Schwabe" fullname="Peter Schwabe"><organization showOnFrontPage="true">National<organization>National Taiwan University</organization> </author> <authorinitials="B."initials="B-Y." surname="Yang" fullname="Bo-Yin Yang"><organization showOnFrontPage="true">Academia<organization>Academia Sinica</organization> </author> <date year="2011"/> </front> <seriesInfo name="DOI" value="10.1007/s13389-012-0027-1"/> </reference> <reference anchor="GNS"target="https://sci-hub.st/10.1007/978-3-319-12280-9_9" quoteTitle="true" derivedAnchor="GNS">target="https://sci-hub.st/10.1007/978-3-319-12280-9_9"> <front> <title>A Censorship-Resistant, Privacy-Enhancing and Fully Decentralized Name System</title> <author initials="M." surname="Wachs" fullname="Matthias Wachs"><organization showOnFrontPage="true">Technische<organization>Technische Universität München</organization> </author> <author initials="M." surname="Schanzenbach" fullname="Martin Schanzenbach"><organization showOnFrontPage="true">Technische<organization>Technische Universität München</organization> </author> <author initials="C." surname="Grothoff" fullname="Christian Grothoff"><organization showOnFrontPage="true">Technische<organization>Technische Universität München</organization> </author> <date month="October" year="2014"/> </front> <refcontent>13th International Conference on Cryptology and Network Security (CANS)</refcontent> <seriesInfo name="DOI" value="10.13140/2.1.4642.3044"/> </reference> <reference anchor="R5N"target="https://sci-hub.st/10.1109/ICNSS.2011.6060022" quoteTitle="true" derivedAnchor="R5N">target="https://sci-hub.st/10.1109/ICNSS.2011.6060022"> <front> <title>R5N: Randomizedrecursive routingRecursive Routing forrestricted-route networks</title>Restricted-Route Networks</title> <author initials="N. S." surname="Evans" fullname="Nathan S. Evans"><organization showOnFrontPage="true">Technische<organization>Technische Universität München</organization> </author> <author initials="C." surname="Grothoff" fullname="Christian Grothoff"><organization showOnFrontPage="true">Technische<organization>Technische Universität München</organization> </author> <date month="September" year="2011"/> </front> <refcontent>5th International Conference on Network and System Security (NSS)</refcontent> <seriesInfo name="DOI" value="10.1109/ICNSS.2011.6060022"/> </reference> <reference anchor="SecureNS"target="https://sci-hub.st/https://doi.org/10.1016/j.cose.2018.01.018" quoteTitle="true" derivedAnchor="SecureNS">target="https://sci-hub.st/https://doi.org/10.1016/j.cose.2018.01.018"> <front><title>Towards<title>Toward secure name resolution on the Internet</title> <author initials="C." surname="Grothoff" fullname="Christian Grothoff"><organization showOnFrontPage="true">Bern<organization>Bern University of Applied Sciences</organization> </author> <author initials="M." surname="Wachs" fullname="Matthias Wachs"><organization showOnFrontPage="true">Technische<organization>Technische Universität München</organization> </author> <author initials="M." surname="Ermert" fullname="Monika Ermert"> </author> <author initials="J." surname="Appelbaum" fullname="Jacob Appelbaum"><organization showOnFrontPage="true">TU<organization>TU Eindhoven</organization> </author> <date month="August" year="2018"/> </front> <refcontent>Computers and Security, Volume 77, Issue C, pp. 694-708</refcontent> <seriesInfo name="DOI" value="10.1016/j.cose.2018.01.018"/> </reference> <reference anchor="GNUnetGNS"target="https://git.gnunet.org/gnunet.git/tree/src/gns" quoteTitle="true" derivedAnchor="GNUnetGNS">target="https://git.gnunet.org/gnunet.git"> <front><title>The<title>gnunet.git - GNUnetGNS Implementation</title>core repository</title> <author><organization showOnFrontPage="true">GNUnet<organization>GNUnet e.V.</organization> </author> <date year="2023"/> </front> </reference> <reference anchor="Ascension"target="https://git.gnunet.org/ascension.git" quoteTitle="true" derivedAnchor="Ascension">target="https://git.gnunet.org/ascension.git"> <front><title>The Ascension Implementation</title><title>ascension.git - DNS zones to GNS migrating using incremental zone transfer (AXFR/IXFR)</title> <author><organization showOnFrontPage="true">GNUnet<organization>GNUnet e.V.</organization> </author> <date year="2023"/> </front> </reference> <reference anchor="GNUnet"target="https://gnunet.org" quoteTitle="true" derivedAnchor="GNUnet">target="https://gnunet.org"> <front> <title>The GNUnetProject</title>Project (Home Page)</title> <author><organization showOnFrontPage="true">GNUnet<organization>GNUnet e.V.</organization> </author> <date year="2023"/> </front> </reference> <reference anchor="reclaim"target="https://reclaim.gnunet.org" quoteTitle="true" derivedAnchor="reclaim">target="https://reclaim.gnunet.org"> <front><title>re:claimID</title><title>re:claimID - Self-sovereign, Decentralised Identity Management and Personal Data Sharing</title> <author><organization showOnFrontPage="true">GNUnet<organization>GNUnet e.V.</organization> </author> <date year="2023"/> </front> </reference> <reference anchor="GoGNS"target="https://github.com/bfix/gnunet-go/tree/master/src/gnunet/service/gns" quoteTitle="true" derivedAnchor="GoGNS">target="https://github.com/bfix/gnunet-go/tree/master/src/gnunet/service/gns"> <front><title>The Go GNS Implementation</title><title>gnunet-go (Go GNS)</title> <author initials="B." surname="Fix" fullname="Bernd Fix"> </author> <date month="July" year="2023"/> </front> <refcontent>commit 5c815ba</refcontent> </reference> <reference anchor="nsswitch"target="https://www.gnu.org/software/libc/manual/html_node/Name-Service-Switch.html" quoteTitle="true" derivedAnchor="nsswitch">target="https://www.gnu.org/software/libc/manual/html_node/Name-Service-Switch.html"> <front> <title>System Databases and Name ServiceSwitch</title>Switch (Section 29)</title> <author><organization showOnFrontPage="true">GNU<organization>GNU Project</organization> </author> </front> </reference> </references><section numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a"> <name slugifiedName="name-usage-and-migration">Usage</references> <section> <name>Usage and Migration</name><t indent="0" pn="section-appendix.a-1"><t> This section outlines a number of specific use caseswhichthat may help readers ofthethis technical specificationtobetter understand theprotocol better.protocol. The considerations below are not meant to be normative for the GNS protocol in any way. Instead, they are provided in order to give context and to provide some background on what the intended use of the protocol is by its designers. Further, this sectioncontainsprovides pointers to migration paths. </t> <sectionanchor="day_in_zoneowner" numbered="true" removeInRFC="false" toc="include" pn="section-a.1"> <name slugifiedName="name-zone-dissemination">Zoneanchor="day_in_zoneowner"> <name>Zone Dissemination</name><t indent="0" pn="section-a.1-1"><t> In order to become a zone owner, it is sufficient to generate 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 local zone database. The resource records can then be published by a GNS implementation as defined in <xreftarget="publish" format="default" sectionFormat="of" derivedContent="Section 6"/>.target="publish"/>. For other users to resolve the resource records, the respective zone information must be disseminated first. 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 the general public. </t><t indent="0" pn="section-a.1-2"><t> Sharing zone information directly with specific users not only allows an implementation to potentially preserve zone and recordprivacy,privacy but also allows the zone owner and the user to establish strong trust relationships. For example, a bank may send a customer letter with a QR codewhichthat contains the GNS zone of the bank. 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 of the online banking web site. </t><t indent="0" pn="section-a.1-3"><t> Most Internet services likely want to make their zones available to the general publicas efficiently asin the most efficient way possible. First, it is reasonable to assume that zoneswhichthat are commanding high levels of reputation and trust are likely included in the default suffix-to-zone mappings of implementations.HenceHence, dissemination of a zone through delegation under such zones can be a viable path in order to disseminate a zone publicly. For example, it is conceivable that organizations such as ICANN or country-codetop-level domainTLD registrars also manage GNS zones and offer registration or delegation services. </t><t indent="0" pn="section-a.1-4"><t> Following bestpractices inpractices, particularly thoserelatingrelated to security and abusemitigationmitigation, are methodswhichthat allow zone owners and aspiring registrars to gain a good reputationand eventuallyand, eventually, trust. This includes, of course, diligent protection of private zone key material. Formalizing such best practices is out of scopeoffor this specification and should be addressed in a separate documentand takethat takes <xreftarget="security" format="default" sectionFormat="of" derivedContent="Section 9"/>target="security"/> of this document into account. </t> </section><section numbered="true" removeInRFC="false" toc="include" pn="section-a.2"> <name slugifiedName="name-start-zone-configuration">Start<section> <name>Start Zone Configuration</name><t indent="0" pn="section-a.2-1"><t> A user is expected to install a GNS implementation if it is not already provided through other means such as the operating system or the browser. It is likely that the implementation ships with a defaultstart zoneStart Zone configuration. 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 defaultstart zoneStart Zone configuration. At thispointpoint, the user may delete or otherwise modify the implementation's default configuration: </t><t indent="0" pn="section-a.2-2"><ul> <li> Deletion of suffix-to-zone mappings may become necessaryofif the zone owner referenced by the mapping has lost the trust of the user. For example, this could be due to lax registration policies resulting in phishing activities. Modification and addition of new mappings are means to heal the namespace perforationwhichthat would occur in the case of a deletion or to simply establish a strong direct trust relationship. However, this requires the user's knowledge of the respective zone keys. This information must be retrieved out of band, as illustrated in <xreftarget="day_in_zoneowner" format="default" sectionFormat="of" derivedContent="Appendix A.1"/>: Atarget="day_in_zoneowner"/>: a bank may send the user a letter with a QR codewhichthat contains the GNS zone of the bank. The user scans the QR code and adds a new suffix-to-name mapping using a chosen local name forhistheir bank. Other examples include scanning zone information off the device of a friend, from a storefront, or from an advertisement. The level of trust in the respective zone is contextual and likely varies from user to user. Trust in a zone provided through a letter from a bankwhichthat may also include a credit card is certainly different from a zone found on a random advertisementinon thestreets.street. However, this trust is immediately tangible to the user and can be reflected in the local naming as well.</t> <t indent="0" pn="section-a.2-3"> User</li> <li> Users that are also clients should facilitate the modification of thestart zone configuration,Start Zone configuration -- forexampleexample, by providing a QR code reader or other import mechanisms. Implementations are ideally implemented according to best practices and addressing applicable points from <xreftarget="security" format="default" sectionFormat="of" derivedContent="Section 9"/>.target="security"/>. Formalizing such best practices is out of scopeoffor this specification.</t></li> </ul> </section> <sectionanchor="uc_virthost" numbered="true" removeInRFC="false" toc="include" pn="section-a.3"> <name slugifiedName="name-globally-unique-names-and-t">Globallyanchor="uc_virthost"> <name>Globally Unique Names and the Web</name><t indent="0" pn="section-a.3-1"><t> HTTP virtual hosting and TLS Server Name Indication (SNI) are common use cases on the Web. HTTP clients supply a DNS name in the HTTP "Host"-header or as part of the TLS handshake, respectively. This allows the HTTP server to serve the indicated virtual host with a matching TLS certificate. The global uniqueness of DNS namesareis a prerequisite of those use cases. </t><t indent="0" pn="section-a.3-2"><t> Not all GNS names are globally unique.But,However, any resource record in GNS can be represented as a concatenation ofofa GNS label and the zTLD of the zone. While nothuman-readable,memorable, this globally unique GNS name can be leveraged in order to facilitate the same use cases. Consider the GNS name"www.example.gns""www.example.gns.alt" entered in a GNS-aware HTTP client. At first,"www.example.gns""www.example.gns.alt" is resolved usingGNSGNS, yielding a record set. Then, the HTTP client determines the virtual host as follows: </t><t indent="0" pn="section-a.3-3"><t> If there is a LEHO record (<xreftarget="gnsrecords_leho" format="default" sectionFormat="of" derivedContent="Section 5.3.1"/>)target="gnsrecords_leho"/>) containing "www.example.com" in the record set, then the HTTP client uses this as the value of the "Host"-header field of the HTTP request: </t><artwork<sourcecode name=""type="" align="left" alt="" pn="section-a.3-4">type="http-message"><![CDATA[ GET / HTTP/1.1 Host: www.example.com</artwork> <t indent="0" pn="section-a.3-5"> If there is no LEHO record in the record set, then the HTTP client tries to find the zone of the record and translates the GNS name into a globally unique zTLD-representation before using it in the "Host"-header field of the HTTP request: </t> <artwork name="" type="" align="left" alt="" pn="section-a.3-6"> GET / HTTP/1.1 Host: www.000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W </artwork> <t indent="0" pn="section-a.3-7">]]></sourcecode> <t> Inorder to determinethecanonical representationabsence ofthe record withazTLD, at most two queries are required: First, it must be checkedLEHO record, an additional GNS resolution is required to check whether "www.example.gns.alt" itself points to a zone delegationrecordrecord, whichwould implyimplies that the record setwhichthat was originally resolved is published under the apex label. </t> <t> If it does, the unique GNS name is simply the zTLD representation of the delegated zone: </t><artwork<sourcecode name=""type="" align="left" alt="" pn="section-a.3-8">type="http-message"><![CDATA[ GET / HTTP/1.1 Host: 000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W</artwork> <t indent="0" pn="section-a.3-9"> If it does not,]]></sourcecode> <t> On the other hand, if there is no zone delegation record for "www.example.gns.alt", then the unique GNS name is the concatenation of the leftmost label"www"(e.g., "www") and the zTLD representation of thezone as given in the example above. In any case,zone: </t> <sourcecode name="" type="http-message"><![CDATA[ GET / HTTP/1.1 Host: www.000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W ]]></sourcecode> <t> Note that thisrepresentation is globally unique. As such, it can be configured bysecond GNS resolution does not require any additional network operation, as only theHTTP server administratorlocal record processing differs asa virtual host name and respective certificates may be issued.per the exception mentioned in the last sentence of <xref target="delegation_processing"/>. </t><t indent="0" pn="section-a.3-10"><t> 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 shown to the user. For example, the name in the URL bar may remain as "www.example.gns.alt" even if the used unique name in the "Host"-header differs. </t> </section><section numbered="true" removeInRFC="false" toc="include" pn="section-a.4"> <name slugifiedName="name-migration-paths">Migration<section> <name>Migration Paths</name><t indent="0" pn="section-a.4-1"><t> DNS resolution is built into a variety of existing softwarecomponents. Most significantlycomponents -- most significantly, operating systems and HTTP clients. This section illustrates possible migration paths for both in order to enable"legacy"legacy applications to resolve GNS names. </t><t indent="0" pn="section-a.4-2"><t> One way to efficiently facilitate the resolution of GNS namesareis via GNS-enabled DNS server implementations. Local DNS queries are thereby either rerouted or explicitly configured to be resolved by a "DNS-to-GNS" server that runs locally. This DNS server tries to interpret any incoming query for a name as a GNS resolution request. If nostart zoneStart Zone can be found for the name and it does not end in a zTLD, the server tries to resolve the name in DNS. Otherwise, the name is resolved in GNS. In the latter case, the resulting record set is converted to a DNS answer packet and is returned accordingly. An implementation of a DNS-to-GNS server can be found in <xreftarget="GNUnet" format="default" sectionFormat="of" derivedContent="GNUnet"/>.target="GNUnet"/>. </t><t indent="0" pn="section-a.4-3"><t> A similar approach is to use operatingsystemssystem extensions such as thename service switchNSS <xreftarget="nsswitch" format="default" sectionFormat="of" derivedContent="nsswitch"/>.target="nsswitch"/>. It allows the system administrator to configure pluginswhichthat are used for hostname resolution. A GNSname service switchnsswitch plugin can be used in asimilarfashionassimilar to that used for the"DNS-to-GNS"DNS-to-GNS server. An implementation of a glibc-compatible nsswitch plugin for GNS can be found in <xreftarget="GNUnet" format="default" sectionFormat="of" derivedContent="GNUnet"/>.target="GNUnet"/>. </t><t indent="0" pn="section-a.4-4"><t> The methods above are usually also effective for HTTP client software. However, HTTP clients are commonly used in combination with TLS. TLS certificatevalidationvalidation, and SNI inparticular server name indication (SNI) requiresparticular, require additional logic in HTTP clients when GNS names are in play (<xreftarget="uc_virthost" format="default" sectionFormat="of" derivedContent="Appendix A.3"/>).target="uc_virthost"/>). In order to transparently enable this functionality for migration purposes, a local GNS-aware SOCKS5 proxy <xreftarget="RFC1928" format="default" sectionFormat="of" derivedContent="RFC1928"/>target="RFC1928"/> can be configured to resolve domain names. The SOCKS5 proxy, similar to the DNS-to-GNS server, is capable of resolving both GNS and DNS names. In the event of a TLS connection request with a GNS name, the SOCKS5 proxy canact as a man-in-the-middle, terminatingterminate the TLS connection andestablishingestablish a secure connection against the requested host. In order to establish a secure connection, the proxy may use LEHO and TLSA records stored in the record set under the GNS name. The proxy must provide a locally trusted certificate for the GNS name to the HTTPclient whichclient; this usually requires the generation and configuration of a local trust anchor in the browser. An implementation of this SOCKS5 proxy can be found in <xreftarget="GNUnet" format="default" sectionFormat="of" derivedContent="GNUnet"/>.target="GNUnet"/>. </t> </section> </section><section numbered="true" removeInRFC="false" toc="include" pn="section-appendix.b"> <name slugifiedName="name-example-flows">Example flows</name> <section numbered="true" removeInRFC="false" toc="include" pn="section-b.1"> <name slugifiedName="name-aaaa-example-resolution">AAAA<section> <name>Example Flows</name> <section> <name>AAAA Example Resolution</name> <figureanchor="figure_resolution_ex_aaaa" align="left" suppress-title="false" pn="figure-27"> <name slugifiedName="name-example-resolution-of-an-ip">Example resolutionanchor="figure_resolution_ex_aaaa"> <name>Example Resolution of an IPv6address.</name>Address</name> <artwork name="" type=""align="left" alt="" pn="section-b.1-1.1">alt=""> Local Host | Remote | Storage | | +---------+ | / /| | +---------+ | +-----------+ (1) +----------+ | | | | | | | | (4,6) | | Record | | |Application|----------| Resolver |---------------|->| Storage | | | |<---------| |<--------------|--| |/ +-----------+ (8) +----------+ (5,7) | +---------+ A | | | (2,3) | | | | | | +---------+ | / v /| | +---------+ | | | | | | | Start | | | | Zones | | | | |/ | +---------+ | </artwork> </figure><ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-b.1-2"> <li pn="section-b.1-2.1" derivedCounter="1.">Lookup<ol> <li>Look up AAAA record for name:www.example.gnu.gns.alt.</li> <li pn="section-b.1-2.2" derivedCounter="2.">Determine start zone"www.example.gnu.gns.alt".</li> <li>Determine Start Zone forwww.example.gnu.gns.alt.</li> <li pn="section-b.1-2.3" derivedCounter="3.">Start zone: zk0"www.example.gnu.gns.alt".</li> <li>Start Zone: zkey0 - Remainder:www.example.</li> <li pn="section-b.1-2.4" derivedCounter="4.">Calculate q0=SHA512(ZKDF(zk0,"www.example".</li> <li>Calculate q0=SHA512(ZKDF(zkey0, "example")) and initiate GET(q0).</li><li pn="section-b.1-2.5" derivedCounter="5.">Retrieve<li>Retrieve and decrypt RRBLOCK consisting of a single PKEY record containingzk1.</li> <li pn="section-b.1-2.6" derivedCounter="6.">Calculate q1=SHA512(ZKDF(zk1,zkey1.</li> <li>Calculate q1=SHA512(ZKDF(zkey1, "www")) and initiate GET(q1).</li><li pn="section-b.1-2.7" derivedCounter="7.">Retrieve<li>Retrieve RRBLOCK consisting of a single AAAA record containing the IPv6 address 2001:db8::1.</li><li pn="section-b.1-2.8" derivedCounter="8.">Return<li>Return record set toapplication</li>application.</li> </ol> </section><section numbered="true" removeInRFC="false" toc="include" pn="section-b.2"> <name slugifiedName="name-redirect-example-resolution">REDIRECT<section> <name>REDIRECT Example Resolution</name> <figureanchor="figure_resolution_ex_redir" align="left" suppress-title="false" pn="figure-28"> <name slugifiedName="name-example-resolution-of-an-ipv">Example resolutionanchor="figure_resolution_ex_redir"> <name>Example Resolution of an IPv6addressAddress withredirect.</name>Redirect</name> <artwork name="" type=""align="left" alt="" pn="section-b.2-1.1">alt=""> Local Host | Remote | Storage | | +---------+ | / /| | +---------+ | +-----------+ (1) +----------+ | | | | | | | | (4,6,8) | | Record | | |Application|----------| Resolver |----------------|->| Storage | | | |<---------| |<---------------|--| |/ +-----------+ (10) +----------+ (5,7,9) | +---------+ A | | | (2,3) | | | | | | +---------+ | / v /| | +---------+ | | | | | | | Start | | | | Zones | | | | |/ | +---------+ | </artwork> </figure><ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-b.2-2"> <li pn="section-b.2-2.1" derivedCounter="1.">Lookup<ol> <li>Look up AAAA record for name:www.example.tld.gns.alt.</li> <li pn="section-b.2-2.2" derivedCounter="2.">Determine start zone"www.example.tld.gns.alt".</li> <li>Determine Start Zone forwww.example.tld.gns.alt.</li> <li pn="section-b.2-2.3" derivedCounter="3.">Start zone: zk0"www.example.tld.gns.alt".</li> <li>Start Zone: zkey0 - Remainder:www.example.</li> <li pn="section-b.2-2.4" derivedCounter="4.">Calculate q0=SHA512(ZKDF(zk0,"www.example".</li> <li>Calculate q0=SHA512(ZKDF(zkey0, "example")) and initiate GET(q0).</li><li pn="section-b.2-2.5" derivedCounter="5.">Retrieve<li>Retrieve and decrypt RRBLOCK consisting of a single PKEY record containingzk1.</li> <li pn="section-b.2-2.6" derivedCounter="6.">Calculate q1=SHA512(ZKDF(zk1,zkey1.</li> <li>Calculate q1=SHA512(ZKDF(zkey1, "www")) and initiate GET(q1).</li><li pn="section-b.2-2.7" derivedCounter="7.">Retrieve<li>Retrieve and decrypt RRBLOCK consisting of a single REDIRECT record containingwww2.+.</li> <li pn="section-b.2-2.8" derivedCounter="8.">Calculate q2=SHA512(ZKDF(zk1,"www2.+".</li> <li>Calculate q2=SHA512(ZKDF(zkey1, "www2")) and initiate GET(q2).</li><li pn="section-b.2-2.9" derivedCounter="9.">Retrieve<li>Retrieve and decrypt RRBLOCK consisting of a single AAAA record containing the IPv6 address 2001:db8::1.</li><li pn="section-b.2-2.10" derivedCounter="10.">Return<li>Return record set to application.</li> </ol> </section><section numbered="true" removeInRFC="false" toc="include" pn="section-b.3"> <name slugifiedName="name-gns2dns-example-resolution">GNS2DNS<section> <name>GNS2DNS Example Resolution</name> <figureanchor="figure_resolution_ex_gnsdns" align="left" suppress-title="false" pn="figure-29"> <name slugifiedName="name-example-resolution-of-an-ipv6">Example resolutionanchor="figure_resolution_ex_gnsdns"> <name>Example Resolution of an IPv6addressAddress with DNShandover.</name>Handover</name> <artwork name="" type=""align="left" alt="" pn="section-b.3-1.1">alt=""> Local Host | Remote | Storage | | +---------+ | / /| | +---------+ | +-----------+ (1) +----------+ | | | | | | | | (4) | | Record | | |Application|----------| Resolver |------------------|->| Storage | | | |<---------| |<-----------------|--| |/ +-----------+ (8) +----------+ (5) | +---------+ A A | | | (6,7) | (2,3) | +----------+ | | | | | v | +---------+ +------------+ | / v /| | System DNS | | +---------+ | |resolverResolver | | | | | +------------+ | | Start | | | | Zones | | | | |/ | +---------+ | </artwork> </figure><ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-b.3-2"> <li pn="section-b.3-2.1" derivedCounter="1.">Lookup<ol> <li>Look up AAAA record for name:www.example.gnu.gns.alt</li> <li pn="section-b.3-2.2" derivedCounter="2.">Determine start zone"www.example.gnu.gns.alt".</li> <li>Determine Start Zone forwww.example.gnu.gns.alt.</li> <li pn="section-b.3-2.3" derivedCounter="3.">Start zone: zk0"www.example.gnu.gns.alt".</li> <li>Start Zone: zkey0 - Remainder:www.example.</li> <li pn="section-b.3-2.4" derivedCounter="4.">Calculate q0=SHA512(ZKDF(zk0,"www.example".</li> <li>Calculate q0=SHA512(ZKDF(zkey0, "example")) and initiate GET(q0).</li><li pn="section-b.3-2.5" derivedCounter="5.">Retrieve<li>Retrieve and decrypt RRBLOCK consisting of a single GNS2DNS record containing the nameexample.com"example.com" and the DNS server IPv4 address 192.0.2.1.</li><li pn="section-b.3-2.6" derivedCounter="6.">Use<li>Use system resolver tolookup anlook up a AAAA record for the DNS namewww.example.com.</li> <li pn="section-b.3-2.7" derivedCounter="7.">Retrieve"www.example.com".</li> <li>Retrieve a DNS reply consisting of a single AAAA record containing the IPv6 address 2001:db8::1.</li><li pn="section-b.3-2.8" derivedCounter="8.">Return<li>Return record set to application.</li> </ol> </section> </section> <sectionnumbered="true" removeInRFC="false" toc="include" pn="section-appendix.c"> <name slugifiedName="name-base32gns">Base32GNS</name> <t indent="0" pn="section-appendix.c-1">anchor="app-c"> <name>Base32GNS</name> <t> Encoding converts a byte array into a string of symbols. Decoding converts a string of symbols into a byte array. Decoding fails if the input string has symbols outside the defined set. </t><t indent="0" pn="section-appendix.c-2"> This table<t> <xref target="CrockfordB32Encode"/> defines theencodeencoding anddecodedecoding symbols for a given symbol value. Each symbol value encodes 5 bits. It can be used to implement the encoding by reading itas: Aas follows: a symbol "A" or "a" is decoded to a5 bit5-bit value 10 when decoding. A5 bit5-bit block with a value of 18 is encoded to the character "J" when encoding. If the bit length of the byte string to encode is not a multiple of55, it is padded to the next multiple with zeroes. 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 letter "V" in Base32GNS. </t><figure anchor="CrockfordB32Encode" align="left" suppress-title="false" pn="figure-30"> <name slugifiedName="name-the-base32gns-alphabet-incl">The<table anchor="CrockfordB32Encode"> <name>The Base32GNSAlphabetAlphabet, Including the AdditionalU Encode Symbol.</name> <artwork name="" type="" align="left" alt="" pn="section-appendix.c-3.1"> Symbol Decode Encode Value SymbolEncoding Symbol0 0"U"</name> <thead> <tr> <th>Symbol Value</th> <th>Decoding Symbol</th> <th>Encoding Symbol</th> </tr> </thead> <tbody> <tr> <td>0</td> <td>0 Oo 0 1 1o</td> <td>0</td> </tr> <tr> <td>1</td> <td>1 I i Ll 1 2 2 2 3 3 3 4 4 4 5 5 5 6 6 6 7 7 7 8 8 8 9 9 9 10 A a A 11 B b B 12 C c C 13 D d D 14 E e E 15 F f F 16 G g G 17 H h H 18 J j J 19 K k K 20 M m M 21 N n N 22 P p P 23 Q q Q 24 R r R 25 S s S 26 T t T 27 Vl</td> <td>1</td> </tr> <tr> <td>2</td> <td>2</td> <td>2</td> </tr> <tr> <td>3</td> <td>3</td> <td>3</td> </tr> <tr> <td>4</td> <td>4</td> <td>4</td> </tr> <tr> <td>5</td> <td>5</td> <td>5</td> </tr> <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 Uu V 28 W w W 29 X x X 30 Y y Y 31 Z z Z </artwork> </figure>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 numbered="true" removeInRFC="false" toc="include" pn="section-appendix.d"> <name slugifiedName="name-test-vectors">Test<section> <name>Test Vectors</name><t indent="0" pn="section-appendix.d-1"><t> The following test vectors can be used by implementations to test for conformance with this specification. Unless indicated otherwise, the test vectors are provided as hexadecimal byte arrays. </t><section numbered="true" removeInRFC="false" toc="include" pn="section-d.1"> <name slugifiedName="name-base32gns-en-decoding">Base32GNS en-/decoding</name> <t indent="0" pn="section-d.1-1"><section> <name>Base32GNS Encoding/Decoding</name> <t> The following are test vectors for the Base32GNS encoding used for zTLDs. The input strings are encoded without the zero terminator. </t><artwork<sourcecode name=""type="" align="left" alt="" pn="section-d.1-2">type="test-vectors"><![CDATA[ Base32GNS-Encode: Input string: "Hello World" Output string: "91JPRV3F41BPYWKCCG" Input bytes: 474e55204e616d652053797374656d Output string: "8X75A82EC5PPA82KF5SQ8SBD" Base32GNS-Decode: Input string: "91JPRV3F41BPYWKCCG" Output string: "Hello World" Input string: "91JPRU3F41BPYWKCCG" Output string: "Hello World"</artwork>]]></sourcecode> </section><section numbered="true" removeInRFC="false" toc="include" pn="section-d.2"> <name slugifiedName="name-record-sets">Record sets</name> <t indent="0" pn="section-d.2-1"><section> <name>Record Sets</name> <t> The test vectors include record sets with a variety of record types and flags for both PKEY and EDKEY zones. This includes labels with UTF-8 characters to demonstrate internationalized labels. </t><t indent="0" pn="section-d.2-2"><strong>(1)<t><strong>(1) PKEY zone with ASCII label and one delegation record</strong></t><artwork<sourcecode name=""type="" align="left" alt="" pn="section-d.2-3">type="test-vectors"><![CDATA[ Zone private key (d, big-endian): 50 d7 b6 52 a4 ef ea df f3 73 96 90 97 85 e5 95 21 71 a0 21 78 c8 e7 d4 50 fa 90 79 25 fa fd 98 Zone identifier (ztype|zkey): 00 01 00 00 67 7c 47 7d 2d 93 09 7c 85 b1 95 c6 f9 6d 84 ff 61 f5 98 2c 2c 4f e0 2d 5a 11 fe df b0 c2 90 1f zTLD: 000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W Label: 74 65 73 74 64 65 6c 65 67 61 74 69 6f 6e Number of records (integer): 1 Record #0 := ( EXPIRATION: 8143584694000000 us 00 1c ee 8c 10 e2 59 80 DATA_SIZE: 00 20 TYPE: 00 01 00 00 FLAGS: 00 01 DATA: 21 e3 b3 0f f9 3b c6 d3 5a c8 c6 e0 e1 3a fd ff 79 4c b7 b4 4b bb c7 48 d2 59 d0 a0 28 4d be 84 ) RDATA: 00 1c ee 8c 10 e2 59 80 00 20 00 01 00 01 00 00 21 e3 b3 0f f9 3b c6 d3 5a c8 c6 e0 e1 3a fd ff 79 4c b7 b4 4b bb c7 48 d2 59 d0 a0 28 4d be 84 Encryption NONCE|EXPIRATION|BLOCK COUNTER: e9 0a 00 61 00 1c ee 8c 10 e2 59 80 00 00 00 01 Encryption key (K): 86 4e 71 38 ea e7 fd 91 a3 01 36 89 9c 13 2b 23 ac eb db 2c ef 43 cb 19 f6 bf 55 b6 7d b9 b3 b3 Storage key (q): 4a dc 67 c5 ec ee 9f 76 98 6a bd 71 c2 22 4a 3d ce 2e 91 70 26 c9 a0 9d fd 44 ce f3 d2 0f 55 a2 73 32 72 5a 6c 8a fb bb b0 f7 ec 9a f1 cc 42 64 12 99 40 6b 04 fd 9b 5b 57 91 f8 6c 4b 08 d5 f4ZKDF(zkey):ZKDF(zkey, label): 18 2b b6 36 ed a7 9f 79 57 11 bc 27 08 ad bb 24 2a 60 44 6a d3 c3 08 03 12 1d 03 d3 48 b7 ce b6 Derived private key (d', big-endian): 0a 4c 5e 0f 00 63 df ce db c8 c7 f2 b2 2c 03 0c 86 28 b2 c2 cb ac 9f a7 29 aa e6 1f 89 db 3e 9c BDATA: 0c 1e da 5c c0 94 a1 c7 a8 88 64 9d 25 fa ee bd 60 da e6 07 3d 57 d8 ae 8d 45 5f 4f 13 92 c0 74 e2 6a c6 69 bd ee c2 34 62 b9 62 95 2c c6 e9 eb RRBLOCK: 00 00 00 a0 00 01 00 00 18 2b b6 36 ed a7 9f 79 57 11 bc 27 08 ad bb 24 2a 60 44 6a d3 c3 08 03 12 1d 03 d3 48 b7 ce b6 0a d1 0b c1 3b 40 3b 5b 25 61 26 b2 14 5a 6f 60 c5 14 f9 51 ff a7 66 f7 a3 fd 4b ac 4a 4e 19 90 05 5c b8 7e 8d 1b fd 19 aa 09 a4 29 f7 29 e9 f5 c6 ee c2 47 0a ce e2 22 07 59 e9 e3 6c 88 6f 35 00 1c ee 8c 10 e2 59 80 0c 1e da 5c c0 94 a1 c7 a8 88 64 9d 25 fa ee bd 60 da e6 07 3d 57 d8 ae 8d 45 5f 4f 13 92 c0 74 e2 6a c6 69 bd ee c2 34 62 b9 62 95 2c c6 e9 eb</artwork> <t indent="0" pn="section-d.2-4"><strong>(2)]]></sourcecode> <t><strong>(2) PKEY zone with UTF-8 label and three records</strong></t><artwork<sourcecode name=""type="" align="left" alt="" pn="section-d.2-5">type="test-vectors"><![CDATA[ Zone private key (d, big-endian): 50 d7 b6 52 a4 ef ea df f3 73 96 90 97 85 e5 95 21 71 a0 21 78 c8 e7 d4 50 fa 90 79 25 fa fd 98 Zone identifier (ztype|zkey): 00 01 00 00 67 7c 47 7d 2d 93 09 7c 85 b1 95 c6 f9 6d 84 ff 61 f5 98 2c 2c 4f e0 2d 5a 11 fe df b0 c2 90 1f zTLD: 000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W Label: e5 a4 a9 e4 b8 8b e7 84 a1 e6 95 b5 Number of records (integer): 3 Record #0 := ( EXPIRATION: 8143584694000000 us 00 1c ee 8c 10 e2 59 80 DATA_SIZE: 00 10 TYPE: 00 00 00 1c FLAGS: 00 00 DATA: 00 00 00 00 00 00 00 00 00 00 00 00 de ad be ef ) Record #1 := ( EXPIRATION: 17999736901000000 us 00 3f f2 aa 54 08 db 40 DATA_SIZE: 00 06 TYPE: 00 01 00 01 FLAGS: 00 00 DATA: e6 84 9b e7 a7 b0 ) Record #2 := ( EXPIRATION: 11464693629000000 us 00 28 bb 13 ff 37 19 40 DATA_SIZE: 00 0b TYPE: 00 00 00 10 FLAGS: 00 04 DATA: 48 65 6c 6c 6f 20 57 6f 72 6c 64 ) RDATA: 00 1c ee 8c 10 e2 59 80 00 10 00 00 00 00 00 1c 00 00 00 00 00 00 00 00 00 00 00 00 de ad be ef 00 3f f2 aa 54 08 db 40 00 06 00 00 00 01 00 01 e6 84 9b e7 a7 b0 00 28 bb 13 ff 37 19 40 00 0b 00 04 00 00 00 10 48 65 6c 6c 6f 20 57 6f 72 6c 64 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Encryption NONCE|EXPIRATION|BLOCK COUNTER: ee 96 33 c1 00 1c ee 8c 10 e2 59 80 00 00 00 01 Encryption key (K): fb 3a b5 de 23 bd da e1 99 7a af 7b 92 c2 d2 71 51 40 8b 77 af 7a 41 ac 79 05 7c 4d f5 38 3d 01 Storage key (q): af f0 ad 6a 44 09 73 68 42 9a c4 76 df a1 f3 4b ee 4c 36 e7 47 6d 07 aa 64 63 ff 20 91 5b 10 05 c0 99 1d ef 91 fc 3e 10 90 9f 87 02 c0 be 40 43 67 78 c7 11 f2 ca 47 d5 5c f0 b5 4d 23 5d a9 77ZKDF(zkey):ZKDF(zkey, label): a5 12 96 df 75 7e e2 75 ca 11 8d 4f 07 fa 7a ae 55 08 bc f5 12 aa 41 12 14 29 d4 a0 de 9d 05 7e Derived private key (d', big-endian): 0a be 56 d6 80 68 ab 40 e1 44 79 0c de 9a cf 4d 78 7f 2d 3c 63 b8 53 05 74 6e 68 03 32 15 f2 ab BDATA: d8 c2 8d 2f d6 96 7d 1a b7 22 53 f2 10 98 b8 14 a4 10 be 1f 59 98 de 03 f5 8f 7e 7c db 7f 08 a6 16 51 be 4d 0b 6f 8a 61 df 15 30 44 0b d7 47 dc f0 d7 10 4f 6b 8d 24 c2 ac 9b c1 3d 9c 6f e8 29 05 25 d2 a6 d0 f8 84 42 67 a1 57 0e 8e 29 4d c9 3a 31 9f cf c0 3e a2 70 17 d6 fd a3 47 b4 a7 94 97 d7 f6 b1 42 2d 4e dd 82 1c 19 93 4e 96 c1 aa 87 76 57 25 d4 94 c7 64 b1 55 dc 6d 13 26 91 74 RRBLOCK: 00 00 00 f0 00 01 00 00 a5 12 96 df 75 7e e2 75 ca 11 8d 4f 07 fa 7a ae 55 08 bc f5 12 aa 41 12 14 29 d4 a0 de 9d 05 7e 08 5b d6 5f d4 85 10 51 ba ce 2a 45 2a fc 8a 7e 4f 6b 2c 1f 74 f0 20 35 d9 64 1a cd ba a4 66 e0 00 ce d6 f2 d2 3b 63 1c 8e 8a 0b 38 e2 ba e7 9a 22 ca d8 1d 4c 50 d2 25 35 8e bc 17 ac 0f 89 9e 00 1c ee 8c 10 e2 59 80 d8 c2 8d 2f d6 96 7d 1a b7 22 53 f2 10 98 b8 14 a4 10 be 1f 59 98 de 03 f5 8f 7e 7c db 7f 08 a6 16 51 be 4d 0b 6f 8a 61 df 15 30 44 0b d7 47 dc f0 d7 10 4f 6b 8d 24 c2 ac 9b c1 3d 9c 6f e8 29 05 25 d2 a6 d0 f8 84 42 67 a1 57 0e 8e 29 4d c9 3a 31 9f cf c0 3e a2 70 17 d6 fd a3 47 b4 a7 94 97 d7 f6 b1 42 2d 4e dd 82 1c 19 93 4e 96 c1 aa 87 76 57 25 d4 94 c7 64 b1 55 dc 6d 13 26 91 74</artwork> <t indent="0" pn="section-d.2-6"><strong>(3)]]></sourcecode> <t><strong>(3) EDKEY zone with ASCII label and one delegation record</strong></t><artwork<sourcecode name=""type="" align="left" alt="" pn="section-d.2-7">type="test-vectors"><![CDATA[ Zone private key (d): 5a f7 02 0e e1 91 60 32 88 32 35 2b bc 6a 68 a8 d7 1a 7c be 1b 92 99 69 a7 c6 6d 41 5a 0d 8f 65 Zone identifier (ztype|zkey): 00 01 00 14 3c f4 b9 24 03 20 22 f0 dc 50 58 14 53 b8 5d 93 b0 47 b6 3d 44 6c 58 45 cb 48 44 5d db 96 68 8f zTLD: 000G051WYJWJ80S04BRDRM2R2H9VGQCKP13VCFA4DHC4BJT88HEXQ5K8HW Label: 74 65 73 74 64 65 6c 65 67 61 74 69 6f 6e Number of records (integer): 1 Record #0 := ( EXPIRATION: 8143584694000000 us 00 1c ee 8c 10 e2 59 80 DATA_SIZE: 00 20 TYPE: 00 01 00 00 FLAGS: 00 01 DATA: 21 e3 b3 0f f9 3b c6 d3 5a c8 c6 e0 e1 3a fd ff 79 4c b7 b4 4b bb c7 48 d2 59 d0 a0 28 4d be 84 ) RDATA: 00 1c ee 8c 10 e2 59 80 00 20 00 01 00 01 00 00 21 e3 b3 0f f9 3b c6 d3 5a c8 c6 e0 e1 3a fd ff 79 4c b7 b4 4b bb c7 48 d2 59 d0 a0 28 4d be 84 Encryption NONCE|EXPIRATION: 98 13 2e a8 68 59 d3 5c 88 bf d3 17 fa 99 1b cb 00 1c ee 8c 10 e2 59 80 Encryption key (K): 85 c4 29 a9 56 7a a6 33 41 1a 96 91 e9 09 4c 45 28 16 72 be 58 60 34 aa e4 a2 a2 cc 71 61 59 e2 Storage key (q): ab aa ba c0 e1 24 94 59 75 98 83 95 aa c0 24 1e 55 59 c4 1c 40 74 e2 55 7b 9f e6 d1 54 b6 14 fb cd d4 7f c7 f5 1d 78 6d c2 e0 b1 ec e7 60 37 c0 a1 57 8c 38 4e c6 1d 44 56 36 a9 4e 88 03 29 e9ZKDF(zkey):ZKDF(zkey, label): 9b f2 33 19 8c 6d 53 bb db ac 49 5c ab d9 10 49 a6 84 af 3f 40 51 ba ca b0 dc f2 1c 8c f2 7a 1a nonce :=SHA-256 (dh[32..63]SHA-256(dh[32..63] || h): 14 f2 c0 6b ed c3 aa 2d f0 71 13 9c 50 39 34 f3 4b fa 63 11 a8 52 f2 11 f7 3a df 2e 07 61 ec 35 Derived private key (d', big-endian): 3b 1b 29 d4 23 0b 10 a8 ec 4d a3 c8 6e db 88 ea cd 54 08 5c 1d db 63 f7 a9 d7 3f 7c cb 2f c3 98 BDATA: 57 7c c6 c9 5a 14 e7 04 09 f2 0b 01 67 e6 36 d0 10 80 7c 4f 00 37 2d 69 8c 82 6b d9 2b c2 2b d6 bb 45 e5 27 7c 01 88 1d 6a 43 60 68 e4 dd f1 c6 b7 d1 41 6f af a6 69 7c 25 ed d9 ea e9 91 67 c3 RRBLOCK: 00 00 00 b0 00 01 00 14 9b f2 33 19 8c 6d 53 bb db ac 49 5c ab d9 10 49 a6 84 af 3f 40 51 ba ca b0 dc f2 1c 8c f2 7a 1a 9f 56 a8 86 ea 73 9d 59 17 50 8f 9b 75 56 39 f3 a9 ac fa ed ed ca 7f bf a7 94 b1 92 e0 8b f9 ed 4c 7e c8 59 4c 9f 7b 4e 19 77 4f f8 38 ec 38 7a 8f 34 23 da ac 44 9f 59 db 4e 83 94 3f 90 72 00 00 1c ee 8c 10 e2 59 80 57 7c c6 c9 5a 14 e7 04 09 f2 0b 01 67 e6 36 d0 10 80 7c 4f 00 37 2d 69 8c 82 6b d9 2b c2 2b d6 bb 45 e5 27 7c 01 88 1d 6a 43 60 68 e4 dd f1 c6 b7 d1 41 6f af a6 69 7c 25 ed d9 ea e9 91 67 c3</artwork> <t indent="0" pn="section-d.2-8"><strong>(4)]]></sourcecode> <t><strong>(4) EDKEY zone with UTF-8 label and three records</strong></t><artwork<sourcecode name=""type="" align="left" alt="" pn="section-d.2-9">type="test-vectors"><![CDATA[ Zone private key (d): 5a f7 02 0e e1 91 60 32 88 32 35 2b bc 6a 68 a8 d7 1a 7c be 1b 92 99 69 a7 c6 6d 41 5a 0d 8f 65 Zone identifier (ztype|zkey): 00 01 00 14 3c f4 b9 24 03 20 22 f0 dc 50 58 14 53 b8 5d 93 b0 47 b6 3d 44 6c 58 45 cb 48 44 5d db 96 68 8f zTLD: 000G051WYJWJ80S04BRDRM2R2H9VGQCKP13VCFA4DHC4BJT88HEXQ5K8HW Label: e5 a4 a9 e4 b8 8b e7 84 a1 e6 95 b5 Number of records (integer): 3 Record #0 := ( EXPIRATION: 8143584694000000 us 00 1c ee 8c 10 e2 59 80 DATA_SIZE: 00 10 TYPE: 00 00 00 1c FLAGS: 00 00 DATA: 00 00 00 00 00 00 00 00 00 00 00 00 de ad be ef ) Record #1 := ( EXPIRATION: 17999736901000000 us 00 3f f2 aa 54 08 db 40 DATA_SIZE: 00 06 TYPE: 00 01 00 01 FLAGS: 00 00 DATA: e6 84 9b e7 a7 b0 ) Record #2 := ( EXPIRATION: 11464693629000000 us 00 28 bb 13 ff 37 19 40 DATA_SIZE: 00 0b TYPE: 00 00 00 10 FLAGS: 00 04 DATA: 48 65 6c 6c 6f 20 57 6f 72 6c 64 ) RDATA: 00 1c ee 8c 10 e2 59 80 00 10 00 00 00 00 00 1c 00 00 00 00 00 00 00 00 00 00 00 00 de ad be ef 00 3f f2 aa 54 08 db 40 00 06 00 00 00 01 00 01 e6 84 9b e7 a7 b0 00 28 bb 13 ff 37 19 40 00 0b 00 04 00 00 00 10 48 65 6c 6c 6f 20 57 6f 72 6c 64 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Encryption NONCE|EXPIRATION: bb 0d 3f 0f bd 22 42 77 50 da 5d 69 12 16 e6 c9 00 1c ee 8c 10 e2 59 80 Encryption key (K): 3d f8 05 bd 66 87 aa 14 20 96 28 c2 44 b1 11 91 88 c3 92 56 37 a4 1e 5d 76 49 6c 29 45 dc 37 7b Storage key (q): ba f8 21 77 ee c0 81 e0 74 a7 da 47 ff c6 48 77 58 fb 0d f0 1a 6c 7f bb 52 fc 8a 31 be f0 29 af 74 aa 0d c1 5a b8 e2 fa 7a 54 b4 f5 f6 37 f6 15 8f a7 f0 3c 3f ce be 78 d3 f9 d6 40 aa c0 d1 edZKDF(zkey):ZKDF(zkey, label): 74 f9 00 68 f1 67 69 53 52 a8 a6 c2 eb 98 48 98 c5 3a cc a0 98 04 70 c6 c8 12 64 cb dd 78 ad 11 nonce :=SHA-256 (dh[32..63]SHA-256(dh[32..63] || h): f8 6a b5 33 8a 74 d7 a1 d2 77 ea 11 ff 95 cb e8 3a cf d3 97 3b b4 ab ca 0a 1b 60 62 c3 7a b3 9c Derived private key (d', big-endian): 17 c0 68 a6 c3 f7 20 de 0e 1b 69 ff 3f 53 e0 5d 3f e5 c5 b0 51 25 7a 89 a6 3c 1a d3 5a c4 35 58 BDATA: 4e b3 5a 50 d4 0f e1 a4 29 c7 f4 b2 67 a0 59 de 4e 2c 8a 89 a5 ed 53 d3 d4 92 58 59 d2 94 9f 7f 30 d8 a2 0c aa 96 f8 81 45 05 2d 1c da 04 12 49 8f f2 5f f2 81 6e f0 ce 61 fe 69 9b fa c7 2c 15 dc 83 0e a9 b0 36 17 1c cf ca bb dd a8 de 3c 86 ed e2 95 70 d0 17 4b 82 82 09 48 a9 28 b7 f0 0e fb 40 1c 10 fe 80 bb bb 02 76 33 1b f7 f5 1b 8d 74 57 9c 14 14 f2 2d 50 1a d2 5a e2 49 f5 bb f2 a6 c3 72 59 d1 75 e4 40 b2 94 39 c6 05 19 cb b1 RRBLOCK: 00 00 01 00 00 01 00 14 74 f9 00 68 f1 67 69 53 52 a8 a6 c2 eb 98 48 98 c5 3a cc a0 98 04 70 c6 c8 12 64 cb dd 78 ad 11 75 6d 2c 15 7a d2 ea 4f c0 b1 b9 1c 08 03 79 44 61 d3 de f2 0d d1 63 6c fe dc 03 89 c5 49 d1 43 6c c3 5b 4e 1b f8 89 5a 64 6b d9 a6 f4 6b 83 48 1d 9c 0e 91 d4 e1 be bb 6a 83 52 6f b7 25 2a 06 00 1c ee 8c 10 e2 59 80 4e b3 5a 50 d4 0f e1 a4 29 c7 f4 b2 67 a0 59 de 4e 2c 8a 89 a5 ed 53 d3 d4 92 58 59 d2 94 9f 7f 30 d8 a2 0c aa 96 f8 81 45 05 2d 1c da 04 12 49 8f f2 5f f2 81 6e f0 ce 61 fe 69 9b fa c7 2c 15 dc 83 0e a9 b0 36 17 1c cf ca bb dd a8 de 3c 86 ed e2 95 70 d0 17 4b 82 82 09 48 a9 28 b7 f0 0e fb 40 1c 10 fe 80 bb bb 02 76 33 1b f7 f5 1b 8d 74 57 9c 14 14 f2 2d 50 1a d2 5a e2 49 f5 bb f2 a6 c3 72 59 d1 75 e4 40 b2 94 39 c6 05 19 cb b1</artwork>]]></sourcecode> </section><section numbered="true" removeInRFC="false" toc="include" pn="section-d.3"> <name slugifiedName="name-zone-revocation-2">Zone revocation</name> <t indent="0" pn="section-d.3-1"><section> <name>Zone Revocation</name> <t> The following is an example revocation for a PKEY zone: </t><artwork<sourcecode name=""type="" align="left" alt="" pn="section-d.3-2">type="test-vectors"><![CDATA[ Zone private key (d, big-endian): 6f ea 32 c0 5a f5 8b fa 97 95 53 d1 88 60 5f d5 7d 8b f9 cc 26 3b 78 d5 f7 47 8c 07 b9 98 ed 70 Zone identifier (ztype|zkey): 00 01 00 00 2c a2 23 e8 79 ec c4 bb de b5 da 17 31 92 81 d6 3b 2e 3b 69 55 f1 c3 77 5c 80 4a 98 d5 f8 dd aaEncoded zone identifier (zkl = zTLD):zTLD: 000G001CM8HYGYFCRJXXXDET2WRS50EP7CQ3PTANY71QEQ409ACDBY6XN8 Difficulty (5 base difficulty + 2 epochs): 7 Signed message: 00 00 00 34 00 00 00 03 00 05 ff 1c 56 e4 b2 68 00 01 00 00 2c a2 23 e8 79 ec c4 bb de b5 da 17 31 92 81 d6 3b 2e 3b 69 55 f1 c3 77 5c 80 4a 98 d5 f8 dd aa Proof: 00 05 ff 1c 56 e4 b2 68 00 00 39 5d 18 27 c0 00 38 0b 54 aa 70 16 ac a2 38 0b 54 aa 70 16 ad 62 38 0b 54 aa 70 16 af 3e 38 0b 54 aa 70 16 af 93 38 0b 54 aa 70 16 b0 bf 38 0b 54 aa 70 16 b0 ee 38 0b 54 aa 70 16 b1 c9 38 0b 54 aa 70 16 b1 e5 38 0b 54 aa 70 16 b2 78 38 0b 54 aa 70 16 b2 b2 38 0b 54 aa 70 16 b2 d6 38 0b 54 aa 70 16 b2 e4 38 0b 54 aa 70 16 b3 2c 38 0b 54 aa 70 16 b3 5a 38 0b 54 aa 70 16 b3 9d 38 0b 54 aa 70 16 b3 c0 38 0b 54 aa 70 16 b3 dd 38 0b 54 aa 70 16 b3 f4 38 0b 54 aa 70 16 b4 42 38 0b 54 aa 70 16 b4 76 38 0b 54 aa 70 16 b4 8c 38 0b 54 aa 70 16 b4 a4 38 0b 54 aa 70 16 b4 c9 38 0b 54 aa 70 16 b4 f0 38 0b 54 aa 70 16 b4 f7 38 0b 54 aa 70 16 b5 79 38 0b 54 aa 70 16 b6 34 38 0b 54 aa 70 16 b6 8e 38 0b 54 aa 70 16 b7 b4 38 0b 54 aa 70 16 b8 7e 38 0b 54 aa 70 16 b8 f8 38 0b 54 aa 70 16 b9 2a 00 01 00 00 2c a2 23 e8 79 ec c4 bb de b5 da 17 31 92 81 d6 3b 2e 3b 69 55 f1 c3 77 5c 80 4a 98 d5 f8 dd aa 08 ca ff de 3c 6d f1 45 f7 e0 79 81 15 37 b2 b0 42 2d 5e 1f b2 01 97 81 ec a2 61 d1 f9 d8 ea 81 0a bc 2f 33 47 7f 04 e3 64 81 11 be 71 c2 48 82 1a d6 04 f4 94 e7 4d 0b f5 11 d2 c1 62 77 2e 81</artwork> <t indent="0" pn="section-d.3-3">]]></sourcecode> <t> The following is an example revocation for an EDKEY zone: </t><artwork<sourcecode name=""type="" align="left" alt="" pn="section-d.3-4">type="test-vectors"><![CDATA[ Zone private key (d): 5a f7 02 0e e1 91 60 32 88 32 35 2b bc 6a 68 a8 d7 1a 7c be 1b 92 99 69 a7 c6 6d 41 5a 0d 8f 65 Zone identifier (ztype|zkey): 00 01 00 14 3c f4 b9 24 03 20 22 f0 dc 50 58 14 53 b8 5d 93 b0 47 b6 3d 44 6c 58 45 cb 48 44 5d db 96 68 8fEncoded zone identifier (zkl = zTLD):zTLD: 000G051WYJWJ80S04BRDRM2R2H9VGQCKP13VCFA4DHC4BJT88HEXQ5K8HW Difficulty (5 base difficulty + 2 epochs): 7 Signed message: 00 00 00 34 00 00 00 03 00 05 ff 1c 57 35 42 bd 00 01 00 14 3c f4 b9 24 03 20 22 f0 dc 50 58 14 53 b8 5d 93 b0 47 b6 3d 44 6c 58 45 cb 48 44 5d db 96 68 8f Proof: 00 05 ff 1c 57 35 42 bd 00 00 39 5d 18 27 c0 00 58 4c 93 3c b0 99 2a 08 58 4c 93 3c b0 99 2d f7 58 4c 93 3c b0 99 2e 21 58 4c 93 3c b0 99 2e 2a 58 4c 93 3c b0 99 2e 53 58 4c 93 3c b0 99 2e 8e 58 4c 93 3c b0 99 2f 13 58 4c 93 3c b0 99 2f 2d 58 4c 93 3c b0 99 2f 3c 58 4c 93 3c b0 99 2f 41 58 4c 93 3c b0 99 2f fd 58 4c 93 3c b0 99 30 33 58 4c 93 3c b0 99 30 82 58 4c 93 3c b0 99 30 a2 58 4c 93 3c b0 99 30 e1 58 4c 93 3c b0 99 31 ce 58 4c 93 3c b0 99 31 de 58 4c 93 3c b0 99 32 12 58 4c 93 3c b0 99 32 4e 58 4c 93 3c b0 99 32 9f 58 4c 93 3c b0 99 33 31 58 4c 93 3c b0 99 33 87 58 4c 93 3c b0 99 33 8c 58 4c 93 3c b0 99 33 e5 58 4c 93 3c b0 99 33 f3 58 4c 93 3c b0 99 34 26 58 4c 93 3c b0 99 34 30 58 4c 93 3c b0 99 34 68 58 4c 93 3c b0 99 34 88 58 4c 93 3c b0 99 34 8a 58 4c 93 3c b0 99 35 4c 58 4c 93 3c b0 99 35 bd 00 01 00 14 3c f4 b9 24 03 20 22 f0 dc 50 58 14 53 b8 5d 93 b0 47 b6 3d 44 6c 58 45 cb 48 44 5d db 96 68 8f 04 ae 26 f7 63 56 5a b7 aa ab 01 71 72 4f 3c a8 bc c5 1a 98 b7 d4 c9 2e a3 3c d9 34 4c a8 b6 3e 04 53 3a bf 1a 3c 05 49 16 b3 68 2c 5c a8 cb 4d d0 f8 4c 3b 77 48 7a ac 6e ce 38 48 0b a9 d5 00</artwork>]]></sourcecode> </section> </section><!-- Change Log v00 2017-07-23 MS Initial version --><sectionanchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.e"> <name slugifiedName="name-authors-addresses">Authors' Addresses</name> <author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach"> <organization showOnFrontPage="true">Fraunhofer AISEC</organization> <address> <postal> <street>Lichtenbergstrasse 11</street> <city>Garching</city> <code>85748</code> <country>DE</country> </postal> <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>numbered="false"> <name>Acknowledgements</name> <t> The authors thank all reviewers for their comments. In particular, we thank <contact fullname="D. J. Bernstein"/>, <contact fullname="S. Bortzmeyer"/>, <contact fullname="A. Farrel"/>, <contact fullname="E. Lear"/>, and <contact fullname="R. Salz"/> for their insightful and detailed technical reviews. We thank <contact fullname="J. Yao"/> and <contact fullname="J. Klensin"/> for the internationalization reviews. We thank <contact fullname="Dr. J. Appelbaum"/> for suggesting the name "GNU Name System" and <contact fullname="Dr. Richard Stallman"/> for approving its use. We thank <contact fullname="T. Lange"/> and <contact fullname="M. Wachs"/> for their earlier contributions to the design and implementation of GNS. We thank NLnet and NGI DISCOVERY for funding work on the GNU Name System. </t> </section> </back> </rfc>