[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: update with lsd series
|
From: |
gnunet |
|
Subject: |
[lsd0001] branch master updated: update with lsd series |
|
Date: |
Wed, 22 Nov 2023 15:25:45 +0100 |
This is an automated email from the git hooks/post-receive script.
martin-schanzenbach pushed a commit to branch master
in repository lsd0001.
The following commit(s) were added to refs/heads/master by this push:
new 6645cc9 update with lsd series
6645cc9 is described below
commit 6645cc9911083c25830dac78e4fc037816164e9a
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Wed Nov 22 15:25:32 2023 +0100
update with lsd series
---
.buildbot/firefly-x86_64-amdepyc_deploy.sh | 4 +-
Makefile | 4 +-
lsd0001.xml | 4782 ++++++++++++++++++++++++++++
3 files changed, 4786 insertions(+), 4 deletions(-)
diff --git a/.buildbot/firefly-x86_64-amdepyc_deploy.sh
b/.buildbot/firefly-x86_64-amdepyc_deploy.sh
index 78eff89..af821ab 100755
--- a/.buildbot/firefly-x86_64-amdepyc_deploy.sh
+++ b/.buildbot/firefly-x86_64-amdepyc_deploy.sh
@@ -5,6 +5,6 @@
if [ -e index.html ]; then
rm index.html
fi
-ln -s rfc9498.html index.html
-chmod -R ag+rX rfc9498.* index.html .
+ln -s lsd0001.html index.html
+chmod -R ag+rX lsd0001.* index.html .
rsync --exclude=".*" --exclude="Makefile" -a --delete ./
lsd@firefly.gnunet.org:~/public/lsd0001/
diff --git a/Makefile b/Makefile
index ba2d48b..19b1796 100644
--- a/Makefile
+++ b/Makefile
@@ -1,8 +1,8 @@
all: txt html
html:
- xml2rfc --html --css style.css rfc9498.xml
+ xml2rfc --html --css style.css lsd0001.xml
txt:
- xml2rfc rfc9498.xml
+ xml2rfc lsd0001.xml
diff --git a/lsd0001.xml b/lsd0001.xml
new file mode 100644
index 0000000..b36eae2
--- /dev/null
+++ b/lsd0001.xml
@@ -0,0 +1,4782 @@
+<?xml 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";
+ category="info"
+ docName="draft-schanzen-gns-28"
+ ipr="trust200902"
+ obsoletes=""
+ updates=""
+ submissionType="independent"
+ sortRefs="false"
+ symRefs="true"
+ tocDepth="3"
+ tocInclude="true"
+ xml:lang="en"
+ version="3">
+
+ <!-- xml2rfc v2v3 conversion 2.26.0 -->
+ <front>
+ <title abbrev="The GNU Name System">The GNU Name System</title>
+ <seriesInfo name="LSD" value="0001"/>
+ <author fullname="Martin Schanzenbach" initials="M."
surname="Schanzenbach">
+ <organization>Fraunhofer AISEC</organization>
+ <address>
+ <postal>
+ <street>Lichtenbergstrasse 11</street>
+ <city>Garching</city>
+ <code>85748</code>
+ <country>Germany</country>
+ </postal>
+ <email>martin.schanzenbach@aisec.fraunhofer.de</email>
+ </address>
+ </author>
+ <author fullname="Christian Grothoff" initials="C." surname="Grothoff">
+ <organization>Berner Fachhochschule</organization>
+ <address>
+ <postal>
+ <street>Hoeheweg 80</street>
+ <city>Biel/Bienne</city>
+ <code>2501</code>
+ <country>Switzerland</country>
+ </postal>
+ <email>christian.grothoff@bfh.ch</email>
+ </address>
+ </author>
+ <author fullname="Bernd Fix" initials="B." surname="Fix">
+ <organization>GNUnet e.V.</organization>
+ <address>
+ <postal>
+ <street>Boltzmannstrasse 3</street>
+ <city>Garching</city>
+ <code>85748</code>
+ <country>Germany</country>
+ </postal>
+ <email>fix@gnunet.org</email>
+ </address>
+ </author>
+ <date month="November" year="2023"/>
+ <keyword>name systems</keyword>
+
+ <abstract>
+ <t>
+ This document provides 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>
+ This document defines the normative wire format of resource records,
+ resolution processes, cryptographic routines, and security and privacy
+ considerations for use by implementers.
+ </t>
+ <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 implementations (for example, pre-existing
+ GNUnet implementations).
+ </t>
+ </abstract>
+ </front>
+ <middle>
+ <section anchor="introduction">
+ <name>Introduction</name>
+ <t>
+ This specification describes the GNU Name System (GNS), a
+ censorship-resistant, privacy-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>
+ Per Domain Name System (DNS) terminology <xref target="RFC1035"/>, GNS
roughly follows the idea of a local
+ root zone deployment (see <xref 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 <xref target="namespace_ambiguity"/>,
+ users should manage to avoid any confusion as to how names are
+ resolved.
+ </t>
+ <t>
+ Name resolution and zone dissemination are 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 <xref target="SDSI"/>,
+ enabling the decentralized mapping of secure identifiers to
+ memorable names. One of the first academic descriptions of the
+ cryptographic ideas behind GNS can be found in <xref target="GNS"/>.
+ </t>
+ <t>
+ This document defines the normative wire format of resource
+ records, resolution processes, cryptographic routines, and
+ security and privacy considerations for use by implementers.
+ </t>
+ <section>
+ <name>Requirements Notation</name>
+ <t>The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document
+ are to be interpreted as described in BCP 14
+ <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
+ when, they appear in all capitals, as shown here.</t>
+ </section>
+ </section>
+ <section>
+ <name>Terminology</name>
+ <dl 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 method for providing what is called the "zone
apex" in DNS
+ <xref target="RFC4033"/>.
+ The apex label is represented using the character U+0040 ("@" without
the quotes).
+ </dd>
+ <dt>Application:</dt>
+ <dd>
+ An application is a component that uses a GNS implementation
+ to resolve names into records and processes its contents.
+ </dd>
+ <dt>Blinded Zone Key:</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>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 <xref target="gnsrecords_redirect"/>).
+ The extension label is represented using the character U+002B ("+"
without the quotes).
+ </dd>
+ <dt>Label Separator:</dt>
+ <dd>
+ Labels in a name are separated using the label separator U+002E
+ ("." without the quotes).
+ In GNS, except for zone Top-Level Domains (zTLDs)
+ (see below) and boxed records (see <xref target="gnsrecords_box"/>),
+ every label separator in a name indicates delegation to another zone.
+ </dd>
+ <dt>Label:</dt>
+ <dd>
+ A GNS label is a label as defined in <xref target="RFC8499"/>.
+ Labels are UTF-8 strings in Unicode
+ Normalization Form C (NFC) <xref target="Unicode-UAX15"/>.
+ The apex label and the extension label have
+ special purposes in the resolution protocol that are defined
+ in the rest of this document.
+ Zone administrators <bcp14>MAY</bcp14> disallow certain labels that
+ might be easily confused with other labels through registration
policies
+ (see also <xref target="security_abuse"/>).
+ </dd>
+ <dt>Name:</dt>
+ <dd>
+ A name in GNS is a domain name as defined in <xref
target="RFC8499"/>:
+ names are UTF-8 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 DNS and, in particular, Internationalized Domain
Names for
+ Applications (IDNA) <xref target="RFC5890"/>.
+ In the spirit of <xref target="RFC5895"/>, applications
<bcp14>MAY</bcp14> preprocess
+ names and labels to ensure compatibility with DNS or support
+ specific user expectations -- for example, according to
+ <xref target="Unicode-UTS46"/>.
+ A GNS name may be indistinguishable from a DNS name, and care must
+ be taken by applications and implementers when handling GNS names
+ (see <xref target="namespace_ambiguity"/>).
+ In order to avoid misinterpretation of example domains with (reserved)
+ DNS domains, this document uses the suffix ".gns.alt" in compliance
with
+ <xref target="RFC9476"/>. ".gns.alt" is also registered in the
GANA ".alt Subdomains" registry
+ <xref target="GANA"/>.
+ </dd>
+ <dt>Resolver:</dt>
+ <dd>
+ In this document, a resolver is the component of a GNS implementation
that provides
+ the recursive name resolution logic defined in
+ <xref target="resolution"/>.
+ </dd>
+ <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>Start Zone:</dt>
+ <dd>
+ In order to resolve any given GNS name, an initial Start Zone must be
+ determined for this name.
+ The Start Zone can be explicitly defined as part of the name using a
+ zTLD.
+ Otherwise, it is determined through a local suffix-to-zone mapping
+ (see <xref target="governance"/>).
+ </dd>
+ <dt>Top-Level Domain (TLD):</dt>
+ <dd>
+ The rightmost part of a GNS name is a GNS TLD.
+ A GNS TLD can consist of one or more labels.
+ Unlike DNS TLDs (defined in <xref target="RFC8499"/>),
+ GNS does not expect all users to use the same global root zone.
Instead,
+ with the exception of zTLDs (see <xref target="zTLD"/>),
+ GNS TLDs are typically part of the configuration of the local resolver
+ (see <xref target="governance"/>) and thus might not be globally
unique.
+ </dd>
+ <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 have an SOA record under the apex label.
+ </dd>
+ <dt>Zone Key:</dt>
+ <dd>
+ The zone key is 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>Zone Key Derivation Function:</dt>
+ <dd>
+ The zone key derivation function (ZKDF) blinds a zone key using a
label.
+ </dd>
+ <dt>Zone Publisher:</dt>
+ <dd>
+ The zone publisher is the component of a GNS implementation that
provides
+ local zone management and publication as defined in
+ <xref target="publish"/>.
+ </dd>
+ <dt>Zone Owner:</dt>
+ <dd>
+ The zone owner is the holder of the secret (typically a private key),
+ 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>Zone Top-Level Domain (zTLD):</dt>
+ <dd>
+ A GNS zTLD is a sequence of GNS labels at
+ the end of a GNS name. The zTLD encodes a zone type and
+ zone key of a zone (see <xref 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>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>
+ <section anchor="overview">
+ <name>Overview</name>
+ <t>
+ GNS exhibits the three properties that are commonly used to describe
+ a petname system:
+ </t>
+ <dl newline="true">
+ <dt>
+ Global names through the concept of zTLDs:</dt><dd>As zones can be
uniquely identified by their zone keys
+ and are statistically unique, zTLDs are globally unique mappings to
zones.
+ Consequently, GNS domain names with a zTLD suffix are also globally
unique.
+ Names with zTLD suffixes are not memorable.</dd>
+ <dt>
+ Memorable petnames for zones:</dt>
+ <dd>Users can configure local, memorable references to zones.
+ Such petnames serve as zTLD monikers that 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
+ respective zone.</dd>
+ <dt>
+ A secure mapping from names to records:</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 published
in remote storage.
+ When names are resolved, signatures on resource records,
+ including delegations, are verified by the recursive resolver.</dd>
+ </dl>
+ <t>
+ In the remainder of this document, the "implementer" refers to the
developer building
+ a GNS implementation that includes the resolver, zone publisher, and
+ supporting configuration such as Start Zones (see <xref
target="governance"/>).
+ </t>
+ <section anchor="names">
+ <name>Names and Zones</name>
+ <t>
+ It follows from the above that GNS does not support names that are
+ simultaneously global, secure, and memorable.
+ Instead, names are either global and not memorable or not globally
+ unique and memorable.
+ An example for a global name pointing to the record "example" in
+ a zone is as follows:
+ </t>
+ <sourcecode>
+example.000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884
+</sourcecode>
+ <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>
+ The delegation of petnames and subsequent resolution of delegation
+ build on ideas from the Simple Distributed Security Infrastructure
+ <xref target="SDSI"/>.
+ In GNS, any user can create and manage any number of zones
+ (see <xref target="zones"/>) if their system provides a zone
publisher implementation.
+ For each zone, the zone type determines the respective set of
cryptographic operations
+ and the wire formats for encrypted data, public keys, and signatures.
+ A zone can be populated with mappings from labels to resource records
+ (see <xref target="rrecords"/>) by its owner.
+ A label can be mapped to a delegation record; 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>
+ <section anchor="publishing">
+ <name>Publishing Binding Information</name>
+ <t>
+ Zone contents are encrypted and signed
+ before being published in remote key-value storage (see <xref
target="publish"/>),
+ as illustrated in <xref 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 remote
+ storage entities, such as distributed hash tables (DHTs), in order to
facilitate
+ availability within a network without the need for dedicated
infrastructure.
+ The specification of such a distributed or decentralized storage
entity is out of
+ scope for this document, but possible existing implementations
include those
+ based on <xref target="RFC7363"/>, <xref target="Kademlia"/>, or
+ <xref target="R5N"/>.
+ </t>
+ <figure anchor="figure_arch_publish">
+ <name>An Example Diagram of Two Hosts Publishing GNS Zones</name>
+ <artwork name="" type="" alt="">
+ Host A | Remote | Host B
+ | Storage |
+ | |
+ | +---------+ |
+ | / /| |
+ Publish | +---------+ | | Publish
+ +-----------+ Records | | | | | Records +-----------+
+ | Zone |----------|->| Record | |<-|----------| Zone |
+ | Publisher | | | Storage | | | | Publisher |
+ +-----------+ | | |/ | +-----------+
+ A | +---------+ | A
+ | | | |
+ +---------+ | | +---------+
+ / | /| | | / | /|
+ +---------+ | | | +---------+ |
+ | | | | | | | |
+ | Local | | | | | Local | |
+ | Zones | | | | | Zones | |
+ | |/ | | | |/
+ +---------+ | | +---------+
+ </artwork>
+ </figure>
+ <t>
+ A zone publisher 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 <xref target="resolution"/>) or if the names end with
a
+ zTLD suffix.
+ </t>
+ </section>
+ <section anchor="resolving">
+ <name>Resolving Names</name>
+ <t>
+ Applications use the resolver to look up GNS names.
+ Starting from a configurable Start Zone, names are resolved by
following zone
+ delegations recursively, as illustrated in <xref
target="figure_arch_resolv"/>.
+ For each label in a name, the recursive GNS resolver
+ fetches the respective record set from the storage layer (see <xref
target="resolution"/>).
+ Without knowledge of the label values and the zone keys, the
+ different derived keys are unlinkable to both the original zone key
and each
+ other.
+ This prevents zone enumeration (except via expensive online
+ brute-force attacks): to 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 which is 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>
+ <figure anchor="figure_arch_resolv">
+ <name>High-Level View of the GNS Resolution Process</name>
+ <artwork name="" type="" alt="">
+ Local Host | Remote
+ | Storage
+ |
+ | +---------+
+ | / /|
+ | +---------+ |
++-----------+ Name +----------+ Recursive | | | |
+| | Lookup | | Resolution | | Record | |
+|Application|--------->| Resolver |-------------|->| Storage | |
+| |<---------| |<------------|--| |/
++-----------+ Results +----------+ Intermediate| +---------+
+ A Results |
+ | |
+ +---------+ |
+ / | /| |
+ +---------+ | |
+ | | | |
+ | Start | | |
+ | Zones | | |
+ | |/ |
+ +---------+ |
+ </artwork>
+ </figure>
+ </section>
+ </section>
+ <section 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 its zTLD
+ (see <xref target="zTLD"/>), which is a string that encodes the zone
type and zone key.
+ The ztype is a unique 32-bit number that corresponds to
+ a resource record type number identifying a delegation record type
+ in the GANA "GNS Record Types" registry <xref 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>
+ <dl newline="true">
+ <dt>KeyGen() -> d, zkey</dt>
+ <dd>
+ A function for generating a new private key d and
+ the corresponding public zone key zkey.
+ </dd>
+ <dt>ZKDF(zkey, label) -> zkey'</dt>
+ <dd>
+ A ZKDF that blinds a zone key zkey
+ using a label. zkey and zkey' must be unlinkable. Furthermore,
+ blinding zkey with different values for the label must result
+ in different, unlinkable zkey' values.
+ </dd>
+ <dt>S-Encrypt(zkey, label, expiration, plaintext) -> ciphertext</dt>
+ <dd>
+ A symmetric encryption function that encrypts the plaintext
+ to derive ciphertext based on key material derived from the zone key
zkey,
+ a label, and an expiration timestamp.
+ In order to leverage performance-enhancing caching features of certain
+ underlying storage entities -- in particular, DHTs -- a deterministic
encryption
+ scheme is recommended.
+ </dd>
+ <dt>S-Decrypt(zkey, label, expiration, ciphertext) -> plaintext</dt>
+ <dd>
+ A symmetric decryption function that decrypts the ciphertext
+ into plaintext based on key material derived from the zone key,
+ a label, and an expiration timestamp.
+ </dd>
+ <dt>Sign(d, message) -> signature</dt>
+ <dd>
+ A function for signing a message using the private
+ key d, yielding an unforgeable cryptographic signature.
+ In order to leverage performance-enhancing caching features of certain
+ underlying storage entities -- in particular, DHTs -- a deterministic
signature
+ scheme is recommended.
+ </dd>
+ <dt>Verify(zkey, message, signature) -> boolean</dt>
+ <dd>
+ A function for verifying that the signature was created using
+ the private key d corresponding to the zone key zkey
+ where d,zkey := KeyGen().
+ The function returns a boolean value of "TRUE" if the signature is
valid
+ and "FALSE" otherwise.
+ </dd>
+ <dt>SignDerived(d, label, message) -> signature</dt>
+ <dd>
+ A function for signing a message (typically encrypted record data)
that
+ can be verified using the derived zone key zkey' := ZKDF(zkey, label).
+ In order to leverage performance-enhancing caching features of certain
+ underlying storage entities -- in particular, DHTs -- a deterministic
signature
+ scheme is recommended.
+ </dd>
+ <dt>VerifyDerived(zkey', message, signature) -> boolean</dt>
+ <dd>
+ A function for verifying the signature using the derived zone key
+ zkey' := ZKDF(zkey, label). The function returns a boolean value
+ of "TRUE" if the signature is valid and "FALSE" otherwise. Depending
+ on the signature scheme used, this function can be identical to
+ the Verify() function.
+ </dd>
+ </dl>
+ <t>
+ The cryptographic functions of the default ztypes are specified with
+ their corresponding delegation records as discussed in <xref
target="gnsrecords_delegation"/>.
+ In order to support cryptographic agility, additional ztypes
<bcp14>MAY</bcp14>
+ be defined in the future that 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 <xref
target="GANA"/>).
+ When defining new record types, the cryptographic security
considerations
+ of this document -- in particular, <xref
target="security_cryptography"/> -- apply.
+ </t>
+ <section anchor="zTLD">
+ <name>Zone Top-Level Domain (zTLD)</name>
+ <t>
+ A zTLD is a string that encodes the
+ zone type and zone key into a domain name suffix.
+ A zTLD is used as a globally unique reference 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 <xref target="figure_zid"/>).
+ The used encoding is a variation of the Crockford Base32 encoding
+ <xref target="CrockfordB32"/> called Base32GNS.
+ The encoding and decoding symbols for Base32GNS, including this
+ variation, are defined in <xref target="CrockfordB32Encode"/>, found
in <xref target="app-c"/>.
+ The functions for encoding and decoding based on <xref
target="CrockfordB32Encode"/> are called
+ Base32GNS-Encode and Base32GNS-Decode, respectively.
+ </t>
+ <figure anchor="figure_zid">
+ <name>The Binary Representation of the zTLD</name>
+ <artwork name="" type="" alt="">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| ZONE TYPE | ZONE KEY /
++-----+-----+-----+-----+ /
+/ /
+/ /
++-----+-----+-----+-----+-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ <t>
+ The ZONE TYPE <bcp14>MUST</bcp14> be encoded in network byte order.
The format
+ of the ZONE KEY depends entirely on the ZONE TYPE.
+ </t>
+ <t>
+ Consequently, a zTLD is encoded and decoded as follows:
+ </t>
+ <artwork name="" type="" alt="">
+zTLD := Base32GNS-Encode(ztype||zkey)
+ztype||zkey := Base32GNS-Decode(zTLD)
+ </artwork>
+ <t>
+ where "||" is the concatenation operator.
+ </t>
+ <t>
+ The zTLD can be used "as is" as a rightmost label in a GNS name.
+ If an application wants to ensure DNS compatibility of the name,
+ it <bcp14>MAY</bcp14> also represent the zTLD as follows:
+ if the zTLD is less than or equal to 63 characters, it can
+ be used as a zTLD 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
+ in DNS-compatible label lengths.
+ For example, assuming a zTLD of 130 characters, the division is as
follows:
+ </t>
+ <artwork name="" type="" alt="">
+zTLD[126..129].zTLD[63..125].zTLD[0..62]
+ </artwork>
+ </section>
+ <section anchor="revocation">
+ <name>Zone Revocation</name>
+ <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 <xref 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 revocation message, including the PoW, <bcp14>MAY</bcp14> be
calculated
+ ahead of time to support timely revocation.
+ </t>
+ <t>
+ For all occurrences below, "Argon2id" is the password-based key
+ derivation function as defined in <xref target="RFC9106"/>. For the
+ PoW calculations, the algorithm is instantiated with the
+ following parameters:
+ </t>
+ <dl newline="false">
+ <dt>S:</dt>
+ <dd>The salt. Fixed 16-byte string: "GnsRevocationPow"</dd>
+ <dt>t:</dt>
+ <dd>Number of iterations: 3</dd>
+ <dt>m:</dt>
+ <dd>Memory size in KiB: 1024</dd>
+ <dt>T:</dt>
+ <dd>Output length of hash in bytes: 64</dd>
+ <dt>p:</dt>
+ <dd>Parallelization parameter: 1</dd>
+ <dt>v:</dt>
+ <dd>Algorithm version: 0x13</dd>
+ <dt>y:</dt>
+ <dd>Algorithm type (Argon2id): 2</dd>
+ <dt>X:</dt>
+ <dd>Unused</dd>
+ <dt>K:</dt>
+ <dd>Unused</dd>
+ </dl>
+ <t>
+ <xref target="figure_revocation"/> illustrates the format
+ of the data "P" on which the PoW is calculated.
+ </t>
+ <figure anchor="figure_revocation">
+ <name>The Format of the PoW Data</name>
+ <artwork name="" type="" alt="">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| POW |
++-----------------------------------------------+
+| TIMESTAMP |
++-----------------------------------------------+
+| ZONE TYPE | ZONE KEY /
++-----+-----+-----+-----+ /
+/ /
+/ /
++-----+-----+-----+-----+-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ <dl newline="false">
+ <dt>POW:</dt>
+ <dd>
+ A 64-bit value that is a solution to the PoW. In network byte order.
+ </dd>
+ <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>ZONE TYPE:</dt>
+ <dd>
+ The 32-bit zone type in network byte order.
+ </dd>
+ <dt>ZONE KEY:</dt>
+ <dd>
+ The 256-bit public key zkey of the zone that is being revoked.
+ The wire format of this value is defined by the ZONE TYPE.
+ </dd>
+ </dl>
+ <t>
+ Usually, PoW schemes require that 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 number of different PoWs
(Z, as defined below)
+ must be found that on average have at least D leading zeroes.
+ </t>
+ <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 leading
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>
+ The parameters are defined as follows:
+ </t>
+ <dl newline="false">
+ <dt>Z:</dt>
+ <dd>The number of PoWs that are required. Its value is fixed at
32.</dd>
+ <dt>D:</dt>
+ <dd>The lower limit of the average difficulty. Its value is fixed at
22.</dd>
+ <dt>EPOCH:</dt>
+ <dd>A single epoch. Its value is fixed at 365 days in
microseconds.</dd>
+ </dl>
+ <t>
+ The revocation message wire format is illustrated in
+ <xref target="figure_revocationdata"/>.
+ </t>
+ <figure anchor="figure_revocationdata">
+ <name>The Revocation Message Wire Format</name>
+ <artwork name="" type="" alt="">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| TIMESTAMP |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| TTL |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| POW_0 |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| ... |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| POW_(Z-1) |
++-----------------------------------------------+
+| ZONE TYPE | ZONE KEY /
++-----+-----+-----+-----+ /
+/ /
+/ /
++-----+-----+-----+-----+-----+-----+-----+-----+
+/ SIGNATURE /
+/ /
+/ /
+/ /
++-----+-----+-----+-----+-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ <dl newline="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 the timestamp used in the
+ individual PoW calculations.
+ </dd>
+ <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 leading zeroes 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>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 values <bcp14>MUST</bcp14> be given in
strictly
+ monotonically increasing order in the message.
+ </dd>
+ <dt>ZONE TYPE:</dt>
+ <dd>
+ The 32-bit zone type corresponding to the zone key in network byte
order.
+ </dd>
+ <dt>ZONE KEY:</dt>
+ <dd>
+ The public key zkey of the zone that is being revoked and
+ the key to be used to verify SIGNATURE.
+ </dd>
+ <dt>SIGNATURE:</dt>
+ <dd>
+ A signature over a timestamp and the zone zkey of the zone
+ that 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 <xref target="zones"/>).
+ </dd>
+ </dl>
+ <t>
+ The signature in the revocation message covers a 32-bit header
+ prefixed to the TIMESTAMP, ZONE TYPE, and ZONE KEY fields.
+ The header includes the key length and signature purpose.
+ The wire format is illustrated
+ in <xref target="figure_revsigwithpseudo"/>.
+ </t>
+ <figure anchor="figure_revsigwithpseudo">
+ <name>The Wire Format of the Revocation Data for Signing</name>
+ <artwork name="" type="" alt="">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SIZE | PURPOSE (0x03) |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| TIMESTAMP |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| ZONE TYPE | ZONE KEY /
++-----+-----+-----+-----+ /
+/ /
+/ /
++-----+-----+-----+-----+-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ <dl 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>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 protocol that might include possible future extensions.
+ The value of this field corresponds to an entry in the
+ GANA "GNUnet Signature Purposes" registry <xref target="GANA"/>.
+ </dd>
+ <dt>TIMESTAMP:</dt>
+ <dd>
+ Field as defined in the revocation message above.
+ </dd>
+ <dt>ZONE TYPE:</dt>
+ <dd>
+ Field as defined in the revocation message above.
+ </dd>
+ <dt>ZONE KEY:</dt>
+ <dd>Field as defined in the revocation message above.</dd>
+ </dl>
+ <t>
+ In order to validate a revocation, the following steps
<bcp14>MUST</bcp14> be taken:
+ </t>
+ <ol>
+ <li>The signature <bcp14>MUST</bcp14> be verified against the zone
key.</li>
+ <li>The set of POW values <bcp14>MUST NOT</bcp14> contain
duplicates; this <bcp14>MUST</bcp14> be checked by verifying that the values
are strictly monotonically increasing.</li>
+ <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>
+ 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>
+ 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 with poorly 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>
+ Verified revocations <bcp14>MUST</bcp14> be stored locally.
+ The implementation <bcp14>MAY</bcp14> discard stale revocations and
+ evict them from the local store at any time.
+ </t>
+ <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> be discarded by the
receiver.
+ </t>
+ <t>
+ Any locally stored revocation <bcp14>MUST</bcp14> be considered during
+ delegation record processing (see <xref
target="delegation_processing"/>).
+ </t>
+ </section>
+ </section>
+ <section anchor="rrecords">
+ <name>Resource Records</name>
+ <t>
+ A GNS implementation <bcp14>SHOULD</bcp14> provide a mechanism for
creating and managing 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 in storage (see <xref target="publish"/>)
+ and name resolution is limited to non-local Start Zones
+ (see <xref target="governance"/>).
+ </t>
+ <t>
+ A GNS resource record holds the data of a specific record in a zone.
+ The resource record format is illustrated in
+ <xref target="figure_gnsrecord"/>.
+ </t>
+ <figure anchor="figure_gnsrecord">
+ <name>The Resource Record Wire Format</name>
+ <artwork name="" type="" alt="">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| EXPIRATION |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SIZE | FLAGS | TYPE |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| DATA /
+/ /
+/ /
+ </artwork>
+ </figure>
+ <dl newline="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>SIZE:</dt>
+ <dd>
+ Denotes the 16-bit size of the DATA field in bytes in network byte
+ order.
+ </dd>
+ <dt>FLAGS:</dt>
+ <dd>
+ A 16-bit field indicating special properties of the resource record.
+ The semantics of the different bits are defined below.
+ </dd>
+ <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 <xref target="rrecords"/>, a DNS record
+ type as defined in <xref target="RFC1035"/>, or any of the
+ complementary standardized DNS resource record types.
+ Note that values
+ below 2<sup>16</sup> are reserved for 16-bit DNS resource record
types allocated by IANA <xref target="RFC6895"/>.
+ Values above 2<sup>16</sup> are allocated by the
+ GANA "GNS Record Types" registry <xref target="GANA"/>.
+ </dd>
+ <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>
+ 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 flag that it does not
+ recognize, the 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 below is valid.
+ <xref target="figure_flag"/>
+ illustrates the flag distribution in the 16-bit FLAGS field of a
+ resource record:
+ </t>
+ <figure anchor="figure_flag">
+ <name>The Resource Record Flag Wire Format</name>
+ <artwork name="" type="" alt="">
+0 13 14 15
++--------...+-------------+-------+---------+
+| Reserved |SUPPLEMENTAL |SHADOW |CRITICAL |
++--------...+-------------+-------+---------+
+ </artwork>
+ </figure>
+ <dl 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>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 into storage.
+ This way, future values can propagate and can be
+ cached before the transition becomes active.
+ </dd>
+ <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>
+ <section anchor="gnsrecords_delegation">
+ <name>Zone Delegation Records</name>
+ <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 <xref target="GANA"/>).
+ Not supporting some zone types will result in resolution failures if
+ 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 stored or 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 type that have
+ the SHADOW flag set in order to facilitate smooth key rollovers.
+ </t>
+ <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 to functions, the
+ zero terminator of the character strings <bcp14>MUST NOT</bcp14> be
+ included.
+ </t>
+ <section 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 format
is illustrated in <xref target="figure_pkeyrecord"/>.
+ </t>
+ <figure anchor="figure_pkeyrecord">
+ <name>The PKEY Wire Format</name>
+ <artwork name="" type="" alt="">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| PUBLIC KEY |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ <dl newline="false">
+ <dt>PUBLIC KEY:</dt>
+ <dd>
+ A 256-bit Ed25519 public key.
+ </dd>
+ </dl>
+ <t>
+ For PKEY zones, the zone key material is derived using the
+ curve parameters of the twisted Edwards representation
+ of Curve25519 <xref target="RFC7748"/> (the reasoning behind choosing
+ this curve can be found in <xref target="security_cryptography"/>)
+ with the ECDSA scheme <xref target="RFC6979"/>.
+ The following naming convention is used for the cryptographic
primitives of PKEY zones:
+ </t>
+ <dl newline="false">
+ <dt>d:</dt>
+ <dd>
+ A 256-bit Ed25519 private key (clamped private scalar).
+ </dd>
+ <dt>zkey:</dt>
+ <dd>
+ The Ed25519 public zone key corresponding to d.
+ </dd>
+ <dt>p:</dt>
+ <dd>
+ The prime of edwards25519 as defined in <xref target="RFC7748"/>,
i.e.,
+ 2<sup>255</sup> - 19.
+ </dd>
+ <dt>G:</dt>
+ <dd>
+ The group generator (X(P),Y(P)). With X(P),Y(P) of edwards25519 as
defined in
+ <xref target="RFC7748"/>.
+ </dd>
+ <dt>L:</dt>
+ <dd>
+ The order of the prime-order subgroup of edwards25519 as defined in
<xref target="RFC7748"/>.
+ </dd>
+ <dt>KeyGen():</dt>
+ <dd>The generation of the private
+ scalar d and the curve point zkey := d*G (where G is the group
generator
+ of the elliptic curve) as defined in <xref target="RFC6979"
sectionFormat="of" section="2.2"/> represents the KeyGen() function.
+ </dd>
+ </dl>
+ <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 output zkey' of the ZKDF(zkey, label) function is
+ calculated as follows for PKEY zones:
+ </t>
+ <artwork name="" type="" alt="">
+ZKDF(zkey, label):
+ PRK_h := HKDF-Extract("key-derivation", zkey)
+ h := HKDF-Expand(PRK_h, label || "gns", 512 / 8)
+ zkey' := (h mod L) * zkey
+ return zkey'
+ </artwork>
+ <t>
+ The PKEY cryptosystem uses an HMAC-based key derivation function
(HKDF) as defined in
+ <xref target="RFC5869"/>, using SHA-512 <xref target="RFC6234"/> for
the extraction
+ phase and SHA-256 <xref target="RFC6234"/> for the expansion phase.
+ PRK_h is key material retrieved using an HKDF that 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 of zkey with h in ZKDF() is a point multiplication,
+ while the multiplication of d with h in SignDerived() below is a
scalar multiplication.
+ </t>
+ <t>
+ The Sign() and Verify() functions
+ for PKEY zones are implemented using 512-bit ECDSA deterministic
+ signatures as specified in <xref target="RFC6979"/>.
+ The same functions can be used for derived keys:
+ </t>
+ <artwork name="" type="" alt="">
+SignDerived(d, label, message):
+ zkey := d * G
+ PRK_h := HKDF-Extract("key-derivation", zkey)
+ h := HKDF-Expand(PRK_h, label || "gns", 512 / 8)
+ d' := (h * d) mod L
+ return Sign(d', message)
+ </artwork>
+ <t>
+ A signature is valid for the derived public key zkey' := ZKDF(zkey,
label) if the following holds:
+ </t>
+ <artwork name="" type="" alt="">
+VerifyDerived(zkey', message, signature):
+ return Verify(zkey', message, signature)
+ </artwork>
+ <t>
+ The S-Encrypt() and S-Decrypt() functions use AES in counter mode
+ as defined in <xref target="MODES"/> (CTR-AES256):
+ </t>
+ <artwork name="" type="" alt="">
+S-Encrypt(zkey, label, expiration, plaintext):
+ PRK_k := HKDF-Extract("gns-aes-ctx-key", zkey)
+ PRK_n := HKDF-Extract("gns-aes-ctx-iv", zkey)
+ K := HKDF-Expand(PRK_k, label, 256 / 8)
+ NONCE := HKDF-Expand(PRK_n, label, 32 / 8)
+ BLOCK_COUNTER := 0x0000000000000001
+ IV := NONCE || expiration || BLOCK_COUNTER
+ return CTR-AES256(K, IV, plaintext)
+
+S-Decrypt(zkey, label, expiration, ciphertext):
+ PRK_k := HKDF-Extract("gns-aes-ctx-key", zkey)
+ PRK_n := HKDF-Extract("gns-aes-ctx-iv", zkey)
+ K := HKDF-Expand(PRK_k, label, 256 / 8)
+ NONCE := HKDF-Expand(PRK_n, label, 32 / 8)
+ BLOCK_COUNTER := 0x0000000000000001
+ IV := NONCE || expiration || BLOCK_COUNTER
+ return CTR-AES256(K, IV, ciphertext)
+ </artwork>
+ <t>
+ The key K and counter Initialization Vector (IV) are derived from
+ the record label and the zone key zkey, using an HKDF as defined in
<xref target="RFC5869"/>.
+ SHA-512 <xref target="RFC6234"/> is used for the
+ extraction phase and SHA-256 <xref 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 the NONCE.
+ The symmetric key K is a 256-bit AES key <xref target="RFC3826"/>.
+ </t>
+ <t>
+ The nonce is combined with a 64-bit IV and a
+ 32-bit block counter as defined in <xref target="RFC3686"/>.
+ The block counter begins with a 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.
+ The format of the counter IV used by the S-Encrypt() and S-Decrypt()
+ functions is illustrated in
+ <xref target="figure_hkdf_ivs_pkey"/>.
+ </t>
+ <figure anchor="figure_hkdf_ivs_pkey">
+ <name>Structure of the Counter IV as Used in S-Encrypt() and
+ S-Decrypt()</name>
+ <artwork name="" type="" alt="">
+0 8 16 24 32
++-----+-----+-----+-----+
+| NONCE |
++-----+-----+-----+-----+
+| EXPIRATION |
+| |
++-----+-----+-----+-----+
+| BLOCK COUNTER |
++-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ </section>
+ <section anchor="gnsrecords_edkey">
+ <name>EDKEY</name>
+ <t>
+ In GNS, a delegation of a label to a zone of type "EDKEY" is
+ represented through an EDKEY record.
+ The EDKEY DATA entry wire format
+ is illustrated in <xref target="figure_edkeyrecord"/>.
+ </t>
+ <figure anchor="figure_edkeyrecord">
+ <name>The EDKEY DATA Wire Format</name>
+ <artwork name="" type="" alt="">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| PUBLIC KEY |
+| |
+| |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ <dl newline="false">
+ <dt>PUBLIC KEY:</dt>
+ <dd>
+ A 256-bit EdDSA zone key.
+ </dd>
+ </dl>
+ <t>
+ For EDKEY zones, the zone key material is derived using the
+ curve parameters of the twisted Edwards representation
+ of Curve25519 <xref target="RFC7748"/> (a.k.a. Ed25519)
+ with the Ed25519 scheme <xref target="ed25519"/> as specified in
+ <xref target="RFC8032"/>.
+ The following naming convention is used for the
+ cryptographic primitives of EDKEY zones:
+ </t>
+ <dl newline="false">
+ <dt>d:</dt>
+ <dd>
+ A 256-bit EdDSA private key.
+ </dd>
+ <dt>a:</dt>
+ <dd>
+ An integer derived from d using the SHA-512 hash function
+ as defined in <xref target="RFC8032"/>.
+ </dd>
+ <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 <xref target="RFC8032"/>.
+ </dd>
+ <dt>p:</dt>
+ <dd>
+ The prime of edwards25519 as defined in <xref target="RFC8032"/>,
i.e.,
+ 2<sup>255</sup> - 19.
+ </dd>
+ <dt>G:</dt>
+ <dd>
+ The group generator (X(P),Y(P)). With X(P),Y(P) of edwards25519
as defined in
+ <xref target="RFC8032"/>.
+ </dd>
+ <dt>L:</dt>
+ <dd>
+ The order of the prime-order subgroup of edwards25519 as defined
in <xref target="RFC8032"/>.
+ </dd>
+ <dt>KeyGen():</dt>
+ <dd>
+ The generation of the private key d and the associated public
+ key zkey := a*G (where G is the
+ group generator of the elliptic curve and a is an integer
+ derived from d using the SHA-512 hash function)
+ as defined
+ in <xref target="RFC8032" sectionFormat="of" section="5.1.5"/>
+ represents the KeyGen()
+ function.
+ </dd>
+ </dl>
+ <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>
+ The "EDKEY" ZKDF instantiation is based on <xref target="Tor224"/>.
+ As noted above for KeyGen(), a is calculated from d using the
+ SHA-512 hash function as defined in <xref target="RFC8032"
sectionFormat="of" section="5.1.5"/>.
+ Given a label, the output of the ZKDF function is
+ calculated as follows:
+ </t>
+ <artwork name="" type="" alt="">
+ZKDF(zkey, label):
+ /* Calculate the blinding factor */
+ PRK_h := HKDF-Extract("key-derivation", zkey)
+ h := HKDF-Expand(PRK_h, label || "gns", 512 / 8)
+ /* Ensure that h == h mod L */
+ h := h mod L
+
+ zkey' := h * zkey
+ return zkey'
+ </artwork>
+ <t>
+ Implementers <bcp14>SHOULD</bcp14> employ a constant-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.
+ </t>
+ <t>
+ The EDKEY cryptosystem uses an HKDF as defined in
+ <xref target="RFC5869"/>, using SHA-512 <xref target="RFC6234"/>
for the extraction
+ phase and HMAC-SHA-256 <xref target="RFC6234"/> for the expansion
phase.
+ PRK_h is key material retrieved using an HKDF that 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 of zkey with h is a point multiplication.
+ </t>
+ <t>
+ The Sign(d, message) and Verify(zkey, message, signature)
procedures <bcp14>MUST</bcp14>
+ be implemented as defined in <xref target="RFC8032"/>.
+ </t>
+ <t>
+ Signatures for EDKEY zones use a derived private scalar d';
+ this is not compliant with <xref target="RFC8032"/>.
+ As the private key that corresponds to the derived private scalar
+ is not known, it is not possible to deterministically derive the
+ signature part R according to <xref target="RFC8032"/>.
+ Instead, signatures <bcp14>MUST</bcp14> be generated as follows for
any given
+ message and private zone key:
+ a 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="" alt="">
+SignDerived(d, label, message):
+ /* Key expansion */
+ dh := SHA-512(d)
+ /* EdDSA clamping */
+ a := dh[0..31]
+ a[0] := a[0] & 248
+ a[31] := a[31] & 127
+ a[31] := a[31] | 64
+ /* Calculate zkey corresponding to d */
+ zkey := a * G
+
+ /* Calculate blinding factor */
+ PRK_h := HKDF-Extract("key-derivation", zkey)
+ h := HKDF-Expand(PRK_h, label || "gns", 512 / 8)
+ /* Ensure that h == h mod L */
+ h := h mod L
+
+ d' := (h * a) mod L
+ nonce := SHA-256(dh[32..63] || h)
+ r := SHA-512(nonce || message)
+ R := r * G
+ S := r + SHA-512(R || zkey' || message) * d' mod L
+ return (R,S)
+ </artwork>
+ <t>
+ A signature (R,S) is valid for the derived public key zkey' :=
+ ZKDF(zkey, label) if the following holds:
+ </t>
+ <artwork name="" type="" alt="">
+VerifyDerived(zkey', message, signature):
+ (R,S) := signature
+ return S * G == R + SHA-512(R, zkey', message) * zkey'
+ </artwork>
+ <t>
+ The S-Encrypt() and S-Decrypt() functions use XSalsa20
+ as defined in <xref target="XSalsa20"/>
+ and use the XSalsa20-Poly1305 encryption function:
+ </t>
+ <artwork name="" type="" alt="">
+S-Encrypt(zkey, label, expiration, plaintext):
+ PRK_k := HKDF-Extract("gns-xsalsa-ctx-key", zkey)
+ PRK_n := HKDF-Extract("gns-xsalsa-ctx-iv", zkey)
+ K := HKDF-Expand(PRK_k, label, 256 / 8)
+ NONCE := HKDF-Expand(PRK_n, label, 128 / 8)
+ IV := NONCE || expiration
+ return XSalsa20-Poly1305(K, IV, plaintext)
+
+S-Decrypt(zkey, label, expiration, ciphertext):
+ PRK_k := HKDF-Extract("gns-xsalsa-ctx-key", zkey)
+ PRK_n := HKDF-Extract("gns-xsalsa-ctx-iv", zkey)
+ K := HKDF-Expand(PRK_k, label, 256 / 8)
+ NONCE := HKDF-Expand(PRK_n, label, 128 / 8)
+ IV := NONCE || expiration
+ return XSalsa20-Poly1305(K, IV, ciphertext)
+ </artwork>
+ <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>
+ The key K and counter IV are derived from
+ the record label and the zone key zkey using an HKDF as defined in
+ <xref target="RFC5869"/>.
+ SHA-512 <xref target="RFC6234"/> is used for the
+ extraction phase and SHA-256 <xref 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
+ <xref target="XSalsa20"/>.
+ No additional authenticated data (AAD) is used.
+ </t>
+ <t>
+ The nonce is combined with an 8-byte IV.
+ The IV is the expiration time of the
+ resource record block in network byte order.
+ The resulting counter (IV) wire format is illustrated in
+ <xref target="figure_hkdf_ivs_edkey"/>.
+ </t>
+ <figure anchor="figure_hkdf_ivs_edkey">
+ <name>The Counter Block Initialization Vector</name>
+ <artwork name="" type="" alt="">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| NONCE |
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| EXPIRATION |
++-----+-----+-----+-----+-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ </section>
+ </section>
+ <section anchor="gnsrecords_redirect">
+ <name>Redirection Records</name>
+ <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 <xref 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 stored or published
under the apex label.
+ </t>
+ <section 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 type that
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 record are provided in <xref
target="redirect_processing"/>.
+
+ A REDIRECT DATA entry is illustrated in <xref
target="figure_redirectrecord"/>.
+ </t>
+ <figure anchor="figure_redirectrecord">
+ <name>The REDIRECT DATA Wire Format</name>
+ <artwork name="" type="" alt="">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| REDIRECT NAME |
+/ /
+/ /
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ <dl newline="false">
+ <dt>REDIRECT NAME:</dt>
+ <dd>
+ The name to continue with.
+ This value can be a regular name or a relative
+ name.
+ Relative GNS names are indicated by an extension label (U+002B
("+"))
+ as the rightmost label.
+ The string is UTF-8 encoded and zero terminated.
+ </dd>
+ </dl>
+ </section>
+ <section 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
+ <xref 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 same type 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 <xref
target="figure_gns2dnsrecord"/>.</t>
+ <figure anchor="figure_gns2dnsrecord">
+ <name>The GNS2DNS DATA Wire Format</name>
+ <artwork name="" type="" alt="">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| NAME |
+/ /
+/ /
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| DNS SERVER NAME |
+/ /
+/ /
+| |
++-----------------------------------------------+
+ </artwork>
+ </figure>
+ <dl newline="false">
+ <dt>NAME:</dt>
+ <dd>
+ The name to continue with in DNS. The value is UTF-8 encoded and
+ zero terminated.
+ </dd>
+ <dt>DNS SERVER NAME:</dt>
+ <dd>
+ The DNS server to use. This value can be an IPv4 address in
dotted-decimal
+ form, an IPv6 address in colon-hexadecimal form, 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 and zero terminated.
+ </dd>
+ </dl>
+ <t>
+ NOTE: If an application uses DNS names obtained from GNS2DNS records
+ in a DNS request, they <bcp14>MUST</bcp14> first be converted to an
IDNA-compliant
+ representation <xref target="RFC5890"/>.
+ </t>
+ </section>
+ </section>
+ <section anchor="gnsrecords_other">
+ <name>Auxiliary Records</name>
+ <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 <xref target="record_processing"/>.
+ </t>
+ <section anchor="gnsrecords_leho">
+ <name>LEHO</name>
+ <t>
+ The LEHO (LEgacy HOstname) record is used to provide a hint for
legacy hostnames:
+ applications can use the GNS to look up IPv4 or IPv6 addresses of
+ Internet services.
+ However, connecting to such services sometimes not only requires
+ the knowledge of an IP address and port but also requires the
canonical
+ DNS name of the service to be transmitted over the transport protocol.
+ In GNS, legacy hostname 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 <xref 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 not work, 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>
+ A LEHO resource record is expected to be found together with A or AAAA
+ resource records with IPv4 or IPv6 addresses.
+ A LEHO DATA entry is illustrated in <xref
target="figure_lehorecord"/>.
+ </t>
+ <figure anchor="figure_lehorecord">
+ <name>The LEHO DATA Wire Format</name>
+ <artwork name="" type="" alt="">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| LEGACY HOSTNAME |
+/ /
+/ /
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ <dl newline="false">
+ <dt>LEGACY HOSTNAME:</dt>
+ <dd>
+ A UTF-8 string (which is not zero terminated) representing the
legacy hostname.
+ </dd>
+ </dl>
+ <t>
+ NOTE: If an application uses a LEHO value in an HTTP request header
+ (e.g., a "Host"-header), it <bcp14>MUST</bcp14> be converted to an
IDNA-compliant representation
+ <xref target="RFC5890"/>.
+ </t>
+ </section>
+ <section 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 suggestion for other zones regarding what label to use when
creating a
+ delegation record (<xref 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.
+ <xref target="nick_processing"/> details how a resolver must process
+ supplemental and non-supplemental NICK records.
+ A NICK DATA entry is illustrated in <xref
target="figure_nickrecord"/>.
+ </t>
+ <figure anchor="figure_nickrecord">
+ <name>The NICK DATA Wire Format</name>
+ <artwork name="" type="" alt="">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| NICKNAME |
+/ /
+/ /
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ <dl newline="false">
+ <dt>NICKNAME:</dt>
+ <dd>
+ A UTF-8 string (which is not zero terminated) representing the
preferred
+ label of the zone. This string <bcp14>MUST</bcp14> be a valid GNS
label.
+ </dd>
+ </dl>
+ </section>
+ <section 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>
+ 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),
protocol (PROTO) 6
+ (tcp), and record TYPE "TLSA".
+ For reference, see also <xref target="RFC2782"/>.
+ A BOX DATA entry is illustrated in <xref
target="figure_boxrecord"/>.
+ </t>
+ <figure anchor="figure_boxrecord">
+ <name>The BOX DATA Wire Format</name>
+ <artwork name="" type="" alt="">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| PROTO | SVC | TYPE |
++-----------+-----------------------------------+
+| RECORD DATA |
+/ /
+/ /
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ <dl newline="false">
+ <dt>PROTO:</dt>
+ <dd>
+ The 16-bit protocol number in network byte order.
+ Values
+ below 2<sup>8</sup> are reserved for 8-bit Internet Protocol
numbers allocated by IANA <xref target="RFC5237"/>
+ (e.g., 6 for TCP).
+ Values above 2<sup>8</sup> are allocated by the
+ GANA "GNUnet Overlay Protocols" registry <xref target="GANA"/>.
+ </dd>
+ <dt>SVC:</dt>
+ <dd>
+ The 16-bit service value of the boxed record in network byte order.
In the case of
+ TCP and UDP, it is the port number.
+ </dd>
+ <dt>TYPE:</dt>
+ <dd>
+ The 32-bit record type of the boxed record in network byte order.
+ </dd>
+ <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 below
2<sup>16</sup>, the
+ format is the same as the respective record type's binary format in
DNS.
+ </dd>
+ </dl>
+ </section>
+ </section>
+ </section>
+ <section anchor="publish">
+ <name>Record Encoding for Remote Storage</name>
+ <t>
+ Any API that 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, and 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> allow blocks of size 1024
bytes
+ or more.
+ In the following, it is assumed that an implementation realizes two
+ procedures on top of storage:
+ </t>
+ <artwork name="" type="" alt="">
+PUT(key, block)
+GET(key) -> block
+</artwork>
+ <t>
+ A GNS implementation publishes blocks
+ in accordance with 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>
+ There is no mechanism for explicitly deleting individual blocks from
remote storage.
+ However, blocks include an EXPIRATION field, 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>
+ All resource records from the same zone sharing the same label are
+ encrypted and published together in a single resource record block
+ (RRBLOCK) in the remote storage under a key q, as illustrated
+ in <xref 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 RRBLOCKs
+ increase strictly monotonically for every change, even if the smallest
+ expiration time of records in the block does not increase.
+ </t>
+ <figure anchor="figure_storage_publish">
+ <name>Management and Publication of Local Zones in Distributed
Storage</name>
+ <artwork name="" type="" alt="">
+ Local Host | Remote
+ | Storage
+ |
+ | +---------+
+ | / /|
+ | +---------+ |
++-----------+ | | | |
+| | +-----------+PUT(q, RRBLOCK) | | Record | |
+| User | | Zone |----------------|->| Storage | |
+| | | Publisher | | | |/
++-----------+ +-----------+ | +---------+
+ | A |
+ | | Zone records |
+ | | grouped by label |
+ | | |
+ | +---------+ |
+ |Create / Delete / | /| |
+ |and Update +---------+ | |
+ |Local Zones | | | |
+ | | Local | | |
+ +-------------->| Zones | | |
+ | |/ |
+ +---------+ |
+ </artwork>
+ </figure>
+ <t>
+ Storage key derivation and record
+ block creation are specified in the following sections and
+ illustrated in <xref target="figure_storage_derivations"/>.
+ </t>
+ <figure anchor="figure_storage_derivations">
+ <name>Storage Key and Record Block Creation Overview</name>
+ <artwork name="" type="" alt="">
++----------+ +-------+ +------------+ +-------------+
+| Zone Key | | Label | | Record Set | | Private Key |
++----------+ +-------+ +------------+ +-------------+
+ | | | |
+ | | v |
+ | | +-----------+ |
+ | +---------->| S-Encrypt | |
+ +----------|---------->+-----------+ |
+ | | | | |
+ | | | v v
+ | | | +-------------+
+ | +---------------|-->| SignDerived |
+ | | | +-------------+
+ | | | |
+ | v v v
+ | +------+ +--------------+
+ +----->| ZKDF |------->| Record Block |
+ +------+ +--------------+
+ |
+ v
+ +------+ +-------------+
+ | Hash |------->| Storage Key |
+ +------+ +-------------+
+ </artwork>
+ </figure>
+ <section anchor="blinding">
+ <name>The Storage Key</name>
+ <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"
sectionFormat="comma" section="3.5"/>).
+ </t>
+ <t>
+ Given a label, the storage key q is derived as follows:
+ </t>
+ <artwork name="" type="" alt="">
+q := SHA-512(ZKDF(zkey, label))
+ </artwork>
+ <dl newline="false">
+ <dt>label:</dt>
+ <dd>A UTF-8 string under which the resource records are published.
+ </dd>
+ <dt>zkey:</dt>
+ <dd>
+ The zone key.
+ </dd>
+ <dt>q:</dt>
+ <dd>
+ The 512-bit storage key under which the resource record block is
+ published.
+ It is the SHA-512 hash <xref target="RFC6234"/> over the derived
zone key.
+ </dd>
+ </dl>
+ </section>
+ <section anchor="rdata">
+ <name>Plaintext Record Data (RDATA)</name>
+ <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 in storage. Such grouped record sets <bcp14>MAY</bcp14> be
paired with
+ supplemental records.
+ </t>
+ <t>
+ Record data (RDATA) is the format used to encode such a group of GNS
records.
+ The binary format of RDATA is illustrated in
+ <xref target="figure_rdata"/>.
+ </t>
+ <figure anchor="figure_rdata">
+ <name>The RDATA Wire Format</name>
+ <artwork name="" type="" alt="">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| EXPIRATION |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SIZE | FLAGS | TYPE |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| DATA /
+/ /
+/ /
++-----+-----+-----+-----+-----+-----+-----+-----+
+| EXPIRATION |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SIZE | FLAGS | TYPE |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| DATA /
+/ /
++-----+-----+-----+-----+-----+-----+-----+-----+
+| PADDING /
+/ /
++-----+-----+-----+-----+-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ <dl newline="false">
+ <dt>EXPIRATION, SIZE, TYPE, FLAGS, and DATA:</dt>
+ <dd>
+ Definitions for these fields are provided below <xref
target="figure_gnsrecord"/>
+ in <xref target="rrecords"/>.
+ </dd>
+ <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
+ using this 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>
+ <section anchor="records_block">
+ <name>The Resource Record Block</name>
+ <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 with metadata into a resource record block (RRBLOCK) for
remote storage.
+ The GNS RRBLOCK wire format is illustrated in
+ <xref target="figure_record_block"/>.
+ </t>
+ <figure anchor="figure_record_block">
+ <name>The RRBLOCK Wire Format</name>
+ <artwork name="" type="" alt="">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SIZE | ZONE TYPE |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| ZONE KEY /
+/ (BLINDED) /
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SIGNATURE |
+/ /
+/ /
+| |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| EXPIRATION |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| BDATA |
+/ /
+/ /
++-----+-----+-----+-----+-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ <dl 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>ZONE TYPE:</dt>
+ <dd>
+ The 32-bit ztype in network byte order.
+ </dd>
+ <dt>ZONE KEY (BLINDED):</dt>
+ <dd>
+ The blinded zone key "ZKDF(zkey, label)"
+ to be used to verify SIGNATURE.
+ The length and format of the blinded public key depend on the ztype.
+ </dd>
+ <dt>SIGNATURE:</dt>
+ <dd>
+ The signature is computed over the EXPIRATION and BDATA fields
+ as shown in <xref target="figure_rrsigwithpseudo"/>.
+ The length and format of the signature depend on the ztype.
+ The signature is created using the SignDerived() function of
+ the cryptosystem of the zone (see <xref target="zones"/>).
+ </dd>
+ <dt>EXPIRATION:</dt>
+ <dd>
+ Specifies when the RRBLOCK expires and the encrypted block
+ <bcp14>SHOULD</bcp14> be removed from storage and caches, 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> be computed by first determining for each record type
present in the RRBLOCK the maximum expiration time of all records of that type,
including shadow
+records. Then, the minimum of all of these expiration times is taken. The
final expiration time is then the larger value of (1) the previous EXPIRATION
value of a previous RRBLOCK for the same storage key plus one (if any) and (2)
the computed minimum expiration time across the contained record types. This
ensures strict monotonicity (see <xref target="security_cryptography"/>).
+ This is a 64-bit absolute date in microseconds since midnight
+ (0 hour), January 1, 1970 UTC in network byte order.
+ </dd>
+ <dt>BDATA:</dt>
+ <dd>
+ The encrypted RDATA computed using S-Encrypt() with the
+ zone key, label, and expiration time as additional inputs.
+ Its ultimate size and content are determined by
+ the S-Encrypt() function of the ztype.
+ </dd>
+ </dl>
+ <t>
+ The signature over the public key covers a 32-bit pseudo header
+ conceptually prefixed to the EXPIRATION and BDATA fields.
+ The wire format is illustrated
+ in <xref target="figure_rrsigwithpseudo"/>.
+ </t>
+ <figure anchor="figure_rrsigwithpseudo">
+ <name>The Wire Format Used for Creating the Signature of the
RRBLOCK</name>
+ <artwork name="" type="" alt="">
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| SIZE | PURPOSE (0x0F) |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| EXPIRATION |
++-----+-----+-----+-----+-----+-----+-----+-----+
+| BDATA |
+/ /
+/ /
++-----+-----+-----+-----+-----+-----+-----+-----+
+ </artwork>
+ </figure>
+ <dl 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>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 protocol that might include possible future extensions.
+ The value of this field corresponds to an entry in the
+ GANA "GNUnet Signature Purposes" registry <xref target="GANA"/>.
+ </dd>
+ <dt>EXPIRATION:</dt>
+ <dd>
+ Field as defined in the RRBLOCK message above.
+ </dd>
+ <dt>BDATA:</dt>
+ <dd>Field as defined in the RRBLOCK message above.</dd>
+ </dl>
+ </section>
+ </section>
+ <section anchor="resolution">
+ <name>Name Resolution</name>
+ <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 message if resolution
+ fails.
+ <xref 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>
+ <figure anchor="figure_resolution">
+ <name>The Recursive GNS Resolution Process</name>
+ <artwork name="" type="" 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>
+ <section anchor="governance">
+ <name>Start Zones</name>
+ <t>
+ The resolution of a GNS name starts by identifying the Start Zone
+ suffix. Once the Start Zone suffix is identified, recursive resolution
+ of the remainder of the name is initiated (see <xref
target="recursion"/>).
+ There are two types of Start 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" section="3.10"
+ sectionFormat="bare"/> of <xref target="RFC8324"/>, respectively).
+ </t>
+ <t>
+ For names ending with a zTLD, the Start Zone is explicitly given in
the
+ suffix of the name to resolve.
+ In order to ensure uniqueness of names with zTLDs, any
+ implementation <bcp14>MUST</bcp14> use the given zone as 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 <xref 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 and
+ Start 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
+ the Start Zone key according to <xref 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 the Start Zone:
+ </t>
+ <artwork name="" type="" alt="">
+Example name: www.example.<zTLD>
+=> Start Zone: zkey of type ztype
+=> Name to resolve from Start Zone: www.example
+ </artwork>
+ <t>
+ For names not ending with a zTLD, the resolver <bcp14>MUST</bcp14>
determine the Start
+ 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 a misconfiguration,
and the
+ implementation <bcp14>MUST</bcp14> return an error.
+ The following is a non-normative example mapping of Start Zones:
+ </t>
+ <artwork name="" type="" alt="">
+Example name: www.example.xyz.gns.alt
+Local suffix mappings:
+xyz.gns.alt = zTLD0 := Base32GNS(ztype0||zkey0)
+example.xyz.gns.alt = zTLD1 := Base32GNS(ztype1||zkey1)
+example.com.gns.alt = zTLD2 := Base32GNS(ztype2||zkey2)
+...
+=> Start Zone: zkey1
+=> Name to resolve from Start Zone: www
+ </artwork>
+ <t>
+ The process given above <bcp14>MAY</bcp14> be supplemented with other
mechanisms if
+ the particular application requires a different process.
+ If no Start Zone can be identified, resolution <bcp14>MUST</bcp14>
fail and an
+ error <bcp14>MUST</bcp14> be returned to the application.
+ </t>
+ </section>
+ <section anchor="recursion">
+ <name>Recursion</name>
+ <t>
+ In each step of the recursive name resolution, there is an
+ authoritative zone zkey 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 the Start Zone.
+ </t>
+ <t>
+ From here, the following steps are recursively executed, in order:
+ </t>
+ <ol>
+ <li>Extract the rightmost label from the name to look up.</li>
+ <li>Calculate q using the label and zkey as defined in
+ <xref target="blinding"/>.</li>
+ <li>Perform a storage query GET(q) to retrieve the RRBLOCK.</li>
+ <li>Check that (a) the block is not expired, (b) the SHA-512 hash
+ of the derived authoritative zone key 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>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 <xref
target="records_block"/>.</li>
+ </ol>
+ <t>
+ Once a well-formed block has been decrypted, the records from
+ RDATA are subjected to record processing.
+ </t>
+ </section>
+ <section anchor="record_processing">
+ <name>Record Processing</name>
+ <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 record type, the resolution
<bcp14>MUST</bcp14> be aborted
+ and an error <bcp14>MUST</bcp14> be returned. Information
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>
+ The next steps depend on the context of the name that is being
+ resolved:
+ </t>
+ <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 REDIRECT DATA and the
+ recursion is started again from the resulting name.
+ Details are provided in <xref target="redirect_processing"/>.</dd>
+ <dt>Case 2:</dt>
+ <dd>If the filtered record set consists exclusively of one or more
GNS2DNS records,
+ resolution continues with DNS.
+ Details are provided in <xref target="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 <xref target="box_processing"/>.</dd>
+ <dt>Case 4:</dt>
+ <dd>If the current record set
+ consists of a single delegation record,
+ resolution of the remainder of the name is delegated to
+ the target zone as described in <xref
target="delegation_processing"/>.</dd>
+ <dt>Case 5:</dt>
+ <dd>If the remainder of the name to resolve is empty,
+ 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 <xref target="nick_processing"/>.
+ Otherwise, the record result set is directly returned as the final
result.</dd>
+ </dl>
+ <t>Finally, if none of the above cases are applicable, resolution
fails and the
+ resolver <bcp14>MUST</bcp14> return an empty record set.</t>
+
+ <section anchor="redirect_processing">
+ <name>REDIRECT</name>
+ <t>
+ If the remaining name is empty and the desired record type is
+ REDIRECT, the resolution concludes with the REDIRECT record.
+ If the rightmost label of the REDIRECT NAME is the extension label
+ (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 resolution process, depending
+ on the system configuration.
+ If resolution continues in DNS, the name <bcp14>MUST</bcp14>
first be
+ converted to an IDNA-compliant representation <xref
target="RFC5890"/>.
+ </t>
+ <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>
+ <section anchor="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 GNS2DNS records;</li>
+ <li>The remaining name is empty; and</li>
+ <li>The desired record type is GNS2DNS.</li>
+ </ol>
+ <t>
+ Otherwise, it is expected that the resolver first resolves the
+ IP addresses of the specified DNS name servers.
+ The DNS name <bcp14>MUST</bcp14> be converted to an IDNA-compliant
+ representation <xref 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 ("+")), 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 zone zkey.
+ </t>
+ <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 are
+ present, the resolution fails and an
+ appropriate error <bcp14>SHOULD</bcp14> be returned to the
application.
+ </t>
+ <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>
+ 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 be resolved and is
+ resolved by querying the DNS name server(s).
+ The synthesized name has to be converted to an IDNA-compliant
+ representation <xref 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. Information
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>
+ 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 <xref target="gnsrecords_leho"/>)
with a
+ relative expiration time of one hour.
+ </t>
+ <t>
+ Once the transition from GNS to 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>
+ 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>
+ <section 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>
+ <section anchor="delegation_processing">
+ <name>Zone Delegation Records</name>
+ <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>
+ Whenever a resolver encounters a new GNS zone, it
<bcp14>MUST</bcp14>
+ check against the local revocation list (see <xref
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>
+ 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>
+ 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. The 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>
+ <section anchor="nick_processing">
+ <name>NICK</name>
+ <t>
+ NICK records are only relevant to the recursive resolver
+ if the record set in question is the final result, which is to
+ be returned to the application. The encountered NICK records can
be either
+ supplemental (see <xref 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>
+ 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="" alt="">
+Query: alice.example.gns.alt (type=A)
+Result:
+A: 192.0.2.1
+NICK: eve (non-supplemental)
+ </artwork>
+ <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 interpreted as 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="" alt="">
+Query: alice.example.gns.alt (type=AAAA)
+Result:
+AAAA: 2001:db8::1
+NICK: john (supplemental)
+ </artwork>
+ <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 with a AAAA record. Here, the NICK record should be
+ interpreted as 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>
+ <section anchor="encoding">
+ <name>Internationalization and Character Encoding</name>
+ <t>
+ All names in GNS are encoded in UTF-8 <xref target="RFC3629"/>.
+ Labels <bcp14>MUST</bcp14> be canonicalized using
+ Normalization Form C (NFC) <xref target="Unicode-UAX15"/>.
+ This does not include any DNS names found in DNS records, such as
CNAME
+ record data, which is internationalized through the IDNA
specifications;
+ see <xref target="RFC5890"/>.
+ </t>
+ </section>
+ <section anchor="security">
+ <name>Security and Privacy Considerations</name>
+ <section anchor="security_availability">
+ <name>Availability</name>
+ <t>
+ In order to ensure availability of records beyond their
+ absolute expiration times, implementations <bcp14>MAY</bcp14> allow
+ relative expiration time values of records to be locally defined.
+ Records can then be published recurringly with updated
+ absolute expiration times by the implementation.
+ </t>
+ <t>
+ Implementations <bcp14>MAY</bcp14> allow users to manage private
records in
+ their zones that are not published in storage.
+ Private records are treated just like
+ regular records when resolving labels in local zones,
+ but their data is completely unavailable to non-local users.
+ </t>
+ </section>
+ <section 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. This 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>
+ 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>
+ 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 type remains,
+ 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>
+ <section 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 <xref target="zones"/>, the same
+ considerations apply.
+ </t>
+ <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 of reasons, as described in
+ the Curve25519 and EdDSA papers <xref target="RFC7748"/> <xref
target="ed25519"/>.
+ Using EdDSA directly is also
+ not possible, as a hash function is used on the private key and
+ 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-bit curves; that way, the encoded (public)
+ keys fit into a single DNS label, which is good for usability.
+ </t>
+ <t>
+ In order to ensure ciphertext indistinguishability, care must be
+ taken with respect to the IV 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 published in storage, its IV is
+ unique, 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 expiration 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 expiration
times,
+ the implementation <bcp14>MUST</bcp14> keep a local record of the
last time obtained
+ from the system clock, so as to construct a monotonic clock if
+ the system clock jumps backwards.
+ </t>
+ </section>
+ <section anchor="security_abuse">
+ <name>Abuse Mitigation</name>
+ <t>
+ GNS names are UTF-8 strings. Consequently, GNS faces issues
+ with respect to name spoofing similar to those for DNS with respect
to internationalized
+ domain names.
+ In DNS, attackers can register similar-sounding or similar-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>
+ 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, the Start Zone of
+ the resolver is defined locally, and hence such a seizure is
+ difficult and ineffective in GNS.
+ </t>
+ </section>
+ <section anchor="security_keymanagement">
+ <name>Zone Management</name>
+ <t>
+ In GNS, zone administrators need to manage and protect their zone
+ keys. Once a private zone key is lost, it cannot be recovered, and
+ the zone revocation message cannot be computed anymore.
+ Revocation messages can be precalculated if revocation is
+ required in cases where a private zone key is lost.
+ Zone administrators, and for GNS this includes 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) that aim to protect private
keys.
+ </t>
+ <t>
+ Similarly, users are required to manage their local Start Zone
configuration.
+ In order to ensure the integrity and availability of names, users
must
+ ensure that their local Start Zone information is not compromised or
+ outdated.
+ It can be expected that the processing of zone revocations and an
+ initial Start Zone are provided with a GNS implementation
+ ("drop shipping").
+ Shipping an initial Start Zone configuration effectively establishes
+ a root zone.
+ Extension and customization of the zone are at the full discretion
of
+ the user.
+ </t>
+ <t>
+ While implementations following this specification will be
+ interoperable, if two implementations connect to different remote
storage 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.
+ 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 Tor network <xref target="TorRendSpec"/>, which would
suggest using Tor routers for remote storage.
+ Implementations of "aggregated" remote storage entities are
conceivable but
+ are expected to be the exception.
+ </t>
+ </section>
+ <section anchor="security_dht">
+ <name>DHTs as Remote Storage</name>
+ <t>
+ This document does not specify the properties of the underlying
+ remote storage, 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 security and
+ 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
+ <xref target="R5N"/>.
+ It should also be taken into consideration that GNS implementations
+ that build upon different DHT overlays are unlikely to be
+ mutually reachable.
+ </t>
+ </section>
+ <section anchor="security_rev">
+ <name>Revocations</name>
+ <t>
+ Zone administrators are advised to pregenerate zone revocations
+ and to securely store the revocation information if the zone
+ key is lost, compromised, or replaced in the future.
+ Precalculated 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>
+ Revocation payloads do not include a "new" key for key replacement.
+ Inclusion of such a key would have two major disadvantages:
+ </t>
+ <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>
+ 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 only when
+ it is deemed no longer secure and, hopefully, after most users have
+ migrated to the replacement.
+ </li>
+ </ol>
+ </section>
+ <section anchor="privacy_labels">
+ <name>Zone Privacy</name>
+ <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 consider whether (1) a label and zone key are public or
+ (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 of well-known or guessable
+ labels effectively threatens the disclosure of the corresponding
records.
+ </t>
+ <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>
+ 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>
+ <section anchor="sec_governance">
+ <name>Zone Governance</name>
+ <t>
+ While DNS is distributed, in practice it
+ relies on centralized, trusted registrars to provide globally unique
+ names. As awareness of the central role DNS plays on the Internet
+ 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 research
+ works, including <xref target="SecureNS"/>.
+ </t>
+ <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 the issue of a
+ single hierarchy with a centrally controlled root and the
+ related issue of distribution and management of root servers in
DNS, as
+ raised in Sections <xref target="RFC8324" section="3.12"
+ sectionFormat="bare"/> and <xref target="RFC8324" section="3.10"
+ sectionFormat="bare"/> of <xref target="RFC8324"/>, respectively.
+ In DNS, those issues directly result from the centralized root
+ zone governance at the Internet Corporation for Assigned Names and
+ Numbers (ICANN), which allows it to provide globally unique names.
+ </t>
+ <t>
+ In GNS, Start 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., 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,
+ secure, and memorable mapping without a trusted authority.
+ </t>
+ <t>
+ Any GNS implementation <bcp14>MAY</bcp14> provide a default
+ governance model in the form of an initial Start Zone mapping.
+ </t>
+ </section>
+ <section anchor="namespace_ambiguity">
+ <name>Namespace Ambiguity</name>
+ <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., the IETF and ICANN) to standardize the use of
GNS for this particular use
+ case.
+ </t>
+ <t>
+ This capability implies that GNS names may be
+ indistinguishable from DNS names in their
+ respective common display format <xref target="RFC8499"/> or
+ other special-use domain names <xref target="RFC6761"/> if
+ a local Start Zone configuration maps suffixes from the
+ global DNS to GNS zones.
+ For applications, which name system should be
+ used in order to resolve a given name will then be ambiguous.
+ This poses a risk when trying to resolve a name through DNS when
+ it is actually a GNS name, as discussed in <xref target="RFC8244"/>.
+ In such a case, the GNS name is likely to be leaked as part of the
DNS
+ resolution.
+ </t>
+ <t>
+ In order to prevent disclosure of queried GNS names, it is
+ <bcp14>RECOMMENDED</bcp14> that GNS-aware applications try to
resolve
+ a given name in GNS before any other method, taking into account
+ potential suffix-to-zone mappings and zTLDs.
+ Suffix-to-zone mappings are expected to be configured by the user or
+ local administrator, 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 using GNS, and
+ resolution <bcp14>MUST NOT</bcp14> continue by any other means
+ independent of the GNS resolution result.
+ </t>
+ <t>
+ Mechanisms such as the Name Service Switch (NSS) of UNIX-like
+ operating systems are an example of how such a resolution process
+ can be implemented and used.
+ The NSS allows system administrators to configure hostname
resolution
+ precedence and is integrated with the system resolver
implementation.
+ </t>
+ <t>
+ For use cases where GNS names may be confused with names
+ of other name resolution mechanisms (in particular, 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>
+ <section anchor="gana">
+ <name>GANA Considerations</name>
+ <section anchor="gana_gnunet-sig-purposes">
+ <name>GNUnet Signature Purposes Registry</name>
+ <t>
+ GANA <xref target="GANA"/> has assigned signature purposes in its
+ "GNUnet Signature Purposes" registry as listed in
+ <xref target="tab_purposenums"/>.
+ </t>
+
+<table anchor="tab_purposenums">
+ <name>The GANA GNUnet Signature Purposes 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 set signature</td>
+ </tr>
+ </tbody>
+</table>
+ </section>
+ <section anchor="gana_gnsrr">
+ <name>GNS Record Types Registry</name>
+ <t>
+ GANA <xref target="GANA"/>
+ manages the "GNS Record Types" registry.
+ </t>
+ <t>Each entry has the following format:
+ </t>
+ <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 the
zone.</dd>
+ <dt>Number:</dt><dd>A 32-bit number above 65535.</dd>
+ <dt>Comment:</dt><dd>Optionally, brief English text describing the
purpose of
+ the record type (in UTF-8).</dd>
+ <dt>Contact:</dt><dd>Optionally, the contact information for a
person to contact for
+ further information.</dd>
+ <dt>References:</dt><dd>Optionally, references (such as an 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 <xref
target="RFC8126"/>
+ and describes the actions taken by GANA:
+ </t>
+ <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 responsible for ensuring that the chosen "Name" is
+ appropriate for the record type.
+ The registry will define a unique number for the entry.
+ </li>
+ <li>
+ Authorized GANA contributors for review of new entries are reachable
at
+ <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 the registry,
with the consent
+ of the requester.
+ The request <bcp14>MAY</bcp14> optionally also contain relevant
references as well
+ as a descriptive comment, as defined above.
+ </li>
+ </ul>
+ <t>
+ GANA has assigned numbers for the record types defined in this
+ specification in the "GNS Record Types" registry as listed in
+ <xref target="tab_rrtypenums"/>.
+ </t>
+
+<table anchor="tab_rrtypenums">
+ <name>The GANA 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)</td>
+ </tr>
+ <tr>
+ <td>65537</td>
+ <td>NICK</td>
+ <td>(*)</td>
+ <td>RFC 9498</td>
+ <td>GNS zone nickname</td>
+ </tr>
+ <tr>
+ <td>65538</td>
+ <td>LEHO</td>
+ <td>(*)</td>
+ <td>RFC 9498</td>
+ <td>GNS legacy hostname</td>
+ </tr>
+ <tr>
+ <td>65540</td>
+ <td>GNS2DNS</td>
+ <td>(*)</td>
+ <td>RFC 9498</td>
+ <td>Delegation to DNS</td>
+ </tr>
+ <tr>
+ <td>65541</td>
+ <td>BOX</td>
+ <td>(*)</td>
+ <td>RFC 9498</td>
+ <td>Box records</td>
+ </tr>
+ <tr>
+ <td>65551</td>
+ <td>REDIRECT</td>
+ <td>(*)</td>
+ <td>RFC 9498</td>
+ <td>Redirection record</td>
+ </tr>
+ <tr>
+ <td>65556</td>
+ <td>EDKEY</td>
+ <td>(*)</td>
+ <td>RFC 9498</td>
+ <td>GNS zone delegation (EDKEY)</td>
+ </tr>
+ </tbody>
+ <tfoot>
+ <tr>
+ <td align="left" colspan="5">(*): gns-registry@gnunet.org</td>
+ </tr>
+ </tfoot>
+</table>
+ </section>
+ <section anchor="gana_alt">
+ <name>.alt Subdomains Registry</name>
+ <t>
+ GANA <xref target="GANA"/>
+ manages the ".alt Subdomains" registry. This 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>
+ <dl newline="false">
+ <dt>Label:</dt><dd>The label of the subdomain (in DNS "letters,
digits, hyphen" (LDH) format as defined in <xref target="RFC5890"
sectionFormat="of" section="2.3.1"/>).</dd>
+ <dt>Description:</dt><dd>Optionally, brief English text describing the
purpose of
+ the subdomain (in UTF-8).</dd>
+ <dt>Contact:</dt><dd>Optionally, the contact information for a
person to contact for
+ further information.</dd>
+ <dt>References:</dt><dd>Optionally, references (such as an 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 <xref
target="RFC8126"/>
+ and describes the actions taken by GANA:
+ </t>
+ <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 responsible for ensuring that the chosen "Subdomain" is
+ appropriate for the purpose.
+ </li>
+ <li>
+ Authorized GANA contributors for review of new entries are reachable
at
+ <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 the registry,
with the consent
+ of the requester.
+ The request <bcp14>MAY</bcp14> optionally also contain relevant
references as well
+ as a descriptive comment, as defined above.
+ </li>
+ </ul>
+ <t>
+ GANA has assigned the subdomain defined in this
+ specification in the ".alt Subdomains" registry
+ as listed in <xref target="tab_altsubdomains"/>.
+ </t>
+<table anchor="tab_altsubdomains">
+ <name>The GANA .alt Subdomains Registry</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 for GNS</td>
+ </tr>
+ </tbody>
+ <tfoot>
+ <tr>
+ <td align="left" colspan="4">(*): alt-registry@gnunet.org</td>
+ </tr>
+ </tfoot>
+</table>
+
+ </section>
+ </section>
+ <section>
+ <name>IANA Considerations</name>
+ <t>
+ This document has no IANA actions.
+ </t>
+ </section>
+ <section>
+ <name>Implementation and Deployment Status</name>
+ <t>
+ There are two implementations conforming to this specification,
written
+ in C and Go, respectively. The C implementation as part of GNUnet
+ <xref target="GNUnetGNS"/> represents the original
+ and reference implementation. The Go implementation
+ <xref target="GoGNS"/> demonstrates how two implementations of GNS are
+ interoperable if they are built on top of the same underlying
+ DHT storage.
+ </t>
+ <t>
+ Currently, the GNUnet peer-to-peer network <xref target="GNUnet"/>
+ is an active deployment of GNS on top of its DHT <xref
target="R5N"/>. The 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>
+ The self-sovereign identity system re:claimID <xref target="reclaim"/>
+ is using GNS in order to selectively share identity attributes and
+ attestations with third parties.
+ </t>
+ <t>
+ The Ascension tool <xref 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>
+ </middle>
+ <back>
+ <references>
+ <name>References</name>
+ <references>
+ <name>Normative References</name>
+
+<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/";>
+ <front>
+ <title>GNUnet Assigned Numbers Authority (GANA)</title>
+ <author>
+ <organization>GNUnet e.V.</organization>
+ </author>
+ <date year="2023"/>
+ </front>
+ </reference>
+
+ <reference anchor="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>NIST</organization>
+ </author>
+ <date year="2001" month="December"/>
+ </front>
+ <refcontent>NIST Special Publication 800-38A</refcontent>
+ <seriesInfo name="DOI" value="10.6028/NIST.SP.800-38A"/>
+ </reference>
+ <reference anchor="CrockfordB32"
target="https://www.crockford.com/base32.html";>
+ <front>
+ <title>Base 32</title>
+ <author initials="D." surname="Crockford" fullname="Douglas
Crockford">
+ </author>
+ <date year="2019" month="March"/>
+ </front>
+ </reference>
+
+ <reference anchor="XSalsa20"
target="https://cr.yp.to/papers.html#xsalsa";>
+ <front>
+ <title>Extending the Salsa20 nonce</title>
+ <author initials="D. J." surname="Bernstein" fullname="Daniel
Bernstein">
+ <organization>University of Illinois at Chicago</organization>
+ </author>
+ <date year="2011"/>
+ </front>
+ </reference>
+
+ <reference anchor="Unicode-UAX15"
target="https://www.unicode.org/reports/tr15/tr15-31.html";>
+ <front>
+ <title>Unicode Standard Annex #15: Unicode Normalization
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";>
+ <front>
+ <title>Unicode Technical Standard #46: Unicode IDNA Compatibility
Processing</title>
+ <author initials="M." surname="Davis" fullname="Mark Davis">
+ <organization/>
+ </author>
+ <author initials="M." surname="Suignard" fullname="Michel Suignard">
+ <organization/>
+ </author>
+ <date year="2023" month="September"/>
+ </front>
+ <refcontent>Revision 31, The 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"/>
+
+ <reference anchor="TorRendSpec"
target="https://github.com/torproject/torspec/blob/main/rend-spec-v3.txt";>
+ <front>
+ <title>Tor Rendezvous Specification - Version 3</title>
+ <author>
+ <organization>Tor Project</organization>
+ </author>
+ <date month="June" year="2023"/>
+ </front>
+ <refcontent>commit b345ca0</refcontent>
+ </reference>
+
+ <reference anchor="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="https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=3837e0206bf73e5e8f0ba6db767a2f714ea7c367";>
+ <front>
+ <title>SDSI - A Simple Distributed Security Infrastructure</title>
+ <author initials="R. L." surname="Rivest" fullname="Ron L. Rivest">
+ </author>
+ <author initials="B." surname="Lampson" fullname="Butler Lampson">
+ </author>
+ <date year="1996" month="October"/>
+ </front>
+ </reference>
+
+ <reference anchor="Kademlia"
target="https://css.csail.mit.edu/6.824/2014/papers/kademlia.pdf";>
+ <front>
+ <title>Kademlia: A Peer-to-peer Information System Based on the XOR
Metric</title>
+ <author initials="P." surname="Maymounkov" fullname="Petar
Maymounkov">
+ </author>
+ <author initials="D." surname="Mazières" fullname="David Mazières">
+ </author>
+ <date year="2002"/>
+ </front>
+ <seriesInfo name="DOI" value="10.1007/3-540-45748-8_5"/>
+ </reference>
+
+ <reference anchor="ed25519"
target="https://ed25519.cr.yp.to/ed25519-20110926.pdf";>
+ <front>
+ <title>High-speed high-security signatures</title>
+ <author initials="D. J." surname="Bernstein" fullname="Daniel
Bernstein">
+ <organization>University of Illinois at Chicago</organization>
+ </author>
+ <author initials="N." surname="Duif" fullname="Niels Duif">
+ <organization>Technische Universiteit Eindhoven</organization>
+ </author>
+ <author initials="T." surname="Lange" fullname="Tanja Lange">
+ <organization>Technische Universiteit Eindhoven</organization>
+ </author>
+ <author initials="P." surname="Schwabe" fullname="Peter Schwabe">
+ <organization>National Taiwan University</organization>
+ </author>
+ <author initials="B-Y." surname="Yang" fullname="Bo-Yin Yang">
+ <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";>
+ <front>
+ <title>A Censorship-Resistant, Privacy-Enhancing and Fully
Decentralized Name System</title>
+ <author initials="M." surname="Wachs" fullname="Matthias Wachs">
+ <organization>Technische Universität München</organization>
+ </author>
+ <author initials="M." surname="Schanzenbach" fullname="Martin
Schanzenbach">
+ <organization>Technische Universität München</organization>
+ </author>
+ <author initials="C." surname="Grothoff" fullname="Christian
Grothoff">
+ <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";>
+ <front>
+ <title>R5N: Randomized Recursive Routing for Restricted-Route
Networks</title>
+ <author initials="N. S." surname="Evans" fullname="Nathan S. Evans">
+ <organization>Technische Universität München</organization>
+ </author>
+ <author initials="C." surname="Grothoff" fullname="Christian
Grothoff">
+ <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";>
+ <front>
+ <title>Toward secure name resolution on the Internet</title>
+ <author initials="C." surname="Grothoff" fullname="Christian
Grothoff">
+ <organization>Bern University of Applied Sciences</organization>
+ </author>
+ <author initials="M." surname="Wachs" fullname="Matthias Wachs">
+ <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>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";>
+ <front>
+ <title>gnunet.git - GNUnet core repository</title>
+ <author>
+ <organization>GNUnet e.V.</organization>
+ </author>
+ <date year="2023"/>
+ </front>
+ </reference>
+
+ <reference anchor="Ascension"
target="https://git.gnunet.org/ascension.git";>
+ <front>
+ <title>ascension.git - DNS zones to GNS migrating using incremental
zone
+transfer (AXFR/IXFR)</title>
+ <author>
+ <organization>GNUnet e.V.</organization>
+ </author>
+ <date year="2023"/>
+ </front>
+ </reference>
+
+ <reference anchor="GNUnet" target="https://gnunet.org";>
+ <front>
+ <title>The GNUnet Project (Home Page)</title>
+ <author>
+ <organization>GNUnet e.V.</organization>
+ </author>
+ <date year="2023"/>
+ </front>
+ </reference>
+
+ <reference anchor="reclaim" target="https://reclaim.gnunet.org";>
+ <front>
+ <title>re:claimID - Self-sovereign, Decentralised Identity
Management and Personal Data Sharing</title>
+ <author>
+ <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";>
+ <front>
+ <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";>
+ <front>
+ <title>System Databases and Name Service Switch (Section 29)</title>
+ <author>
+ <organization>GNU Project</organization>
+ </author>
+ </front>
+ </reference>
+ </references>
+ </references>
+ <section>
+ <name>Usage and Migration</name>
+ <t>
+ This section outlines a number of specific use cases that may
+ help readers of this technical specification better understand the
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 section provides pointers to migration paths.
+ </t>
+ <section anchor="day_in_zoneowner">
+ <name>Zone Dissemination</name>
+ <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 <xref 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>
+ Sharing zone information directly with specific users not only
allows
+ an implementation to potentially preserve zone and record 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 code that
+ 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>
+ Most Internet services likely want to make their zones available
+ to the general public in the most efficient way possible.
+ First, it is reasonable to assume that zones that are commanding
+ high levels of reputation and trust are likely included in the
+ default suffix-to-zone mappings of implementations.
+ Hence, 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-code TLD registrars also manage GNS zones
+ and offer registration or delegation services.
+ </t>
+ <t>
+ Following best practices, particularly those related to
+ security and abuse mitigation, are methods that allow zone owners
+ and aspiring registrars to gain a good reputation and, eventually,
+ trust.
+ This includes, of course, diligent protection of private zone key
+ material.
+ Formalizing such best practices is out of scope for this
+ specification and should be addressed in a separate document that
takes
+ <xref target="security"/> of this document into account.
+ </t>
+ </section>
+ <section>
+ <name>Start Zone Configuration</name>
+ <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
+ default Start 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
+ default Start Zone configuration.
+ At this point, the user may delete or otherwise modify the
+ implementation's default configuration:
+ </t>
+ <ul>
+ <li>
+ Deletion of suffix-to-zone mappings may become necessary if the
+ zone owner referenced by the mapping has lost the trust of the
user.
+ 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 perforation that 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
+ <xref target="day_in_zoneowner"/>:
+ a bank may send the user a letter with a QR code that 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 for their 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 bank that
+ may also include a credit card is certainly different from a zone
+ found on a random advertisement on the street.
+ However, this trust is immediately tangible to the user and can
+ be reflected in the local naming as well.
+ </li>
+ <li>
+ Users that are also clients should facilitate the modification of
the Start Zone
+ configuration -- for example, by providing a QR code reader or
other
+ import mechanisms.
+ Implementations are ideally implemented
+ according to best practices and addressing applicable points
+ from <xref target="security"/>.
+ Formalizing such best practices is out of scope for this
+ specification.
+ </li>
+ </ul>
+ </section>
+ <section anchor="uc_virthost">
+ <name>Globally Unique Names and the Web</name>
+ <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 names is a prerequisite of those use
cases.
+ </t>
+ <t>
+ Not all GNS names are globally unique.
+ However, any resource record in GNS can be represented as a
+ concatenation of a GNS label and the zTLD of the zone.
+ While not memorable, this globally unique GNS name can be
+ leveraged in order to facilitate the same use cases.
+ Consider the GNS name "www.example.gns.alt" entered in a GNS-aware
+ HTTP client.
+ At first, "www.example.gns.alt" is resolved using GNS, yielding a
record
+ set.
+ Then, the HTTP client determines the virtual host as follows:
+ </t>
+ <t>
+ If there is a LEHO record (<xref 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>
+ <sourcecode name="" type="http-message"><![CDATA[
+GET / HTTP/1.1
+Host: www.example.com
+]]></sourcecode>
+ <t>
+In the absence of a LEHO record, an additional GNS resolution is
+required to check whether "www.example.gns.alt" itself points to a
+zone delegation record, which implies that the record set that 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>
+ <sourcecode name="" type="http-message"><![CDATA[
+GET / HTTP/1.1
+Host: 000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W
+]]></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 (e.g., "www") and the zTLD representation of the zone:
+ </t>
+ <sourcecode name="" type="http-message"><![CDATA[
+GET / HTTP/1.1
+Host: www.000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W
+]]></sourcecode>
+ <t>
+Note that this second GNS resolution does not require any additional
+network operation, as only the local record processing differs as per
+the exception mentioned in the last sentence of <xref
target="delegation_processing"/>.
+ </t>
+ <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>
+ <name>Migration Paths</name>
+ <t>
+ DNS resolution is built into a variety of existing software
+ components -- most significantly, operating systems and HTTP
clients.
+ This section illustrates possible migration paths for both in order
+ to enable legacy applications to resolve GNS names.
+ </t>
+ <t>
+ One way to efficiently facilitate the resolution of GNS names
+ is 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 no Start Zone can be found for the name and it does not end in
+ a zTLD, the server tries to resolve the name in DNS.
+ 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
+ <xref target="GNUnet"/>.
+ </t>
+ <t>
+ A similar approach is to use operating system extensions such as
+ the NSS <xref target="nsswitch"/>.
+ It allows the system administrator to configure plugins
+ that are used for hostname resolution.
+ A GNS nsswitch plugin can be used in a fashion similar to
+ that used for the DNS-to-GNS server.
+ An implementation of a glibc-compatible nsswitch plugin for GNS
+ can be found in <xref target="GNUnet"/>.
+ </t>
+ <t>
+ The methods above are usually also effective for HTTP client
+ software.
+ However, HTTP clients are commonly used in combination with
+ TLS.
+ TLS certificate validation, and SNI in particular, require
additional logic in HTTP clients when GNS names are
+ in play (<xref target="uc_virthost"/>).
+ In order to transparently enable this functionality for migration
+ purposes, a local GNS-aware SOCKS5 proxy <xref 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 can terminate the TLS connection
+ and establish 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 HTTP client; 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
+ <xref target="GNUnet"/>.
+ </t>
+ </section>
+ </section>
+ <section>
+ <name>Example Flows</name>
+ <section>
+ <name>AAAA Example Resolution</name>
+ <figure anchor="figure_resolution_ex_aaaa">
+ <name>Example Resolution of an IPv6 Address</name>
+ <artwork name="" type="" alt="">
+ Local Host | Remote
+ | Storage
+ |
+ | +---------+
+ | / /|
+ | +---------+ |
++-----------+ (1) +----------+ | | | |
+| | | | (4,6) | | Record | |
+|Application|----------| Resolver |---------------|->| Storage | |
+| |<---------| |<--------------|--| |/
++-----------+ (8) +----------+ (5,7) | +---------+
+ A |
+ | |
+ (2,3) | |
+ | |
+ | |
+ +---------+ |
+ / v /| |
+ +---------+ | |
+ | | | |
+ | Start | | |
+ | Zones | | |
+ | |/ |
+ +---------+ |
+ </artwork>
+ </figure>
+ <ol>
+ <li>Look up AAAA record for name: "www.example.gnu.gns.alt".</li>
+ <li>Determine Start Zone for "www.example.gnu.gns.alt".</li>
+ <li>Start Zone: zkey0 - Remainder: "www.example".</li>
+ <li>Calculate q0=SHA512(ZKDF(zkey0, "example")) and initiate
GET(q0).</li>
+ <li>Retrieve and decrypt RRBLOCK consisting of a single PKEY record
containing zkey1.</li>
+ <li>Calculate q1=SHA512(ZKDF(zkey1, "www")) and initiate
GET(q1).</li>
+ <li>Retrieve RRBLOCK consisting of a single AAAA record containing
the IPv6 address 2001:db8::1.</li>
+ <li>Return record set to application.</li>
+ </ol>
+ </section>
+ <section>
+ <name>REDIRECT Example Resolution</name>
+ <figure anchor="figure_resolution_ex_redir">
+ <name>Example Resolution of an IPv6 Address with Redirect</name>
+ <artwork name="" type="" 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>
+ <li>Look up AAAA record for name: "www.example.tld.gns.alt".</li>
+ <li>Determine Start Zone for "www.example.tld.gns.alt".</li>
+ <li>Start Zone: zkey0 - Remainder: "www.example".</li>
+ <li>Calculate q0=SHA512(ZKDF(zkey0, "example")) and initiate
GET(q0).</li>
+ <li>Retrieve and decrypt RRBLOCK consisting of a single PKEY record
containing zkey1.</li>
+ <li>Calculate q1=SHA512(ZKDF(zkey1, "www")) and initiate
GET(q1).</li>
+ <li>Retrieve and decrypt RRBLOCK consisting of a single REDIRECT
record containing "www2.+".</li>
+ <li>Calculate q2=SHA512(ZKDF(zkey1, "www2")) and initiate
GET(q2).</li>
+ <li>Retrieve and decrypt RRBLOCK consisting of a single AAAA record
containing the IPv6 address 2001:db8::1.</li>
+ <li>Return record set to application.</li>
+ </ol>
+ </section>
+ <section>
+ <name>GNS2DNS Example Resolution</name>
+ <figure anchor="figure_resolution_ex_gnsdns">
+ <name>Example Resolution of an IPv6 Address with DNS Handover</name>
+ <artwork name="" type="" alt="">
+ Local Host | Remote
+ | Storage
+ |
+ | +---------+
+ | / /|
+ | +---------+ |
++-----------+ (1) +----------+ | | | |
+| | | | (4) | | Record | |
+|Application|----------| Resolver |------------------|->| Storage | |
+| |<---------| |<-----------------|--| |/
++-----------+ (8) +----------+ (5) | +---------+
+ A A |
+ | | (6,7) |
+ (2,3) | +----------+ |
+ | | |
+ | v |
+ +---------+ +------------+ |
+ / v /| | System DNS | |
+ +---------+ | | Resolver | |
+ | | | +------------+ |
+ | Start | | |
+ | Zones | | |
+ | |/ |
+ +---------+ |
+ </artwork>
+ </figure>
+ <ol>
+ <li>Look up AAAA record for name: "www.example.gnu.gns.alt".</li>
+ <li>Determine Start Zone for "www.example.gnu.gns.alt".</li>
+ <li>Start Zone: zkey0 - Remainder: "www.example".</li>
+ <li>Calculate q0=SHA512(ZKDF(zkey0, "example")) and initiate
GET(q0).</li>
+ <li>Retrieve and decrypt RRBLOCK consisting of a single GNS2DNS
record containing the name "example.com" and the DNS server IPv4 address
192.0.2.1.</li>
+ <li>Use system resolver to look up a AAAA record for the DNS name
"www.example.com".</li>
+ <li>Retrieve a DNS reply consisting of a single AAAA record
containing the IPv6 address 2001:db8::1.</li>
+ <li>Return record set to application.</li>
+ </ol>
+ </section>
+ </section>
+ <section 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>
+ <xref target="CrockfordB32Encode"/> defines the encoding and decoding
symbols for a given
+ symbol value.
+ Each symbol value encodes 5 bits.
+ It can be used to implement the encoding by reading it as follows:
+ a symbol "A" or "a" is decoded to a 5-bit value 10 when decoding.
+ A 5-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 of 5,
+ 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>
+<table anchor="CrockfordB32Encode">
+ <name>The Base32GNS Alphabet, Including the Additional Encoding Symbol
"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 O o</td>
+ <td>0</td>
+ </tr>
+ <tr>
+ <td>1</td>
+ <td>1 I i L l</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 U u</td>
+ <td>V</td>
+ </tr>
+ <tr>
+ <td>28</td>
+ <td>W w</td>
+ <td>W</td>
+ </tr>
+ <tr>
+ <td>29</td>
+ <td>X x</td>
+ <td>X</td>
+ </tr>
+ <tr>
+ <td>30</td>
+ <td>Y y</td>
+ <td>Y</td>
+ </tr>
+ <tr>
+ <td>31</td>
+ <td>Z z</td>
+ <td>Z</td>
+ </tr>
+ </tbody>
+</table>
+
+ </section>
+ <section>
+ <name>Test Vectors</name>
+ <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>
+ <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>
+<sourcecode name="" 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"
+]]></sourcecode>
+
+ </section>
+ <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><strong>(1) PKEY zone with ASCII label and one delegation
record</strong></t>
+ <sourcecode name="" 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 f4
+
+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
+]]></sourcecode>
+ <t><strong>(2) PKEY zone with UTF-8 label and three
records</strong></t>
+ <sourcecode name="" 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 77
+
+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
+]]></sourcecode>
+ <t><strong>(3) EDKEY zone with ASCII label and one delegation
record</strong></t>
+ <sourcecode name="" 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 e9
+
+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] || 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
+]]></sourcecode>
+ <t><strong>(4) EDKEY zone with UTF-8 label and three
records</strong></t>
+ <sourcecode name="" 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 ed
+
+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] || 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
+]]></sourcecode>
+ </section>
+ <section>
+ <name>Zone Revocation</name>
+ <t>
+ The following is an example revocation for a PKEY zone:
+ </t>
+ <sourcecode name="" 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 aa
+
+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
+]]></sourcecode>
+ <t>
+ The following is an example revocation for an EDKEY zone:
+ </t>
+ <sourcecode name="" 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
+
+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
+]]></sourcecode>
+ </section>
+ </section>
+ <section 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>
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0001] branch master updated: update with lsd series,
gnunet <=