path: root/draft-schanzen-gns.xml

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" [
<!ENTITY RFC1034 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml">
<!ENTITY RFC1035 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC2119 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!--<!ENTITY RFC2693 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2693.xml">-->
<!ENTITY RFC2782 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml">
<!ENTITY RFC3629 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml">
<!ENTITY RFC3686 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3686.xml">
<!ENTITY RFC3826 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3826.xml">
<!--<!ENTITY RFC3912 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3912.xml">-->
<!ENTITY RFC5869 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5869.xml">
<!ENTITY RFC5890 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml">
<!ENTITY RFC5891 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5891.xml">
<!ENTITY RFC6234 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6234.xml">
<!ENTITY RFC6781 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6781.xml">
<!ENTITY RFC6895 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6895.xml">
<!ENTITY RFC6979 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6979.xml">
<!ENTITY RFC7363 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7363.xml">
<!ENTITY RFC7748 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7748.xml">
<!ENTITY RFC8032 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8032.xml">
<!ENTITY RFC8126 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml">
<!ENTITY RFC8174 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8324 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8324.xml">
<!ENTITY RFC8499 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8499.xml">
<!ENTITY RFC9106 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9106.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-schanzen-gns-06" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" 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="Internet-Draft" value="draft-schanzen-gns-06"/>
  <author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach">
   <organization>GNUnet e.V.</organization>
   <address>
    <postal>
     <street>Boltzmannstrasse 3</street>
     <city>Garching</city>
     <code>85748</code>
     <country>DE</country>
    </postal>
    <email>schanzen@gnunet.org</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>CH</country>
    </postal>
    <email>grothoff@gnunet.org</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>DE</country>
    </postal>
    <email>fix@gnunet.org</email>
   </address>
  </author>

  <!-- Meta-data Declarations -->
  <area>General</area>
  <workgroup>Independent Stream</workgroup>
  <keyword>name systems</keyword>
  <abstract>
    <t>
      This document contains the GNU Name System (GNS) technical
      specification.
      GNS is a decentralized and censorship-resistant name
      system that provides a privacy-enhancing alternative to the Domain
      Name System (DNS).
    </t>
    <t>
      This document defines the normative wire format of resource records,
      resolution processes, cryptographic routines and security
      considerations for use by implementers.
      It is published here to inform readers about the function
      of GNS, guide future GNS implementations, and ensure
      interoperability among implementations including with the
      pre-existing GNUnet implementation.
    </t>
    <t>
      This specification was developed outside the IETF and does not have
      IETF consensus.  It is published here to guide implementation of GNS
      and to ensure interoperability among implementations.
    </t>
  </abstract>
 </front>
 <middle>
   <section anchor="introduction" numbered="true" toc="default">
     <name>Introduction</name>
     <t>
       The Domain Name System (DNS) <xref target="RFC1035" /> is a unique
       distributed database and a vital service for most Internet applications.
       While DNS is distributed, in practice it
       relies on centralized, trusted registrars to provide globally unique
       names. As the awareness of the central role DNS plays on the Internet
       rises, various institutions are using their power (including legal means)
       to engage in attacks on the DNS, thus threatening the global availability
       and integrity of information on the Internet.
     </t>
     <t>
       DNS was not designed with security as a goal. This makes it very
       vulnerable, especially to attackers that have the technical capabilities
       of an entire nation state at their disposal.
       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>
       This specification describes a censorship-resistant, privacy-preserving
       and decentralized name system: The GNU Name System (GNS) <xref target="GNS" />.
       It is designed to provide a secure, privacy-enhancing alternative to
       DNS, especially when censorship or manipulation is encountered.
       In particular, it directly addresses concerns in DNS with respect to "Query
       Privacy", the "Single Hierarchy with a Centrally Controlled Root" and
       "Distribution and Management of Root Servers" as raised in
       <xref target="RFC8324"/>.
       GNS can bind names to any kind of
       cryptographically secured token, enabling it to double in some respects as
       even as an alternative to some of today’s Public Key Infrastructures, in
       particular X.509 for the Web.
     </t>
     <t>
       The design of GNS incorporates the capability to integrate and
       coexist with DNS.
       GNS is based on the principle of a petname
       system and builds on ideas from the Simple Distributed Security
       Infrastructure <xref target="SDSI" />, addressing a central issue with the decentralized
       mapping of secure identifiers to memorable names: namely the impossibility
       of providing a global, secure and memorable mapping without a trusted
       authority. GNS uses the transitivity in the SDSI design to replace the
       trusted root with secure delegation of authority thus making petnames
       useful to other users while operating under a very strong adversary model.
     </t>
     <t>
       This is an important distinguishing factor from the Domain Name System
       where root zone governance is centralized at the Internet Corporation
       for Assigned Names and Numbers (ICANN).
       In DNS terminology, GNS roughly follows the idea of a hyperlocal root
       zone deployment, with the difference that it is not
       expected that all deployments use the same local root zone.
     </t>
     <t>
       This document defines the normative wire format of resource records, resolution processes,
       cryptographic routines and security 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 guide implementation of GNS
       and to ensure interoperability among implementations.
     </t>
     <section numbered="true" toc="default">
       <name>Requirements Notation</name>
       <t>
         The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
         "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
         "OPTIONAL" 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>
       <dt>Label</dt>
       <dd>
         A GNS label is a label as defined in <xref target="RFC8499"/>.
         Within this document, labels are always assumed to be strings of
         UTF-8 characters <xref target="RFC8499"/> with a maximum length of
         63 bytes.  When hashed, labels MUST be canonicalized using
         Normalization Form C (NFC) <xref target="Unicode-UAX15"/>.
       </dd>
       <dt>Name</dt>
       <dd>
         A name in GNS is a domain name as defined in  <xref target="RFC8499"/>
         as an ordered list of labels.
         The labels in a name are separated using the character "." (dot).
         Names, like labels, are encoded in UTF-8.
       </dd>
       <dt>Top-Level Domain</dt>
       <dd>
	 The rightmost part of a GNS name is a GNS Top-Level Domain (TLD).
         A GNS TLD may consist of one or more labels.
	 Unlike DNS Top-Level Domains (defined in <xref target="RFC8499"/>),
	 GNS does not expect all users to use the same global root zone. Instead,
         with the exception of Zone Top-Level Domains (see below),
         GNS TLDs are typically part of the configuration of the local resolver
         (see <xref target="governance"/>), and may thus 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 a SOA record at its apex.
       </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 signatures.
       </dd>
       <dt>Zone Key</dt>
       <dd>
         The zone key uniquely identifies a zone.
         The zone key is usually a public key of an asymmetric key pair.
       </dd>
       <dt>Blinded Zone Key</dt>
       <dd>
         A blinded zone key is derived from the zone key and a label.
         The zone key and the blinded zone key are unlinkable without knowing the label.
       </dd>
       <dt>Zone Owner</dt>
       <dd>
         The owner of a GNS zone is the holder of the secret (typically a private key)
	 that (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</dt>
       <dd>
         A GNS Zone Top-Level Domain (zTLD) is a sequence of GNS labels at
         the end of a GNS name which encodes a zone type and
         zone key of a zone.
         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>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>
     </dl>
   </section>
   <section anchor="overview" numbered="true" toc="default">
     <name>Overview</name>
     <t>
       In GNS, any user may create and manage one or more cryptographically
       secured zones (<xref target="zones"/>).
       Zones are uniquely identified by a zone key.
       Zone contents are signed using blinded private keys and
       encrypted using derived secret keys.
       The zone type determines the respective set of cryptographic operations
       and the wire formats for encrypted data, public keys and signatures.
     </t>
     <t>
       A zone can be populated with mappings from labels to resource records by
       its owner (<xref target="rrecords"/>).
       A label can be mapped to a delegation record which 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 traditional DNS records.
     </t>
     <t>
       Zone contents are encrypted and signed
       before being published in a distributed key-value storage
       (<xref target="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 blinding factors.
       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 distributed or decentralized
       storages such as distributed hash tables (DHT) in order to facilitate
       availability within a network without the need for dedicated infrastructure.
       Specification of such a distributed or decentralized storage is out of
       scope of this document, but possible existing implementations include those
       based on <xref target="RFC7363" />, <xref target="Kademlia" /> or
       <xref target="R5N" />.
     </t>
     <t>
       Names in GNS are domain names as defined in <xref target="RFC8499"/>.
       Starting from a configurable root zone, names are resolved by following zone
       delegations. For each label in a name, the recursive GNS resolver
       fetches the respective record from the storage layer (<xref target="resolution"/>).
       Without knowledge of the label values and the zone keys, the
       different derived keys are unlinkable both to the original zone key and to each
       other.
       This prevents zone enumeration (except via impractical online brute
       force attacks) and requires knowledge
       of both the zone key and the label to confirm affiliation of a
       query or the corresponding encrypted record set with a
       specific zone. At the same time, the blinded zone key provides
       resolvers
       with the ability to verify the integrity of the published information
       without disclosing the originating zone.
     </t>
     <t>
       In the remainder of this document, the "implementer" refers to the developer building
       a GNS implementation including, for example, zone management tools and
       name resolution components.
       An "application" refers to a component which uses a GNS implementation
       to resolve records from the network and (usually) processes its contents.
     </t>
   </section>
   <section anchor="zones" numbered="true" toc="default">
     <name>Zones</name>
     <t>
       A zone in GNS is uniquely identified by its zone type and zone key.
       It can be represented by a Zone Top-Level Domain (zTLD) string.
     </t>
     <t>
       Each zone type (ztype) is assigned a unique 32-bit number when it is registered
       in the GNUnet Assigned Numbers Authority <xref target="GANA" />.
       The ztype determines which cryptosystem is used for the
       asymmetric and symmetric key operations of the zone.
       The ztype number always corresponds to a resource record type
       number identifying a delegation into a zone of this type. To
       ensure that there are no conflicts with DNS record types, ztypes
       are always assigned numeric values above 65535.
     </t>
     <t>
       For any zone, let d be the private key and zk the public zone key.
       The specific wire format used depends on the ztype.
       The creation of zone keys for the default ztypes are specified in
       <xref target="gnsrecords_delegation"/>.
       New ztypes may be specified in the future, for example if the
       cryptographic mechanisms used in this document are broken.
       Any ztype MUST define the following set of cryptographic functions:
     </t>
     <dl>
       <dt>KeyGen() -> d, zk</dt>
       <dd>
         is a function to generate a fresh private key d and
	 the corresponding public zone key zk.
       </dd>
       <dt>ZKDF-Private(d,label) -> d'</dt>
       <dd>
         is a zone key derivation function which blinds a private key d
         using label, resulting in another private key which
         can be used to create cryptographic signatures.  We note that
         GNS only requires a signature to be created directly with
         d to sign a revocation message for the zone key zk.
       </dd>
       <dt>ZKDF-Public(zk,label) -> zk'</dt>
       <dd>
         is a zone key derivation function which blinds a zone key zk
         using a label. zk and zk' must be unlinkable. Furthermore,
         blinding zk with different values for the label must result
         in unlinkable zk' values.
       </dd>
       <dt>S-Encrypt(zk,label,nonce,expiration,message) -> ciphertext</dt>
       <dd>
         is a symmetric encryption function which encrypts the record
         data based on key material derived from the zone key,
         a label, a nonce and an expiration.
         In order to leverage performance-enhancing caching features of certain
         underlying storages, in particular DHTs, a deterministic encryption
         scheme is recommended.
       </dd>
       <dt>S-Decrypt(zk,label,nonce,expiration,ciphertext) -> message</dt>
       <dd>
         is a symmetric decryption function which decrypts the encrypted record
         data based on key material derived from the zone key,
         a label, a nonce and an expiration.
       </dd>
       <dt>Sign(d,message) -> signature, Sign(d',message) -> signature</dt>
       <dd>
         is a function to sign a message (typically encrypted record data) using the (blinded) private
         key d (d'), yielding an unforgable cryptographic signature.
       </dd>
       <dt>Verify(zk,message,signature) -> boolean, Verify(zk',message,signature) -> boolean</dt>
       <dd>
         is a function to verify the signature was created by
         the private key d (or derived key d') corresponding to
         the zone key zk (or derived zone key zk')
         where d,zk := Keygen(). If deriviations were used, they
         must have used the same label.
         The function returns a boolean value of "TRUE" if the signature is valid,
         and otherwise "FALSE".
       </dd>
     </dl>
     <section anchor="zTLD" numbered="true" toc="default">
       <name>Zone Top-Level Domain</name>
       <figure anchor="figure_zid">
       <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|       ZONE TYPE       |      ZONE KEY         /
+-----+-----+-----+-----+                       /
/                                               /
/                                               /
         ]]></artwork>
     </figure>
       <t>The decoded binary representation of the zTLD</t>
       <t>
         The zTLD is the Zone Top-Level Domain.
         It is a string which encodes the zone type and zone key into a domain name.
         The zTLD is used as a globally unique reference to a specific
         namespace in the process of name resolution.
         To encode the zone key, a zone key label zkl is derived from a
         concatenation of the zone type and zone key (see <xref target="figure_zid"/>)
         using the Crockford Base32 encoding <xref target="CrockfordB32"/>.
         In order to further increase tolerance for failures in character
         recognition, the letter "U" MUST be decoded to the same Base32 value as the
         letter "V".
         The encoding and decoding symbols for Crockford Base32 including this modification are defined in
         <xref target="CrockfordB32Encode"/>.
         The functions for encoding and decoding based on this table are called
         GNSCrockfordEncode and GNSCrockfordDecode, respectively.
       </t>
       <figure anchor="CrockfordB32Encode">
         <artwork name="" type="" align="left" alt=""><![CDATA[
Symbol      Decode            Encode
Value       Symbol            Symbol
0           0 O o             0
1           1 I i L l         1
2           2                 2
3           3                 3
4           4                 4
5           5                 5
6           6                 6
7           7                 7
8           8                 8
9           9                 9
10          A a               A
11          B b               B
12          C c               C
13          D d               D
14          E e               E
15          F f               F
16          G g               G
17          H h               H
18          J j               J
19          K k               K
20          M m               M
21          N n               N
22          P p               P
23          Q q               Q
24          R r               R
25          S s               S
26          T t               T
27          V v               V U
28          W w               W
29          X x               X
30          Y y               Y
31          Z z               Z
         ]]></artwork>
       </figure>
       <t>
         The Base32-Crockford Alphabet Including the Additional U Encode Symbol.
       </t>
       <t>
         For the string representation of a zTLD we define:
       </t>
       <artwork name="" type="" align="left" alt=""><![CDATA[
zkl := GNSCrockfordEncode(ztype|zkey)
ztype|zkey := GNSCrockfordDecode(zkl)
    ]]></artwork>
       <t>
         If zkl is less than 63 characters, it can directly be
         used as a zTLD.
         If zkl is longer than 63 characters, the
         zTLD is constructed by dividing zkl 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 zkl length from the rightmost label and
         to subsequently determine how many labels the zTLD should span.
         For example, assuming a zkl of 130 characters, the encoding would be:
       </t>
       <artwork name="" type="" align="left" alt=""><![CDATA[
zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
       ]]></artwork>
   </section>
    <section anchor="revocation" numbered="true" toc="default">
       <name>Zone Revocation</name>
       <t>
         Whenever a resolver encounters a new GNS zone, it MUST
         check against the local revocation list whether the respective
         zone key has been revoked.  If the zone key was revoked, the
         resolution MUST fail with an empty result set.
       </t>
       <t>
         In order to revoke a zone key, a signed revocation message MUST be
         published.
         This message MUST be signed using the private key.
         The revocation message is broadcast to the network.
         The specification of the broadcast mechanism is out of scope of 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 MUST contain a proof of work
         (PoW).
         The revocation message including the PoW MAY 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>
         <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">
         <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                      POW                      |
+-----------------------------------------------+
|                   TIMESTAMP                   |
+-----------------------------------------------+
|       ZONE TYPE       |    ZONE KEY           |
+-----+-----+-----+-----+                       |
/                                               /
/                                               /
+-----+-----+-----+-----+-----+-----+-----+-----+
           ]]></artwork>
       </figure>
       <t>The Format of the PoW Data.</t>
       <dl>
         <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 in network
           byte order.
         </dd>
         <dt>ZONE TYPE</dt>
         <dd>
           is the 32-bit zone type.
         </dd>
         <dt>ZONE KEY</dt>
         <dd>
           is the 256-bit public key zk of the zone which is being revoked.
           The wire format of this value is defined by the ZONE TYPE.
         </dd>
       </dl>
       <t>
         Traditionally, PoW schemes require to find a POW value such that
         at least D leading zeroes are found in the hash result.
         D is then referred to as the difficulty of the PoW.
         In order to reduce the variance in time it takes to calculate the
         PoW, we require that a number Z different PoWs must be
         found that on average have D leading zeroes.
       </t>
       <t>
         The resulting proofs may then published and disseminated. The concrete
         dissemination and publication methods are out of scope of this
         document. Given an average difficulty of D, the proofs have an
         expiration time of EPOCH. With each additional bit difficulty, the
         lifetime of the proof is prolonged for another EPOCH.
         Consequently, by calculating a more difficult PoW, the lifetime of the
         proof can be increased on demand by the zone owner.
       </t>
       <t>
         The parameters are defined as follows:
       </t>
       <dl>
         <dt>Z</dt>
         <dd>The number of PoWs required is fixed at 32.</dd>
         <dt>D</dt>
         <dd>The minimum average difficulty is fixed at 22.</dd>
         <dt>EPOCH</dt>
         <dd>A single epoch is fixed at 365 days.</dd>
       </dl>
       <t>
         The revocation message wire format is illustrated in
         <xref target="figure_revocationdata"/>.
       </t>
       <figure anchor="figure_revocationdata">
         <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   TIMESTAMP                   |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                      TTL                      |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                     POW_0                     |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                       ...                     |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                     POW_Z-1                   |
+-----------------------------------------------+
|       ZONE TYPE       |    ZONE KEY           |
+-----+-----+-----+-----+                       |
/                                               /
/                                               /
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   SIGNATURE                   |
/                                               /
/                                               /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
           ]]></artwork>
       </figure>
       <t>The Revocation Message Wire Format.</t>
       <dl>
         <dt>TIMESTAMP</dt>
         <dd>
           denotes the absolute 64-bit date when the revocation was computed.
           In microseconds since midnight (0 hour), January 1, 1970 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 also in network byte order. This field is informational
           for a verifier. A verifier MAY discard a revocation without
           checking the POW values or the signature if the TTL (in combination with TIMESTAMP)
           indicates that the revocation has already expired. However, the actual TTL of the
           revocation must be determined by examining the leading zeros in the
           proof of work calculation.
         </dd>
         <dt>POW_i</dt>
         <dd>
           The values calculated as part of the PoW, in network byte order.
           Each POW_i MUST be unique in the set of POW values.
           To facilitate fast verification
           of uniqueness, the POW values must 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.
         </dd>
         <dt>ZONE KEY</dt>
         <dd>
           is the public key zk of the zone which 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 zk of the zone
           which 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 over the public key covers a 32-bit pseudo header
         conceptually prefixed to the public key. The pseudo header includes
        the key length and signature purpose. The wire format is illustrated
        in <xref target="figure_revsigwithpseudo"/>.
       </t>
       <figure anchor="figure_revsigwithpseudo">
         <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|         SIZE (0x30)   |       PURPOSE (0x03)  |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   TIMESTAMP                   |
+-----+-----+-----+-----+-----+-----+-----+-----+
|       ZONE TYPE       |     ZONE KEY          |
+-----+-----+-----+-----+                       |
/                                               /
/                                               /
+-----+-----+-----+-----+-----+-----+-----+-----+
           ]]></artwork>
       </figure>
       <t>The Wire Format of the Revocation Data for Signing.</t>
       <dl>
         <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. This field MUST be 3 (in network
           byte order).
         </dd>
         <dt>ZONE TYPE</dt>
         <dd>
           The 32-bit zone type corresponding to the zone key.
         </dd>
         <dt>ZONE KEY / TIMESTAMP</dt>
         <dd>Both values as defined in the revocation message above.</dd>
       </dl>
       <t>
         In order to verify a revocation the following steps must be taken,
         in order: <!-- FIXME: why can an implementation not change the order, say if one check is slower than other checks? -->
       </t>
       <ol>
         <li>The signature MUST match the public key.</li>
         <li>The set of POW values MUST NOT contain duplicates.</li>
         <li>The average number of leading zeroes D' resulting from the provided
         POW values MUST be greater than and not equal to D.  Implementors
         MUST NOT use an integer data type to calculate or represent D'.</li>
         <li>The validation period (TTL) of the revocation is calculated as
           (D'-D) * EPOCH * 1.1. The EPOCH is extended by
           10% in order to deal with unsynchronized clocks.
           The TTL added on top of the TIMESTAMP yields the
           expiration date.</li>
         <!-- FIXME: what if the TTL in the message disagrees with our calculations? What should be done?
              What if floating point rounding errors cause a disagreement in TTL calculations?
              IMO we should simply mandate that when FORWARDING a message, the sender should
              use the TTL they calculated themselves. -->
         <li>The current time MUST be between TIMESTAMP and
           TIMESTAMP+TTL.</li>
       </ol>
     </section>


   </section>
   <section anchor="rrecords" numbered="true" toc="default">
     <name>Resource Records</name>
     <t>
       A GNS implementer MUST provide a mechanism to create and manage resource
       records for local zones. A local zone is established by selecting a
       zone type and creating a zone key pair.
       As records may be added to each created zone, a (local) persistence
       mechanism such as a database for resource records and zones must be provided.
       This local zone database is used by the name resolution logic and serves
       as a basis for publishing zones into the GNS storage (see <xref target="publish"/>).
     </t>
     <t>
       A GNS resource record holds the data of a specific record in a zone.
       The resource record format is defined in
       <xref target="figure_gnsrecord"/>.
     </t>
     <figure anchor="figure_gnsrecord">
       <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   EXPIRATION                  |
+-----+-----+-----+-----+-----+-----+-----+-----+
|       DATA SIZE       |          TYPE         |
+-----+-----+-----+-----+-----+-----+-----+-----+
|           FLAGS       |        DATA           /
+-----+-----+-----+-----+                       /
/                                               /
/                                               /
         ]]></artwork>
     </figure>
     <t>The Resource Record Wire Format.</t>
     <dl>
       <dt>EXPIRATION</dt>
       <dd>
         denotes the absolute 64-bit expiration date of the record.
         In microseconds since midnight (0 hour), January 1, 1970 in network
         byte order.
       </dd>
       <dt>DATA SIZE</dt>
       <dd>
         denotes the 32-bit size of the DATA field in bytes and in network byte
         order.
       </dd>
       <dt>TYPE</dt>
       <dd>
         is the 32-bit resource record type. This type can be one of the GNS resource
         records as defined in <xref target="rrecords" /> or a DNS record
         type as defined in <xref target="RFC1035" /> or any of the
         complementary standardized DNS resource record types. This value must be
         stored in network byte order. Note that values
         below 2^16 are reserved for allocation via IANA <xref target="RFC6895" />,
         while values above 2^16 are allocated by the
         GNUnet Assigned Numbers Authority <xref target="GANA" />.
       </dd>
       <dt>FLAGS</dt>
       <dd>
         is a 32-bit resource record flags field (see below).
       </dd>
       <dt>DATA</dt>
       <dd>
         the variable-length resource record data payload. The contents are defined
         by the
         respective type of the resource record.
       </dd>
     </dl>
     <t>
       Flags indicate metadata surrounding the resource record. A flag
       value of 0 indicates that all flags are unset.
       Applications creating resource records MUST set all bits which are
       not defined as a flag to 0. Additional flags may be defined in
       future protocol versions.
       If an application or implementation encounters a flag which it does not
       recognize, it MUST be ignored.
       <xref target="figure_flag"/>
       illustrates the flag distribution in the 32-bit flag value of a
       resource record:
     </t>
     <figure anchor="figure_flag">
       <artwork name="" type="" align="left" alt=""><![CDATA[
 0        1        2        3        4        5...
+--------+--------+--------+--------+--------+----
|RESERVED|PRIVATE |SUPPL   |EXPREL  | SHADOW | ...
+--------+--------+--------+--------+--------+----
         ]]></artwork>
     </figure>
     <t>The Resource Record Flag Wire Format.</t>
     <dl>
       <dt>SHADOW</dt>
       <dd>
         If this flag is set, this record should be ignored by resolvers unless all (other)
         records of the same record type have expired.  Used to allow zone publishers to
         facilitate good performance when records change by allowing them to put future
         values of records into the storage.
         This way, future values can propagate and may be
         cached before the transition becomes active.
       </dd>
       <dt>EXPREL</dt>
       <dd>
         The expiration time value of the record is a relative time (still in microseconds)
         and not an absolute time. This flag should never be encountered by a resolver
         for records obtained from the storage, but might be present when a resolver looks up
         private records of a zone hosted locally.
       </dd>
       <dt>
         SUPPL
       </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
         may be useful for the application. This flag should only be encountered
         by a resolver for records obtained from the storage.
       </dd>
       <dt>PRIVATE</dt>
       <dd>
         This is a private record of this peer and it should thus not be
         published.  Thus, this flag should never be encountered by
         a resolver for records obtained from the storage.
         Private records should still be considered just like
         regular records when resolving labels in local zones.
       </dd>
     </dl>
   <section anchor="gnsrecords_delegation" numbered="true" toc="default">
     <name>Zone Delegation Records</name>
     <t>
       This section defines the initial set of zone delegation record types.
       Any implementation MUST support all zone types defined here and
       MAY support any number of additional delegation records defined in
       the GNU Name System Record Types registry <xref target="gana"/>.
       Zone delegation records MUST NOT be stored and published under the
       empty label.
     </t>
     <section anchor="gnsrecords_pkey" numbered="true" toc="default">
       <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 number is a zone
         type and thus also implies the cryptosystem for the zone that
         is being delegated to.
         A PKEY resource record contains the public key of the zone to
         delegate to.
         A PKEY record MUST be the only record under a label. No other
         records are allowed. The PKEY DATA entry wire format can be found
         in <xref target="figure_pkeyrecord"/>.
       </t>
       <figure anchor="figure_pkeyrecord">
         <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   PUBLIC KEY                  |
