The GNU Name System
draft-schanzen-gns-07
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9498.
|
|
|---|---|---|---|
| Authors | Martin Schanzenbach , Christian Grothoff , Bernd Fix | ||
| Last updated | 2022-02-15 (Latest revision 2022-02-14) | ||
| RFC stream | Independent Submission | ||
| Formats | |||
| Reviews | |||
| IETF conflict review | conflict-review-schanzen-gns, conflict-review-schanzen-gns, conflict-review-schanzen-gns, conflict-review-schanzen-gns, conflict-review-schanzen-gns, conflict-review-schanzen-gns, conflict-review-schanzen-gns | ||
| Stream | ISE state | In ISE Review | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | Eliot Lear | ||
| IESG | IESG state | Became RFC 9498 (Informational) | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | rfc-ise@rfc-editor.org |
draft-schanzen-gns-07
Independent Stream M. Schanzenbach
Internet-Draft GNUnet e.V.
Intended status: Informational C. Grothoff
Expires: 18 August 2022 Berner Fachhochschule
B. Fix
GNUnet e.V.
14 February 2022
The GNU Name System
draft-schanzen-gns-07
Abstract
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).
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.
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 18 August 2022.
Schanzenbach, et al. Expires 18 August 2022 [Page 1]
Internet-Draft The GNU Name System February 2022
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Zone Top-Level Domain . . . . . . . . . . . . . . . . . . 9
4.2. Zone Revocation . . . . . . . . . . . . . . . . . . . . . 10
5. Resource Records . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Zone Delegation Records . . . . . . . . . . . . . . . . . 16
5.1.1. PKEY . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.2. EDKEY . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2. Redirection Records . . . . . . . . . . . . . . . . . . . 24
5.2.1. REDIRECT . . . . . . . . . . . . . . . . . . . . . . 25
5.2.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . 25
5.3. Auxiliary Records . . . . . . . . . . . . . . . . . . . . 26
5.3.1. LEHO . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3.2. NICK . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3.3. BOX . . . . . . . . . . . . . . . . . . . . . . . . . 28
6. Record Storage . . . . . . . . . . . . . . . . . . . . . . . 29
6.1. The Storage Key . . . . . . . . . . . . . . . . . . . . . 29
6.2. The Records Block . . . . . . . . . . . . . . . . . . . . 30
7. Name Resolution . . . . . . . . . . . . . . . . . . . . . . . 33
7.1. Start Zones . . . . . . . . . . . . . . . . . . . . . . . 33
7.2. Recursion . . . . . . . . . . . . . . . . . . . . . . . . 34
7.3. Record Processing . . . . . . . . . . . . . . . . . . . . 35
7.3.1. REDIRECT . . . . . . . . . . . . . . . . . . . . . . 36
7.3.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . 36
7.3.3. BOX . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.3.4. Zone Delegation Records . . . . . . . . . . . . . . . 38
7.3.5. NICK . . . . . . . . . . . . . . . . . . . . . . . . 38
8. Internationalization and Character Encoding . . . . . . . . . 39
9. Security and Privacy Considerations . . . . . . . . . . . . . 39
Schanzenbach, et al. Expires 18 August 2022 [Page 2]
Internet-Draft The GNU Name System February 2022
9.1. Availability . . . . . . . . . . . . . . . . . . . . . . 39
9.2. Agility . . . . . . . . . . . . . . . . . . . . . . . . . 39
9.3. Cryptography . . . . . . . . . . . . . . . . . . . . . . 40
9.4. Abuse Mitigation . . . . . . . . . . . . . . . . . . . . 41
9.5. Zone Management . . . . . . . . . . . . . . . . . . . . . 41
9.6. Impact of DHTs as Underlying Storage . . . . . . . . . . 42
9.7. Revocations . . . . . . . . . . . . . . . . . . . . . . . 42
9.8. Label Guessing . . . . . . . . . . . . . . . . . . . . . 43
10. GANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
12. Implementation and Deployment Status . . . . . . . . . . . . 45
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45
14. Normative References . . . . . . . . . . . . . . . . . . . . 45
15. Informative References . . . . . . . . . . . . . . . . . . . 48
Appendix A. Base32GNS . . . . . . . . . . . . . . . . . . . . . 49
Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63
1. Introduction
The Domain Name System (DNS) [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.
DNS was not designed with security in mind. 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 [SecureNS].
This specification describes a censorship-resistant, privacy-
preserving and decentralized name system: The GNU Name System (GNS)
[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 [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.
Schanzenbach, et al. Expires 18 August 2022 [Page 3]
Internet-Draft The GNU Name System February 2022
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 [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.
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, and that users can easily
delegate control of arbitrary domain names to arbitrary zones.
This document defines the normative wire format of resource records,
resolution processes, cryptographic routines and security
considerations for use by implementers.
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.
1.1. Requirements Notation
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Terminology
Label A GNS label is a label as defined in [RFC8499]. Within this
document, labels are always assumed to be strings of UTF-8
characters [RFC8499] with a maximum length of 63 bytes for
compatibility with applications enforcing DNS legacy limitations.
Labels MUST be canonicalized using Normalization Form C (NFC)
[Unicode-UAX15].
Apex Label The apex label is represented using the character "@"
Schanzenbach, et al. Expires 18 August 2022 [Page 4]
Internet-Draft The GNU Name System February 2022
(without quotes). The apex label is used to publish resource
records in a zone that can be resolved without providing a
specific label. It is the GNS method to provide what is the "zone
apex" in DNS [RFC4033].
Name A name in GNS is a domain name as defined in [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.
Top-Level Domain 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 [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
Section 7.1), and may thus not be globally unique.
Zone 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 under the
apex label.
Zone Type The type of a GNS zone determines the cipher system and
binary encoding format of the zone key, blinded zone keys, and
signatures.
Zone Key The zone key uniquely identifies a zone. The zone key is
usually a public key of an asymmetric key pair.
Blinded Zone Key A blinded zone key is derived from the zone key and
a label. The zone key and the blinded zone key are unlinkable
without knowledge of the label.
Zone Key Derivation Function The zone key derivation function (ZKDF)
blinds a key using a label. There are different functions for
public and private keys, respectively.
Zone Owner 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.
Zone Top-Level Domain A GNS Zone Top-Level Domain (zTLD) is a
Schanzenbach, et al. Expires 18 August 2022 [Page 5]
Internet-Draft The GNU Name System February 2022
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.
Resource Record 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.
Application An application refers to a component which uses a GNS
implementation to resolve names into records and processes its
contents.
3. Overview
In GNS, any user may create and manage one or more cryptographically
secured zones (Section 4). 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.
A zone can be populated with mappings from labels to resource records
by its owner (Section 5). 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.
Schanzenbach, et al. Expires 18 August 2022 [Page 6]
Internet-Draft The GNU Name System February 2022
Zone contents are encrypted and signed before being published in a
distributed key-value storage (Section 6). 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 [RFC7363], [Kademlia] or
[R5N].
Names in GNS are domain names as defined in [RFC8499]. Starting from
a configurable start 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 (Section 7).
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.
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.
4. Zones
A zone in GNS is uniquely identified by its zone type and zone key.
Each zone can be represented by a Zone Top-Level Domain (zTLD)
string.
A implementation SHOULD enable the user to create and manage zones.
If this functionality is not implemented, names can still be resolved
if zone keys for the initial step in the name resolution are
available (see Section 7).
Schanzenbach, et al. Expires 18 August 2022 [Page 7]
Internet-Draft The GNU Name System February 2022
Each zone type (ztype) is assigned a unique 32-bit number when it is
registered in the GNUnet Assigned Numbers Authority [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.
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 Section 5.1. 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:
KeyGen() -> d, zk is a function to generate a new private key d and
the corresponding public zone key zk.
ZKDF-Private(d,label) -> d' 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.
ZKDF-Public(zk,label) -> zk' 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 different, unlinkable zk' values.
S-Encrypt(zk,label,expiration,message) -> ciphertext is a symmetric
encryption function which encrypts the record data based on key
material derived from the zone key, a label, and an expiration
timestamp. In order to leverage performance-enhancing caching
features of certain underlying storages, in particular DHTs, a
deterministic encryption scheme is recommended.
S-Decrypt(zk,label,expiration,ciphertext) -> message is a symmetric
decryption function which decrypts the encrypted record data based
on key material derived from the zone key, a label, and an
expiration timestamp.
Sign(d,message) -> signature, SignDerived(d,label,message) ->
signature is a function to sign a message (typically encrypted
Schanzenbach, et al. Expires 18 August 2022 [Page 8]
Internet-Draft The GNU Name System February 2022
record data) using the (blinded) private key d (d'), yielding an
unforgeable cryptographic signature. In order to leverage
performance-enhancing caching features of certain underlying
storages, in particular DHTs, a deterministic signature scheme is
recommended.
Verify(zk,message,signature) -> boolean,
VerifyDerived(zk,label,message,signature) -> boolean 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 derivations 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".
4.1. Zone Top-Level Domain
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| ZONE TYPE | ZONE KEY /
+-----+-----+-----+-----+ /
/ /
/ /
Figure 1
The decoded binary representation of the zTLD
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
Figure 1). The result is encoded using a variation of the Crockford
Base32 encoding [CrockfordB32] called Base32GNS. The encoding and
decoding symbols for Base32GNS including this modification are
defined in Figure 23. The functions for encoding and decoding based
on this table are called Base32GNS-Encode and Base32GNS-Decode,
respectively.
For the string representation of a zTLD we define:
zkl := Base32GNS-Encode(ztype||zkey)
ztype||zkey := Base32GNS-Decode(zkl)
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"
Schanzenbach, et al. Expires 18 August 2022 [Page 9]
Internet-Draft The GNU Name System February 2022
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:
zTLD := zkl[126..129].zkl[63..125].zkl[0..62]
4.2. Zone Revocation
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.
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 for this document. A
possible broadcast mechanism for efficient flooding in a distributed
network is implemented in [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.
For all occurrences below, "Argon2id" is the Password-based Key
Derivation Function as defined in [RFC9106]. For the PoW
calculations the algorithm is instantiated with the following
parameters:
S The salt. Fixed 16-byte string: "GnsRevocationPow".
t Number of iterations: 3
m Memory size in KiB: 1024
T Output length of hash in bytes: 64
p Parallelization parameter: 1
v Algorithm version: 0x13
y Algorithm type (Argon2id): 2
X Unused
Schanzenbach, et al. Expires 18 August 2022 [Page 10]
Internet-Draft The GNU Name System February 2022
K Unused
Figure 2 illustrates the format of the data "P" on which the PoW is
calculated.
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| POW |
+-----------------------------------------------+
| TIMESTAMP |
+-----------------------------------------------+
| ZONE TYPE | ZONE KEY |
+-----+-----+-----+-----+ |
/ /
/ /
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 2
The Format of the PoW Data.
POW A 64-bit value that is a solution to the PoW. In network byte
order.
TIMESTAMP denotes the absolute 64-bit date when the revocation was
computed. In microseconds since midnight (0 hour), January 1,
1970 UTC in network byte order.
ZONE TYPE is the 32-bit zone type.
ZONE KEY 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.
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.
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.
Schanzenbach, et al. Expires 18 August 2022 [Page 11]
Internet-Draft The GNU Name System February 2022
The parameters are defined as follows:
Z The number of PoWs required is fixed at 32.
D The minimum average difficulty is fixed at 22.
EPOCH A single epoch is fixed at 365 days.
The revocation message wire format is illustrated in Figure 3.
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| TIMESTAMP |
+-----+-----+-----+-----+-----+-----+-----+-----+
| TTL |
+-----+-----+-----+-----+-----+-----+-----+-----+
| POW_0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
| ... |
+-----+-----+-----+-----+-----+-----+-----+-----+
| POW_Z-1 |
+-----------------------------------------------+
| ZONE TYPE | ZONE KEY |
+-----+-----+-----+-----+ |
/ /
/ /
+-----+-----+-----+-----+-----+-----+-----+-----+
| SIGNATURE |
/ /
/ /
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 3
The Revocation Message Wire Format.
TIMESTAMP denotes the absolute 64-bit date when the revocation was
computed. In microseconds since midnight (0 hour), January 1,
1970 UTC in network byte order. This is the same value as the
time stamp used in the individual PoW calculations.
TTL denotes the relative 64-bit time to live of the record in
Schanzenbach, et al. Expires 18 August 2022 [Page 12]
Internet-Draft The GNU Name System February 2022
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 zeroes in the proof of work
calculation.
POW_i 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.
ZONE TYPE The 32-bit zone type corresponding to the zone key.
ZONE KEY is the public key zk of the zone which is being revoked and
the key to be used to verify SIGNATURE.
SIGNATURE A signature over a time stamp 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 Section 4).
The signature over the public key covers a 32-bit header prefixed to
the time stamp and public key fields. The header includes the key
length and signature purpose. The wire format is illustrated in
Figure 4.
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| SIZE | PURPOSE (0x03) |
+-----+-----+-----+-----+-----+-----+-----+-----+
| TIMESTAMP |
+-----+-----+-----+-----+-----+-----+-----+-----+
| ZONE TYPE | ZONE KEY |
+-----+-----+-----+-----+ |
/ /
/ /
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 4
The Wire Format of the Revocation Data for Signing.
SIZE A 32-bit value containing the length of the signed data in
bytes in network byte order.
PURPOSE A 32-bit signature purpose flag. The value of this field
Schanzenbach, et al. Expires 18 August 2022 [Page 13]
Internet-Draft The GNU Name System February 2022
MUST be 3. The value is encoded in network byte order. It
defines the context in which the signature is created so that it
cannot be reused in other parts of the protocol including possible
future extensions. The value of this field corresponds to an
entry in the GANA "GNUnet Signature Purpose" registry Section 10.
TIMESTAMP Field as defined in the revocation message above.
ZONE TYPE Field as defined in the revocation message above.
ZONE KEY Field as defined in the revocation message above.
In order to verify a revocation the following steps MUST be taken:
1. The signature MUST be verified against the zone key.
2. The set of POW values MUST NOT contain duplicates which MUST be
checked by verifying that the values are strictly monotonically
increasing.
3. The average number of leading zeroes D' resulting from the
provided POW values MUST be greater than and not equal to D.
Implementers MUST NOT use an integer data type to calculate or
represent D'.
4. 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. Should the verifier
calculate the TTL and find that it differs from the field value,
the verifier MUST continue and use the calculated value when
forwarding the revocation.
5. The current time SHOULD be between TIMESTAMP and TIMESTAMP+TTL.
Implementations MAY process the revocation without validating
this.
5. Resource Records
A GNS implementer SHOULD provide a mechanism to create and manage
resource records for local zones. A new local zone is established by
selecting a zone type and creating a zone key pair. As records may
be added to each zone by its owner, a (local) persistence mechanism
such as a database for resource records and zones SHOULD 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
Section 6).
Schanzenbach, et al. Expires 18 August 2022 [Page 14]
Internet-Draft The GNU Name System February 2022
A GNS resource record holds the data of a specific record in a zone.
The resource record format is defined in Figure 5.
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| EXPIRATION |
+-----+-----+-----+-----+-----+-----+-----+-----+
| SIZE | FLAGS | TYPE |
+-----+-----+-----+-----+-----+-----+-----+-----+
| DATA /
/ /
/ /
Figure 5
The Resource Record Wire Format.
EXPIRATION denotes the absolute 64-bit expiration date of the
record. In microseconds since midnight (0 hour), January 1, 1970
UTC in network byte order.
SIZE denotes the 16-bit size of the DATA field in bytes and in
network byte order.
FLAGS is a 16-bit resource record flags field (see below).
TYPE is the 32-bit resource record type. This type can be one of
the GNS resource records as defined in Section 5 or a DNS record
type as defined in [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 [RFC6895], while values above 2^16 are
allocated by the GNUnet Assigned Numbers Authority [GANA].
DATA the variable-length resource record data payload. The content
is defined by the respective type of the resource record.
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. Figure 6 illustrates the flag
distribution in the 16-bit flag field of a resource record:
Schanzenbach, et al. Expires 18 August 2022 [Page 15]
Internet-Draft The GNU Name System February 2022
0 1 2 3 4 5...
+--------+--------+--------+--------+--------+----
|CRITICAL|SHADOW |SUPPL |RESERVED
+--------+--------+--------+--------+--------+----
Figure 6
The Resource Record Flag Wire Format.
CRITICAL If this flag is set, it indicates that processing is
critical. Implementations that do not support the record type or
are otherwise unable to process the record must abort resolution
upon encountering the record in the resolution process.
SHADOW 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.
SUPPL 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.
5.1. Zone Delegation Records
This section defines the initial set of zone delegation record types.
Any implementation SHOULD support all zone types defined here and MAY
support any number of additional delegation records defined in the
GNU Name System Record Types registry (see Section 10). Zone
delegation records MUST have the CRTITICAL flag set. Not supporting
some zone types MAY result in resolution failures. This MAY BE a
valid choice if some zone delegation record types have been
determined to be cryptographically insecure. Zone delegation records
MUST NOT be stored and published under the apex label. A zone
delegation record type value is the same as the respective ztype
value. The ztype defines the cryptographic primitives for the zone
that is being delegated to. A zone delegation resource record
payload contains the public key of the zone to delegate to. A zone
delegation record MUST be the only record under a label. No other
records are allowed.
Schanzenbach, et al. Expires 18 August 2022 [Page 16]
Internet-Draft The GNU Name System February 2022
5.1.1. PKEY
In GNS, a delegation of a label to a zone of type "PKEY" is
represented through a PKEY record. The PKEY DATA entry wire format
can be found in Figure 7.
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| PUBLIC KEY |
| |
| |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 7
The PKEY Wire Format.
PUBLIC KEY A 256-bit Ed25519 public key.
For PKEY zones the zone key material is derived using the curve
parameters of the twisted Edwards representation of Curve25519
[RFC7748] (a.k.a. Ed25519) with the ECDSA scheme [RFC6979].
Consequently, we use the following naming convention for our
cryptographic primitives for PKEY zones:
d is a 256-bit Ed25519 private key (private scalar).
zk is the Ed25519 public zone key corresponding to d.
p is the prime of edwards25519 as defined in [RFC7748], i.e. 2^255
- 19.
G is the group generator (X(P),Y(P)) of edwards25519 as defined in
[RFC7748].
L is the order of the prime-order subgroup of edwards25519 in
[RFC7748].
KeyGen() 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 [RFC6979] represents the KeyGen()
function.
The zone type and zone key of a PKEY are 4 + 32 bytes in length.
This means that a zTLD will always fit into a single label and does
not need any further conversion.
Schanzenbach, et al. Expires 18 August 2022 [Page 17]
Internet-Draft The GNU Name System February 2022
Given a label, the output d' of the ZKDF-Private(d,label) function
for zone key blinding is calculated as follows for PKEY zones:
ZKDF-Private(d,label):
zk := d * G
PRK_h := HKDF-Extract ("key-derivation", zk)
h := HKDF-Expand (PRK_h, label || "gns", 512 / 8)
d' := (h * d) mod L
return d'
Equally, given a label, the output zk' of the ZKDF-Public(zk,label)
function is calculated as follows for PKEY zones:
ZKDF-Public(zk,label)
PRK_h := HKDF-Extract ("key-derivation", zk)
h := HKDF-Expand (PRK_h, label || "gns", 512 / 8)
zk' := (h mod L) * zk
return zk'
The PKEY cryptosystem uses a hash-based key derivation function
(HKDF) as defined in [RFC5869], using SHA-512 [RFC6234] for the
extraction phase and SHA-256 [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.
The Sign() and Verify() functions for PKEY zones are implemented
using 512-bit ECDSA deterministic signatures as specified in
[RFC6979]. The same functions can be used for derived keys:
SignDerived(d,label,message):
d' := ZKDF-Private(d,label)
return Sign(d',message)
A signature (R,S) is valid if the following holds:
VerifyDerived(zk,label,message,signature):
zk' := ZKDF-Public(zk,label)
return Verify(zk',message,signature)
The S-Encrypt() and S-Decrypt() functions use AES in counter mode as
defined in [MODES] (CTR-AES-256):
Schanzenbach, et al. Expires 18 August 2022 [Page 18]
Internet-Draft The GNU Name System February 2022
S-Encrypt(zk,label,expiration,plaintext):
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)
IV := NONCE || expiration || 0x0000000000000001
return CTR-AES256(K, IV, plaintext)
Figure 8
The PKEY S-Encrypt Procedure.
S-Decrypt(zk,label,expiration,ciphertext):
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)
IV := NONCE || expiration || 0x0000000000000001
return CTR-AES256(K, IV, ciphertext)
Figure 9
The PKEY S-Decrypt Procedure.
The key K and counter IV are derived from the record label and the
zone key zk using a hash-based key derivation function (HDKF) as
defined in [RFC5869]. SHA-512 [RFC6234] is used for the extraction
phase and SHA-256 [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
[RFC3826] key.
The nonce is combined with a 64-bit initialization vector and a
32-bit block counter as defined in [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
Figure 10.
Schanzenbach, et al. Expires 18 August 2022 [Page 19]
Internet-Draft The GNU Name System February 2022
0 8 16 24 32
+-----+-----+-----+-----+
| NONCE |
+-----+-----+-----+-----+
| EXPIRATION |
| |
+-----+-----+-----+-----+
| BLOCK COUNTER |
+-----+-----+-----+-----+
Figure 10
The Block Counter Wire Format.
5.1.2. EDKEY
In GNS, a delegation of a label to a zone of type "EDKEY" is
represented through a EDKEY record. The EDKEY DATA entry wire format
is illustrated in Figure 11.
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| PUBLIC KEY |
| |
| |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 11
The EDKEY DATA Wire Format.
PUBLIC KEY A 256-bit EdDSA zone key.
For EDKEY zones the zone key material is derived using the curve
parameters of the twisted edwards representation of Curve25519
[RFC7748] (a.k.a. Ed25519) with the Ed25519 scheme [ed25519] as
specified in [RFC8032]. Consequently, we use the following naming
convention for our cryptographic primitives for EDKEY zones:
d is a 256-bit EdDSA private key.
a is is an integer derived from d using the SHA-512 hash function as
defined in [RFC8032].
zk 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 [RFC8032].
Schanzenbach, et al. Expires 18 August 2022 [Page 20]
Internet-Draft The GNU Name System February 2022
p is the prime of edwards25519 as defined in [RFC8032], i.e. 2^255
- 19.
G is the group generator (X(P),Y(P)) of edwards25519 as defined in
[RFC8032].
L is the order of the prime-order subgroup of edwards25519 in
[RFC8032].
KeyGen() 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 5.1.5 of [RFC8032]
represents the KeyGen() function.
The zone type and zone key of an EDKEY are 4 + 32 bytes in length.
This means that a zTLD will always fit into a single label and does
not need any further conversion.
The "EDKEY" ZKDF instantiation is based on [Tor224]. The calculation
of a is defined in Section 5.1.5 of [RFC8032]. Given a label, the
output of the ZKDF-Private function for zone key blinding is
calculated as follows for EDKEY zones:
ZKDF-Private(d,label):
/* EdDSA clamping */
a := SHA-512 (d)
a[0] &= 248
a[31] &= 127
a[31] |= 64
/* Calculate zk from d */
zk := a * G
/* Calculate the blinding factor */
PRK_h := HKDF-Extract ("key-derivation", zk)
h := HKDF-Expand (PRK_h, label || "gns", 512 / 8)
/* Ensure that h == h mod L */
h[31] &= 7
a1 := a >> 3
a2 := (h * a1) mod L
d' := a2 << 3
return d'
Equally, given a label, the output of the ZKDF-Public function is
calculated as follows for PKEY zones:
Schanzenbach, et al. Expires 18 August 2022 [Page 21]
Internet-Draft The GNU Name System February 2022
ZKDF-Public(zk,label):
/* Calculate the blinding factor */
PRK_h := HKDF-Extract ("key-derivation", zk)
h := HKDF-Expand (PRK_h, label || "gns", 512 / 8)
/* Ensure that h == h mod L */
h[31] &= 7
zk' := h * zk
return zk'
We note that implementers SHOULD employ a constant time scalar
multiplication for the constructions above to protect against timing
attacks. Otherwise, timing attacks may leak private key material if
an attacker can predict when a system starts the publication process.
The EDKEY cryptosystem uses a hash-based key derivation function
(HKDF) as defined in [RFC5869], using SHA-512 [RFC6234] for the
extraction phase and HMAC-SHA256 [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.
The Sign(d,message) and Verify(zk,message,signature) procedures MUST
be implemented as defined in [RFC8032].
Signatures for EDKEY zones using the derived private scalar d' are
not compliant with [RFC8032]. As the corresponding private key to
the derived private scalar d' is not known, it is not possible to
deterministically derive the signature part R according to [RFC8032].
Instead, signatures MUST be generated as follows for any given
message and private zone key: A nonce is calculated from the highest
32 bytes of the expansion of the private key d and the blinding
factor h. The nonce is then hashed with the message to r. This way,
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.
Schanzenbach, et al. Expires 18 August 2022 [Page 22]
Internet-Draft The GNU Name System February 2022
SignDerived(d,label,message):
/* EdDSA clamping */
a := SHA-512 (d)
a[0] &= 248
a[31] &= 127
a[31] |= 64
/* Calculate zk from d */
zk := a * G
/* Calculate blinding factor */
PRK_h := HKDF-Extract ("key-derivation", zk)
h := HKDF-Expand (PRK_h, label || "gns", 512 / 8)
d' := ZKDF-Private(d,label)
dh := SHA-512 (d)
nonce := SHA-256 (dh[32..63] || h)
r := SHA-512 (nonce || message)
R := r * G
S := r + SHA-512(R || zk' || message) * d' mod L
return (R,S)
A signature (R,S) is valid if the following holds:
VerifyDerived(zk,label,message,signature):
zk' := ZKDF-Public(zk,label)
(R,S) := signature
return S * G == R + SHA-512(R, zk', message) * zk'
The S-Encrypt() and S-Decrypt() functions use XSalsa20 as defined in
[XSalsa20] (XSalsa20-Poly1305):
S-Encrypt(zk,label,expiration,message):
PRK_k := HKDF-Extract ("gns-xsalsa-ctx-key", zk)
PRK_n := HKDF-Extract ("gns-xsalsa-ctx-iv", zk)
K := HKDF-Expand (PRK_k, label, 256 / 8)
NONCE := HKDF-Expand (PRK_n, label, 128 / 8)
IV := NONCE || expiration
return XSalsa20-Poly1305(K, IV, message)
S-Decrypt(zk,label,expiration,ciphertext):
PRK_k := HKDF-Extract ("gns-xsalsa-ctx-key", zk)
PRK_n := HKDF-Extract ("gns-xsalsa-ctx-iv", zk)
K := HKDF-Expand (PRK_k, label, 256 / 8)
NONCE := HKDF-Expand (PRK_n, label, 128 / 8)
IV := NONCE || expiration
return XSalsa20-Poly1305(K, IV, ciphertext)
Schanzenbach, et al. Expires 18 August 2022 [Page 23]
Internet-Draft The GNU Name System February 2022
The result of the XSalsa20-Poly1305 encryption function is the
encrypted ciphertext followed by the 128-bit authentication tag.
Accordingly, the length of encrypted data equals the length of the
data plus the 16 bytes of the authentication tag.
The key K and counter IV are derived from the record label and the
zone key zk using a hash-based key derivation function (HKDF) as
defined in [RFC5869]. SHA-512 [RFC6234] is used for the extraction
phase and SHA-256 [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 [XSalsa20] key. No additional authenticated data (AAD) is
used.
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 Figure 12.
0 8 16 24 32
+-----+-----+-----+-----+
| NONCE |
| |
| |
| |
+-----+-----+-----+-----+
| EXPIRATION |
| |
+-----+-----+-----+-----+
Figure 12
The Counter Block Initialization Vector
5.2. Redirection Records
Redirect records may be used to redirect resolution. Any
implementation SHOULD support all redirection record types defined
here and MAY support any number of additional redirection records
defined in the GNU Name System Record Types registry (see
Section Section 10). Redirection records MUST have the CRTITICAL
flag set. Not supporting some record types MAY result in resolution
failures. This MAY BE a valid choice if some redirection record
types have been determined to be insecure, or if an application has
reasons to not support redirection to DNS for reasons such as
complexity or security. Redirection records MUST NOT be stored and
published under the apex label.
Schanzenbach, et al. Expires 18 August 2022 [Page 24]
Internet-Draft The GNU Name System February 2022
5.2.1. REDIRECT
A REDIRECT record is the GNS equivalent of a CNAME record in DNS. A
REDIRECT record MUST be the only record under a label. No other
records are allowed. Details on processing of this record is defined
in Section 7.3.1. A REDIRECT DATA entry is illustrated in Figure 13.
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| REDIRECT NAME |
/ /
/ /
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 13
The REDIRECT DATA Wire Format
REDIRECT NAME The name to continue with. The value of a redirect
record may be a regular name, or a relative name. Relative GNS
names are indicated using the suffix ".+". The string is UTF-8
encoded and 0-terminated.
5.2.2. GNS2DNS
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 [RFC1034] for DNS names. There MAY be multiple
GNS2DNS records under a label. There MAY also be DNSSEC DS records
or any other records used to secure the connection with the DNS
servers under the same label. No other record types are allowed in
the same record set. A GNS2DNS DATA entry is illustrated in
Figure 14.
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| DNS NAME |
/ /
/ /
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| DNS SERVER NAME |
/ /
/ /
| |
+-----------------------------------------------+
Schanzenbach, et al. Expires 18 August 2022 [Page 25]
Internet-Draft The GNU Name System February 2022
Figure 14
The GNS2DNS DATA Wire Format
DNS NAME The name to continue with in DNS. The value is UTF-8
encoded and 0-terminated.
DNS SERVER NAME 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
"+" as the rightmost label. The implementation MUST check the
string syntactically for an IP address in the respective notation
before checking for a relative GNS name. If all three checks
fail, the name MUST be treated as a DNS name. The value is UTF-8
encoded and 0-terminated.
NOTE: If an application uses DNS names obtained from GNS2DNS records
in a DNS request they must first be converted to an IDNA punycode
representation [RFC5891].
5.3. Auxiliary Records
This section defines the initial set of auxiliary GNS record types.
Any implementation SHOULD be able to process the specified record
types according to Section 7.3.
5.3.1. LEHO
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. Furthermore, even if uniqueness is not an issue, the legacy
service might not even be aware of GNS. 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 Figure 15.
Schanzenbach, et al. Expires 18 August 2022 [Page 26]
Internet-Draft The GNU Name System February 2022
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| LEGACY HOSTNAME |
/ /
/ /
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 15
The LEHO DATA Wire Format.
LEGACY HOSTNAME A UTF-8 string (which is not 0-terminated)
representing the legacy hostname.
NOTE: If an application uses a LEHO value in an HTTP request header
(e.g. "Host:" header) it must be converted to an IDNA punycode
representation [RFC5891].
5.3.2. NICK
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 (Section 5.1) containing this zone key. This
record SHOULD only be stored under the apex label "@" but MAY be
returned with record sets under any label as a supplemental record.
Section 7.3.5 details how a resolver must process supplemental and
non-supplemental NICK records. A NICK DATA entry is illustrated in
Figure 16.
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| NICKNAME |
/ /
/ /
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 16
The NICK DATA Wire Format.
NICKNAME A UTF-8 string (which is not 0-terminated) representing the
preferred label of the zone. This string MUST NOT include a "."
character.
Schanzenbach, et al. Expires 18 August 2022 [Page 27]
Internet-Draft The GNU Name System February 2022
5.3.3. BOX
In GNS, with the notable exception of zTLDs, every "." in a name
delegates to another zone. Furthermore, GNS lookups are expected to
return all of the required useful information in one record set.
This avoids unnecessary additional lookups and cryptographically ties
together information that belongs together, making it impossible for
an adversarial storage to provide partial answers that might omit
information critical for security.
However, this general strategy is incompatible with the special
labels used by DNS for SRV and TLSA records. Thus, GNS defines the
BOX record format to box up SRV and TLSA records and include them in
the record set of the label they are associated with. For example, a
TLSA record for "_https._tcp.example.org" will be stored in the
record set of "example.org" as a BOX record with service (SVC) 443
(https) and protocol (PROTO) 6 (tcp) and record TYPE "TLSA". For
reference, see also [RFC2782]. A BOX DATA entry is illustrated in
Figure 17.
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| PROTO | SVC | TYPE |
+-----------+-----------------------------------+
| RECORD DATA |
/ /
/ /
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 17
The BOX DATA Wire Format.
PROTO the 16-bit protocol number, e.g. 6 for tcp. Note that values
below 2^8 are reserved for allocation via IANA [RFC5237], while
values above 2^8 are allocated by the GNUnet Assigned Numbers
Authority [GANA]. In network byte order.
SVC the 16-bit service value of the boxed record. In case of TCP
and UDP it is the port number. In network byte order.
TYPE is the 32-bit record type of the boxed record. In network byte
order.
RECORD DATA is a variable length field containing the "DATA" format
of TYPE as defined for the respective TYPE in DNS.
Schanzenbach, et al. Expires 18 August 2022 [Page 28]
Internet-Draft The GNU Name System February 2022
6. Record Storage
Any API which allows storing a value under a 512-bit key and
retrieving one or more values from the key can be used by an
implementation for record storage. To be useful, the API MUST permit
storing at least 176 byte values to be able to support the defined
zone delegation record encodings, and SHOULD allow at least 1024 byte
values. We assume that an implementation realizes two procedures on
top of a storage:
PUT(key,value)
GET(key) -> value
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.
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 [RFC8324], Section 3.5). The storage key
derivation and records block creation is specified in the following
sections. The implementation MUST use the PUT storage procedure in
order to update the zone contents accordingly.
6.1. The Storage Key
Given a label, the storage key q is derived as follows:
q := SHA-512 (ZKDF-Public(zk, label))
label is a UTF-8 string under which the resource records are
published.
zk is the zone key.
q Is the 512-bit storage key under which the resource records block
is published. It is the SHA-512 hash [RFC6234] over the derived
zone key.
Schanzenbach, et al. Expires 18 August 2022 [Page 29]
Internet-Draft The GNU Name System February 2022
6.2. The Records Block
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 Section 5). The contained resource
records are encrypted using a symmetric encryption scheme. A GNS
implementation publish RRBLOCKs in accordance to the properties and
recommendations of the underlying storage. This may include a
periodic refresh operation to ensure the availability of the
published RRBLOCKs. The GNS RRBLOCK wire format is illustrated in
Figure 18.
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| SIZE | ZONE TYPE |
+-----+-----+-----+-----+-----+-----+-----+-----+
/ ZONE KEY /
/ (BLINDED) /
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| SIGNATURE |
/ /
/ /
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| EXPIRATION |
+-----+-----+-----+-----+-----+-----+-----+-----+
| BDATA /
/ /
/ |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 18
The RRBLOCK Wire Format.
SIZE A 32-bit value containing the length of the block. While a
32-bit value is used, implementations MAY refuse to publish blocks
beyond a certain size significantly below 4 GB.
ZONE TYPE is the 32-bit ztype.
ZONE KEY is the blinded zone key "ZKDF-Public(zk, label)" to be used
to verify SIGNATURE. The length and format of the public key
depends on the ztype.
SIGNATURE The signature is computed over the EXPIRATION and BDATA
Schanzenbach, et al. Expires 18 August 2022 [Page 30]
Internet-Draft The GNU Name System February 2022
fields as detailed in Figure 19. The length and format of the
signature depends on the ztype. The signature is created using
the Sign() function of the cryptosystem of the zone and the
derived private key "ZKDF-Private(d, label)" (see Section 4).
EXPIRATION 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 UTC in
network byte order.
BDATA The encrypted RDATA. Its size is determined by the
S-Encrypt() function of the ztype.
The signature over the public key covers a 32-bit pseudo header
conceptually prefixed to the EXPIRATION and the BDATA fields. The
wire format is illustrated in Figure 19.
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| SIZE | PURPOSE (0x0F) |
+-----+-----+-----+-----+-----+-----+-----+-----+
| EXPIRATION |
+-----+-----+-----+-----+-----+-----+-----+-----+
| BDATA |
/ /
/ /
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 19
The Wire Format used for creating the signature of the RRBLOCK.
SIZE A 32-bit value containing the length of the signed data in
bytes in network byte order.
PURPOSE A 32-bit signature purpose flag. The value of this field
MUST be 15. The value is encoded in network byte order. It
defines the context in which the signature is created so that it
cannot be reused in other parts of the protocol including possible
future extensions. The value of this field corresponds to an
entry in the GANA "GNUnet Signature Purpose" registry Section 10.
Schanzenbach, et al. Expires 18 August 2022 [Page 31]
Internet-Draft The GNU Name System February 2022
EXPIRATION Field as defined in the RRBLOCK message above.
BDATA Field as defined in the RRBLOCK message above.
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 Figure 20.
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
| EXPIRATION |
+-----+-----+-----+-----+-----+-----+-----+-----+
| SIZE | FLAGS | TYPE |
+-----+-----+-----+-----+-----+-----+-----+-----+
| DATA /
/ /
/ /
+-----+-----+-----+-----+-----+-----+-----+-----+
| EXPIRATION |
+-----+-----+-----+-----+-----+-----+-----+-----+
| SIZE | FLAGS | TYPE |
+-----+-----+-----+-----+-----+-----+-----+-----+
| DATA /
/ /
+-----+-----+-----+-----+-----+-----+-----+-----+
/ PADDING /
/ /
Figure 20
The RDATA Wire Format.
EXPIRATION, SIZE, TYPE, FLAGS and DATA These fields were defined in
the resource record format in Section 5.
PADDING When publishing an RDATA block, the implementation MUST
ensure that the size of the RDATA 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.
Schanzenbach, et al. Expires 18 August 2022 [Page 32]
Internet-Draft The GNU Name System February 2022
7. Name Resolution
Names in GNS are resolved by recursively querying the record storage.
Recursive in this context means that a resolver does not provide
intermediate results for a query. 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.
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 Section 7.1.
The application MAY provide a desired record type to the resolver.
The desired record type is used to guide processing. For example, if
a zone delegation record type is requested, the resolution of the
apex label in that zone must be skipped, as the desired record is
already found. The resolver implementation MUST NOT filter results
according to the desired record type. Filtering of record sets is
typically done by the application.
7.1. Start Zones
The resolution of a GNS name starts in an initial start zone. The
resolver may have one or more local start zones configured which
point to local or remote zone keys. A resolver 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 [RFC8324], Section 3.10 and 3.12).
In the following, we give examples how a resolver SHOULD discover the
start zone. The process given is not exhaustive and resolvers MAY
supplement it with other mechanisms or ignore it if the particular
application requires a different process.
GNS implementations 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 can be converted to a valid ztype and zone key
value, the resulting zone key is used as the start zone:
Schanzenbach, et al. Expires 18 August 2022 [Page 33]
Internet-Draft The GNU Name System February 2022
Example name: www.example.<zTLD>
=> Start zone: zk of type ztype
=> Name to resolve from start zone: www.example
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 with the longest
matching suffix:
Example name: www.example.org
Local zones:
fr = (d0,zk0)
org = (d1,zk1)
com = (d2,zk2)
...
=> Start zone: zk1
=> Name to resolve from start zone: www.example
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.
Example name: www.example.org
Local suffix mappings:
org = zk0
example.org = zk1
example.com = zk2
...
=> Start zone: zk1
=> Name to resolve from start zone: www
7.2. Recursion
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 "@".
From here, the following steps are recursively executed, in order:
Schanzenbach, et al. Expires 18 August 2022 [Page 34]
Internet-Draft The GNU Name System February 2022
1. Extract the right-most label from the name to look up.
2. Calculate q using the label and zk as defined in Section 6.1.
3. Perform a storage query GET(q) to retrieve the RRBLOCK.
4. Verify and process the RRBLOCK and decrypt the BDATA contained in
it as defined by its zone type (see also Section 6.2).
Upon receiving the RRBLOCK from the storage, as part of verifying the
provided signature, the resolver MUST check that the SHA-512 hash of
the derived authoritative zone key zk' from the RRBLOCK matches the
query q and that the overall block is not yet expired. If the
signature does not match or the block is expired, the RRBLOCK MUST be
ignored and, if applicable, the storage lookup GET(q) MUST continue
to look for other RRBLOCKs.
7.3. Record Processing
Record processing occurs once a well-formed block was decrypted. In
record processing, only the valid records obtained are considered.
To filter records by validity, the resolver MUST at least check the
expiration time and the FLAGS of the respective record. In
particular, FLAGS may exclude shadow and supplemental records from
being considered. If the resolver encounters a record with the
CRITICAL flag set and does not support the record type the resolution
MUST be aborted and an error MUST be returned. The information that
the critical record could not be processed SHOULD be returned in the
error description. The implementation MAY choose not to return the
reason for the failure, merely complicating troubleshooting for the
user. The next steps depend on the context of the name we are trying
to resolve:
* Case 1: If the filtered record set consists of a single REDIRECT
record, the remainder of the name is prepended to the REDIRECT
data and the recursion is started again from the resulting name.
Details are described in Section 7.3.1.
* Case 2: If the filtered record set consists exclusively of one or
more GNS2DNS records resolution continues with DNS. Details are
described in Section 7.3.2.
* Case 3: If the remainder of the name to be resolved is of the
format "_SERVICE._PROTO" and the record set contains one or more
matching BOX records, the records in the BOX records are the final
result and the recursion is concluded as described in
Section 7.3.3.
Schanzenbach, et al. Expires 18 August 2022 [Page 35]
Internet-Draft The GNU Name System February 2022
* Case 4: If the current record set consist of a single delegation
record, resolution of the remainder of the name is delegated to
the target zone as described in Section 7.3.4.
* Case 5: If the remainder of the name to resolve is empty the
record set (including supplemental records) is the final result
and the recursion is concluded.
* Otherwise, resolution fails and the resolver MUST return an empty
record set.
7.3.1. REDIRECT
If the remaining name is empty and the desired record type is
REDIRECT, in which case the resolution concludes with the REDIRECT
record. If the redirect 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 trigger a GNS name resolution process
depending on the system configuration. In case resolution continues
in DNS, the name MUST first be converted to an IDNA punycode
representation [RFC5891].
In order to prevent infinite loops, the resolver MUST implement loop
detections or limit the number of recursive resolution steps. The
loop detection MUST be effective even if a REDIRECT found in GNS
triggers subsequent GNS lookups via the default operating system name
resolution process.
7.3.2. GNS2DNS
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.
Otherwise, it is expected that the resolver first resolves the IP
addresses of the specified DNS name servers. The DNS name may have
to be converted to an IDNA punycode representation [RFC5891] for
resolution in DNS. 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.
Schanzenbach, et al. Expires 18 August 2022 [Page 36]
Internet-Draft The GNU Name System February 2022
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 appropriate error is SHOULD be returned to
the application.
If there are DNSSEC DS records or any other records used to secure
the connection with the DNS servers stored under the label, the DNS
resolver SHOULD use them to secure the connection with the DNS
server.
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 application. In
addition, the resolver SHOULD return the queried DNS name as a
supplemental LEHO record (see Section 5.3.1) with a relative
expiration time of one hour.
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
DNS CNAME records MUST NOT be interpreted as GNS names.
GNS resolvers SHOULD offer a configuration option to disable DNS
processing to avoid information leakage and provide a consistent
security profile for all name resolutions. Such resolvers would
return an empty record set upon encountering a GNS2DNS record during
the recursion. However, if GNS2DNS records are encountered in the
record set for the apex label and a GNS2DNS record is explicitly
requested by the application, such records MUST still be returned,
even if DNS support is disabled by the GNS resolver configuration.
7.3.3. BOX
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.
Schanzenbach, et al. Expires 18 August 2022 [Page 37]
Internet-Draft The GNU Name System February 2022
7.3.4. Zone Delegation Records
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 delegations
under a single label. Implementations MAY support any subset of
ztypes. Handling of Implementations MUST NOT process zone delegation
for the 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.
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 apex label "@" as remaining name. Except in the case where
the desired record type as specified by the application is equal to
the ztype, in which case the delegation record is returned.
7.3.5. NICK
NICK records are only relevant to the recursive resolver if the
record set in question is the final result which is to be returned to
the application. The encountered NICK records may either be
supplemental (see Section 5) 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.
The differentiation between a supplemental and non-supplemental NICK
record allows the application to match the record to the
authoritative zone. Consider the following example:
Query: alice.example (type=A)
Result:
A: 192.0.2.1
NICK: eve (non-Supplemental)
In this example, the returned NICK record is non-supplemental. For
the application, this means that the NICK belongs to the zone
"alice.example" and is published under the apex 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:
Schanzenbach, et al. Expires 18 August 2022 [Page 38]
Internet-Draft The GNU Name System February 2022
Query: alice.example (type=AAAA)
Result:
AAAA: 2001:DB8::1
NICK: john (Supplemental)
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.
8. Internationalization and Character Encoding
All labels in GNS are encoded in UTF-8 [RFC3629]. Labels MUST be
canonicalized using Normalization Form C (NFC) [Unicode-UAX15]. This
does not include any DNS names found in DNS records, such as CNAME
records, which are internationalized through the IDNA specifications
[RFC5890].
9. Security and Privacy Considerations
9.1. Availability
In order to ensure availability of records beyond their absolute
expiration times, implementations MAY allow to locally define
relative expiration time values of records. Records can then be
published recurringly with updated absolute expiration times by the
implementation.
Implementations MAY allow users to manage private records in their
zones that are not published in the storage. Private records are
considered just like regular records when resolving labels in local
zones, but their data is completely unavailable to non-local users.
9.2. Agility
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 ztype considered secure at the time of releasing the
software. For applications targeting end users that are not expected
to understand cryptography, the application developer MUST NOT leave
the ztype selection of new zones to end users.
Schanzenbach, et al. Expires 18 August 2022 [Page 39]
Internet-Draft The GNU Name System February 2022
This document concerns itself with the selection of cryptographic
algorithms used in GNS. The algorithms identified in this document
are not known to be broken (in the cryptographic sense) at the
current time, and cryptographic research so far leads us to believe
that they are likely to remain secure into the foreseeable future.
However, this is not necessarily forever, and it is expected that new
revisions of this document will be issued from time to time to
reflect the current best practices in this area.
In terms of crypto-agility, whenever the need for an updated
cryptographic scheme arises to, for example, replace ECDSA over
Ed25519 for PKEY records it 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. To ensure
that implementations correctly generate an error message when
encountering a ztype that they do not support, current and future
delegation records must always have the CRITICAL flag set.
9.3. Cryptography
GNS PKEY zone keys use ECDSA over Ed25519. 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 Ed25519 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.
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 always includes the expiration time of the
record block. When applications store records with relative
expiration times, monotonicity is implicitly ensured because each
time a block is published into the storage, its IV is unique as the
expiration time is calculated dynamically and increases monotonically
with the system time. Still, an implementation MUST ensure that when
relative expiration times are decreased, the expiration time of the
next record block MUST be after the last published block. For
records where an absolute expiration time is used, the implementation
MUST ensure that the expiration time is always increased when the
record data changes. For example, the expiration time on the wire
may be increased by a single microsecond even if the user did not
request a change. In case of deletion of all resource records under
a label, the implementation MUST keep track of the last absolute
Schanzenbach, et al. Expires 18 August 2022 [Page 40]
Internet-Draft The GNU Name System February 2022
expiration time of the last published resource block.
Implementations MAY use a PADDING record as a tombstone that
preserves the last absolute expiration time, but then MUST take care
to not publish a block with just a PADDING record. 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.
9.4. Abuse Mitigation
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.
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.
9.5. Zone Management
In GNS, zone administrators need to manage and protect their zone
keys. Once a zone key is lost, it cannot be recovered or revoked.
Revocation messages may be pre-calculated if revocation is required
in case a zone key is lost. Zone administrators, and for GNS this
includes end-users, are required to responsibly and diligently
protect their cryptographic keys. GNS supports offline signing of
records.
Similarly, users are required to manage their local start zone
configuration. In order to ensure integrity and availability or
names, users must ensure that their local start zone information is
not compromised or outdated. It can be expected that the processing
of zone revocations and an initial start zone is provided with a GNS
implementation ("drop shipping"). Shipping an initial start zone
with an entry for the root (".") effectively establishes a root zone.
Extension and customization of the zone is at the full discretion of
the user.
Schanzenbach, et al. Expires 18 August 2022 [Page 41]
Internet-Draft The GNU Name System February 2022
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 depends 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, which may suggest using Tor routers for
storage. Implementations of "aggregated" storages are conceivable,
but are expected to be the exception.
9.6. Impact of DHTs as Underlying Storage
This document does not specify the properties of the underlying
storage which is required by any GNS implementation. It is important
to note that the properties of the underlying storage 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 as storage in a GNS implementation. DHTs
with reasonable security and performance properties exist [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.
9.7. Revocations
Zone administrators are advised to pre-generate zone revocations and
to 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
take precautions in order to manage revocations accordingly.
Revocation payloads do NOT include a 'new' key for key replacement.
Inclusion of such a key would have two major disadvantages:
1. If a revocation is published after a private key was compromised,
allowing key replacement would be dangerous: if an adversary took
over the private key, the adversary could then broadcast a
revocation with a key replacement. For the replacement, the
compromised owner would have no chance to issue even a
revocation. Thus, allowing a revocation message to replace a
private key makes dealing with key compromise situations worse.
Schanzenbach, et al. Expires 18 August 2022 [Page 42]
Internet-Draft The GNU Name System February 2022
2. Sometimes, key revocations are used with the objective of
changing cryptosystems. Migration to another cryptosystem by
replacing keys via a revocation message would only be secure as
long as both cryptosystems are still secure against forgery.
Such a planned, non-emergency migration to another cryptosystem
should be done by running zones for both cipher systems in
parallel for a while. The migration would conclude by revoking
the legacy zone key only once it is deemed no longer secure, and
hopefully after most users have migrated to the replacement.
9.8. Label Guessing
Record blocks are published in encrypted form 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.
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. However, zone keys do become
public during revocation.
10. GANA Considerations
GANA [GANA] manages the "GNU Name System Record Types" registry.
Each entry has the following format:
* 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.
* Number: 32-bit, above 65535
* Comment: Optionally, a brief English text describing the purpose
of the record type (in UTF-8)
* Contact: Optionally, the contact information of a person to
contact for further information.
Schanzenbach, et al. Expires 18 August 2022 [Page 43]
Internet-Draft The GNU Name System February 2022
* References: Optionally, references describing the record type
(such as an RFC)
The registration policy for this registry is "First Come First
Served". This policy is modeled on that described in [RFC8126], and
describes the actions taken by GANA:
Adding new 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.
The current contact(s) for expert review are reachable at gns-
registry@gnunet.org.
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.
GANA is requested to populate this registry as listed in Figure 21.
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
65540 | GNS2DNS | N/A | [This.I-D] | Delegation to DNS
65541 | BOX | N/A | [This.I-D] | Boxed records
65551 | REDIRECT| N/A | [This.I-D] | Redirection record.
65556 | EDKEY | N/A | [This.I-D] | GNS zone delegation (EDKEY)
Figure 21
The GANA Resource Record Registry.
GANA is requested to amend the "GNUnet Signature Purpose" registry as
illustrated in Figure 22.
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
Figure 22
Requested Changes in the GANA GNUnet Signature Purpose Registry.
Schanzenbach, et al. Expires 18 August 2022 [Page 44]
Internet-Draft The GNU Name System February 2022
11. IANA Considerations
This document makes no requests for IANA action. This section may be
removed on publication as an RFC.
12. Implementation and Deployment Status
There are two implementations conforming to this specification
written in C and Go, respectively. The C implementation as part of
GNUnet [GNUnetGNS] represents the original and reference
implementation. The Go implementation [GoGNS] demonstrates how two
implementations of GNS are interoperable given that they are built on
top of the same underlying DHT storage.
Currently, the GNUnet peer-to-peer network [GNUnet] is an active
deployment of GNS on top of its [R5N] DHT. The [GoGNS]
implementation uses this deployment by building on top of the GNUnet
DHT services available on any GNUnet peer. It shows how GNS
implementations can attach to this existing deployment and
participate in name resolution as well as zone publication.
The self-sovereign identity system re:claimID [reclaim] is using GNS
in order to selectively share identity attributes and attestations
with third parties.
The Ascension tool [Ascension] facilitates the migration of DNS zones
to GNS zones by translating information retrieved from a DNS zone
transfer into a GNS zone.
13. Acknowledgements
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.
14. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
Schanzenbach, et al. Expires 18 August 2022 [Page 45]
Internet-Draft The GNU Name System February 2022
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000,
<https://www.rfc-editor.org/info/rfc2782>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload
(ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004,
<https://www.rfc-editor.org/info/rfc3686>.
[RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The
Advanced Encryption Standard (AES) Cipher Algorithm in the
SNMP User-based Security Model", RFC 3826,
DOI 10.17487/RFC3826, June 2004,
<https://www.rfc-editor.org/info/rfc3826>.
[RFC5237] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for
the Protocol Field", BCP 37, RFC 5237,
DOI 10.17487/RFC5237, February 2008,
<https://www.rfc-editor.org/info/rfc5237>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>.
[RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891,
DOI 10.17487/RFC5891, August 2010,
<https://www.rfc-editor.org/info/rfc5891>.
Schanzenbach, et al. Expires 18 August 2022 [Page 46]
Internet-Draft The GNU Name System February 2022
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
April 2013, <https://www.rfc-editor.org/info/rfc6895>.
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
Algorithm (DSA) and Elliptic Curve Digital Signature
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
2013, <https://www.rfc-editor.org/info/rfc6979>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC9106] Biryukov, A., Dinu, D., Khovratovich, D., and S.
Josefsson, "Argon2 Memory-Hard Function for Password
Hashing and Proof-of-Work Applications", RFC 9106,
DOI 10.17487/RFC9106, September 2021,
<https://www.rfc-editor.org/info/rfc9106>.
[GANA] GNUnet e.V., "GNUnet Assigned Numbers Authority (GANA)",
April 2020, <https://gana.gnunet.org/>.
[MODES] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Methods and Techniques", December 2001,
<https://doi.org/10.6028/NIST.SP.800-38A>.
Schanzenbach, et al. Expires 18 August 2022 [Page 47]
Internet-Draft The GNU Name System February 2022
[CrockfordB32]
Douglas, D., "Base32", March 2019,
<https://www.crockford.com/base32.html>.
[XSalsa20] Bernstein, D., "Extending the Salsa20 nonce", 2011,
<https://cr.yp.to/snuffle/xsalsa-20110204.pdf>.
[Unicode-UAX15]
Consortium, T. U., "Unicode Standard Annex #15: Unicode
Normalization Forms, Revision 31", September 2009,
<http://www.unicode.org/reports/tr15/tr15-31.html>.
15. Informative References
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
[RFC7363] Maenpaa, J. and G. Camarillo, "Self-Tuning Distributed
Hash Table (DHT) for REsource LOcation And Discovery
(RELOAD)", RFC 7363, DOI 10.17487/RFC7363, September 2014,
<https://www.rfc-editor.org/info/rfc7363>.
[RFC8324] Klensin, J., "DNS Privacy, Authorization, Special Uses,
Encoding, Characters, Matching, and Root Structure: Time
for Another Look?", RFC 8324, DOI 10.17487/RFC8324,
February 2018, <https://www.rfc-editor.org/info/rfc8324>.
[Tor224] Goulet, D., Kadianakis, G., and N. Mathewson, "Next-
Generation Hidden Services in Tor", November 2013,
<https://gitweb.torproject.org/torspec.git/tree/
proposals/224-rend-spec-ng.txt#n2135>.
[SDSI] Rivest, R. and B. Lampson, "SDSI - A Simple Distributed
Security Infrastructure", April 1996,
<http://people.csail.mit.edu/rivest/Sdsi10.ps>.
[Kademlia] Maymounkov, P. and D. Mazieres, "Kademlia: A peer-to-peer
information system based on the xor metric.", 2002,
<http://css.csail.mit.edu/6.824/2014/papers/kademlia.pdf>.
[ed25519] Bernstein, D., Duif, N., Lange, T., Schwabe, P., and B.
Yang, "High-Speed High-Security Signatures", 2011,
<http://link.springer.com/
chapter/10.1007/978-3-642-23951-9_9>.
Schanzenbach, et al. Expires 18 August 2022 [Page 48]
Internet-Draft The GNU Name System February 2022
[GNS] Wachs, M., Schanzenbach, M., and C. Grothoff, "A
Censorship-Resistant, Privacy-Enhancing and Fully
Decentralized Name System", 2014,
<https://sci-hub.st/10.1007/978-3-319-12280-9_9>.
[R5N] Evans, N. S. and C. Grothoff, "R5N: Randomized recursive
routing for restricted-route networks", 2011,
<https://sci-hub.st/10.1109/ICNSS.2011.6060022>.
[SecureNS] Grothoff, C., Wachs, M., Ermert, M., and J. Appelbaum,
"Towards secure name resolution on the Internet", 2018,
<https://sci-hub.st/https://doi.org/10.1016/
j.cose.2018.01.018>.
[GNUnetGNS]
GNUnet e.V., "The GNUnet GNS Implementation",
<https://git.gnunet.org/gnunet.git/tree/src/gns>.
[Ascension]
GNUnet e.V., "The Ascension Implementation",
<https://git.gnunet.org/ascension.git>.
[GNUnet] GNUnet e.V., "The GNUnet Project", <https://gnunet.org>.
[reclaim] GNUnet e.V., "The GNUnet Project",
<https://reclaim.gnunet.org>.
[GoGNS] Fix, B., "The Go GNS Implementation",
<https://github.com/bfix/gnunet-
go/tree/master/src/gnunet/service/gns>.
Appendix A. Base32GNS
This table defines the encode symbol and decode symbol for a given
symbol value. It can be used to implement the encoding by reading it
as: A character "A" or "a" is decoded to a 5 bit value 10 when
decoding. A 5 bit block with a value of 18 is encoded to the
character "J" when encoding. If the bit length of the byte string to
encode is not a multiple of 5 it is padded to the next multiple with
zeroes. In order to further increase tolerance for failures in
character recognition, the letter "U" MUST be decoded to the same
value as the letter "V" in Base32GNS.
Schanzenbach, et al. Expires 18 August 2022 [Page 49]
Internet-Draft The GNU Name System February 2022
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 U u V
28 W w W
29 X x X
30 Y y Y
31 Z z Z
Figure 23
The Base32GNS Alphabet Including the Additional U Encode Symbol.
Appendix B. Test Vectors
The following are test vectors for the Base32GNS encoding used for
zTLDs. The strings are encoded without the zero terminator.
Schanzenbach, et al. Expires 18 August 2022 [Page 50]
Internet-Draft The GNU Name System February 2022
Base32GNS-Encode:
Input string: "Hello World"
Output string: "91JPRV3F41BPYWKCCG"
Input bytes: 474e55204e616d652053797374656d
Output string: "8X75A82EC5PPA82KF5SQ8SBD"
Base32GNS-Decode:
Input string: "91JPRV3F41BPYWKCCG"
Output string: "Hello World"
Input string: "91JPRU3F41BPYWKCCG"
Output string: "Hello World"
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".
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: testdelegation
RRCOUNT: 1
Record #0
EXPIRATION: 2463385894000000
DATA_SIZE: 36
TYPE: 65536
FLAGS: 01000000
DATA:
0001000021e3b30f
f93bc6d35ac8c6e0
Schanzenbach, et al. Expires 18 August 2022 [Page 51]
Internet-Draft The GNU Name System February 2022
e13afdff794cb7b4
4bbbc748d259d0a0
284dbe84
RDATA:
0008c06fb9281580
0024000100010000
0001000021e3b30f
f93bc6d35ac8c6e0
e13afdff794cb7b4
4bbbc748d259d0a0
284dbe84
Encryption NONCE|EXPIRATION|BLOCK COUNTER:
e90a00610008c06f
b928158000000001
Encryption key (K):
864e7138eae7fd91
a30136899c132b23
acebdb2cef43cb19
f6bf55b67db9b3b3
Storage key (q):
4adc67c5ecee9f76
986abd71c2224a3d
ce2e917026c9a09d
fd44cef3d20f55a2
7332725a6c8afbbb
b0f7ec9af1cc4264
1299406b04fd9b5b
5791f86c4b08d5f4
BDATA:
41dc7b5f2176ba59
199cafb9e3c82579
71b21ccb6de51d38
bd2a21e9322c6af8
4243e8de876b5b76
37462e79b2c162db
4014d5c9
RRBLOCK:
000000a400010000
182bb636eda79f79
5711bc2708adbb24
2a60446ad3c30803
121d03d348b7ceb6
Schanzenbach, et al. Expires 18 August 2022 [Page 52]
Internet-Draft The GNU Name System February 2022
01a968a5eac3cb95
ed58c1c5386f4ab6
539edd8099b4893a
be83f242115e3e35
03965dc924a6001a
e94ecab9b2f25c4c
6fdc7ffbe9f3b2a2
854b321b1d7ea9ab
0008c06fb9281580
41dc7b5f2176ba59
199cafb9e3c82579
71b21ccb6de51d38
bd2a21e9322c6af8
4243e8de876b5b76
37462e79b2c162db
4014d5c9
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: testset
RRCOUNT: 3
Record #0
EXPIRATION: 2463385894000000
DATA_SIZE: 16
TYPE: 28
FLAGS: 00000000
DATA:
0000000000000000
00000000deadbeef
Record #1
EXPIRATION: 49556645701000000
Schanzenbach, et al. Expires 18 August 2022 [Page 53]
Internet-Draft The GNU Name System February 2022
DATA_SIZE: 9
TYPE: 65537
FLAGS: 00800000
DATA:
536f6d65206e6963
6b
Record #2
EXPIRATION: 6091321688
DATA_SIZE: 11
TYPE: 16
FLAGS: 04400000
DATA:
48656c6c6f20576f
726c64
RDATA:
0008c06fb9281580
001000000000001c
0000000000000000
00000000deadbeef
00b00f81b7449b40
0009800000010001
536f6d65206e6963
6b000000016b1231
58000b4004000000
1048656c6c6f2057
6f726c6400000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
Encryption NONCE|EXPIRATION|BLOCK COUNTER:
4edb104e0005d78a
44e4e6c800000001
Encryption key (K):
4a7d3f21f67c377e
ad2cb255b6c05930
6287e78caeff4c80
f08e1df327900d21
Storage key (q):
e8f9a842256e825b
Schanzenbach, et al. Expires 18 August 2022 [Page 54]
Internet-Draft The GNU Name System February 2022
f40e802ab2a81a3c
31d621100b4adec0
3c152e22cdbcab0d
d5dde37815887f74
950b22179269e6b3
2b75928dd80111de
3e12eca5517ae246
BDATA:
a6b26ac00e485ddd
26e8db68e3eaba01
b5760ae197f70e28
39cc9e4ac40668f4
61285e42d8e7c397
cfc90e8042106666
9a0506edccfacb1b
520103c2a68eb06d
770c7bd65e6810c3
88e192cc313f924b
ffe67ce114694f20
03d851c7fe5623b2
5eb0fad6bbdf917b
e7eac3a9ec795dd4
a9c8b4c683896b2c
69d4d5ae8dafd93a
RRBLOCK:
000000f000010000
d84c242613691d2f
2150f55b89ee03ca
0b13f9fa6905eb17
acedcbc55518b8aa
042c1e6e6e3aa52a
6538a91fd3d5e9cd
987edb1106f3f864
fea111382f5a0a42
0b954ccb4dc6e9e1
3cbec65e7ae021ec
7c4f7830aa158423
da439dc17fee7586
0005d78a44e4e6c8
a6b26ac00e485ddd
26e8db68e3eaba01
b5760ae197f70e28
39cc9e4ac40668f4
61285e42d8e7c397
cfc90e8042106666
9a0506edccfacb1b
Schanzenbach, et al. Expires 18 August 2022 [Page 55]
Internet-Draft The GNU Name System February 2022
520103c2a68eb06d
770c7bd65e6810c3
88e192cc313f924b
ffe67ce114694f20
03d851c7fe5623b2
5eb0fad6bbdf917b
e7eac3a9ec795dd4
a9c8b4c683896b2c
69d4d5ae8dafd93a
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".
Zone private key (d):
5af7020ee1916032
8832352bbc6a68a8
d71a7cbe1b929969
a7c66d415a0d8f65
Zone identifier (ztype|zkey):
000100143cf4b924
032022f0dc505814
53b85d93b047b63d
446c5845cb48445d
db96688f
Encoded zone identifier (zkl = zTLD):
000G051WYJWJ80S04BRDRM2R2H9VGQCKP13VCFA4DHC4BJT88HEXQ5K8HW
Label: testdelegation
RRCOUNT: 1
Record #0
EXPIRATION: 2463385894000000
DATA_SIZE: 36
TYPE: 65536
FLAGS: 01000000
DATA:
0001000021e3b30f
f93bc6d35ac8c6e0
e13afdff794cb7b4
4bbbc748d259d0a0
284dbe84
Schanzenbach, et al. Expires 18 August 2022 [Page 56]
Internet-Draft The GNU Name System February 2022
RDATA:
0008c06fb9281580
0024000100010000
0001000021e3b30f
f93bc6d35ac8c6e0
e13afdff794cb7b4
4bbbc748d259d0a0
284dbe84
Encryption NONCE|EXPIRATION:
98132ea86859d35c
88bfd317fa991bcb
0008c06fb9281580
Encryption key (K):
85c429a9567aa633
411a9691e9094c45
281672be586034aa
e4a2a2cc716159e2
Storage key (q):
abaabac0e1249459
75988395aac0241e
5559c41c4074e255
7b9fe6d154b614fb
cdd47fc7f51d786d
c2e0b1ece76037c0
a1578c384ec61d44
5636a94e880329e9
BDATA:
7d9ecea3c19ef07b
0db1fab44c5e4477
6ea8d8894e904a0c
35ed1c5c2ff2ed93
bd204b3fcae98192
fad94afbc5bba3a6
de538c01c7e1f65e
2a883cc068c02109
7afd7330
RRBLOCK:
000000b400010014
9bf233198c6d53bb
dbac495cabd91049
a684af3f4051baca
b0dcf21c8cf27a1a
69ac3485946796d1
Schanzenbach, et al. Expires 18 August 2022 [Page 57]
Internet-Draft The GNU Name System February 2022
e31837f569d71e06
e79c4777ab9c41fa
29cdd198464aac3d
aaeea2c192eb6e71
1d0dc7bb76994eca
ab837e402ba2c994
4df155b6e96fdf0a
0008c06fb9281580
7d9ecea3c19ef07b
0db1fab44c5e4477
6ea8d8894e904a0c
35ed1c5c2ff2ed93
bd204b3fcae98192
fad94afbc5bba3a6
de538c01c7e1f65e
2a883cc068c02109
7afd7330
Zone private key (d):
5af7020ee1916032
8832352bbc6a68a8
d71a7cbe1b929969
a7c66d415a0d8f65
Zone identifier (ztype|zkey):
000100143cf4b924
032022f0dc505814
53b85d93b047b63d
446c5845cb48445d
db96688f
Encoded zone identifier (zkl = zTLD):
000G051WYJWJ80S04BRDRM2R2H9VGQCKP13VCFA4DHC4BJT88HEXQ5K8HW
Label: testset
RRCOUNT: 3
Record #0
EXPIRATION: 2463385894000000
DATA_SIZE: 16
TYPE: 28
FLAGS: 00000000
DATA:
0000000000000000
00000000deadbeef
Record #1
Schanzenbach, et al. Expires 18 August 2022 [Page 58]
Internet-Draft The GNU Name System February 2022
EXPIRATION: 49556645701000000
DATA_SIZE: 9
TYPE: 65537
FLAGS: 00800000
DATA:
536f6d65206e6963
6b
Record #2
EXPIRATION: 6091321688
DATA_SIZE: 11
TYPE: 16
FLAGS: 04400000
DATA:
48656c6c6f20576f
726c64
RDATA:
0008c06fb9281580
001000000000001c
0000000000000000
00000000deadbeef
00b00f81b7449b40
0009800000010001
536f6d65206e6963
6b000000016b1231
58000b4004000000
1048656c6c6f2057
6f726c6400000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
Encryption NONCE|EXPIRATION:
0a27e1f82798d680
4285c81ef29391f9
0005d78a44e4ff82
Encryption key (K):
227730f8c97f94ab
5de3645aa731be24
769f04cacb88312d
e8e5102909693488
Schanzenbach, et al. Expires 18 August 2022 [Page 59]
Internet-Draft The GNU Name System February 2022
Storage key (q):
60c6e5b3442eb232
837e70205f26ca16
539f1354692fbeb3
05541efd0e3216cc
9373d3e2c6f8fa1d
1e49cfd9c19cb654
0621377eb989461c
f09676309323b000
BDATA:
dfc0aa69cee85288
434b48d487ed3911
5118213b7b2efe73
9067c6f6c0e83d59
7d9288b018e73b66
264ee8587d026c60
bd2ff2e3d50a7d49
1b53803c8ff4eb3c
03197178d551434e
20851fda85950116
5a6f51dc9accaf5a
daf5ed94a707ffb9
2854ef15c67fb1ec
465f168d480f6436
a1c5affccef33fdd
0b99ea4719debbfd
c1e7e52aaa546b3f
4c4c91d7f1aba812
RRBLOCK:
0000010000010014
dd541a46885a250a
27db63b2b1c07c04
3137271edc77df52
0a30b7bb909060f6
3b8be702f815cb02
f3186874a331d87f
0263393fa66b6197
52b35fd117f27b73
86ab6924bd948de9
cd5f512d3ca370c5
3bfccfc5238516cc
0ddeacf65b145709
0005d78a44e4ff82
dfc0aa69cee85288
434b48d487ed3911
5118213b7b2efe73
Schanzenbach, et al. Expires 18 August 2022 [Page 60]
Internet-Draft The GNU Name System February 2022
9067c6f6c0e83d59
7d9288b018e73b66
264ee8587d026c60
bd2ff2e3d50a7d49
1b53803c8ff4eb3c
03197178d551434e
20851fda85950116
5a6f51dc9accaf5a
daf5ed94a707ffb9
2854ef15c67fb1ec
465f168d480f6436
a1c5affccef33fdd
0b99ea4719debbfd
c1e7e52aaa546b3f
4c4c91d7f1aba812
The following is an example revocation for a zone:
Zone private key (d, big-endian scalar):
6fea32c05af58bfa
979553d188605fd5
7d8bf9cc263b78d5
f7478c07b998ed70
Zone identifier (ztype|zkey):
000100002ca223e8
79ecc4bbdeb5da17
319281d63b2e3b69
55f1c3775c804a98
d5f8ddaa
Encoded zone identifier (zkl = zTLD):
000G001CM8HYGYFCRJXXXDET2WRS50EP7CQ3PTANY71QEQ409ACDBY6XN8
Difficulty (5 base difficulty + 2 epochs): 7
Signed message:
0000003400000003
0005d66da3598127
000100002ca223e8
79ecc4bbdeb5da17
319281d63b2e3b69
55f1c3775c804a98
d5f8ddaa
Proof:
Schanzenbach, et al. Expires 18 August 2022 [Page 61]
Internet-Draft The GNU Name System February 2022
0005d66da3598127
0000395d1827c000
3ab877d07570f2b8
3ab877d07570f332
3ab877d07570f4f5
3ab877d07570f50f
3ab877d07570f537
3ab877d07570f599
3ab877d07570f5cd
3ab877d07570f5d9
3ab877d07570f66a
3ab877d07570f69b
3ab877d07570f72f
3ab877d07570f7c3
3ab877d07570f843
3ab877d07570f8d8
3ab877d07570f91b
3ab877d07570f93a
3ab877d07570f944
3ab877d07570f98a
3ab877d07570f9a7
3ab877d07570f9b0
3ab877d07570f9df
3ab877d07570fa05
3ab877d07570fa3e
3ab877d07570fa63
3ab877d07570fa84
3ab877d07570fa8f
3ab877d07570fa91
3ab877d07570fad6
3ab877d07570fb0a
3ab877d07570fc0f
3ab877d07570fc43
3ab877d07570fca5
000100002ca223e8
79ecc4bbdeb5da17
319281d63b2e3b69
55f1c3775c804a98
d5f8ddaa053b0259
700039187d1da461
3531502bc4a4eecc
c69900d24f8aac54
30f28fc509270133
1f178e290fe06e82
ce2498ce7b23a340
58e3d6a2f247e92b
c9d7b9ab
Schanzenbach, et al. Expires 18 August 2022 [Page 62]
Internet-Draft The GNU Name System February 2022
Authors' Addresses
Martin Schanzenbach
GNUnet e.V.
Boltzmannstrasse 3
85748 Garching
Germany
Email: schanzen@gnunet.org
Christian Grothoff
Berner Fachhochschule
Hoeheweg 80
CH-2501 Biel/Bienne
Switzerland
Email: grothoff@gnunet.org
Bernd Fix
GNUnet e.V.
Boltzmannstrasse 3
85748 Garching
Germany
Email: fix@gnunet.org
Schanzenbach, et al. Expires 18 August 2022 [Page 63]