|                                               |
|                                               |
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
           ]]></artwork>
       </figure>
       <t>The PKEY Wire Format.</t>
       <dl>
         <dt>PUBLIC KEY</dt>
         <dd>
           A 256-bit ECDSA zone 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" /> (a.k.a. edwards25519)
         with the ECDSA scheme <xref target="RFC6979" />.
         Consequently, we use the following naming convention for our
         cryptographic primitives for PKEY zones:
       </t>
       <dl>
         <dt>d</dt>
         <dd>
           is a 256-bit ECDSA private key.
         </dd>
         <dt>zk</dt>
         <dd>
           is the ECDSA public zone key corresponding to d.
         </dd>
         <dt>p</dt>
         <dd>
           is the prime of edwards25519 as defined in <xref target="RFC7748" />, i.e.
           2^255 - 19.
         </dd>
         <dt>G</dt>
         <dd>
           is the group generator (X(P),Y(P)) of edwards25519 as defined in
           <xref target="RFC7748" />.
         </dd>
         <dt>L</dt>
         <dd>
           is the order of the prime-order subgroup of edwards25519 in <xref target="RFC7748" />.
         </dd>
         <dt>KeyGen()</dt>
         <dd>The generation of the private
           scalar d and the curve point zk := d*G (where G is the group generator
           of the elliptic curve) as defined in Section 2.2. of
           <xref target="RFC6979" /> represents the KeyGen() function.
         </dd>
       </dl>
       <t>
         The zone type and zone key of a PKEY are 32 + 4 bytes in length. This means that
         a zTLD will always fit into a single label and does
         not need any further conversion.
       </t>
       <t>
         Given a label, the output d' of the ZKDF-Private(d,label) function for zone
         key blinding is calculated as follows for PKEY zones:
       </t>
       <artwork name="" type="" align="left" alt=""><![CDATA[
zk := d * G
PRK_h := HKDF-Extract ("key-derivation", zk)
h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
d' := (h * d) mod L
        ]]></artwork>
       <t>
         Equally, given a label, the output zk' of the ZKDF-Public(zk,label) function is
         calculated as follows for PKEY zones:
       </t>
         <artwork name="" type="" align="left" alt=""><![CDATA[
PRK_h := HKDF-Extract ("key-derivation", zk)
h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
zk' := (h mod L) * zk
        ]]></artwork>
       <t>
         The PKEY cryptosystem uses a hash-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 using the string
         "key-derivation" as salt and the zone key as 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 label is a UTF-8 string under which the resource records are
         published.
         The multiplication of zk with h is a point multiplication,
         while the multiplication of d with h 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" />.
       </t>
       <t>
         The S-Encrypt() and S-Decrypt() functions use AES in counter mode
         as defined in <xref target="MODES" /> (CTR-AES-256):
       </t>
       <artwork name="" type="" align="left" alt=""><![CDATA[
CIPHERTEXT := CTR-AES256(K, IV, DATA)
DATA := CTR-AES256(K, IV, CIPHERTEXT)
         ]]></artwork>
       <t>
         The key K and counter IV are derived from
         the record label and the zone key zk as follows:
       </t>
       <artwork name="" type="" align="left" alt=""><![CDATA[
PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
PRK_n := HKDF-Extract ("gns-aes-ctx-iv", zk)
K := HKDF-Expand (PRK_k, label, 256 / 8);
NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
]]></artwork>
       <t>
         HKDF is a hash-based key derivation function as defined in
         <xref target="RFC5869" />. Specifically, 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 <xref target="RFC3826" /> key.
       </t>
       <t>
         The nonce is combined with a 64-bit initialization vector and a
         32-bit block counter as defined in <xref target="RFC3686" />.
         The block counter begins with the 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 initialization vector is the expiration time of the
         resource record block in network byte order.
         The resulting counter (IV) wire format can be found in
         <xref target="figure_hkdf_ivs_pkey"/>.
       </t>
       <figure anchor="figure_hkdf_ivs_pkey">
         <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32
+-----+-----+-----+-----+
|         NONCE         |
+-----+-----+-----+-----+
|       EXPIRATION      |
|                       |
+-----+-----+-----+-----+
|      BLOCK COUNTER    |
+-----+-----+-----+-----+
           ]]></artwork>
       </figure>
       <t>The Block Counter Wire Format.</t>
     </section>
     <section anchor="gnsrecords_edkey" numbered="true" toc="default">
       <name>EDKEY</name>
       <t>
         In GNS, a delegation of a label to a zone of type "EDKEY" is
         represented through a EDKEY record.  The EDKEY number is a zone
         type and thus also implies the cryptosystem for the zone that
         is being delegated to.
         An EDKEY resource record contains the public key of the zone to
         delegate to.
         A EDKEY record MUST be the only record under a label. No other
           records are allowed. The EDKEY DATA entry wire format
         is illustrated in <xref target="figure_edkeyrecord"/>.
       </t>
       <figure anchor="figure_edkeyrecord">
         <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   PUBLIC KEY                  |
|                                               |
|                                               |
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
           ]]></artwork>
       </figure>
       <t>The EDKEY DATA Wire Format.</t>
       <dl>
         <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. edwards25519)
           with the Ed25519-SHA-512 scheme <xref target="ed25519" />.
           Consequently, we use the following naming convention for our
           cryptographic primitives for EDKEY zones:
         </t>
         <dl>
           <dt>d</dt>
           <dd>
             is a 256-bit EdDSA private key.
           </dd>
           <dt>a</dt>
           <dd>
             is is an integer derived from d using the SHA-512 hash function
             as defined in <xref target="ed25519" />.
           </dd>
           <dt>zk</dt>
           <dd>
             is 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="ed25519" />.
           </dd>
           <dt>p</dt>
           <dd>
             is the prime of edwards25519 as defined in <xref target="RFC7748" />, i.e.
             2^255 - 19.
           </dd>
           <dt>G</dt>
           <dd>
             is the group generator (X(P),Y(P)) of edwards25519 as defined in
            <xref target="RFC7748" />.
           </dd>
           <dt>L</dt>
           <dd>
             is the order of the prime-order subgroup of edwards25519 in <xref target="RFC7748" />.
           </dd>
           <dt>KeyGen()</dt>
           <dd>
             The generation of the private key d and the associated public
             key zk := 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 Section 3.2. of <xref target="RFC8032" /> represents the KeyGen()
             function.
            </dd>
         </dl>
         <t>
           The zone type and zone key of an EDKEY are 32 + 4 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"/>.
           Given a label, the output of the ZKDF-Private function for zone
           key blinding is calculated as follows for EDKEY zones:
         </t>
         <artwork name="" type="" align="left" alt=""><![CDATA[
zk := a * G
PRK_h := HKDF-Extract ("key-derivation", zk)
h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
h[31] &= 7
a1 := a / 8 /* 8 is the cofactor of Curve25519 */
a2 := (h * a1) mod L
a' = a2 * 8 /* 8 is the cofactor of Curve25519 */
           ]]></artwork>
         <t>
           Equally, given a label, the output of the ZKDF-Public function is
           calculated as follows for PKEY zones:
         </t>
         <artwork name="" type="" align="left" alt=""><![CDATA[
PRK_h := HKDF-Extract ("key-derivation", zk)
h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
h[31] &= 7  // Implies h mod L == h
zk' := h * zk
           ]]></artwork>
         <t>
           We note that implementers must employ a constant time scalar
           multiplication for the constructions above. Also, implementers
           must ensure that the private key a is an ed25519 private key
           and specifically that "a[0] &#38; 7 == 0" holds.
         </t>
         <t>
           The EDKEY cryptosystem uses a
           hash-based key derivation function (HKDF) as defined in
           <xref target="RFC5869" />, using SHA-512 <xref target="RFC6234"/> for the extraction
           phase and HMAC-SHA256 <xref target="RFC6234"/> for the expansion phase.
           PRK_h is key material retrieved using an HKDF using the string
           "key-derivation" as salt and the zone key as 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 label is a UTF-8 string under which the resource records are
           published.
           The multiplication of zk with h is a point multiplication,
           while the division and multiplication of a and a1 with the
           co-factor are integer operations.
         </t>
         <t>
           Signatures for EDKEY zones using the derived private key a'
           are not compliant with <xref target="ed25519" />.
           As the corresponding private key to the derived private scalar a'
           is not known, it is not possible to deterministically derive the
           signature part R according to <xref target="ed25519" />.
           Instead, signatures MUST be generated as follows for any given
           message M:
           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 M to r.
           This way, we include the full derivation path in the calculation
           of the R value of the signature, ensuring that it is never reused
           for two different derivation paths or messages.
         </t>
         <artwork name="" type="" align="left" alt=""><![CDATA[
dh := SHA-512 (d)
nonce := SHA-256 (dh[32..63] | h)
r := SHA-512 (nonce | M)
R := r * G
S := r + SHA-512(R | zk' | M) * a' mod L
           ]]></artwork>
         <t>
           A signature (R,S) is valid if the following holds:
         </t>
         <artwork name="" type="" align="left" alt=""><![CDATA[
S * G == R + SHA-512(R, zk', M) * zk'
           ]]></artwork>
         <t>
           The S-Encrypt() and S-Decrypt() functions use XSalsa20
           as defined in <xref target="XSalsa20" />
           (XSalsa20-Poly1305):
         </t>
         <artwork name="" type="" align="left" alt=""><![CDATA[
CIPHERTEXT := XSalsa20-Poly1305(K, IV, DATA)
DATA := XSalsa20-Poly1305(K, IV, CIPHERTEXT)
           ]]></artwork>
         <t>
           The result of the XSalsa20-Poly1305 encryption function is the encrypted
           ciphertext concatenated with 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 zk as follows:
         </t>
         <artwork name="" type="" align="left" alt=""><![CDATA[
PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
PRK_n := HKDF-Extract ("gns-aes-ctx-iv", zk)
K := HKDF-Expand (PRK_k, label, 256 / 8);
NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
]]></artwork>
         <t>
           HKDF is a hash-based key derivation function as defined in
           <xref target="RFC5869" />. Specifically, 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
           <xref target="XSalsa20" /> key.
           No additional authenticated data (AAD) is used.
         </t>
         <t>
           The nonce is combined with an 8 byte initialization vector.
           The initialization vector 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">
           <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32
+-----+-----+-----+-----+
|         NONCE         |
|                       |
|                       |
|                       |
+-----+-----+-----+-----+
|       EXPIRATION      |
|                       |
+-----+-----+-----+-----+
             ]]></artwork>
       </figure>
       <t>The Counter Block Initialization Vector</t>

     </section>
       <section anchor="gnsrecords_gns2dns" numbered="true" toc="default">
       <name>GNS2DNS</name>
       <t>It is possible to delegate a label back into DNS through a GNS2DNS record.
         The resource record contains a DNS name for the resolver to continue with
         in DNS followed by a DNS server. Both names are in the format defined in
         <xref target="RFC1034" /> for DNS names.
           A GNS2DNS DATA entry is illustrated in <xref target="figure_gns2dnsrecord"/>.</t>
       <figure anchor="figure_gns2dnsrecord">
         <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                    DNS NAME                   |
/                                               /
/                                               /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                 DNS SERVER NAME               |
/                                               /
/                                               /
|                                               |
+-----------------------------------------------+
           ]]></artwork>
       </figure>
       <t> The GNS2DNS DATA Wire Format</t>
       <dl>
         <dt>DNS NAME</dt>
         <dd>
           The name to continue with in DNS. The value is UTF-8 encoded and
           0-terminated.
         </dd>
         <dt>DNS SERVER NAME</dt>
         <dd>
           The DNS server to use. May be an IPv4 address in dotted-decimal
           form or an IPv6 address in colon-hexadecimal form or a DNS name.
           It may also be a relative GNS name ending with a
           "+" top-level domain.
           The implementation MUST check the string syntactically for a
           an IP address in the respective notation before checking for a
           relative GNS name.
           If all three checks fail, the name MUST be treated as a DNS name.
           The value is UTF-8 encoded and 0-terminated.
         </dd>
       </dl>
     </section>


   </section>
     <section anchor="gnsrecords_other" numbered="true" toc="default">
       <name>Auxiliary Records</name>
       <t>
         This section defines the initial set of auxiliary GNS record types. Any
         implementation MUST be able to process the specified record types
         according to <xref target="record_processing"/>.
       </t>
     <section anchor="gnsrecords_leho" numbered="true" toc="default">
       <name>LEHO</name>
       <t>
         Applications can use the GNS to lookup IPv4 or IPv6 addresses of
         internet services.
         However, sometimes connecting to such services does not only require
         the knowledge of an address and port, but also requires the canonical
         DNS name of the service to be transmitted over the transport protocol.
         In GNS, legacy host name 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, where a DNS name must
         be supplied in the HTTP "Host"-header.
         Using a GNS name for the "Host"-header may not work as
         it may not be globally unique.

         A LEHO resource record is expected to be found together in a single
         resource record with an IPv4 or IPv6 address.
         A LEHO DATA entry is illustrated in <xref target="figure_lehorecord"/>.</t>
       <figure anchor="figure_lehorecord">
         <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                 LEGACY HOSTNAME               |
/                                               /
/                                               /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
           ]]></artwork>
       </figure>
       <t> The LEHO DATA Wire Format.</t>
       <dl>
         <dt>LEGACY HOSTNAME</dt>
         <dd>
           A UTF-8 string (which is not 0-terminated) representing the legacy hostname.
         </dd>
       </dl>
       <t>
         NOTE: If an application uses a LEHO value in an HTTP request header
         (e.g. "Host:" header) it must be converted to a punycode representation
         <xref target="RFC5891" />.
       </t>
     </section>
     <section anchor="gnsrecords_nick" numbered="true" toc="default">
       <name>NICK</name>
       <t>
         Nickname records can be used by zone administrators to publish an
         the label that a zone prefers to have used when it is referred to.
         This is a suggestion to other zones what label to use when creating a
         delegation record (<xref target="gnsrecords_delegation" />) containing
         this zone key.
         This record SHOULD only be stored under the empty label "@" but MAY 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">
         <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                  NICKNAME                     |
/                                               /
/                                               /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
           ]]></artwork>
       </figure>
       <t>The NICK DATA Wire Format.</t>
       <dl>
         <dt>NICKNAME</dt>
         <dd>
           A UTF-8 string (which is not 0-terminated) representing the preferred
           label of the zone. This string MUST NOT include a "." character.
         </dd>
       </dl>
     </section>
     <section anchor="gnsrecords_box" numbered="true" toc="default">
       <name>BOX</name>
       <t>
         In GNS, with the notable exception of zTLDs, every "." in a name
         delegates to another zone, and
         GNS lookups are expected to return all of the required useful
         information in one record set.  This is incompatible with the
         special labels used by DNS for SRV and TLSA records.  Thus, GNS
         defines the BOX record format to box up SRV and TLSA records and
         include them in the record set of the label they are associated
         with.  For example, a
         TLSA record for "_https._tcp.example.org" will be stored in the record set of
         "example.org" as a BOX record with service (SVC) 443 (https) and 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">
         <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|   PROTO   |    SVC    |       TYPE            |
+-----------+-----------------------------------+
|                 RECORD DATA                   |
/                                               /
/                                               /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
           ]]></artwork>
       </figure>
       <t>The BOX DATA Wire Format.</t>
       <dl>
         <dt>PROTO</dt>
         <dd>
           the 16-bit protocol number, e.g. 6 for tcp. In network byte order.
         </dd>
         <dt>SVC</dt>
         <dd>
           the 16-bit service value of the boxed record, i.e. the port number.
           In network byte order.
         </dd>
         <dt>TYPE</dt>
         <dd>
           is the 32-bit record type of the boxed record. In network byte order.
         </dd>
         <dt>RECORD DATA</dt>
         <dd>
           is a variable length field containing the "DATA" format of TYPE as
           defined for the respective TYPE in DNS.
         </dd>
       </dl>
     </section>
     <section anchor="gnsrecords_vpn" numbered="true" toc="default">
       <name>GTS</name>
       <t>
         The GNUnet Tunnel Service record is used by
         applications to establish a tunnel between two peers in the
         peer-to-peer network (see <xref target="GNUnet"/>).
         The GTS record serves as an example of how resolvers may automatically
         initiate tunnel establishment and provide IP address information in the
         resolution process as specified in <xref target="resolution"/>.
       </t>
       <t>
           A GTS DATA entry wire format is illustrated in
         <xref target="figure_vpnrecord"/>.
       </t>
       <figure anchor="figure_vpnrecord">
         <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|          HOSTING PEER PUBLIC KEY              |
|                (256 bits)                     |
|                                               |
|                                               |
+-----------+-----------------------------------+
|   PROTO   |    SERVICE  NAME                  |
+-----------+                                   +
/                                               /
/                                               /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
           ]]></artwork>
       </figure>
       <t>The GTS DATA Wire Format.</t>
       <dl>
         <dt>HOSTING PEER PUBLIC KEY</dt>
         <dd>
           is a 256-bit EdDSA public key identifying the peer hosting the
           service.
         </dd>
         <dt>PROTO</dt>
         <dd>
           the 16-bit tunnel protocol number. In network byte order.
           The possible values are defined by the GNUnet Tunnel Service.
         </dd>
         <dt>SERVICE NAME</dt>
         <dd>
           a shared secret used to identify the service at the hosting peer,
           used to derive the port number required to connect to the service.
           The service name MUST be a 0-terminated UTF-8 string.
         </dd>
       </dl>
     </section>
   </section>
   </section>
   <section anchor="publish" numbered="true" toc="default">
     <name>Record Storage</name>
     <t>
       Any API which allows storing a value under a key and retrieving
       a value from the key can be used by an implementation for record storage.
       We assume that an implementation realizes two procedures on top of a
       storage:
     </t>
     <artwork name="" type="" align="left" alt=""><![CDATA[
PUT(key,value)
GET(key) -> value
       ]]></artwork>
     <t>
       There is no explicit delete function as the deletion of a non-expired
       record would require a revocation of the record.
       In GNS, zones can only be revoked as a whole. Records automatically
       expire and it is under the discretion of the storage as to when to delete
       the record. The GNS implementation MUST NOT publish expired resource
       records. Any GNS resolver MUST discard expired records returned from
       the storage.
     </t>
     <t>
       Resource records are grouped by their respective labels,
       encrypted and published together in a single resource records block
       (RRBLOCK) in the storage under a key q: PUT(q, RRBLOCK).
       The key q is derived from the zone key and the respective
       label of the contained records.
       The required knowledge of both zone key and label in combination
       with the similarly derived symmetric secret keys and blinded zone keys
       ensure query privacy (see <xref target="RFC8324"/>, Section 3.5).
       The storage key derivation and records
       block creation is specified in the following sections.
       A client implementation MUST enable the user the manage zones.
       The implementation MUST use the PUT storage procedure in order to update
       the zone contents accordingly.
     </t>
     <section anchor="blinding" numbered="true" toc="default">
       <name>The Storage Key</name>
       <t>
         Given a label, the storage key q is derived as follows:
       </t>
       <artwork name="" type="" align="left" alt=""><![CDATA[
q := SHA-512 (ZKDF-Public(zk, label))
         ]]></artwork>
       <dl>
         <dt>label</dt>
         <dd>is a UTF-8 string under which the resource records are published.
         </dd>
         <dt>zk</dt>
         <dd>
           is the zone key.
         </dd>
         <dt>q</dt>
         <dd>
           Is the 512-bit storage key under which the resource records block is
           published.
           It is the SHA-512 hash <xref target="RFC6234"/> over the derived zone key.
         </dd>
       </dl>
     </section>
     <section anchor="records_block" numbered="true" toc="default">
       <name>The Records Block (RRBLOCK)</name>
       <t>
         GNS records are grouped by their labels and published as a single
         block in the storage. The grouped record sets MAY be paired with any
         number of supplemental records. Supplemental records must have the
         supplemental flag set (See <xref target="rrecords"/>).
         The contained resource records are encrypted using a symmetric
         encryption scheme.
         A GNS implementation must publish RRBLOCKs
         in accordance to the properties and recommendations of the underlying
         storage. This may include a periodic refresh publication.
         The GNS RRBLOCK wire format is illustrated in
         <xref target="figure_record_block"/>.
       </t>
       <figure anchor="figure_record_block">
         <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|       ZONE TYPE       |    ZONE KEY           |
+-----+-----+-----+-----+       (BLINDED)       |
/                                               /
/                                               /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   SIGNATURE                   |
/                                               /
/                                               /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
|         SIZE          |       PURPOSE         |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   EXPIRATION                  |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                    BDATA                      /
/                                               /
/                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
           ]]></artwork>
       </figure>
       <t>The RRBLOCK Wire Format.</t>
       <dl>
         <dt>ZONE TYPE</dt>
         <dd>
           is the 32-bit zone type.
         </dd>
         <dt>ZONE KEY</dt>
         <dd>
           is the blinded zone key "ZKDF-Public(zk, label)"
           to be used to verify SIGNATURE.
         </dd>
         <dt>SIGNATURE</dt>
         <dd>
           The signature is computed over the data following
           this field.
           The signature is created using the Sign() function of
           the cryptosystem of the zone and the derived private key
           "ZKDF-Private(d, label)" (see <xref target="zones" />).
         </dd>
         <dt>SIZE</dt>
         <dd>
           A 32-bit value containing the length of the signed data following the
           PUBLIC KEY field in network byte order. This value always includes the
           length of the fields SIZE (4), PURPOSE (4) and EXPIRATION (8) in
           addition to the length of the BDATA.  While a 32-bit value is used,
           implementations MAY refuse to publish blocks beyond a certain
           size significantly below 4 GB. However, a minimum block size of
           62 kilobytes MUST be supported.
           <!-- See GNUNET_CONSTANTS_MAX_BLOCK_SIZE -->
         </dd>
         <dt>PURPOSE</dt>
         <dd>
           A 32-bit signature purpose flag. For a RRBLOCK the value of this
           field MUST be 15. The value is encoded in network byte order.
           The value of this field corresponds to an entry in the
           GANA "GNUnet Signature Purpose" registry.
         </dd>
         <dt>EXPIRATION</dt>
         <dd>
           Specifies when the RRBLOCK expires and the encrypted block
           SHOULD be removed from the storage and caches as it is likely stale.
           However, applications MAY continue to use non-expired individual
           records until they expire.  The value MUST be set to the
           expiration time of the resource record contained within this block with the
           smallest expiration time.
           If a records block includes shadow records, then the maximum
           expiration time of all shadow records with matching type and the
           expiration times of the non-shadow records is considered.
           This is a 64-bit absolute date in microseconds since midnight
           (0 hour), January 1, 1970 in network byte order.
         </dd>
         <dt>BDATA</dt>
         <dd>
           The encrypted RDATA with a total size of SIZE - 16.
         </dd>
       </dl>
       <t>
         A symmetric encryption scheme is used to encrypt the resource records
         set RDATA into the BDATA field of a GNS RRBLOCK.
         The wire format of the RDATA is illustrated in
         <xref target="figure_rdata"/>.
       </t>
       <figure anchor="figure_rdata">
         <artwork name="" type="" align="left" alt=""><![CDATA[
0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|     RR COUNT          |        EXPIRA-        /
+-----+-----+-----+-----+-----+-----+-----+-----+
/         -TION         |       DATA SIZE       |
+-----+-----+-----+-----+-----+-----+-----+-----+
|         TYPE          |          FLAGS        |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                      DATA                     /
/                                               /
/                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   EXPIRATION                  |
+-----+-----+-----+-----+-----+-----+-----+-----+
|       DATA SIZE       |          TYPE         |
+-----+-----+-----+-----+-----+-----+-----+-----+
|           FLAGS       |        DATA           /
+-----+-----+-----+-----+                       /
/                       +-----------------------/
/                       |                       /
+-----------------------+                       /
/                     PADDING                   /
/                                               /
           ]]></artwork>
       </figure>
       <t>The RDATA Wire Format.</t>
       <dl>
         <dt>RR COUNT</dt>
         <dd>
           A 32-bit value containing the number of variable-length resource
           records which are
           following after this field in network byte order.
         </dd>
         <dt>EXPIRATION, DATA SIZE, TYPE, FLAGS and DATA</dt>
         <dd>
           These fields were defined
           in the resource record format in <xref target="rrecords" />.
           There MUST be a total of RR COUNT of these resource records
           present.
         </dd>
         <dt>PADDING</dt>
         <dd>
           When publishing an RDATA block, the implementation MUST ensure that
           the size of the RDATA WITHOUT the RR COUNT field is a power of two
           using the padding field. The field MUST be set to zero and MUST be
           ignored on receipt.
           As a special exception, record sets with (only) a zone delegation
           record type are never padded.
           Note that a record set with a delegation record MUST NOT
           contain other records. If other records are encountered, the whole
           record block MUST be discarded.
         </dd>
       </dl>
     </section>
   </section>
    <section anchor="resolution" numbered="true" toc="default">
     <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
       iterative results for a query.
       <!--(as is the case with iterative DNS resolution). REMOVED -->
       Instead, it MUST respond to a resolution request with either the
       requested resource record or an error message in case the resolution
       fails.
       In the following, we define how resolution is initiated and each
       iteration in the resolution is processed.
     </t>
     <t>
       GNS resolution of a name must start in a given starting zone indicated using
       a zone key.
       Details on how the starting zone may be determined are discussed in
       <xref target="governance" />.
     </t>
     <t>
       When GNS name resolution is requested, a desired record type MAY be
       provided by the client.
       The GNS resolver will use the desired record type to guide
       processing, for example by providing conversion of GTS records to A
       or AAAA records.

       However, filtering of record sets according to the required record
       types MUST still be done by the client after the resource record set
       is retrieved.
     </t>
     <section anchor="governance" numbered="true" toc="default">
       <name>Root Zone</name>
       <t>
         The resolution of a GNS name must start in a given start zone
         indicated to the resolver using any zone key.
         The local resolver may have a local start zone configured/hard-coded
         which points to a local or remote start zone key.
         A resolver client may also determine the start zone from the
         suffix of the name given for resolution or using information
   retrieved out of band.
         The governance model of any zone is at the sole discretion
         of the zone owner.
         However, the choice of start zone(s) 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 <xref target="RFC8324"/>, Section 3.10 and 3.12).
       </t>
        <t>
         In the following, we give examples how a local client resolver SHOULD
         discover the start zone.  The process given is not exhaustive and
         clients MAY supplement it with other mechanisms or ignore it if the
   particular application requires a different process.
       </t>
       <t>
         GNS clients MUST first try to interpret the top-level domain of
         a GNS name as a zone key representation (i.e. a zTLD).
         If the top-level domain is indicated to be a label representation of
         a zone key with a supported zone type value, the root zone of
         the resolution process is implicitly given by the suffix of the name:
       </t>
       <artwork name="" type="" align="left" alt=""><![CDATA[
Example name: www.example.<zTLD>
=> Root zone: zk of type ztype
=> Name to resolve from root zone: www.example
         ]]></artwork>
       <t>
         In GNS, users MAY own and manage their own zones.
         Each local zone SHOULD be associated with a single GNS label,
   but users MAY choose to use longer names consisting of
   multiple labels.
         If the name of a locally managed zone matches the suffix
         of the name to be resolved, resolution MUST start from the respective local zone:
       </t>
       <artwork name="" type="" align="left" alt=""><![CDATA[
Example name: www.example.org
Local zones:
fr = (d0,zk0)
org = (d1,zk1)
com = (d2,zk2)
...
=> Root zone: zk1
=> Name to resolve from root zone: www.example
         ]]></artwork>
       <t>
         Finally, additional "suffix-to-zone" mappings MAY be configured.
         Suffix to zone key mappings MUST be configurable through a local
         configuration file or database by the user or system administrator.
         The suffix MAY consist of multiple GNS labels concatenated with a
         ".". If multiple suffixes match the name to resolve, the longest
         matching suffix MUST be used. The suffix length of two results
         MUST NOT be equal. This indicates a misconfiguration and the
         implementation MUST return an error.
         If both a locally managed zone and a configuration entry exist
         for the same suffix, the locally managed zone MUST have priority.
       </t>
       <artwork name="" type="" align="left" alt=""><![CDATA[
Example name: www.example.org
Local suffix mappings:
org = zk0
example.org = zk1
example.com = zk2
...
=> Root zone: zk1
=> Name to resolve from root zone: www
         ]]></artwork>
     </section>

       <section anchor="recursion" numbered="true" toc="default">
         <name>Recursion</name>
         <t>
           In each step of the recursive name resolution, there is an
           authoritative zone zk and a name to resolve. The name may be empty.
           Initially, the authoritative zone is the start zone. If the name
           is empty, it is interpreted as the apex label "@".
         </t>
         <t>
           From here, the following steps are recursively executed, in order:
         </t>
         <ol>
           <li>Extract the right-most label from the name to look up.</li>
           <li>Calculate q using the label and zk as defined in
           <xref target="blinding" />.</li>
           <li>Perform a storage query GET(q) to retrieve the RRBLOCK.</li>
           <li>Verify and process the RRBLOCK and decrypt the BDATA contained
             in it as defined by its zone type (see also <xref target="records_block" />).</li>
         </ol>
         <t>
           Upon receiving the RRBLOCK from the storage, apart from verifying the
           provided signature, the resolver MUST check that the authoritative
           zone key was used to sign the record:
           The derived zone key zk' MUST match the public key provided in
           the RRBLOCK, otherwise the RRBLOCK MUST be ignored and the storage
           lookup GET(q) MUST continue.
         </t>
       </section>
       <section anchor="record_processing" numbered="true" toc="default">
         <name>Record Processing</name>
   <t>
           Record processing occurs at the end of a single recursion. We assume
           that the RRBLOCK has been cryptographically verified and decrypted.
           At this point, we must first determine if we have received a valid
           record set in the context of the name we are trying to resolve:
         </t>
   <ul>
         <li>
           Case 1:
           If the remainder of the name to resolve is empty and the record set
           does not consist of a delegation, CNAME or DNS2GNS record,
           the record set is the result and the recursion is concluded.
         </li>
   <li>
     Case 2:
     If 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 result and the recursion
     is concluded (<xref target="box_processing" />).
   </li>
         <li>
           Case 3:
           If the remainder of the name to resolve is not empty and
     does not match the "_SERVICE._PROTO" syntax, then the current record set
           MUST consist of a single delegation record (<xref target="delegation_processing" />),
           a single CNAME record (<xref target="cname_processing" />),
           or one or more GNS2DNS records (<xref target="gns2dns_processing" />),
           which are processed as described in the respective sections below.
           The record set may include any number of supplemental records.
           Otherwise, resolution fails
           and the resolver MUST return an empty record set.

     Finally, after the recursion terminates, the client preferences
     for the record type MUST be considered and possible conversions such as
           defined in <xref target="vpn_processing" /> MUST be performed.
     </li>
   </ul>
         <section anchor="delegation_processing" numbered="true" toc="default">
           <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.
             Implementations MUST NOT allow multiple different zone type
             delegations under a single label.
             Implementations MAY support any subset of zone types.  If
             an unsupported zone type is encountered, resolution fails and an
             error MUST be returned. The information that the zone type is
             unknown SHOULD be returned in the error description. The
             implementation MAY choose not to return the reason for the failure,
             merely impacting troubleshooting information for the user.
             Implementations MUST NOT process zone delegation for the empty
             apex label "@". Upon encountering a zone delegation record under
             this label, resolution fails and an error MUST be returned. The
             implementation MAY 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 we have
             received a record set containing only a single delegation record, the
             recursion is continued with the record value as authoritative zone
             and the empty apex label "@" as remaining name, except in the case
             where the desired record type is equal to the zone type, in which
             case the delegation record is returned and the resolution is concluded without
             resolving the empty apex label.
           </t>
         </section>
         <section anchor="gns2dns_processing" numbered="true" toc="default">
           <name>GNS2DNS</name>
           <t>
             When a resolver encounters one or more GNS2DNS records and the remaining name
             is empty and the desired record type is GNS2DNS, the GNS2DNS
             records are returned.
           </t>
           <t>
             Otherwise, it is expected that the resolver first resolves the
             IP addresses of the specified DNS name servers. GNS2DNS records MAY
             contain numeric IPv4 or IPv6 addresses, allowing the resolver to
             skip this step.
             The DNS server names may themselves be names in GNS or DNS.
             If the DNS server name ends in ".+", the rest of the name is to be
             interpreted relative to the zone of the GNS2DNS record.
             If the DNS server name ends in a label representation of a
             zone key, the DNS server name is to be resolved against
             the GNS zone zk.
           </t>
           <t>
             Multiple GNS2DNS records may be stored under the same label,
             in which case the resolver MUST try all of them.
             The resolver MAY try them in any order or even in parallel.
             If multiple GNS2DNS records are present, the DNS name MUST be
             identical for all of them, if not the resolution fails and an
             empty record set is returned as the record set is invalid.
           </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
             resolved by querying the DNS name server(s).  As the DNS servers
             specified are possibly authoritative DNS servers, the GNS resolver MUST
             support recursive DNS resolution and MUST NOT delegate this to the
             authoritative DNS servers.
             The first successful recursive name resolution result
             is returned to the client.
             In addition, the resolver returns the queried DNS name as a
             supplemental LEHO record (<xref target="gnsrecords_leho" />) with a
             relative expiration time of one hour.
           </t>
           <t>
             Once the transition from GNS into DNS is made through a
             GNS2DNS record, there is no "going back".
             The (possibly recursive) resolution of the DNS name MUST NOT
             delegate back into GNS and should only follow the DNS specifications.
             For example, names contained in CNAME records MUST NOT be
             interpreted as GNS names.
           </t>
     <t>
       GNS resolvers MUST 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 and a GNS2DNS record
       is explicitly requested by the application, such records MUST
       still be returned, even if DNS support is disabled by the
       GNS resolver configuration.
     </t>
         </section>
         <section anchor="cname_processing" numbered="true" toc="default">
           <name>CNAME</name>
           <t>
             If a CNAME record is encountered, the canonical name is
             appended to the remaining name, except if the remaining name
             is empty and the desired record type is CNAME, in which case
             the resolution concludes with the CNAME record.
             If the canonical name ends in ".+",
             resolution continues in GNS with the new name in the
             current zone.  Otherwise, the resulting name is resolved via the
             default operating system name resolution process.
             This may in turn again trigger a GNS resolution process depending
             on the system configuration.
             <!-- Note: this permits non-DNS resolvers to be triggered via NSS! -->
           </t>
           <t>
             The recursive DNS resolution process may yield a CNAME as well
             which in turn may either point into the DNS or GNS namespace
             (if it ends in a label representation of a zone key).
             In order to prevent infinite loops, the resolver MUST
             implement loop detections or limit the number of recursive
             resolution steps.
             If the last CNAME was a DNS name, the resolver returns the DNS name
             as a supplemental LEHO record (<xref target="gnsrecords_leho" />)
             with a relative expiration time of one hour.
       <!-- Note: Martin: do we actually implement this in GNS today?
      Seems rather tricky to detect if we go via NSS... -->
           </t>
         </section>
         <section anchor="box_processing" numbered="true" toc="default">
           <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="vpn_processing" numbered="true" toc="default">
           <name>GTS</name>
           <t>
             At the end of the recursion,
             if the queried record type is either A or AAAA and the retrieved
             record set contains at least one GTS record, the resolver SHOULD
             open a tunnel and return the IPv4 or IPv6 tunnel address,
             respectively.
             If the implementation does not have the capacity to establish
             a GTS tunnel, for example because it is not connected to the GNUnet
             network, the record set MUST be returned as retrieved from the network.
           </t>
         </section>
         <section anchor="nick_processing" numbered="true" toc="default">
           <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 client. The encountered NICK records may either
             be 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 client to match the record to the
             authoritative zone. Consider the following example:
           </t>
         <artwork name="" type="" align="left" alt=""><![CDATA[
Query: alice.example (type=A)
Result:
A: 192.0.2.1
NICK: eve
         ]]></artwork>
        <t>
          In this example, the returned NICK record is non-supplemental.
          For the client, this means that the NICK belongs to the zone
          "alice.example" and is published under the empty label along with an A
          record. The NICK record should be interpreted as: The zone defined by
          "alice.example" wants to be referred to as "eve".
          In contrast, consider the following:
        </t>
         <artwork name="" type="" align="left" alt=""><![CDATA[
Query: alice.example (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" and is published under the
       label "alice" along with an A record. The NICK record should be
       interpreted as: The zone defined by "example" 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" numbered="true" toc="default">
       <name>Internationalization and Character Encoding</name>
       <t>
         All labels in GNS are encoded in UTF-8 <xref target="RFC3629" />.
         This does not include any DNS names found in DNS records, such as CNAME
         records, which are internationalized through the IDNA specifications
         <xref target="RFC5890" />.
       </t>
     </section>
     <section anchor="security" numbered="true" toc="default">
       <name>Security and Privacy Considerations</name>
       <section anchor="security_crypto" numbered="true" toc="default">
         <name>Cryptography</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.  The 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 SHOULD
           select a default zone type considered secure at the time of
           releasing the software.
           For applications targeting end users that are not expected to
           understand cryptography, the application developer MUST NOT leave
           the zone type selection of new zones to end users.
         </t>
         <t>
           This document concerns itself with the selection of cryptographic
           algorithms for use 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
           isn't 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>
           GNS PKEY zone keys use ECDSA over Curve25519.
           This is an unconventional choice,
           as ECDSA is usually used with other curves.  However, traditional
           ECDSA curves are problematic for a range of reasons described in
           the Curve25519 and EdDSA papers.  Using EdDSA directly is also
           not possible, as a hash function is used on the private key which
           destroys the linearity that the GNU Name System depends upon.
           We are not aware of anyone suggesting that using Curve25519 instead
           of another common curve of similar size would lower the security of
           ECDSA.  GNS uses 256-bit curves because that way the encoded (public)
           keys fit into a single DNS label, which is good for usability.
         </t>
         <t>
           In terms of crypto-agility, whenever the need for an updated cryptographic
           scheme arises to, for example, replace ECDSA over Curve25519 for
           PKEY records it may simply be introduced
           through a new record type. Such a new record type may then replace
           the delegation record type for future records.
           The old record type remains
           and zones can iteratively migrate to the updated zone keys.
         </t>
         <t>
           In order to ensure ciphertext indistinguishability, care must be
           taken with respect to the initialization vector in the counter
           block. In our design, the IV is always the expiration time of the
           record block.
           For blocks with relative expiration times it is implicitly
           ensured that each time a block is published into the storage, its IV is
           unique as the expiration time is calculated dynamically and increases
           monotonically.
           The implementation MUST ensure that when relative expiration times
           are decreased that the expiration time of the next record block is
           always after the last published block.
           For blocks with absolute expiration times, the implementation
           MUST ensure that the expiration time is increased when the record
           data changes. For example, the expiration time may be increased
           by a single microsecond.
           In case of deletion of all resource records under a label, the
           implementation MUST keep track of the last absolute expiration time
           of the last published resource block.
           When new records are added under this label later, the implementation
           MUST ensure that the expiration times are after the last published
           block.
           Finally, in order to ensure monotonically increasing expiration times
           the implementation MUST keep a local record of the last time obtained
           from the system clock, so as to construct a monotonic clock in case
           the system clock jumps backwards.
         </t>
       </section>
       <section anchor="security_abuse" numbered="true" toc="default">
         <name>Abuse Mitigation</name>
         <t>
           GNS names are UTF-8 strings. Consequently, GNS faces similar issues
           with respect to name spoofing as DNS does for internationalized
           domain names.
           In DNS, attackers may register similar sounding or 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, which is one of the motivations behind GNS.
           Hence, such a seizure is, by design, difficult to impossible in GNS.
           <!--In particular, GNS does not support WHOIS (<xref target="RFC3912" />).-->
         </t>
       </section>
       <section anchor="security_keymanagement" numbered="true" toc="default">
         <name>Zone Management</name>
         <t>
           In GNS, zone administrators need to manage and protect their zone
           keys. Once a zone key is lost it cannot be recovered. Once it is
           compromised it cannot be revoked (unless a revocation message was
           pre-calculated and is still available).
           Zone administrators, and for GNS this includes end-users, are
           required to responsibly and diligently protect their cryptographic
           keys.
           GNS supports offline signing of records.
           It does not support separate zone signing and key-signing keys
           (as in <xref target="RFC6781" />) in order to provide usable security.
         </t>
         <t>
           Similarly, users are required to manage their local root zone.
           In order to ensure integrity and availability or names, users must
           ensure that their local root zone information is not compromised or
           outdated.
           It can be expected that the processing of zone revocations and an
           initial root zone is provided with a GNS client implementation
           ("drop shipping").
           Extension and customization of the zone is at the full discretion of
           the user.
         </t>
         <t>
           While implementations following this specification will be
           interoperable, if two implementations connect to different storages
           they are mutually unreachable.
           This may lead to a state where a record may exist in the global
           namespace for a particular name, but the implementation is not
           communicating with the storage and is hence unable to resolve it.
           This situation is similar to a split-horizon DNS configuration.
           Which storages are implemented usually depend on the application
           it is built for.
           The storage used will most likely depend on the specific application
           context using GNS resolution.
           For example, one application may be the resolution of hidden services
           within the Tor network.
           Implementations of "aggregated" storages are conceivable, but
           are expected to be the exception.
         </t>
       </section>
       <section anchor="security_dht" numbered="true" toc="default">
         <name>Impact of DHTs as Underlying Storage</name>
         <t>
           This document does not specify the properties of the underlying
           storage which is required by any GNS implementation.
           For implementers using a DHT as underlying storage, it is important
           to note that the properties of the DHT are directly inherited by the
           GNS implementation. This includes both security as well as
           other non-functional properties such as scalability and performance.
           Implementers should take great care when selecting or implementing
           a DHT for use in a GNS implementation.
           DHTs with strong security and performance guarantees exist
           <xref target="R5N"/>.
           It should also be taken into consideration that GNS implementations
           which build upon different DHT overlays are unlikely to be
           interoperable with each other.
         </t>
       </section>
       <section anchor="security_rev" numbered="true" toc="default">
         <name>Revocations</name>
         <t>
           Zone administrators are advised to pre-generate zone revocations
           and securely store the revocation information in case the zone
           key is lost, compromised or replaced in the future.
           Pre-calculated revocations may become invalid due to expirations
           or protocol changes such as epoch adjustments.
           Consequently, implementers and users must make 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>
         <t>
           If revocation is used 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 even a
           revocation. Thus, allowing a revocation message to replace a private
           key makes dealing with key compromise situations worse.
         </t>
         <t>
           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 ciphersystems in parallel for a while. The
           migration would conclude by revoking the legacy zone key only once
           it is deemed no longer secure, and hopefully after most users have
           migrated to the replacement.
         </t>
       </section>
       <section anchor="privacy_labels" numbered="true" toc="default">
         <name>Label Guessing</name>
         <t>
           Record blocks are published encrypted using keys derived from the
           zone key and record label. Zone administrators should
           carefully consider if the label and zone key may be public or if
           those should be used and considered as a shared secret.
           Unlike zone keys, labels can also be guessed by
           an attacker in the network observing queries and responses. Given
           a known and targeted zone key, the use of well known or easily guessable
           labels effectively result in general disclosure of the records to
           the public.
           If the labels and hence the records should be kept secret except to
           those knowing a secret label and the zone in which to look, the
           label must be chosen accordingly. It is recommended to then use a
           label with sufficient entropy as to prevent guessing attacks.
         </t>
         <t>
           It should be noted that this 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 the zone keys are blinded beforehand.
         </t>
       </section>
     </section>
     <section anchor="gana" numbered="true" toc="default">
       <name>GANA Considerations</name>
       <t>
         GANA <xref target="GANA" />
         is requested to create an "GNU Name System Record Types" registry.
         The registry shall record for each entry:
       </t>
       <ul>
         <li>Name: 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.</li>
         <li>Number: 32-bit, above 65535</li>
         <li>Comment: Optionally, a brief English text describing the purpose of
           the record type (in UTF-8)</li>
         <li>Contact: Optionally, the contact information of a person to contact for
           further information.</li>
         <li>References: Optionally, references describing the record type
           (such as an RFC)</li>
       </ul>
       <t>
         The registration policy for this sub-registry is "First Come First
         Served". This policy is modeled on that described in <xref target="RFC8126"/>,
         but describes the actions taken by GANA.
       </t>
       <t>
         Adding records is possible after expert review, using a
         first-come-first-served policy for unique name allocation.
         Experts are responsible to ensure that the chosen "Name" is
         appropriate for the record type.
         The registry will assign a unique number for the entry.
       </t>
       <t>
         The current contact(s) for expert review are reachable at
         gns-registry@gnunet.org.
       </t>
       <t>
         Any request MUST contain a unique name and a point of contact.
         The contact information MAY be added to the registry given the consent
         of the requester.
         The request MAY optionally also contain relevant references as well
         as a descriptive comment as defined above.
       </t>
       <t>
         GANA is requested to populate this registry as listed in
         <xref target="figure_rrtypenums"/>.
       </t>
       <figure anchor="figure_rrtypenums">
         <artwork name="" type="" align="left" alt=""><![CDATA[
Number | Name    | Contact | References | Comment
-------+---------+---------+------------+-------------------------
65536  | PKEY    | N/A     | [This.I-D] | GNS zone delegation (PKEY)
65537  | NICK    | N/A     | [This.I-D] | GNS zone nickname
65538  | LEHO    | N/A     | [This.I-D] | GNS legacy hostname
65539  | GTS     | N/A     | [This.I-D] | GTS tunnel metadata
65540  | GNS2DNS | N/A     | [This.I-D] | Delegation to DNS
65556  | EDKEY   | N/A     | [This.I-D] | GNS zone delegation (EDKEY)

           ]]></artwork>
       </figure>
       <t>The GANA Resource Record Registry.</t>
       <t>
         GANA is requested to amend the "GNUnet Signature Purpose" registry
           as illustrated in <xref target="figure_purposenums"/>.
       </t>
       <figure anchor="figure_purposenums">
         <artwork name="" type="" align="left" alt=""><![CDATA[
Purpose | Name            | References | Comment
--------+-----------------+------------+--------------------------
  3     | GNS_REVOCATION  | [This.I-D] | GNS zone key revocation
 15     | GNS_RECORD_SIGN | [This.I-D] | GNS record set signature
           ]]></artwork>
       </figure>
       <t>Requested Changes in the GANA GNUnet Signature Purpose Registry.</t>
     </section>
     <!-- gana -->
     <section>
       <name>IANA Considerations</name>
       <t>
         This document makes no requests for IANA action.
         This section may be removed on publication as an RFC.
       </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 given that 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 <xref target="R5N"/>
         DHT. The <xref target="GoGNS"/> implementation uses this deployment
         by building on top of the GNUnet DHT services available on any
         GNUnet peer. It shows how GNS implementations and client resolvers
         can attach to this existing deployment and participate in name
         resolution as well as zone publication.
       </t>
     </section>
     <section>
       <name>Test Vectors</name>
       <t>
         The following represents a test vector for a record set with a DNS
         record of type "A" as well as a GNS record of type "PKEY"
         under the label "test".
       </t>
       <artwork name="" type="" align="left" alt="">
         <![CDATA[
Zone private key (d, big-endian):
50d7b652a4efeadf
f37396909785e595
2171a02178c8e7d4
50fa907925fafd98

Zone identifier (ztype|zkey):
00010000677c477d
2d93097c85b195c6
f96d84ff61f5982c
2c4fe02d5a11fedf
b0c2901f

Encoded zone identifier (zkl = zTLD):
000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W

Label: test
RRCOUNT: 2

Record #0
EXPIRATION: 2463385894000000
DATA_SIZE: 4
TYPE: 1
FLAGS: 0
DATA:
01020304

Record #1
EXPIRATION: 49556645701000000
DATA_SIZE: 36
TYPE: 65537
FLAGS: 2
DATA:
536f6d65206e6963
6b005265636f7264
2023310a00524441
54413a0a00456e63
72797074

RDATA:
000000020008c06f
b928158000000004
0000000100000000
0102030400b00f81
b7449b4000000024
0001000100000002
536f6d65206e6963
6b005265636f7264
2023310a00524441
54413a0a00456e63
7279707400000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
00000000

Encryption NONCE|EXPIRATION|BLOCK COUNTER:
67ebda270008c06f
b928158000000001

Encryption key (K):
551f157acf2bf1d4
a975036999ea7c82
86acb318f1493e63
b500603a9b02e3e4

Storage key (q):
83e2711f96bb61ee
858d3d3213d4fad2
87dc6949416a1182
101ebc66b2c54ba9
bee3ee6e1a573930
47b7bd957f5217e9
12c355c108939888
d675a1f2a46bea54

BDATA:
4a09ed7c23601304
02325780fea8f56b
c074062a7af2a9c7
673e8e695444de95
290cd1ce411fa53f
71a001b98cfd803c
4d252520c761c642
2084f9ee5ceff183
da22bef9b872378e
7c25835471d5ab17
16675dc8ce214b7b
e107d4eb798add6b
78d78d47762a79c3
4f155f97d68bacf1
8f30ef0086ebed06
6e03640c1bdcf038
73979bf2

RRBLOCK:
000100008e16da87
203b5159c5538e9b
765742e968c54af9
afbc0890dc80205a
d14c84e10d545799
e1d609108114b0c8
caabece848609ed7
d8f286340fde5ba6
848083170a43c3e9
47a7dca1fb2c3c05
4ffd607359021e12
5582b0ef4dfefc46
113d421c00000094
0000000f0008c06f
b92815804a09ed7c
2360130402325780
fea8f56bc074062a
7af2a9c7673e8e69
5444de95290cd1ce
411fa53f71a001b9
8cfd803c4d252520
c761c6422084f9ee
5ceff183da22bef9
b872378e7c258354
71d5ab1716675dc8
ce214b7be107d4eb
798add6b78d78d47
762a79c34f155f97
d68bacf18f30ef00
86ebed066e03640c
1bdcf03873979bf2


         ]]>
       </artwork>

       <t>
         The following represents a test vector for a record set with a DNS
         record of type "A" as well as a GNS record of type "EDKEY"
         under the label "test".
       </t>
       <artwork name="" type="" align="left" alt="">
         <![CDATA[
Zone private key (d):
5af7020ee1916032
8832352bbc6a68a8
d71a7cbe1b929969
a7c66d415a0d8f65

Zone identifier (ztype|zkey):
000100143cf4b924
032022f0dc505814
53b85d93b047b63d
446c5845cb48445d
db96688f

Encoded zone identifier (zkl = zTLD):
000G051WYJWJ80S04BRDRM2R2H9VGQCKP13VCFA4DHC4BJT88HEXQ5K8HW

Label: test
RRCOUNT: 2

Record #0
EXPIRATION: 2463385894000000
DATA_SIZE: 4
TYPE: 1
FLAGS: 0
DATA:
01020304

Record #1
EXPIRATION: 49556645701000000
DATA_SIZE: 36
TYPE: 65537
FLAGS: 2
DATA:
4d79204e69636b00
456e637279707469
6f6e204e4f4e4345
7c45585049524154
494f4e3a

RDATA:
000000020008c06f
b928158000000004
0000000100000000
0102030400b00f81
b7449b4000000024
0001000100000002
4d79204e69636b00
456e637279707469
6f6e204e4f4e4345
7c45585049524154
494f4e3a00000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
00000000

Encryption NONCE|EXPIRATION:
1c1600abdd297064
99b96e8e135b903d
0008c06fb9281580

Encryption key (K):
4b8bdb9ecf347434
61a8ac529447d2ea
d76248a2be79e7b6
a4dd9800d304230e

Storage key (q):
952779babc3ff83c
9c5191f2d517f84a
35c964f925fcaf59
454ced7b3d8f2283
3ab1ae7f85ba02f0
4dde3f94495b5fb8
0b69bed17d8452ba
9e125a7cd83981e8

BDATA:
3d7c6988468933e9
89e95c994fec9536
85e2efe5b32e4b11
d8cbfe4ca800c322
6dd5752e3f48378d
6e2b55f1d73b0dcc
87fe7ce2ff310b2b
faf8f3fa73c7ed97
5c7b44d48b6d8e14
aaafc267b3a077f7
db95324df4cce80e
76ec45de1b8953f4
6be2d720e3340483
0c2cc77ee4859093
e380b5eedec6effb
420156e67e7d3241
4784a71203fc8b99
d3ea99541a27a1d9
146ec9ad

RRBLOCK:
0001001472c18971
854e4a4f428934e1
52746b9dc464e7a9
122f7750fe4eaa6b
33b7bba079a5e37e
655cd68ceee90723
6ec333bdc4996dba
9aa6ce4f1eaba9cf
b43b9cb4856277ab
3b8ebfce0ccb124b
3e2e0877757454a3
fe62df18e193cdff
3e54690b000000a4
0000000f0008c06f
b92815803d7c6988
468933e989e95c99
4fec953685e2efe5
b32e4b11d8cbfe4c
a800c3226dd5752e
3f48378d6e2b55f1
d73b0dcc87fe7ce2
ff310b2bfaf8f3fa
73c7ed975c7b44d4
8b6d8e14aaafc267
b3a077f7db95324d
f4cce80e76ec45de
1b8953f46be2d720
e33404830c2cc77e
e4859093e380b5ee
dec6effb420156e6
7e7d32414784a712
03fc8b99d3ea9954
1a27a1d9146ec9ad
           ]]>
       </artwork>
       <t>
         The following is an example revocation for a zone:
       </t>
       <artwork name="" type="" align="left" alt="">
         <![CDATA[
Zone private key (d, big-endian scalar):
6b1ee07223116bd7
dad0f22677c5dd33
823b204e5e845d19
7e64f1b66879ced0

Zone identifier (ztype|zkey):
00010000432ff523
fc9dd390ba829320
75ff7283df74cd96
204838dd0448b4f9
4a40f932

Encoded zone identifier (zkl = zTLD):
000G00235ZTJ7Z4XTE8BN0MK41TZYWM3VXTCV5H090WDT128PKWMMG7S68

Difficulty (5 base difficulty + 2 epochs): 7

Proof:
0005d657213d208c
0000395d1827c000
7fcb353aff966e2e
7fcb353aff96708a
7fcb353aff967108
7fcb353aff967152
7fcb353aff967164
7fcb353aff96718f
7fcb353aff967213
7fcb353aff9672d4
7fcb353aff9673ae
7fcb353aff9673b5
7fcb353aff967402
7fcb353aff96746e
7fcb353aff96750b
7fcb353aff967546
7fcb353aff96755f
7fcb353aff96762c
7fcb353aff967634
7fcb353aff967695
7fcb353aff9676a5
7fcb353aff9676cb
7fcb353aff9676eb
7fcb353aff9676f4
7fcb353aff96771d
7fcb353aff967755
7fcb353aff96777e
7fcb353aff9677b4
7fcb353aff9678a2
7fcb353aff967914
7fcb353aff967941
7fcb353aff967aa9
7fcb353aff967d04
7fcb353aff967d1b
00010000432ff523
fc9dd390ba829320
75ff7283df74cd96
204838dd0448b4f9
4a40f93200010000
075713bbc84bd10e
e9efe31ab81893c1
c813e0a19761c070
fd52827e3929c9b5
0a6841a44c8b37de
b9f76ffcb798c0d5
b9ae0482cdaa9095
2fb5aa5bc7a1c120
         ]]>
       </artwork>
     </section>
     <section pn="section-acks">
        <name>Acknowledgements</name>
        <t>
          The authors thank D. J. Bernstein, A. Farrel and S. Bortzmeyer for their
          insightful reviews. We thank NLnet and NGI DISCOVERY for funding
          work on the GNU Name System.
        </t>
     </section>
   </middle>
   <back>
     <references>
       <name>Normative References</name>

       &RFC1034;
       &RFC1035;
       &RFC2782;
       &RFC2119;
       &RFC3629;
       &RFC3686;
       &RFC3826;
       &RFC5869;
       &RFC5890;
       &RFC5891;
       &RFC6234;
       &RFC6895;
       &RFC6979;
       &RFC7748;
       &RFC8032;
       &RFC8126;
       &RFC8174;
       &RFC8499;
       &RFC9106;

       <reference anchor="GANA" target="https://gana.gnunet.org/">
         <front>
           <title>GNUnet Assigned Numbers Authority (GANA)</title>
           <author><organization>GNUnet e.V.</organization>
           </author>
           <date month="April" year="2020" />
         </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"/>
           <abstract>
             <t>
               This recommendation defines five confidentiality modes of operation for use with an underlying symmetric key block cipher algorithm: Electronic Codebook (ECB), Cipher Block Chaining (CBC), Cipher Feedback (CFB), Output Feedback (OFB), and Counter (CTR). Used with an underlying block cipher algorithm that is approved in a Federal Information Processing Standard (FIPS), these modes can provide cryptographic protection for sensitive, but unclassified, computer data.
             </t>
           </abstract>
         </front>
       </reference>
       <!--       <reference anchor="GCM" target="https://doi.org/10.6028/NIST.SP.800-38D">
         <front>
           <title>Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC</title>
          <author initials="M." surname="Dworkin" fullname="Morris Dworkin">
            <organization>NIST</organization>
          </author>

           <date year="2007" month="November"/>
           <abstract>
             <t>
               This Recommendation specifies the Galois/Counter Mode (GCM), an algorithm for authenticated encryption with associated data, and its specialization, GMAC, for generating a message authentication code (MAC) on data that is not encrypted. GCM and GMAC are modes of operation for an underlying approved symmetric key block cipher.
             </t>
           </abstract>
         </front>
       </reference>-->
      <reference anchor="CrockfordB32" target="https://www.crockford.com/base32.html">
         <front>
           <title>Base32</title>
          <author initials="D." surname="Douglas" fullname="Crockford">
          </author>

           <date year="2019" month="March"/>
         </front>
       </reference>
       <reference anchor="XSalsa20" target="https://cr.yp.to/snuffle/xsalsa-20110204.pdf">
         <front>
           <title>Extending the Salsa20 nonce</title>
          <author initials="D." surname="Bernstein" fullname="Daniel Bernstein">
            <organization>University of Illinois at Chicago</organization>
          </author>
           <date year="2011"/>
         </front>
       </reference>
       <reference anchor="Unicode-UAX15" target="http://www.unicode.org/reports/tr15/tr15-31.html">
         <front>
           <title>Unicode Standard Annex #15: Unicode Normalization Forms, Revision 31</title>
          <author fullname="The Unicode Consortium">
            <organization>University of Illinois at Chicago</organization>
          </author>
           <date year="2009" month="September"/>
         </front>
       </reference>



             <!--    <reference anchor="ISO20022">
         <front>
         <title>ISO 20022 Financial Services - Universal financial industry message scheme</title>
         <author>
         <organization>International Organization for Standardization</organization>
         <address>
         <uri>http://www.iso.ch</uri>
         </address>
         </author>
         <date month="May" year="2013"/>
         </front>
       </reference>-->
     </references>
     <references>
       <name>Informative References</name>
         &RFC6781;
         &RFC7363;
         &RFC8324;
       <!--         &RFC3912;-->

       <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>
       </reference>
       <reference anchor="SDSI" target="http://people.csail.mit.edu/rivest/Sdsi10.ps">
         <front>
           <title>SDSI - A Simple Distributed Security Infrastructure</title>
           <author initials="R." surname="Rivest" fullname="Ron Rivest">
           </author>
           <author initials="B." surname="Lampson" fullname="Butler Lampson">
           </author>
           <date year="1996" month="April"/>
        </front>
       </reference>
       <reference anchor="Kademlia" target="http://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="Mazieres"
            fullname="David Mazieres">
        </author>
           <date year="2002"/>
         </front>
       </reference>
       <!--<reference anchor="Ipfs" target="https://arxiv.org/pdf/1407.3561">
         <front>
           <title>Ipfs-content addressed, versioned, p2p file system.</title>
          <author initials="J." surname="Benet" fullname="Juan Benet">
          </author>
           <date year="2014"/>
         </front>
       </reference>
       -->

       <reference anchor="ed25519" target="http://link.springer.com/chapter/10.1007/978-3-642-23951-9_9">
         <front>
           <title>High-Speed High-Security Signatures</title>
          <author initials="D." 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." surname="Yang"
            fullname="Bo-Yin Yang">
          <organization>Academia Sinica</organization>

          </author>
           <date year="2011"/>
         </front>
       </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 year="2014"/>
         </front>
       </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 year="2011"/>
         </front>
       </reference>
       <reference anchor="SecureNS" target="https://sci-hub.st/https://doi.org/10.1016/j.cose.2018.01.018">
         <front>
           <title>Towards 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 year="2018"/>
         </front>
       </reference>

       <reference anchor="GNUnetGNS" target="https://git.gnunet.org/gnunet.git/tree/src/gns">
         <front>
           <title>The GNUnet GNS Implementation</title>
          <author>
            <organization>GNUnet e.V.</organization>
          </author>
        </front>
       </reference>
       <reference anchor="GNUnet" target="https://gnunet.org">
         <front>
           <title>The GNUnet Project</title>
          <author>
            <organization>GNUnet e.V.</organization>
          </author>
        </front>
       </reference>
       <reference anchor="GoGNS" target="https://github.com/bfix/gnunet-go/tree/master/src/gnunet/service/gns">
         <front>
           <title>The Go GNS Implementation</title>
          <author initials="B." surname="Fix" fullname="Bernd Fix">
          </author>
        </front>
       </reference>





     </references>


     <!-- Change Log
       v00 2017-07-23  MS   Initial version
     -->
   </back>
 </rfc>