rfc9498.original   rfc9498.txt 
Independent Stream M. Schanzenbach Independent Submission M. Schanzenbach
Internet-Draft Fraunhofer AISEC Request for Comments: 9498 Fraunhofer AISEC
Intended status: Informational C. Grothoff Category: Informational C. Grothoff
Expires: 7 January 2024 Berner Fachhochschule ISSN: 2070-1721 Berner Fachhochschule
B. Fix B. Fix
GNUnet e.V. GNUnet e.V.
6 July 2023 November 2023
The GNU Name System The GNU Name System
draft-schanzen-gns-28
Abstract Abstract
This document contains the GNU Name System (GNS) technical This document provides the GNU Name System (GNS) technical
specification. GNS is a decentralized and censorship-resistant specification. GNS is a decentralized and censorship-resistant
domain name resolution protocol that provides a privacy-enhancing domain name resolution protocol that provides a privacy-enhancing
alternative to the Domain Name System (DNS) protocols. alternative to the Domain Name System (DNS) protocols.
This document defines the normative wire format of resource records, This document defines the normative wire format of resource records,
resolution processes, cryptographic routines and security resolution processes, cryptographic routines, and security and
considerations for use by implementers. privacy considerations for use by implementers.
This specification was developed outside the IETF and does not have This specification was developed outside the IETF and does not have
IETF consensus. It is published here to inform readers about the IETF consensus. It is published here to inform readers about the
function of GNS, guide future GNS implementations, and ensure function of GNS, guide future GNS implementations, and ensure
interoperability among implementations including with the pre- interoperability among implementations (for example, pre-existing
existing GNUnet implementation. GNUnet implementations).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This is a contribution to the RFC Series, independently of any other
and may be updated, replaced, or obsoleted by other documents at any RFC stream. The RFC Editor has chosen to publish this document at
time. It is inappropriate to use Internet-Drafts as reference its discretion and makes no statement about its value for
material or to cite them other than as "work in progress." implementation or deployment. Documents approved for publication by
the RFC Editor are not candidates for any level of Internet Standard;
see Section 2 of RFC 7841.
This Internet-Draft will expire on 7 January 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9498.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document.
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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Notation
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Overview
3.1. Names and Zones . . . . . . . . . . . . . . . . . . . . . 7 3.1. Names and Zones
3.2. Publishing Binding Information . . . . . . . . . . . . . 8 3.2. Publishing Binding Information
3.3. Resolving Names . . . . . . . . . . . . . . . . . . . . . 9 3.3. Resolving Names
4. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Zones
4.1. Zone Top-Level Domain . . . . . . . . . . . . . . . . . . 12 4.1. Zone Top-Level Domain (zTLD)
4.2. Zone Revocation . . . . . . . . . . . . . . . . . . . . . 13 4.2. Zone Revocation
5. Resource Records . . . . . . . . . . . . . . . . . . . . . . 17 5. Resource Records
5.1. Zone Delegation Records . . . . . . . . . . . . . . . . . 19 5.1. Zone Delegation Records
5.1.1. PKEY . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1.1. PKEY
5.1.2. EDKEY . . . . . . . . . . . . . . . . . . . . . . . . 23 5.1.2. EDKEY
5.2. Redirection Records . . . . . . . . . . . . . . . . . . . 27 5.2. Redirection Records
5.2.1. REDIRECT . . . . . . . . . . . . . . . . . . . . . . 27 5.2.1. REDIRECT
5.2.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . 27 5.2.2. GNS2DNS
5.3. Auxiliary Records . . . . . . . . . . . . . . . . . . . . 28 5.3. Auxiliary Records
5.3.1. LEHO . . . . . . . . . . . . . . . . . . . . . . . . 28 5.3.1. LEHO
5.3.2. NICK . . . . . . . . . . . . . . . . . . . . . . . . 29 5.3.2. NICK
5.3.3. BOX . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.3.3. BOX
6. Record Encoding for Remote Storage . . . . . . . . . . . . . 31 6. Record Encoding for Remote Storage
6.1. The Storage Key . . . . . . . . . . . . . . . . . . . . . 33 6.1. The Storage Key
6.2. Plaintext Record Data (RDATA) . . . . . . . . . . . . . . 34 6.2. Plaintext Record Data (RDATA)
6.3. The Resource Records Block . . . . . . . . . . . . . . . 35 6.3. The Resource Record Block
7. Name Resolution . . . . . . . . . . . . . . . . . . . . . . . 37 7. Name Resolution
7.1. Start Zones . . . . . . . . . . . . . . . . . . . . . . . 38 7.1. Start Zones
7.2. Recursion . . . . . . . . . . . . . . . . . . . . . . . . 39 7.2. Recursion
7.3. Record Processing . . . . . . . . . . . . . . . . . . . . 40 7.3. Record Processing
7.3.1. REDIRECT . . . . . . . . . . . . . . . . . . . . . . 41 7.3.1. REDIRECT
7.3.2. GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . 41 7.3.2. GNS2DNS
7.3.3. BOX . . . . . . . . . . . . . . . . . . . . . . . . . 42 7.3.3. BOX
7.3.4. Zone Delegation Records . . . . . . . . . . . . . . . 43 7.3.4. Zone Delegation Records
7.3.5. NICK . . . . . . . . . . . . . . . . . . . . . . . . 43 7.3.5. NICK
8. Internationalization and Character Encoding . . . . . . . . . 44 8. Internationalization and Character Encoding
9. Security and Privacy Considerations . . . . . . . . . . . . . 44 9. Security and Privacy Considerations
9.1. Availability . . . . . . . . . . . . . . . . . . . . . . 44 9.1. Availability
9.2. Agility . . . . . . . . . . . . . . . . . . . . . . . . . 45 9.2. Agility
9.3. Cryptography . . . . . . . . . . . . . . . . . . . . . . 45 9.3. Cryptography
9.4. Abuse Mitigation . . . . . . . . . . . . . . . . . . . . 46 9.4. Abuse Mitigation
9.5. Zone Management . . . . . . . . . . . . . . . . . . . . . 47 9.5. Zone Management
9.6. DHTs as Remote Storage . . . . . . . . . . . . . . . . . 48 9.6. DHTs as Remote Storage
9.7. Revocations . . . . . . . . . . . . . . . . . . . . . . . 48 9.7. Revocations
9.8. Zone Privacy . . . . . . . . . . . . . . . . . . . . . . 49 9.8. Zone Privacy
9.9. Zone Governance . . . . . . . . . . . . . . . . . . . . . 49 9.9. Zone Governance
9.10. Namespace Ambiguity . . . . . . . . . . . . . . . . . . . 50 9.10. Namespace Ambiguity
10. GANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 10. GANA Considerations
10.1. GNS Record Types Registry . . . . . . . . . . . . . . . 51 10.1. GNUnet Signature Purposes Registry
10.2. .alt Subdomains Registry . . . . . . . . . . . . . . . . 52 10.2. GNS Record Types Registry
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 10.3. .alt Subdomains Registry
12. Implementation and Deployment Status . . . . . . . . . . . . 53 11. IANA Considerations
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54 12. Implementation and Deployment Status
14. Normative References . . . . . . . . . . . . . . . . . . . . 54 13. References
15. Informative References . . . . . . . . . . . . . . . . . . . 57 13.1. Normative References
Appendix A. Usage and Migration . . . . . . . . . . . . . . . . 59 13.2. Informative References
A.1. Zone Dissemination . . . . . . . . . . . . . . . . . . . 59 Appendix A. Usage and Migration
A.2. Start Zone Configuration . . . . . . . . . . . . . . . . 60 A.1. Zone Dissemination
A.3. Globally Unique Names and the Web . . . . . . . . . . . . 61 A.2. Start Zone Configuration
A.4. Migration Paths . . . . . . . . . . . . . . . . . . . . . 62 A.3. Globally Unique Names and the Web
Appendix B. Example flows . . . . . . . . . . . . . . . . . . . 63 A.4. Migration Paths
B.1. AAAA Example Resolution . . . . . . . . . . . . . . . . . 63 Appendix B. Example Flows
B.2. REDIRECT Example Resolution . . . . . . . . . . . . . . . 64 B.1. AAAA Example Resolution
B.3. GNS2DNS Example Resolution . . . . . . . . . . . . . . . 65 B.2. REDIRECT Example Resolution
Appendix C. Base32GNS . . . . . . . . . . . . . . . . . . . . . 66 B.3. GNS2DNS Example Resolution
Appendix D. Test Vectors . . . . . . . . . . . . . . . . . . . . 67 Appendix C. Base32GNS
D.1. Base32GNS en-/decoding . . . . . . . . . . . . . . . . . 67 Appendix D. Test Vectors
D.2. Record sets . . . . . . . . . . . . . . . . . . . . . . . 68 D.1. Base32GNS Encoding/Decoding
D.3. Zone revocation . . . . . . . . . . . . . . . . . . . . . 81 D.2. Record Sets
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 84 D.3. Zone Revocation
Acknowledgements
Authors' Addresses
1. Introduction 1. Introduction
This specification describes the GNU Name System (GNS), a censorship- This specification describes the GNU Name System (GNS), a censorship-
resistant, privacy-preserving and decentralized domain name resistant, privacy-preserving, and decentralized domain name
resolution protocol. GNS cryptographically secures the binding of resolution protocol. GNS cryptographically secures the binding of
names to arbitrary tokens, enabling it to double in some respects as names to arbitrary tokens, enabling it to double in some respects as
an alternative to some of today's public key infrastructures. an alternative to some of today's public key infrastructures.
In the terminology of the Domain Name System (DNS) [RFC1035], GNS Per Domain Name System (DNS) terminology [RFC1035], GNS roughly
roughly follows the idea of a local root zone deployment (see follows the idea of a local root zone deployment (see [RFC8806]),
[RFC8806]), with the difference that the design encourages with the difference that the design encourages alternative roots and
alternative roots and does not expect all deployments to use the same does not expect all deployments to use the same or any specific root
or any specific root zone. In the GNS reference implementation, zone. In the GNS reference implementation, users can autonomously
users can autonomously and freely delegate control of names to zones and freely delegate control of names to zones through their local
through their local configurations. GNS expects each user to be in configurations. GNS expects each user to be in control of their
control of their setup. By following Section 9.10 guidelines, users setup. By following the guidelines in Section 9.10, users should
should manage to avoid any confusion as to how names are resolved. manage to avoid any confusion as to how names are resolved.
Name resolution and zone dissemination is based on the principle of a Name resolution and zone dissemination are based on the principle of
petname system where users can assign local names to zones. The GNS a petname system where users can assign local names to zones. The
has its roots in ideas from the Simple Distributed Security GNS has its roots in ideas from the Simple Distributed Security
Infrastructure [SDSI], enabling the decentralized mapping of secure Infrastructure [SDSI], enabling the decentralized mapping of secure
identifiers to memorable names. A first academic description of the identifiers to memorable names. One of the first academic
cryptographic ideas behind GNS can be found in [GNS]. descriptions of the cryptographic ideas behind GNS can be found in
[GNS].
This document defines the normative wire format of resource records, This document defines the normative wire format of resource records,
resolution processes, cryptographic routines and security resolution processes, cryptographic routines, and security and
considerations for use by implementers. privacy considerations for use by implementers.
This specification was developed outside the IETF and does not have
IETF consensus. It is published here to guide implementers of GNS
and to ensure interoperability among implementations.
1.1. Requirements Notation 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Terminology 2. Terminology
Apex Label This type of label is used to publish resource records in Apex Label: This type of label is used to publish resource records
a zone that can be resolved without providing a specific label. 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 It is the GNS method for providing what is called the "zone apex"
[RFC4033]. The apex label is represented using the character in DNS [RFC4033]. The apex label is represented using the
U+0040 ("@" without the quotes). character U+0040 ("@" without the quotes).
Application A component which uses a GNS implementation to resolve Application: An application is a component that uses a GNS
names into records and processes its contents. implementation to resolve names into records and processes its
contents.
Blinded Zone Key Key derived from a zone key and a label. The zone Blinded Zone Key: A blinded zone key is a key derived from a zone
key and any blinded zone key derived from it are unlinkable key and a label. The zone key and any blinded zone key derived
without knowledge of the specific label used for the derivation. from it are unlinkable without knowledge of the specific label
used for the derivation.
Extension Label This type of label is used to refer to the Extension Label: This type of label is used to refer to the
authoritative zone that the record is in. The primary use for the authoritative zone that the record is in. The primary use for the
extension label is in redirections where the redirection target is extension label is in redirections where the redirection target is
defined relative to the authoritative zone of the redirection defined relative to the authoritative zone of the redirection
record (see Section 5.2). The extension label is represented record (see Section 5.2). The extension label is represented
using the character U+002B ("+" without the quotes). using the character U+002B ("+" without the quotes).
Label Separator Labels in a name are separated using the label Label Separator: Labels in a name are separated using the label
separator U+002E ("." without the quotes). In GNS, with the separator U+002E ("." without the quotes). In GNS, except for
exceptions of zone Top-Level Domains (see below) and boxed records zone Top-Level Domains (zTLDs) (see below) and boxed records (see
(see Section 5.3.3), every label separator in a name indicates Section 5.3.3), every label separator in a name indicates
delegation to another zone. delegation to another zone.
Label A GNS label is a label as defined in [RFC8499]. Labels are Label: A GNS label is a label as defined in [RFC8499]. Labels are
UTF-8 strings in Unicode Normalization Form C (NFC) UTF-8 strings in Unicode Normalization Form C (NFC)
[Unicode-UAX15]. The apex label and the extension label have [Unicode-UAX15]. The apex label and the extension label have
special purposes in the resolution protocol which are defined in special purposes in the resolution protocol that are defined in
the rest of the document. Zone administrators MAY disallow the rest of this document. Zone administrators MAY disallow
certain labels that might be easily confused with other labels certain labels that might be easily confused with other labels
through registration policies (see also Section 9.4). through registration policies (see also Section 9.4).
Name A name in GNS is a domain name as defined in [RFC8499]: Names Name: A name in GNS is a domain name as defined in [RFC8499]: names
are UTF-8 [RFC3629] strings consisting of an ordered list of are UTF-8 strings [RFC3629] consisting of an ordered list of
labels concatenated with a label separator. Names are resolved labels concatenated with a label separator. Names are resolved
starting from the rightmost label. GNS does not impose length starting from the rightmost label. GNS does not impose length
restrictions on names or labels. However, applications MAY ensure restrictions on names or labels. However, applications MAY ensure
that name and label lengths are compatible with DNS and in that name and label lengths are compatible with DNS and, in
particular IDNA [RFC5890]. In the spirit of [RFC5895], particular, Internationalized Domain Names for Applications (IDNA)
applications MAY preprocess names and labels to ensure [RFC5890]. In the spirit of [RFC5895], applications MAY
compatibility with DNS or support specific user expectations, for preprocess names and labels to ensure compatibility with DNS or
example according to [Unicode-UTS46]. A GNS name may be support specific user expectations -- for example, according to
indistinguishable from a DNS name and care must be taken by [Unicode-UTS46]. A GNS name may be indistinguishable from a DNS
applications and implementors when handling GNS names (see name, and care must be taken by applications and implementers when
Section 9.10). In order to avoid misinterpretation of example handling GNS names (see Section 9.10). In order to avoid
domains with (reserved) DNS domains this draft uses the suffix misinterpretation of example domains with (reserved) DNS domains,
".gns.alt" in examples which is also registered in the GANA ".alt this document uses the suffix ".gns.alt" in compliance with
Subdomains" registry [GANA] (see also [I-D.ietf-dnsop-alt-tld]). [RFC9476]. ".gns.alt" is also registered in the GANA ".alt
Subdomains" registry [GANA].
Resolver The component of a GNS implementation which provides the Resolver: In this document, a resolver is the component of a GNS
recursive name resolution logic defined in Section 7. implementation that provides the recursive name resolution logic
defined in Section 7.
Resource Record A GNS resource record is the information associated Resource Record: A GNS resource record is the information associated
with a label in a GNS zone. A GNS resource record contains with a label in a GNS zone. A GNS resource record contains
information as defined by its resource record type. information as defined by its resource record type.
Start Zone In order to resolve any given GNS name an initial start Start Zone: In order to resolve any given GNS name, an initial Start
zone must be determined for this name. The start zone can be Zone must be determined for this name. The Start Zone can be
explicitly defined as part of the name using a zone Top-Level explicitly defined as part of the name using a zTLD. Otherwise,
Domain (zTLD). Otherwise, it is determined through a local it is determined through a local suffix-to-zone mapping (see
suffix-to-zone mapping (see Section 7.1). Section 7.1).
Top-Level Domain The rightmost part of a GNS name is a GNS Top-Level Top-Level Domain (TLD): The rightmost part of a GNS name is a GNS
Domain (TLD). A GNS TLD can consist of one or more labels. TLD. A GNS TLD can consist of one or more labels. Unlike DNS
Unlike DNS Top-Level Domains (defined in [RFC8499]), GNS does not TLDs (defined in [RFC8499]), GNS does not expect all users to use
expect all users to use the same global root zone. Instead, with the same global root zone. Instead, with the exception of zTLDs
the exception of Zone Top-Level Domains (see Section 4.1), GNS (see Section 4.1), GNS TLDs are typically part of the
TLDs are typically part of the configuration of the local resolver configuration of the local resolver (see Section 7.1) and thus
(see Section 7.1), and might thus not be globally unique. might not be globally unique.
Zone A GNS zone contains authoritative information (resource Zone: A GNS zone contains authoritative information (resource
records). A zone is uniquely identified by its zone key. Unlike 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 DNS zones, a GNS zone does not need to have an SOA record under
apex label. the apex label.
Zone Key A key which uniquely identifies a zone. It is usually a Zone Key: The zone key is a key that uniquely identifies a zone. It
public key of an asymmetric key pair. However, the established is usually a public key of an asymmetric key pair. However, the
technical term "public key" is misleading, as in GNS a zone key established technical term "public key" is misleading, as in GNS a
may be a shared secret that should not be disclosed to zone key may be a shared secret that should not be disclosed to
unauthorized parties. unauthorized parties.
Zone Key Derivation Function The zone key derivation function (ZKDF) Zone Key Derivation Function: The zone key derivation function
blinds a zone key using a label. (ZKDF) blinds a zone key using a label.
Zone Master The component of a GNS implementation which provides Zone Publisher: The zone publisher is the component of a GNS
local zone management and publication as defined in Section 6. implementation that provides local zone management and publication
as defined in Section 6.
Zone Owner The holder of the secret (typically a private key) that Zone Owner: The zone owner is the holder of the secret (typically a
(together with a label and a value to sign) allows the creation of private key), which (together with a label and a value to sign)
zone signatures that can be validated against the respective allows the creation of zone signatures that can be validated
blinded zone key. against the respective blinded zone key.
Zone Top-Level Domain A GNS Zone Top-Level Domain (zTLD) is a Zone Top-Level Domain (zTLD): A GNS zTLD is a sequence of GNS labels
sequence of GNS labels at the end of a GNS name which encodes a at the end of a GNS name. The zTLD encodes a zone type and zone
zone type and zone key of a zone (see Section 4.1). Due to the key of a zone (see Section 4.1). Due to the statistical
statistical uniqueness of zone keys, zTLDs are also globally uniqueness of zone keys, zTLDs are also globally unique. A zTLD
unique. A zTLD label sequence can only be distinguished from label sequence can only be distinguished from ordinary TLD label
ordinary TLD label sequences by attempting to decode the labels sequences by attempting to decode the labels into a zone type and
into a zone type and zone key. zone key.
Zone Type The type of a GNS zone determines the cipher system and Zone Type: The type of a GNS zone determines the cipher system and
binary encoding format of the zone key, blinded zone keys, and binary encoding format of the zone key, blinded zone keys, and
cryptographic signatures. cryptographic signatures.
3. Overview 3. Overview
GNS exhibits the three properties that are commonly used to describe GNS exhibits the three properties that are commonly used to describe
a petname system: a petname system:
1. Global names through the concept of zone top-level domains Global names through the concept of zTLDs:
(zTLDs): As zones can be uniquely identified by their zone key As zones can be uniquely identified by their zone keys and are
and are statistically unique, zTLDs are globally unique mappings statistically unique, zTLDs are globally unique mappings to zones.
to zones. Consequently, GNS domain names with a zTLD suffix are Consequently, GNS domain names with a zTLD suffix are also
also globally unique. Names with zTLDs suffixes are not human- globally unique. Names with zTLD suffixes are not memorable.
readable.
2. Memorable petnames for zones: Users can configure local, human- Memorable petnames for zones:
readable references to zones. Such petnames serve as zTLD Users can configure local, memorable references to zones. Such
monikers which provide convenient names for zones to the local petnames serve as zTLD monikers that provide convenient names for
operator. The petnames may also be published as suggestions for zones to the local operator. The petnames may also be published
other users searching for good label to use when referencing the as suggestions for other users searching for a good label to use
respective zone. when referencing the respective zone.
3. A secure mapping from names to records: GNS allows zone owners to A secure mapping from names to records:
map labels to resource records or to delegate authority of names GNS allows zone owners to map labels to resource records or to
in the subdomain induced by a label to other zones. Zone owners delegate authority of names in the subdomain induced by a label to
may choose to publish this information to make it available to other zones. Zone owners may choose to publish this information
other users. Mappings are encrypted and signed using keys to make it available to other users. Mappings are encrypted and
derived from the respective label before being published to signed using keys derived from the respective label before being
remote storage. When names are resolved, signatures on resource published in remote storage. When names are resolved, signatures
records including delegations are verified by the recursive on resource records, including delegations, are verified by the
resolver. recursive resolver.
In the remainder of this document, the "implementer" refers to the In the remainder of this document, the "implementer" refers to the
developer building a GNS implementation including the resolver, zone developer building a GNS implementation that includes the resolver,
master, and supporting configuration such as start zones (see zone publisher, and supporting configuration such as Start Zones (see
Section 7.1). Section 7.1).
3.1. Names and Zones 3.1. Names and Zones
It follows from the above that GNS does not support names which are It follows from the above that GNS does not support names that are
simultaneously global, secure and human-readable. Instead, names are simultaneously global, secure, and memorable. Instead, names are
either global and not human-readable or not globally unique and either global and not memorable or not globally unique and memorable.
human-readable. An example for a global name pointing to the record An example for a global name pointing to the record "example" in a
"example" in a zone is: zone is as follows:
example.000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884 example.000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884
Now consider the case where a user locally configured the petname Now consider the case where a user locally configured the petname
"pet.gns.alt" for the zone with the "example" record of the name "pet.gns.alt" for the zone with the "example" record of the name
above. The name "example.pet.gns.alt" would then point to the same above. The name "example.pet.gns.alt" would then point to the same
record as the globally unique name above, but name resolution would record as the globally unique name above, but name resolution would
only work on the local system where the "pet.gns.alt" petname is only work on the local system where the "pet.gns.alt" petname is
configured. configured.
The delegation of petnames and subsequent resolution of delegation The delegation of petnames and subsequent resolution of delegation
builds on ideas from the Simple Distributed Security Infrastructure build on ideas from the Simple Distributed Security Infrastructure
[SDSI]. In GNS, any user can create and manage any number of zones [SDSI]. In GNS, any user can create and manage any number of zones
(see Section 4) if their system provides a zone master (see Section 4) if their system provides a zone publisher
implementation. For each zone, the zone type determines the implementation. For each zone, the zone type determines the
respective set of cryptographic operations and the wire formats for respective set of cryptographic operations and the wire formats for
encrypted data, public keys and signatures. A zone can be populated encrypted data, public keys, and signatures. A zone can be populated
with mappings from labels to resource records (see Section 5) by its with mappings from labels to resource records (see Section 5) by its
owner. A label can be mapped to a delegation record which results in owner. A label can be mapped to a delegation record; this results in
the corresponding subdomain being delegated to another zone. the corresponding subdomain being delegated to another zone.
Circular delegations are explicitly allowed, including delegating a Circular delegations are explicitly allowed, including delegating a
subdomain to its immediate parent zone. In order to support (legacy) subdomain to its immediate parent zone. In order to support (legacy)
applications as well as to facilitate the use of petnames, GNS applications as well as to facilitate the use of petnames, GNS
defines auxiliary record types in addition to supporting existing DNS defines auxiliary record types in addition to supporting existing DNS
records. records.
3.2. Publishing Binding Information 3.2. Publishing Binding Information
Zone contents are encrypted and signed before being published in a Zone contents are encrypted and signed before being published in
remote key-value storage (see Section 6) as illustrated in Figure 1. remote key-value storage (see Section 6), as illustrated in Figure 1.
In this process, unique zone identification is hidden from the In this process, unique zone identification is hidden from the
network through the use of key blinding. Key blinding allows the network through the use of key blinding. Key blinding allows the
creation of signatures for zone contents using a blinded public/ creation of signatures for zone contents using a blinded public/
private key pair. This blinding is realized using a deterministic private key pair. This blinding is realized using a deterministic
key derivation from the original zone key and corresponding private key derivation from the original zone key and corresponding private
key using record label values as inputs from which blinding factors key using record label values as inputs from which blinding factors
are derived. Specifically, the zone owner can derive blinded private are derived. Specifically, the zone owner can derive blinded private
keys for each record set published under a label, and a resolver can keys for each record set published under a label, and a resolver can
derive the corresponding blinded public keys. It is expected that derive the corresponding blinded public keys. It is expected that
GNS implementations use decentralized remote storages such as GNS implementations use decentralized remote storage entities, such
distributed hash tables (DHT) in order to facilitate availability as distributed hash tables (DHTs), in order to facilitate
within a network without the need for dedicated infrastructure. availability within a network without the need for dedicated
Specification of such a distributed or decentralized storage is out infrastructure. The specification of such a distributed or
of scope of this document, but possible existing implementations decentralized storage entity is out of scope for this document, but
include those based on [RFC7363], [Kademlia] or [R5N]. possible existing implementations include those based on [RFC7363],
[Kademlia], or [R5N].
Host A | Remote | Host B Host A | Remote | Host B
| Storage | | Storage |
| | | |
| +---------+ | | +---------+ |
| / /| | | / /| |
Publish | +---------+ | | Publish Publish | +---------+ | | Publish
+---------+ Records | | | | | Records +---------+ +-----------+ Records | | | | | Records +-----------+
| Zone |----------|->| Record | |<-|----------| Zone | | Zone |----------|->| Record | |<-|----------| Zone |
| Master | | | Storage | | | | Master | | Publisher | | | Storage | | | | Publisher |
+---------+ | | |/ | +---------+ +-----------+ | | |/ | +-----------+
A | +---------+ | A A | +---------+ | A
| | | | | | | |
+---------+ | | +---------+ +---------+ | | +---------+
/ | /| | | / | /| / | /| | | / | /|
+---------+ | | | +---------+ | +---------+ | | | +---------+ |
| | | | | | | | | | | | | | | |
| Local | | | | | Local | | | Local | | | | | Local | |
| Zones | | | | | Zones | | | Zones | | | | | Zones | |
| |/ | | | |/ | |/ | | | |/
+---------+ | | +---------+ +---------+ | | +---------+
Figure 1: An example diagram of two hosts publishing GNS zones. Figure 1: An Example Diagram of Two Hosts Publishing GNS Zones
A zone master implementation SHOULD be provided as part of a GNS A zone publisher implementation SHOULD be provided as part of a GNS
implementation to enable users to create and manage zones. If this implementation to enable users to create and manage zones. If this
functionality is not implemented, names can still be resolved if zone functionality is not implemented, names can still be resolved if zone
keys for the initial step in the name resolution have been configured keys for the initial step in the name resolution have been configured
(see Section 7) or if the names end with a zTLD suffix. (see Section 7) or if the names end with a zTLD suffix.
3.3. Resolving Names 3.3. Resolving Names
Applications use the resolver to lookup GNS names. Starting from a Applications use the resolver to look up GNS names. Starting from a
configurable start zone, names are resolved by following zone configurable Start Zone, names are resolved by following zone
delegations recursively as illustrated in Figure 2. For each label delegations recursively, as illustrated in Figure 2. For each label
in a name, the recursive GNS resolver fetches the respective record in a name, the recursive GNS resolver fetches the respective record
set from the storage layer (see Section 7). Without knowledge of the set from the storage layer (see Section 7). Without knowledge of the
label values and the zone keys, the different derived keys are label values and the zone keys, the different derived keys are
unlinkable both to the original zone key and to each other. This unlinkable to both the original zone key and each other. This
prevents zone enumeration (except via expensive online brute force prevents zone enumeration (except via expensive online brute-force
attacks): To confirm affiliation of a query or the corresponding attacks): to confirm the affiliation of a query or the corresponding
encrypted record set with a specific zone requires knowledge of both encrypted record set with a specific zone requires knowledge of both
the zone key and the label, neither of which are disclosed to remote the zone key and the label, neither of which is disclosed to remote
storage by the protocol. At the same time, the blinded zone key and storage by the protocol. At the same time, the blinded zone key and
digital signatures associated with each encrypted record set allow digital signatures associated with each encrypted record set allow
resolvers and oblivious remote storage to verify the integrity of the resolvers and oblivious remote storage to verify the integrity of the
published information without disclosing anything about the published information without disclosing anything about the
originating zone or the record sets. originating zone or the record sets.
Local Host | Remote Local Host | Remote
| Storage | Storage
| |
| +---------+ | +---------+
| / /| | / /|
| +---------+ | | +---------+ |
+-----------+ Name +----------+ Recursive | | | | +-----------+ Name +----------+ Recursive | | | |
| | Lookup | | Resolution | | Record | | | | Lookup | | Resolution | | Record | |
|Application|----------| Resolver |-------------|->| Storage | | |Application|--------->| Resolver |-------------|->| Storage | |
| |<---------| |<------------|--| |/ | |<---------| |<------------|--| |/
+-----------+ Results +----------+ Intermediate| +---------+ +-----------+ Results +----------+ Intermediate| +---------+
A Results | A Results |
| | | |
+---------+ | +---------+ |
/ | /| | / | /| |
+---------+ | | +---------+ | |
| | | | | | | |
| Start | | | | Start | | |
| Zones | | | | Zones | | |
| |/ | | |/ |
+---------+ | +---------+ |
Figure 2: High-level view of the GNS resolution process. Figure 2: High-Level View of the GNS Resolution Process
4. Zones 4. Zones
A zone in GNS is uniquely identified by its zone type and zone key. A zone in GNS is uniquely identified by its zone type (ztype) and
Each zone can be referenced by its zone Top-Level Domain (zTLD) zone key. Each zone can be referenced by its zTLD (see Section 4.1),
string (see Section 4.1) which encodes the zone type and zone key. A which is a string that encodes the zone type and zone key. The ztype
zone type (ztype) is a unique 32-bit number which corresponds to a is a unique 32-bit number that corresponds to a resource record type
resource record type number identifying a delegation record type in number identifying a delegation record type in the GANA "GNS Record
the GANA "GNS Record Types" registry [GANA]. The ztype is a unique Types" registry [GANA]. The ztype is a unique identifier for the set
identifier for the set cryptographic functions of the zone and the cryptographic functions of the zone and the format of the delegation
format of the delegation record type. Any ztype registration MUST record type. Any ztype registration MUST define the following set of
define the following set of cryptographic functions: cryptographic functions:
KeyGen() -> d, zk is a function to generate a new private key d and KeyGen() -> d, zkey
the corresponding public zone key zk. A function for generating a new private key d and the
corresponding public zone key zkey.
ZKDF(zk,label) -> zk' is a zone key derivation function which blinds ZKDF(zkey, label) -> zkey'
a zone key zk using a label. zk and zk' must be unlinkable. A ZKDF that blinds a zone key zkey using a label. zkey and zkey'
Furthermore, blinding zk with different values for the label must must be unlinkable. Furthermore, blinding zkey with different
result in different, unlinkable zk' values. values for the label must result in different, unlinkable zkey'
values.
S-Encrypt(zk,label,expiration,plaintext) -> ciphertext is a S-Encrypt(zkey, label, expiration, plaintext) -> ciphertext
symmetric encryption function which encrypts the plaintext to A symmetric encryption function that encrypts the plaintext to
derive ciphertext based on key material derived from the zone key derive ciphertext based on key material derived from the zone key
zk, a label and an expiration timestamp. In order to leverage zkey, a label, and an expiration timestamp. In order to leverage
performance-enhancing caching features of certain underlying performance-enhancing caching features of certain underlying
storages, in particular DHTs, a deterministic encryption scheme is storage entities -- in particular, DHTs -- a deterministic
recommended. encryption scheme is recommended.
S-Decrypt(zk,label,expiration,ciphertext) -> plaintext is a S-Decrypt(zkey, label, expiration, ciphertext) -> plaintext
symmetric decryption function which decrypts the ciphertext into A symmetric decryption function that decrypts the ciphertext into
plaintext based on key material derived from the zone key, a plaintext based on key material derived from the zone key, a
label, and an expiration timestamp. label, and an expiration timestamp.
Sign(d,message) -> signature is a function to sign a message using Sign(d, message) -> signature
the private key d, yielding an unforgeable cryptographic A function for signing a message using the private key d, yielding
signature. In order to leverage performance-enhancing caching an unforgeable cryptographic signature. In order to leverage
features of certain underlying storages, in particular DHTs, a performance-enhancing caching features of certain underlying
deterministic signature scheme is recommended. storage entities -- in particular, DHTs -- a deterministic
signature scheme is recommended.
Verify(zk,message,signature) -> boolean is a function to verify the Verify(zkey, message, signature) -> boolean
signature was created using the private key d corresponding to the A function for verifying that the signature was created using the
zone key zk where d,zk := Keygen(). The function returns a private key d corresponding to the zone key zkey where d,zkey :=
boolean value of "TRUE" if the signature is valid, and otherwise KeyGen(). The function returns a boolean value of "TRUE" if the
"FALSE". signature is valid and "FALSE" otherwise.
SignDerived(d,label,message) -> signature is a function to sign a SignDerived(d, label, message) -> signature
message (typically encrypted record data) that can be verified A function for signing a message (typically encrypted record data)
using the derived zone key zk' := ZKDF(zk,label). In order to that can be verified using the derived zone key zkey' :=
leverage performance-enhancing caching features of certain ZKDF(zkey, label). In order to leverage performance-enhancing
underlying storages, in particular DHTs, a deterministic signature caching features of certain underlying storage entities -- in
scheme is recommended. particular, DHTs -- a deterministic signature scheme is
recommended.
VerifyDerived(zk,label,message,signature) -> boolean is function to VerifyDerived(zkey', message, signature) -> boolean
verify the signature using the derived zone key zk' := A function for verifying the signature using the derived zone key
ZKDF(zk,label). The function returns a boolean value of "TRUE" if zkey' := ZKDF(zkey, label). The function returns a boolean value
the signature is valid, and otherwise "FALSE". of "TRUE" if the signature is valid and "FALSE" otherwise.
Depending on the signature scheme used, this function can be
identical to the Verify() function.
The cryptographic functions of the default ztypes are specified with The cryptographic functions of the default ztypes are specified with
their corresponding delegation records in Section 5.1. In order to their corresponding delegation records as discussed in Section 5.1.
support cryptographic agility, additional ztypes MAY be defined in In order to support cryptographic agility, additional ztypes MAY be
the future which replace or update the default ztypes defined in this defined in the future that replace or update the default ztypes
document. All ztypes MUST be registered as dedicated zone delegation defined in this document. All ztypes MUST be registered as dedicated
record types in the GANA "GNS Record Types" registry (see [GANA]). zone delegation record types in the GANA "GNS Record Types" registry
When defining new record types the cryptographic security (see [GANA]). When defining new record types, the cryptographic
considerations of this document apply, in particular Section 9.3. security considerations of this document -- in particular,
Section 9.3 -- apply.
4.1. Zone Top-Level Domain 4.1. Zone Top-Level Domain (zTLD)
A zone Top-Level Domain (zTLD) is a string which encodes the zone A zTLD is a string that encodes the zone type and zone key into a
type and zone key into a domain name suffix. A zTLD is used as a domain name suffix. A zTLD is used as a globally unique reference to
globally unique references to a zone in the process of name a zone in the process of name resolution. It is created by encoding
resolution. It is created by encoding a binary concatenation of the a binary concatenation of the zone type and zone key (see Figure 3).
zone type and zone key (see Figure 3). The used encoding is a The used encoding is a variation of the Crockford Base32 encoding
variation of the Crockford Base32 encoding [CrockfordB32] called [CrockfordB32] called Base32GNS. The encoding and decoding symbols
Base32GNS. The encoding and decoding symbols for Base32GNS including for Base32GNS, including this variation, are defined in Table 4,
this modification are defined in Figure 30. The functions for found in Appendix C. The functions for encoding and decoding based
encoding and decoding based on this table are called Base32GNS-Encode on Table 4 are called Base32GNS-Encode and Base32GNS-Decode,
and Base32GNS-Decode, respectively. respectively.
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| ZONE TYPE | ZONE KEY / | ZONE TYPE | ZONE KEY /
+-----+-----+-----+-----+ / +-----+-----+-----+-----+ /
/ / / /
/ / / /
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 3: The binary representation of the zTLD Figure 3: The Binary Representation of the zTLD
The ZONE TYPE must be encoded in network byte order. The format of The ZONE TYPE MUST be encoded in network byte order. The format of
the ZONE KEY depends entirely on the ZONE TYPE. the ZONE KEY depends entirely on the ZONE TYPE.
Consequently, a zTLD is encoded and decoded as follows: Consequently, a zTLD is encoded and decoded as follows:
zTLD := Base32GNS-Encode(ztype||zkey) zTLD := Base32GNS-Encode(ztype||zkey)
ztype||zkey := Base32GNS-Decode(zTLD) ztype||zkey := Base32GNS-Decode(zTLD)
where "||" is the concatenation operator. where "||" is the concatenation operator.
The zTLD can be used as-is as a rightmost label in a GNS name. If an The zTLD can be used "as is" as a rightmost label in a GNS name. If
application wants to ensure DNS compatibility of the name, it MAY an application wants to ensure DNS compatibility of the name, it MAY
also represent the zTLD as follows: If the zTLD is less than or equal also represent the zTLD as follows: if the zTLD is less than or equal
to 63 characters, it can be used as a zTLD as-is. If the zTLD is to 63 characters, it can be used as a zTLD as is. If the zTLD is
longer than 63 characters, the zTLD is divided into smaller labels longer than 63 characters, the zTLD is divided into smaller labels
separated by the label separator. Here, the most significant bytes separated by the label separator. Here, the most significant bytes
of the "ztype||zkey" concatenation must be contained in the rightmost of the "ztype||zkey" concatenation must be contained in the rightmost
label of the resulting string and the least significant bytes in the label of the resulting string and the least significant bytes in the
leftmost label of the resulting string. This allows the resolver to leftmost label of the resulting string. This allows the resolver to
determine the ztype and zTLD length from the rightmost label and to determine the ztype and zTLD length from the rightmost label and to
subsequently determine how many labels the zTLD should span. A GNS subsequently determine how many labels the zTLD should span. A GNS
implementation MUST support the division of zTLDs in DNS compatible implementation MUST support the division of zTLDs in DNS-compatible
label lengths. For example, assuming a zTLD of 130 characters, the label lengths. For example, assuming a zTLD of 130 characters, the
division is: division is as follows:
zTLD[126..129].zTLD[63..125].zTLD[0..62] zTLD[126..129].zTLD[63..125].zTLD[0..62]
4.2. Zone Revocation 4.2. Zone Revocation
In order to revoke a zone key, a signed revocation message MUST be In order to revoke a zone key, a signed revocation message MUST be
published. This message MUST be signed using the private key of the published. This message MUST be signed using the private key of the
zone. The revocation message is broadcast to the network. The zone. The revocation message is broadcast to the network. The
specification of the broadcast mechanism is out of scope for this specification of the broadcast mechanism is out of scope for this
document. A possible broadcast mechanism for efficient flooding in a document. A possible broadcast mechanism for efficient flooding in a
distributed network is implemented in [GNUnet]. Alternatively, distributed network is implemented in [GNUnet]. Alternatively,
revocation messages could also be distributed via a distributed revocation messages could also be distributed via a distributed
ledger or a trusted central server. To prevent flooding attacks, the ledger or a trusted central server. To prevent flooding attacks, the
revocation message MUST contain a proof of work (PoW). The revocation message MUST contain a proof of work (PoW). The
revocation message including the PoW MAY be calculated ahead of time revocation message, including the PoW, MAY be calculated ahead of
to support timely revocation. time to support timely revocation.
For all occurrences below, "Argon2id" is the Password-based Key For all occurrences below, "Argon2id" is the password-based key
Derivation Function as defined in [RFC9106]. For the PoW derivation function as defined in [RFC9106]. For the PoW
calculations the algorithm is instantiated with the following calculations, the algorithm is instantiated with the following
parameters: parameters:
S The salt. Fixed 16-byte string: "GnsRevocationPow". S: The salt. Fixed 16-byte string: "GnsRevocationPow"
t Number of iterations: 3 t: Number of iterations: 3
m Memory size in KiB: 1024 m: Memory size in KiB: 1024
T Output length of hash in bytes: 64 T: Output length of hash in bytes: 64
p Parallelization parameter: 1 p: Parallelization parameter: 1
v Algorithm version: 0x13 v: Algorithm version: 0x13
y Algorithm type (Argon2id): 2 y: Algorithm type (Argon2id): 2
X Unused X: Unused
K Unused K: Unused
Figure 4 illustrates the format of the data "P" on which the PoW is Figure 4 illustrates the format of the data "P" on which the PoW is
calculated. calculated.
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| POW | | POW |
+-----------------------------------------------+ +-----------------------------------------------+
| TIMESTAMP | | TIMESTAMP |
+-----------------------------------------------+ +-----------------------------------------------+
| ZONE TYPE | ZONE KEY | | ZONE TYPE | ZONE KEY /
+-----+-----+-----+-----+ | +-----+-----+-----+-----+ /
/ / / /
/ / / /
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 4: The Format of the PoW Data. Figure 4: The Format of the PoW Data
POW A 64-bit value that is a solution to the PoW. In network byte POW: A 64-bit value that is a solution to the PoW. In network byte
order. order.
TIMESTAMP denotes the absolute 64-bit date when the revocation was TIMESTAMP: Denotes the absolute 64-bit date when the revocation was
computed. In microseconds since midnight (0 hour), January 1, computed. In microseconds since midnight (0 hour), January 1,
1970 UTC in network byte order. 1970 UTC in network byte order.
ZONE TYPE is the 32-bit zone type in network byte order. ZONE TYPE: The 32-bit zone type in network byte order.
ZONE KEY is the 256-bit public key zk of the zone which is being ZONE KEY: The 256-bit public key zkey of the zone that is being
revoked. The wire format of this value is defined by the ZONE revoked. The wire format of this value is defined by the ZONE
TYPE. TYPE.
Usually, PoW schemes require to find one POW value such that a Usually, PoW schemes require that one POW value be found, such that a
specific number of leading zeroes are found in the hash result. This specific number of leading zeroes are found in the hash result. This
number is then referred to as the difficulty of the PoW. In order to number is then referred to as the difficulty of the PoW. In order to
reduce the variance in time it takes to calculate the PoW, a valid reduce the variance in time it takes to calculate the PoW, a valid
GNS revocation requires that a number Z different PoWs must be found GNS revocation requires that a number of different PoWs (Z, as
that on average have D leading zeroes. defined below) must be found that on average have at least D leading
zeroes.
Given an average difficulty of D, the proofs have an expiration time Given an average difficulty of D, the proofs have an expiration time
of EPOCH. Applications MAY calculate proofs with a difficulty that of EPOCH. Applications MAY calculate proofs with a difficulty that
is higher than D by providing POW values where there are (on average) is higher than D by providing POW values where there are (on average)
more than D bits of leading zeros. With each additional bit of more than D bits of leading zeroes. With each additional bit of
difficulty, the lifetime of the proof is prolonged by another EPOCH. difficulty, the lifetime of the proof is prolonged by another EPOCH.
Consequently, by calculating a more difficult PoW, the lifetime of Consequently, by calculating a more difficult PoW, the lifetime of
the proof and thus the persistence of the revocation message can be the proof -- and thus the persistence of the revocation message --
increased on demand by the zone owner. can be increased on demand by the zone owner.
The parameters are defined as follows: The parameters are defined as follows:
Z The number of PoWs that are required. Its value is fixed at 32. Z: The number of PoWs that are required. Its value is fixed at 32.
D The lower limit of the average difficulty. Its value is fixed at D: The lower limit of the average difficulty. Its value is fixed at
22. 22.
EPOCH A single epoch. Its value is fixed at 365 days in EPOCH: A single epoch. Its value is fixed at 365 days in
microseconds. microseconds.
The revocation message wire format is illustrated in Figure 5. The revocation message wire format is illustrated in Figure 5.
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| TIMESTAMP | | TIMESTAMP |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| TTL | | TTL |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| POW_0 | | POW_0 |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| ... | | ... |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| POW_Z-1 | | POW_(Z-1) |
+-----------------------------------------------+ +-----------------------------------------------+
| ZONE TYPE | ZONE KEY | | ZONE TYPE | ZONE KEY /
+-----+-----+-----+-----+ | +-----+-----+-----+-----+ /
/ / / /
/ / / /
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| SIGNATURE | / SIGNATURE /
/ /
/ / / /
/ / / /
| |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 5: The Revocation Message Wire Format. Figure 5: The Revocation Message Wire Format
TIMESTAMP denotes the absolute 64-bit date when the revocation was TIMESTAMP: Denotes the absolute 64-bit date when the revocation was
computed. In microseconds since midnight (0 hour), January 1, computed. In microseconds since midnight (0 hour), January 1,
1970 UTC in network byte order. This is the same value as the 1970 UTC in network byte order. This is the same value as the
time stamp used in the individual PoW calculations. timestamp used in the individual PoW calculations.
TTL denotes the relative 64-bit time to live of the record in TTL: Denotes the relative 64-bit time to live of the record in
microseconds in network byte order. The field SHOULD be set to microseconds in network byte order. The field SHOULD be set to
EPOCH * 1.1. Given an average number of leading zeros D', then EPOCH * 1.1. Given an average number of leading zeroes D', then
the field value MAY be increased up to (D'-D+1) * EPOCH * 1.1. the field value MAY be increased up to (D'-D+1) * EPOCH * 1.1.
Validators MAY reject messages with lower or higher values when Validators MAY reject messages with lower or higher values when
received. received.
POW_i The values calculated as part of the PoW, in network byte 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 order. Each POW_i MUST be unique in the set of POW values. To
facilitate fast verification of uniqueness, the POW values must be facilitate fast verification of uniqueness, the POW values MUST be
given in strictly monotonically increasing order in the message. given in strictly monotonically increasing order in the message.
ZONE TYPE The 32-bit zone type corresponding to the zone key in ZONE TYPE: The 32-bit zone type corresponding to the zone key in
network byte order. network byte order.
ZONE KEY is the public key zk of the zone which is being revoked and ZONE KEY: The public key zkey of the zone that is being revoked and
the key to be used to verify SIGNATURE. the key to be used to verify SIGNATURE.
SIGNATURE A signature over a time stamp and the zone zk of the zone SIGNATURE: A signature over a timestamp and the zone zkey of the
which is revoked and corresponds to the key used in the PoW. The zone that is revoked and corresponds to the key used in the PoW.
signature is created using the Sign() function of the cryptosystem The signature is created using the Sign() function of the
of the zone and the private key (see Section 4). 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 signature in the revocation message covers a 32-bit header
the time stamp and public key fields. The header includes the key prefixed to the TIMESTAMP, ZONE TYPE, and ZONE KEY fields. The
length and signature purpose. The wire format is illustrated in header includes the key length and signature purpose. The wire
Figure 6. format is illustrated in Figure 6.
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| SIZE | PURPOSE (0x03) | | SIZE | PURPOSE (0x03) |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| TIMESTAMP | | TIMESTAMP |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| ZONE TYPE | ZONE KEY | | ZONE TYPE | ZONE KEY /
+-----+-----+-----+-----+ | +-----+-----+-----+-----+ /
/ / / /
/ / / /
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 6: The Wire Format of the Revocation Data for Signing. Figure 6: The Wire Format of the Revocation Data for Signing
SIZE A 32-bit value containing the length of the signed data in SIZE: A 32-bit value containing the length of the signed data in
bytes in network byte order. bytes in network byte order.
PURPOSE A 32-bit signature purpose flag. The value of this field PURPOSE: A 32-bit signature purpose flag. The value of this field
MUST be 3. The value is encoded in network byte order. It MUST be 3. The value is encoded in network byte order. It
defines the context in which the signature is created so that it defines the context in which the signature is created so that it
cannot be reused in other parts of the protocol including possible cannot be reused in other parts of the protocol that might include
future extensions. The value of this field corresponds to an possible future extensions. The value of this field corresponds
entry in the GANA "GNUnet Signature Purpose" registry [GANA]. to an entry in the GANA "GNUnet Signature Purposes" registry
[GANA].
TIMESTAMP Field as defined in the revocation message above. TIMESTAMP: Field as defined in the revocation message above.
ZONE TYPE 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. ZONE KEY: Field as defined in the revocation message above.
In order to validate a revocation the following steps MUST be taken: In order to validate a revocation, the following steps MUST be taken:
1. The signature MUST be verified against the zone key. 1. The signature MUST be verified against the zone key.
2. The set of POW values MUST NOT contain duplicates which MUST be 2. The set of POW values MUST NOT contain duplicates; this MUST be
checked by verifying that the values are strictly monotonically checked by verifying that the values are strictly monotonically
increasing. increasing.
3. The average number of leading zeroes D' resulting from the 3. The average number of leading zeroes D' resulting from the
provided POW values MUST be greater than or equal to D. provided POW values MUST be greater than or equal to D.
Implementers MUST NOT use an integer data type to calculate or Implementers MUST NOT use an integer data type to calculate or
represent D'. represent D'.
The TTL field in the revocation message is informational. A The TTL field in the revocation message is informational. A
revocation MAY be discarded without checking the POW values or the revocation MAY be discarded without checking the POW values or the
signature if the TTL (in combination with TIMESTAMP) indicates that signature if the TTL (in combination with TIMESTAMP) indicates that
the revocation has already expired. The actual validity period of the revocation has already expired. The actual validity period of
the revocation MUST be determined by examining the leading zeroes in the revocation MUST be determined by examining the leading zeroes in
the POW values. the POW values.
The validity period of the revocation is calculated as (D'-D+1) * The validity period of the revocation is calculated as (D'-D+1) *
EPOCH * 1.1. The EPOCH is extended by 10% in order to deal with EPOCH * 1.1. The EPOCH is extended by 10% in order to deal with
unsynchronized clocks. The validity period added on top of the poorly synchronized clocks. The validity period added on top of the
TIMESTAMP yields the expiration date. If the current time is after TIMESTAMP yields the expiration date. If the current time is after
the expiration date, the revocation is considered stale. the expiration date, the revocation is considered stale.
Verified revocations MUST be stored locally. The implementation MAY Verified revocations MUST be stored locally. The implementation MAY
discard stale revocations and evict then from the local store at any discard stale revocations and evict them from the local store at any
time. time.
Implementations MUST broadcast received revocations if they are valid It is important that implementations broadcast received revocations
and not stale. Should the calculated validity period differ from the if they are valid and not stale. Should the calculated validity
TTL field value, the calculated value MUST be used as TTL field value period differ from the TTL field value, the calculated value MUST be
when forwarding the revocation message. Systems might disagree on used as the TTL field value when forwarding the revocation message.
the current time, so implementations MAY use stale but otherwise Systems might disagree on the current time, so implementations MAY
valid revocations but SHOULD NOT broadcast them. Forwarded stale use stale but otherwise valid revocations but SHOULD NOT broadcast
revocations MAY be discarded. them. Forwarded stale revocations MAY be discarded by the receiver.
Any locally stored revocation MUST be considered during delegation Any locally stored revocation MUST be considered during delegation
record processing (see Section 7.3.4). record processing (see Section 7.3.4).
5. Resource Records 5. Resource Records
A GNS implementation SHOULD provide a mechanism to create and manage A GNS implementation SHOULD provide a mechanism for creating and
local zones as well as a persistence mechanism (such as a local managing local zones as well as a persistence mechanism (such as a
database) for resource records. A new local zone is established by local database) for resource records. A new local zone is
selecting a zone type and creating a zone key pair. If this established by selecting a zone type and creating a zone key pair.
mechanism is not implemented, no zones can be published in the If this mechanism is not implemented, no zones can be published in
storage (see Section 6) and name resolution is limited to non-local storage (see Section 6) and name resolution is limited to non-local
start zones (see Section 7.1). Start Zones (see Section 7.1).
A GNS resource record holds the data of a specific record in a zone. A GNS resource record holds the data of a specific record in a zone.
The resource record format is defined in Figure 7. The resource record format is illustrated in Figure 7.
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| EXPIRATION | | EXPIRATION |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| SIZE | FLAGS | TYPE | | SIZE | FLAGS | TYPE |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| DATA / | DATA /
/ / / /
/ / / /
Figure 7: The Resource Record Wire Format. Figure 7: The Resource Record Wire Format
EXPIRATION denotes the absolute 64-bit expiration date of the EXPIRATION: Denotes the absolute 64-bit expiration date of the
record. In microseconds since midnight (0 hour), January 1, 1970 record. In microseconds since midnight (0 hour), January 1, 1970
UTC in network byte order. UTC in network byte order.
SIZE denotes the 16-bit size of the DATA field in bytes in network SIZE: Denotes the 16-bit size of the DATA field in bytes in network
byte order. byte order.
FLAGS is a 16-bit bit field indicating special properties of the FLAGS: A 16-bit field indicating special properties of the resource
resource record. The semantics of the different bits are defined record. The semantics of the different bits are defined below.
below.
TYPE is the 32-bit resource record type in network byte order. This TYPE: The 32-bit resource record type in network byte order. This
type can be one of the GNS resource records as defined in 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 Section 5, a DNS record type as defined in [RFC1035], or any of
the complementary standardized DNS resource record types. Note the complementary standardized DNS resource record types. Note
that values below 2^16 are reserved for 16-bit DNS Resorce Record that values below 2^16 are reserved for 16-bit DNS resource record
types allocated by IANA [RFC6895]. Values above 2^16 are types allocated by IANA [RFC6895]. Values above 2^16 are
allocated by the GANA "GNS Record Types" registry [GANA]. allocated by the GANA "GNS Record Types" registry [GANA].
DATA the variable-length resource record data payload. The content DATA: The variable-length resource record data payload. The content
is defined by the respective type of the resource record. is defined by the respective type of the resource record.
The FLAGS field is used to indicate special properties of the The FLAGS field is used to indicate special properties of the
resource record. An application creating resource records MUST set resource record. An application creating resource records MUST set
all bits in FLAGS to 0 unless it specifically understands and wants all bits in FLAGS to 0 unless it specifically understands and wants
to set the respective flag. As additional flags can be defined in to set the respective flag. As additional flags can be defined in
future protocol versions, if an application or implementation future protocol versions, if an application or implementation
encounters a flag which it does not recognize, it MUST be ignored. encounters a flag that it does not recognize, the flag MUST be
However, all implementations MUST understand the SHADOW and CRITICAL ignored. However, all implementations MUST understand the SHADOW and
flags defined below. Any combination of the flags specified below CRITICAL flags defined below. Any combination of the flags specified
are valid. Figure 8 illustrates the flag distribution in the 16-bit below is valid. Figure 8 illustrates the flag distribution in the
FLAGS field of a resource record: 16-bit FLAGS field of a resource record:
0 13 14 15 0 13 14 15
+--------...+-------------+-------+---------+ +--------...+-------------+-------+---------+
| Reserved |SUPPLEMENTAL |SHADOW |CRITICAL | | Reserved |SUPPLEMENTAL |SHADOW |CRITICAL |
+--------...+-------------+-------+---------+ +--------...+-------------+-------+---------+
Figure 8: The Resource Record Flag Wire Format. Figure 8: The Resource Record Flag Wire Format
CRITICAL If this flag is set, it indicates that processing is CRITICAL: If this flag is set, it indicates that processing is
critical. Implementations that do not support the record type or critical. Implementations that do not support the record type or
are otherwise unable to process the record MUST abort resolution are otherwise unable to process the record MUST abort resolution
upon encountering the record in the resolution process. upon encountering the record in the resolution process.
SHADOW If this flag is set, this record MUST be ignored by resolvers SHADOW: If this flag is set, this record MUST be ignored by
unless all (other) records of the same record type have expired. resolvers unless all (other) records of the same record type have
Used to allow zone publishers to facilitate good performance when expired. Used to allow zone publishers to facilitate good
records change by allowing them to put future values of records performance when records change by allowing them to put future
into the storage. This way, future values can propagate and can values of records into storage. This way, future values can
be cached before the transition becomes active. propagate and can be cached before the transition becomes active.
SUPPLEMENTAL This is a supplemental record. It is provided in SUPPLEMENTAL: This is a supplemental record. It is provided in
addition to the other records. This flag indicates that this addition to the other records. This flag indicates that this
record is not explicitly managed alongside the other records under record is not explicitly managed alongside the other records under
the respective name but might be useful for the application. the respective name but might be useful for the application.
5.1. Zone Delegation Records 5.1. Zone Delegation Records
This section defines the initial set of zone delegation record types. This section defines the initial set of zone delegation record types.
Any implementation SHOULD support all zone types defined here and MAY Any implementation SHOULD support all zone types defined here and MAY
support any number of additional delegation records defined in the support any number of additional delegation records defined in the
GANA "GNS Record Types" registry (see [GANA]). Not supporting some GANA "GNS Record Types" registry (see [GANA]). Not supporting some
zone types will result in resolution failures in case the respective zone types will result in resolution failures if the respective zone
zone type is encountered. This can be a valid choice if some zone type is encountered. This can be a valid choice if some zone
delegation record types have been determined to be cryptographically delegation record types have been determined to be cryptographically
insecure. Zone delegation records MUST NOT be stored and published insecure. Zone delegation records MUST NOT be stored or published
under the apex label. A zone delegation record type value is the under the apex label. A zone delegation record type value is the
same as the respective ztype value. The ztype defines the same as the respective ztype value. The ztype defines the
cryptographic primitives for the zone that is being delegated to. A cryptographic primitives for the zone that is being delegated to. A
zone delegation record payload contains the public key of the zone to zone delegation record payload contains the public key of the zone to
delegate to. A zone delegation record MUST have the CRITICAL flag delegate to. A zone delegation record MUST have the CRITICAL flag
set and MUST be the only non-supplemental record under a label. set and MUST be the only non-supplemental record under a label.
There MAY be inactive records of the same type which have the SHADOW There MAY be inactive records of the same type that have the SHADOW
flag set in order to facilitate smooth key rollovers. flag set in order to facilitate smooth key rollovers.
In the following, "||" is the concatenation operator of two byte In the following, "||" is the concatenation operator of two byte
strings. The algorithm specification uses character strings such as strings. The algorithm specification uses character strings such as
GNS labels or constant values. When used in concatenations or as GNS labels or constant values. When used in concatenations or as
input to functions the null-terminator of the character strings MUST input to functions, the zero terminator of the character strings MUST
NOT be included. NOT be included.
5.1.1. PKEY 5.1.1. PKEY
In GNS, a delegation of a label to a zone of type "PKEY" is In GNS, a delegation of a label to a zone of type "PKEY" is
represented through a PKEY record. The PKEY DATA entry wire format represented through a PKEY record. The PKEY DATA entry wire format
can be found in Figure 9. is illustrated in Figure 9.
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| PUBLIC KEY | | PUBLIC KEY |
| | | |
| | | |
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 9: The PKEY Wire Format. Figure 9: The PKEY Wire Format
PUBLIC KEY A 256-bit Ed25519 public key. PUBLIC KEY: A 256-bit Ed25519 public key.
For PKEY zones the zone key material is derived using the curve For PKEY zones, the zone key material is derived using the curve
parameters of the twisted Edwards representation of Curve25519 parameters of the twisted Edwards representation of Curve25519
[RFC7748] (the reasoning behind choosing this curve can be found in [RFC7748] (the reasoning behind choosing this curve can be found in
Section 9.3) with the ECDSA scheme [RFC6979]. The following naming Section 9.3) with the ECDSA scheme [RFC6979]. The following naming
convention is used for the cryptographic primitives of PKEY zones: convention is used for the cryptographic primitives of PKEY zones:
d is a 256-bit Ed25519 private key (private scalar). d: A 256-bit Ed25519 private key (clamped private scalar).
zk is the Ed25519 public zone key corresponding to d. zkey: The Ed25519 public zone key corresponding to d.
p is the prime of edwards25519 as defined in [RFC7748], i.e. 2^255 p: The prime of edwards25519 as defined in [RFC7748], i.e., 2^255 -
- 19. 19.
G is the group generator (X(P),Y(P)). With X(P),Y(P) of G: The group generator (X(P),Y(P)). With X(P),Y(P) of edwards25519
edwards25519 as defined in [RFC7748]. as defined in [RFC7748].
L is the order of the prime-order subgroup of edwards25519 in L: The order of the prime-order subgroup of edwards25519 as defined
[RFC7748]. in [RFC7748].
KeyGen() The generation of the private scalar d and the curve point 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) zkey := d*G (where G is the group generator of the elliptic curve)
as defined in Section 2.2. of [RFC6979] represents the KeyGen() as defined in Section 2.2 of [RFC6979] represents the KeyGen()
function. function.
The zone type and zone key of a PKEY are 4 + 32 bytes in length. 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 This means that a zTLD will always fit into a single label and does
not need any further conversion. Given a label, the output zk' of not need any further conversion. Given a label, the output zkey' of
the ZKDF(zk,label) function is calculated as follows for PKEY zones: the ZKDF(zkey, label) function is calculated as follows for PKEY
zones:
ZKDF(zk,label): ZKDF(zkey, label):
PRK_h := HKDF-Extract ("key-derivation", zk) PRK_h := HKDF-Extract("key-derivation", zkey)
h := HKDF-Expand (PRK_h, label || "gns", 512 / 8) h := HKDF-Expand(PRK_h, label || "gns", 512 / 8)
zk' := (h mod L) * zk zkey' := (h mod L) * zkey
return zk' return zkey'
The PKEY cryptosystem uses a hash-based key derivation function The PKEY cryptosystem uses an HMAC-based key derivation function
(HKDF) as defined in [RFC5869], using SHA-512 [RFC6234] for the (HKDF) as defined in [RFC5869], using SHA-512 [RFC6234] for the
extraction phase and SHA-256 [RFC6234] for the expansion phase. extraction phase and SHA-256 [RFC6234] for the expansion phase.
PRK_h is key material retrieved using an HKDF using the string "key- PRK_h is key material retrieved using an HKDF that uses the string
derivation" as salt and the zone key as initial keying material. h "key-derivation" as the salt and the zone key as the initial keying
is the 512-bit HKDF expansion result and must be interpreted in material. h is the 512-bit HKDF expansion result and must be
network byte order. The expansion information input is a interpreted in network byte order. The expansion information input
concatenation of the label and the string "gns". The multiplication is a concatenation of the label and the string "gns". The
of zk with h is a point multiplication, while the multiplication of d multiplication of zkey with h in ZKDF() is a point multiplication,
with h is a scalar multiplication. while the multiplication of d with h in SignDerived() below is a
scalar multiplication.
The Sign() and Verify() functions for PKEY zones are implemented The Sign() and Verify() functions for PKEY zones are implemented
using 512-bit ECDSA deterministic signatures as specified in using 512-bit ECDSA deterministic signatures as specified in
[RFC6979]. The same functions can be used for derived keys: [RFC6979]. The same functions can be used for derived keys:
SignDerived(d,label,message): SignDerived(d, label, message):
zk := d * G zkey := d * G
PRK_h := HKDF-Extract ("key-derivation", zk) PRK_h := HKDF-Extract("key-derivation", zkey)
h := HKDF-Expand (PRK_h, label || "gns", 512 / 8) h := HKDF-Expand(PRK_h, label || "gns", 512 / 8)
d' := (h * d) mod L d' := (h * d) mod L
return Sign(d',message) return Sign(d', message)
A signature (R,S) is valid if the following holds: A signature is valid for the derived public key zkey' := ZKDF(zkey,
label) if the following holds:
VerifyDerived(zk,label,message,signature): VerifyDerived(zkey', message, signature):
zk' := ZKDF(zk,label) return Verify(zkey', message, signature)
return Verify(zk',message,signature)
The S-Encrypt() and S-Decrypt() functions use AES in counter mode as The S-Encrypt() and S-Decrypt() functions use AES in counter mode as
defined in [MODES] (CTR-AES-256): defined in [MODES] (CTR-AES256):
S-Encrypt(zk,label,expiration,plaintext): S-Encrypt(zkey, label, expiration, plaintext):
PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk) PRK_k := HKDF-Extract("gns-aes-ctx-key", zkey)
PRK_n := HKDF-Extract ("gns-aes-ctx-iv", zk) PRK_n := HKDF-Extract("gns-aes-ctx-iv", zkey)
K := HKDF-Expand (PRK_k, label, 256 / 8) K := HKDF-Expand(PRK_k, label, 256 / 8)
NONCE := HKDF-Expand (PRK_n, label, 32 / 8) NONCE := HKDF-Expand(PRK_n, label, 32 / 8)
IV := NONCE || expiration || 0x0000000000000001 BLOCK_COUNTER := 0x0000000000000001
IV := NONCE || expiration || BLOCK_COUNTER
return CTR-AES256(K, IV, plaintext) return CTR-AES256(K, IV, plaintext)
S-Decrypt(zk,label,expiration,ciphertext): S-Decrypt(zkey, label, expiration, ciphertext):
PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk) PRK_k := HKDF-Extract("gns-aes-ctx-key", zkey)
PRK_n := HKDF-Extract ("gns-aes-ctx-iv", zk) PRK_n := HKDF-Extract("gns-aes-ctx-iv", zkey)
K := HKDF-Expand (PRK_k, label, 256 / 8) K := HKDF-Expand(PRK_k, label, 256 / 8)
NONCE := HKDF-Expand (PRK_n, label, 32 / 8) NONCE := HKDF-Expand(PRK_n, label, 32 / 8)
IV := NONCE || expiration || 0x0000000000000001 BLOCK_COUNTER := 0x0000000000000001
IV := NONCE || expiration || BLOCK_COUNTER
return CTR-AES256(K, IV, ciphertext) return CTR-AES256(K, IV, ciphertext)
The key K and counter IV are derived from the record label and the The key K and counter Initialization Vector (IV) are derived from the
zone key zk using a hash-based key derivation function (HKDF) as record label and the zone key zkey, using an HKDF as defined in
defined in [RFC5869]. SHA-512 [RFC6234] is used for the extraction [RFC5869]. SHA-512 [RFC6234] is used for the extraction phase and
phase and SHA-256 [RFC6234] for the expansion phase. The output SHA-256 [RFC6234] for the expansion phase. The output keying
keying material is 32 bytes (256 bits) for the symmetric key and 4 material is 32 bytes (256 bits) for the symmetric key and 4 bytes (32
bytes (32 bits) for the nonce. The symmetric key K is a 256-bit AES bits) for the NONCE. The symmetric key K is a 256-bit AES key
[RFC3826] key. [RFC3826].
The nonce is combined with a 64-bit initialization vector and a The nonce is combined with a 64-bit IV and a 32-bit block counter as
32-bit block counter as defined in [RFC3686]. The block counter defined in [RFC3686]. The block counter begins with a value of 1,
begins with the value of 1, and it is incremented to generate and it is incremented to generate subsequent portions of the key
subsequent portions of the key stream. The block counter is a 32-bit stream. The block counter is a 32-bit integer value in network byte
integer value in network byte order. The initialization vector is order. The format of the counter IV used by the S-Encrypt() and
the expiration time of the resource record block in network byte S-Decrypt() functions is illustrated in Figure 10.
order. The resulting counter (IV) wire format can be found in
Figure 10.
0 8 16 24 32 0 8 16 24 32
+-----+-----+-----+-----+ +-----+-----+-----+-----+
| NONCE | | NONCE |
+-----+-----+-----+-----+ +-----+-----+-----+-----+
| EXPIRATION | | EXPIRATION |
| | | |
+-----+-----+-----+-----+ +-----+-----+-----+-----+
| BLOCK COUNTER | | BLOCK COUNTER |
+-----+-----+-----+-----+ +-----+-----+-----+-----+
Figure 10: The Block Counter Wire Format. Figure 10: Structure of the Counter IV as Used in S-Encrypt() and
S-Decrypt()
5.1.2. EDKEY 5.1.2. EDKEY
In GNS, a delegation of a label to a zone of type "EDKEY" is In GNS, a delegation of a label to a zone of type "EDKEY" is
represented through a EDKEY record. The EDKEY DATA entry wire format represented through an EDKEY record. The EDKEY DATA entry wire
is illustrated in Figure 11. format is illustrated in Figure 11.
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| PUBLIC KEY | | PUBLIC KEY |
| | | |
| | | |
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 11: The EDKEY DATA Wire Format. Figure 11: The EDKEY DATA Wire Format
PUBLIC KEY A 256-bit EdDSA zone key. PUBLIC KEY: A 256-bit EdDSA zone key.
For EDKEY zones the zone key material is derived using the curve For EDKEY zones, the zone key material is derived using the curve
parameters of the twisted edwards representation of Curve25519 parameters of the twisted Edwards representation of Curve25519
[RFC7748] (a.k.a. Ed25519) with the Ed25519 scheme [ed25519] as [RFC7748] (a.k.a. Ed25519) with the Ed25519 scheme [ed25519] as
specified in [RFC8032]. The following naming convention is used for specified in [RFC8032]. The following naming convention is used for
the cryptographic primitives of EDKEY zones: the cryptographic primitives of EDKEY zones:
d is a 256-bit EdDSA private key. d: A 256-bit EdDSA private key.
a is is an integer derived from d using the SHA-512 hash function as a: An integer derived from d using the SHA-512 hash function as
defined in [RFC8032]. defined in [RFC8032].
zk is the EdDSA public key corresponding to d. It is defined as the zkey: 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 point a*G where G is the group generator of the elliptic
curve as defined in [RFC8032]. curve as defined in [RFC8032].
p is the prime of edwards25519 as defined in [RFC8032], i.e. 2^255 p: The prime of edwards25519 as defined in [RFC8032], i.e., 2^255 -
- 19. 19.
G is the group generator (X(P),Y(P)). With X(P),Y(P) of G: The group generator (X(P),Y(P)). With X(P),Y(P) of edwards25519
edwards25519 as defined in [RFC8032]. as defined in [RFC8032].
L is the order of the prime-order subgroup of edwards25519 in L: The order of the prime-order subgroup of edwards25519 as defined
[RFC8032]. in [RFC8032].
KeyGen() The generation of the private key d and the associated KeyGen(): The generation of the private key d and the associated
public key zk := a*G where G is the group generator of the public key zkey := a*G (where G is the group generator of the
elliptic curve and a is an integer derived from d using the 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] SHA-512 hash function) as defined in Section 5.1.5 of [RFC8032]
represents the KeyGen() function. represents the KeyGen() function.
The zone type and zone key of an EDKEY are 4 + 32 bytes in length. 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 This means that a zTLD will always fit into a single label and does
not need any further conversion. not need any further conversion.
The "EDKEY" ZKDF instantiation is based on [Tor224]. The calculation The "EDKEY" ZKDF instantiation is based on [Tor224]. As noted above
of a is defined in Section 5.1.5 of [RFC8032]. Given a label, the for KeyGen(), a is calculated from d using the SHA-512 hash function
output of the ZKDF function is calculated as follows: as defined in Section 5.1.5 of [RFC8032]. Given a label, the output
of the ZKDF function is calculated as follows:
ZKDF(zk,label): ZKDF(zkey, label):
/* Calculate the blinding factor */ /* Calculate the blinding factor */
PRK_h := HKDF-Extract ("key-derivation", zk) PRK_h := HKDF-Extract("key-derivation", zkey)
h := HKDF-Expand (PRK_h, label || "gns", 512 / 8) h := HKDF-Expand(PRK_h, label || "gns", 512 / 8)
/* Ensure that h == h mod L */ /* Ensure that h == h mod L */
h[31] &= 7 h := h mod L
zk' := h * zk zkey' := h * zkey
return zk' return zkey'
Implementers SHOULD employ a constant time scalar multiplication for Implementers SHOULD employ a constant-time scalar multiplication for
the constructions above to protect against timing attacks. the constructions above to protect against timing attacks.
Otherwise, timing attacks could leak private key material if an Otherwise, timing attacks could leak private key material if an
attacker can predict when a system starts the publication process. attacker can predict when a system starts the publication process.
The EDKEY cryptosystem uses a hash-based key derivation function The EDKEY cryptosystem uses an HKDF as defined in [RFC5869], using
(HKDF) as defined in [RFC5869], using SHA-512 [RFC6234] for the SHA-512 [RFC6234] for the extraction phase and HMAC-SHA-256 [RFC6234]
extraction phase and HMAC-SHA256 [RFC6234] for the expansion phase. for the expansion phase. PRK_h is key material retrieved using an
PRK_h is key material retrieved using an HKDF using the string "key- HKDF that uses the string "key-derivation" as the salt and the zone
derivation" as salt and the zone key as initial keying material. The key as the initial keying material. The blinding factor h is the
blinding factor h is the 512-bit HKDF expansion result. The 512-bit HKDF expansion result. The expansion information input is a
expansion information input is a concatenation of the label and the concatenation of the label and the string "gns". The result of the
string "gns". The result of the HKDF must be clamped and interpreted HKDF must be clamped and interpreted in network byte order. a is the
in network byte order. a is the 256-bit integer corresponding to the 256-bit integer corresponding to the 256-bit private key d. The
256-bit private key d. The multiplication of zk with h is a point multiplication of zkey with h is a point multiplication.
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 The Sign(d, message) and Verify(zkey, message, signature) procedures
be implemented as defined in [RFC8032]. MUST be implemented as defined in [RFC8032].
Signatures for EDKEY zones use a derived private scalar d' which is Signatures for EDKEY zones use a derived private scalar d'; this is
not compliant with [RFC8032]. As the corresponding private key to not compliant with [RFC8032]. As the private key that corresponds to
the derived private scalar is not known, it is not possible to the derived private scalar is not known, it is not possible to
deterministically derive the signature part R according to [RFC8032]. deterministically derive the signature part R according to [RFC8032].
Instead, signatures MUST be generated as follows for any given Instead, signatures MUST be generated as follows for any given
message and private zone key: A nonce is calculated from the highest 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 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, factor h. The nonce is then hashed with the message to r. This way,
the full derivation path is included in the calculation of the R the full derivation path is included in the calculation of the R
value of the signature, ensuring that it is never reused for two value of the signature, ensuring that it is never reused for two
different derivation paths or messages. different derivation paths or messages.
SignDerived(d,label,message): SignDerived(d, label, message):
/* Key expansion */ /* Key expansion */
dh := SHA-512 (d) dh := SHA-512(d)
/* EdDSA clamping */ /* EdDSA clamping */
a := dh[0..31] a := dh[0..31]
a[0] &= 248 a[0] := a[0] & 248
a[31] &= 127 a[31] := a[31] & 127
a[31] |= 64 a[31] := a[31] | 64
/* Calculate zk corresponding to d */ /* Calculate zkey corresponding to d */
zk := a * G zkey := a * G
/* Calculate blinding factor */ /* Calculate blinding factor */
PRK_h := HKDF-Extract ("key-derivation", zk) PRK_h := HKDF-Extract("key-derivation", zkey)
h := HKDF-Expand (PRK_h, label || "gns", 512 / 8) h := HKDF-Expand(PRK_h, label || "gns", 512 / 8)
/* Ensure that h == h mod L */ /* Ensure that h == h mod L */
h[31] &= 7 h := h mod L
zk' := h * zk d' := (h * a) mod L
a1 := a >> 3 nonce := SHA-256(dh[32..63] || h)
a2 := (h * a1) mod L r := SHA-512(nonce || message)
d' := a2 << 3
nonce := SHA-256 (dh[32..63] || h)
r := SHA-512 (nonce || message)
R := r * G R := r * G
S := r + SHA-512(R || zk' || message) * d' mod L S := r + SHA-512(R || zkey' || message) * d' mod L
return (R,S) return (R,S)
A signature (R,S) is valid if the following holds: A signature (R,S) is valid for the derived public key zkey' :=
ZKDF(zkey, label) if the following holds:
VerifyDerived(zk,label,message,signature): VerifyDerived(zkey', message, signature):
zk' := ZKDF(zk,label)
(R,S) := signature (R,S) := signature
return S * G == R + SHA-512(R, zk', message) * zk' return S * G == R + SHA-512(R, zkey', message) * zkey'
The S-Encrypt() and S-Decrypt() functions use XSalsa20 as defined in The S-Encrypt() and S-Decrypt() functions use XSalsa20 as defined in
[XSalsa20] (XSalsa20-Poly1305): [XSalsa20] and use the XSalsa20-Poly1305 encryption function:
S-Encrypt(zk,label,expiration,plaintext): S-Encrypt(zkey, label, expiration, plaintext):
PRK_k := HKDF-Extract ("gns-xsalsa-ctx-key", zk) PRK_k := HKDF-Extract("gns-xsalsa-ctx-key", zkey)
PRK_n := HKDF-Extract ("gns-xsalsa-ctx-iv", zk) PRK_n := HKDF-Extract("gns-xsalsa-ctx-iv", zkey)
K := HKDF-Expand (PRK_k, label, 256 / 8) K := HKDF-Expand(PRK_k, label, 256 / 8)
NONCE := HKDF-Expand (PRK_n, label, 128 / 8) NONCE := HKDF-Expand(PRK_n, label, 128 / 8)
IV := NONCE || expiration IV := NONCE || expiration
return XSalsa20-Poly1305(K, IV, plaintext) return XSalsa20-Poly1305(K, IV, plaintext)
S-Decrypt(zk,label,expiration,ciphertext): S-Decrypt(zkey, label, expiration, ciphertext):
PRK_k := HKDF-Extract ("gns-xsalsa-ctx-key", zk) PRK_k := HKDF-Extract("gns-xsalsa-ctx-key", zkey)
PRK_n := HKDF-Extract ("gns-xsalsa-ctx-iv", zk) PRK_n := HKDF-Extract("gns-xsalsa-ctx-iv", zkey)
K := HKDF-Expand (PRK_k, label, 256 / 8) K := HKDF-Expand(PRK_k, label, 256 / 8)
NONCE := HKDF-Expand (PRK_n, label, 128 / 8) NONCE := HKDF-Expand(PRK_n, label, 128 / 8)
IV := NONCE || expiration IV := NONCE || expiration
return XSalsa20-Poly1305(K, IV, ciphertext) return XSalsa20-Poly1305(K, IV, ciphertext)
The result of the XSalsa20-Poly1305 encryption function is the The result of the XSalsa20-Poly1305 encryption function is the
encrypted ciphertext followed by the 128-bit authentication tag. encrypted ciphertext followed by the 128-bit authentication tag.
Accordingly, the length of encrypted data equals the length of the Accordingly, the length of encrypted data equals the length of the
data plus the 16 bytes of the authentication tag. data plus the 16 bytes of the authentication tag.
The key K and counter IV are derived from the record label and the 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 zone key zkey using an HKDF as defined in [RFC5869]. SHA-512
defined in [RFC5869]. SHA-512 [RFC6234] is used for the extraction [RFC6234] is used for the extraction phase and SHA-256 [RFC6234] for
phase and SHA-256 [RFC6234] for the expansion phase. The output the expansion phase. The output keying material is 32 bytes (256
keying material is 32 bytes (256 bits) for the symmetric key and 16 bits) for the symmetric key and 16 bytes (128 bits) for the NONCE.
bytes (128 bits) for the NONCE. The symmetric key K is a 256-bit The symmetric key K is a 256-bit XSalsa20 key [XSalsa20]. No
XSalsa20 [XSalsa20] key. No additional authenticated data (AAD) is additional authenticated data (AAD) is used.
used.
The nonce is combined with an 8 byte initialization vector. The The nonce is combined with an 8-byte IV. The IV is the expiration
initialization vector is the expiration time of the resource record time of the resource record block in network byte order. The
block in network byte order. The resulting counter (IV) wire format resulting counter (IV) wire format is illustrated in Figure 12.
is illustrated in Figure 12.
0 8 16 24 32 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| NONCE | | NONCE |
| | | |
| | +-----+-----+-----+-----+-----+-----+-----+-----+
| | | EXPIRATION |
+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| EXPIRATION |
| |
+-----+-----+-----+-----+
Figure 12: The Counter Block Initialization Vector. Figure 12: The Counter Block Initialization Vector
5.2. Redirection Records 5.2. Redirection Records
Redirect records are used to redirect resolution. Any implementation Redirection records are used to redirect resolution. Any
SHOULD support all redirection record types defined here and MAY implementation SHOULD support all redirection record types defined
support any number of additional redirection records defined in the here and MAY support any number of additional redirection records
GANA "GNS Record Types" registry [GANA]. Redirection records MUST defined in the GANA "GNS Record Types" registry [GANA]. Redirection
have the CRITICAL flag set. Not supporting some record types can records MUST have the CRITICAL flag set. Not supporting some record
result in resolution failures. This can be a valid choice if some types can result in resolution failures. This can be a valid choice
redirection record types have been determined to be insecure, or if if some redirection record types have been determined to be insecure,
an application has reasons to not support redirection to DNS for or if an application has reasons to not support redirection to DNS
reasons such as complexity or security. Redirection records MUST NOT for reasons such as complexity or security. Redirection records MUST
be stored and published under the apex label. NOT be stored or published under the apex label.
5.2.1. REDIRECT 5.2.1. REDIRECT
A REDIRECT record is the GNS equivalent of a CNAME record in DNS. A A REDIRECT record is the GNS equivalent of a CNAME record in DNS. A
REDIRECT record MUST be the only non-supplemental record under a REDIRECT record MUST be the only non-supplemental record under a
label. There MAY be inactive records of the same type which have the label. There MAY be inactive records of the same type that have the
SHADOW flag set in order to facilitate smooth changes of redirection SHADOW flag set in order to facilitate smooth changes of redirection
targets. No other records are allowed. Details on processing of targets. No other records are allowed. Details on the processing of
this record is defined in Section 7.3.1. A REDIRECT DATA entry is this record are provided in Section 7.3.1. A REDIRECT DATA entry is
illustrated in Figure 13. illustrated in Figure 13.
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| REDIRECT NAME | | REDIRECT NAME |
/ / / /
/ / / /
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 13: The REDIRECT DATA Wire Format. Figure 13: The REDIRECT DATA Wire Format
REDIRECT NAME The name to continue with. The value of a redirect REDIRECT NAME: The name to continue with. This value can be a
record can be a regular name, or a relative name. Relative GNS regular name or a relative name. Relative GNS names are indicated
names are indicated by an extension label (U+002B, "+") as by an extension label (U+002B ("+")) as the rightmost label. The
rightmost label. The string is UTF-8 encoded and 0-terminated. string is UTF-8 encoded and zero terminated.
5.2.2. GNS2DNS 5.2.2. GNS2DNS
A GNS2DNS record delegates resolution to DNS. The resource record A GNS2DNS record delegates resolution to DNS. The resource record
contains a DNS name for the resolver to continue with in DNS followed 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] 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. 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 There MAY also be DNSSEC DS records or any other records used to
secure the connection with the DNS servers under the same label. secure the connection with the DNS servers under the same label.
There MAY be inactive records of the same type(s) which have the There MAY be inactive records of the same type or types that have the
SHADOW flag set in order to facilitate smooth changes of redirection SHADOW flag set in order to facilitate smooth changes of redirection
targets. No other non-supplemental record types are allowed in the targets. No other non-supplemental record types are allowed in the
same record set. A GNS2DNS DATA entry is illustrated in Figure 14. same record set. A GNS2DNS DATA entry is illustrated in Figure 14.
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| NAME | | NAME |
/ / / /
/ / / /
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| DNS SERVER NAME | | DNS SERVER NAME |
/ / / /
/ / / /
| | | |
+-----------------------------------------------+ +-----------------------------------------------+
Figure 14: The GNS2DNS DATA Wire Format. Figure 14: The GNS2DNS DATA Wire Format
NAME The name to continue with in DNS. The value is UTF-8 encoded NAME: The name to continue with in DNS. The value is UTF-8 encoded
and 0-terminated. and zero terminated.
DNS SERVER NAME The DNS server to use. This value can be an IPv4 DNS SERVER NAME: The DNS server to use. This value can be an IPv4
address in dotted-decimal form or an IPv6 address in colon- address in dotted-decimal form, an IPv6 address in colon-
hexadecimal form or a DNS name. It can also be a relative GNS hexadecimal form, or a DNS name. It can also be a relative GNS
name ending with a "+" as the rightmost label. The implementation name ending with a "+" as the rightmost label. The implementation
MUST check the string syntactically for an IP address in the MUST check the string syntactically for an IP address in the
respective notation before checking for a relative GNS name. If respective notation before checking for a relative GNS name. If
all three checks fail, the name MUST be treated as a DNS name. all three checks fail, the name MUST be treated as a DNS name.
The value is UTF-8 encoded and 0-terminated. The value is UTF-8 encoded and zero terminated.
NOTE: If an application uses DNS names obtained from GNS2DNS records NOTE: If an application uses DNS names obtained from GNS2DNS records
in a DNS request they MUST first be converted to an IDNA compliant in a DNS request, they MUST first be converted to an IDNA-compliant
representation [RFC5890]. representation [RFC5890].
5.3. Auxiliary Records 5.3. Auxiliary Records
This section defines the initial set of auxiliary GNS record types. This section defines the initial set of auxiliary GNS record types.
Any implementation SHOULD be able to process the specified record Any implementation SHOULD be able to process the specified record
types according to Section 7.3. types according to Section 7.3.
5.3.1. LEHO 5.3.1. LEHO
This record is used to provide a hint for LEgacy HOstnames: The LEHO (LEgacy HOstname) record is used to provide a hint for
Applications can use the GNS to lookup IPv4 or IPv6 addresses of legacy hostnames: applications can use the GNS to look up IPv4 or
internet services. However, sometimes connecting to such services IPv6 addresses of Internet services. However, connecting to such
does not only require the knowledge of an address and port, but also services sometimes not only requires the knowledge of an IP address
requires the canonical DNS name of the service to be transmitted over and port but also requires the canonical DNS name of the service to
the transport protocol. In GNS, legacy host name records provide be transmitted over the transport protocol. In GNS, legacy hostname
applications the DNS name that is required to establish a connection records provide applications the DNS name that is required to
to such a service. The most common use case is HTTP virtual hosting establish a connection to such a service. The most common use case
and TLS Server Name Indication [RFC6066], where a DNS name must be is HTTP virtual hosting and TLS Server Name Indication [RFC6066],
supplied in the HTTP "Host"-header and the TLS handshake, where a DNS name must be supplied in the HTTP "Host"-header and the
respectively. Using a GNS name in those cases might not work as it TLS handshake, respectively. Using a GNS name in those cases might
might not be globally unique. Furthermore, even if uniqueness is not not work, as it might not be globally unique. Furthermore, even if
an issue, the legacy service might not even be aware of GNS. 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 A LEHO resource record is expected to be found together with A or
resource record with an IPv4 or IPv6 address. A LEHO DATA entry is AAAA resource records with IPv4 or IPv6 addresses. A LEHO DATA entry
illustrated in Figure 15. is illustrated in Figure 15.
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| LEGACY HOSTNAME | | LEGACY HOSTNAME |
/ / / /
/ / / /
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 15: The LEHO DATA Wire Format. Figure 15: The LEHO DATA Wire Format
LEGACY HOSTNAME A UTF-8 string (which is not 0-terminated) LEGACY HOSTNAME: A UTF-8 string (which is not zero terminated)
representing the legacy hostname. representing the legacy hostname.
NOTE: If an application uses a LEHO value in an HTTP request header NOTE: If an application uses a LEHO value in an HTTP request header
(e.g. "Host:" header) it MUST be converted to an IDNA compliant (e.g., a "Host"-header), it MUST be converted to an IDNA-compliant
representation [RFC5890]. representation [RFC5890].
5.3.2. NICK 5.3.2. NICK
Nickname records can be used by zone administrators to publish a Nickname records can be used by zone administrators to publish a
label that a zone prefers to have used when it is referred to. This 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 is a suggestion for other zones regarding what label to use when
delegation record (Section 5.1) containing this zone key. This creating a delegation record (Section 5.1) containing this zone key.
record SHOULD only be stored locally under the apex label "@" but MAY This record SHOULD only be stored locally under the apex label "@"
be returned with record sets under any label as a supplemental but MAY be returned with record sets under any label as a
record. Section 7.3.5 details how a resolver must process supplemental record. Section 7.3.5 details how a resolver must
supplemental and non-supplemental NICK records. A NICK DATA entry is process supplemental and non-supplemental NICK records. A NICK DATA
illustrated in Figure 16. entry is illustrated in Figure 16.
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| NICKNAME | | NICKNAME |
/ / / /
/ / / /
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 16: The NICK DATA Wire Format.
NICKNAME A UTF-8 string (which is not 0-terminated) representing the Figure 16: The NICK DATA Wire Format
preferred label of the zone. This string MUST be a valid GNS
NICKNAME: A UTF-8 string (which is not zero terminated) representing
the preferred label of the zone. This string MUST be a valid GNS
label. label.
5.3.3. BOX 5.3.3. BOX
GNS lookups are expected to return all of the required useful GNS lookups are expected to return all of the required useful
information in one record set. This avoids unnecessary additional information in one record set. This avoids unnecessary additional
lookups and cryptographically ties together information that belongs lookups and cryptographically ties together information that belongs
together, making it impossible for an adversarial storage to provide together, making it impossible for an adversarial storage entity to
partial answers that might omit information critical for security. provide partial answers that might omit information critical for
security.
This general strategy is incompatible with the special labels used by This general strategy is incompatible with the special labels used by
DNS for SRV and TLSA records. Thus, GNS defines the BOX record 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 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 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 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 of "example.org" as a BOX record with service (SVC) 443 (https),
protocol (PROTO) 6 (tcp) and record TYPE "TLSA". For reference, see protocol (PROTO) 6 (tcp), and record TYPE "TLSA". For reference, see
also [RFC2782]. A BOX DATA entry is illustrated in Figure 17. also [RFC2782]. A BOX DATA entry is illustrated in Figure 17.
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| PROTO | SVC | TYPE | | PROTO | SVC | TYPE |
+-----------+-----------------------------------+ +-----------+-----------------------------------+
| RECORD DATA | | RECORD DATA |
/ / / /
/ / / /
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 17: The BOX DATA Wire Format. Figure 17: The BOX DATA Wire Format
PROTO the 16-bit protocol number in network byte order. Values PROTO: The 16-bit protocol number in network byte order. Values
below 2^8 are reserved for 8-bit Internet Protocol numbers below 2^8 are reserved for 8-bit Internet Protocol numbers
allocated by IANA [RFC5237] (e.g. 6 for TCP). Values above 2^8 allocated by IANA [RFC5237] (e.g., 6 for TCP). Values above 2^8
are allocated by the GANA "Overlay Protocols" registry [GANA]. are allocated by the GANA "GNUnet Overlay Protocols" registry
[GANA].
SVC the 16-bit service value of the boxed record in network byte SVC: The 16-bit service value of the boxed record in network byte
order. In case of TCP and UDP it is the port number. order. In the case of TCP and UDP, it is the port number.
TYPE is the 32-bit record type of the boxed record in network byte TYPE: The 32-bit record type of the boxed record in network byte
order. order.
RECORD DATA is a variable length field containing the "DATA" format RECORD DATA: A variable-length field containing the "DATA" format of
of TYPE as defined for the respective TYPE. Thus, for TYPE values TYPE as defined for the respective TYPE. Thus, for TYPE values
below 2^16, the format is the same as the respective record type's below 2^16, the format is the same as the respective record type's
binary format in DNS. binary format in DNS.
6. Record Encoding for Remote Storage 6. Record Encoding for Remote Storage
Any API which allows storing a block under a 512-bit key and Any API that allows storing a block under a 512-bit key and
retrieving one or more blocks from a key can be used by an retrieving one or more blocks from a key can be used by an
implementation for remote storage. To be useful, the API MUST permit implementation for remote storage. To be useful, and to be able to
storing at least 176 byte blocks to be able to support the defined support the defined zone delegation record encodings, the API MUST
zone delegation record encodings, and SHOULD allow at least 1024 byte permit storing blocks of size 176 bytes or more and SHOULD allow
blocks. In the following, it is assumed that an implementation blocks of size 1024 bytes or more. In the following, it is assumed
realizes two procedures on top of a storage: that an implementation realizes two procedures on top of storage:
PUT(key,block) PUT(key, block)
GET(key) -> block GET(key) -> block
A GNS implementation publishes blocks in accordance to the properties A GNS implementation publishes blocks in accordance with the
and recommendations of the underlying remote storage. This can properties and recommendations of the underlying remote storage.
include a periodic refresh operation to preserve the availability of This can include a periodic refresh operation to preserve the
published blocks. availability of published blocks.
There is no mechanism to explicitly delete individual blocks from There is no mechanism for explicitly deleting individual blocks from
remote storage. However, blocks include an EXPIRATION field which remote storage. However, blocks include an EXPIRATION field, which
guides remote storage implementations to decide when to delete guides remote storage implementations to decide when to delete
blocks. Given multiple blocks for the same key, remote storage blocks. Given multiple blocks for the same key, remote storage
implementations SHOULD try to preserve and return the block with the implementations SHOULD try to preserve and return the block with the
largest EXPIRATION value. largest EXPIRATION value.
All resource records from the same zone sharing the same label are All resource records from the same zone sharing the same label are
encrypted and published together in a single resource records block encrypted and published together in a single resource record block
(RRBLOCK) in the remote storage under a key q as illustrated in (RRBLOCK) in the remote storage under a key q, as illustrated in
Figure 18. A GNS implementation MUST NOT include expired resource Figure 18. A GNS implementation MUST NOT include expired resource
records in blocks. An implementation MUST use the PUT storage records in blocks. An implementation MUST use the PUT storage
procedure when record sets change to update the zone contents. procedure when record sets change to update the zone contents.
Implementations MUST ensure that the EXPIRATION fields of RRBLOCKs Implementations MUST ensure that the EXPIRATION fields of RRBLOCKs
increases strictly monotonically for every change, even if the increase strictly monotonically for every change, even if the
smallest expiration time of records in the block does not. smallest expiration time of records in the block does not increase.
Local Host | Remote Local Host | Remote
| Storage | Storage
| |
| +---------+ | +---------+
| / /| | / /|
| +---------+ | | +---------+ |
+-----------+ | | | | +-----------+ | | | |
| | +---------+PUT(q, RRBLOCK) | | Record | | | | +-----------+PUT(q, RRBLOCK) | | Record | |
| User | | Zone |----------------|->| Storage | | | User | | Zone |----------------|->| Storage | |
| | | Master | | | |/ | | | Publisher | | | |/
+-----------+ +---------+ | +---------+ +-----------+ +-----------+ | +---------+
| A | | A |
| | Zone records | | | Zone records |
| | grouped by label | | | grouped by label |
| | | | | |
| +---------+ | | +---------+ |
|Create / Delete / | /| | |Create / Delete / | /| |
|and Update +---------+ | | |and Update +---------+ | |
|Local Zones | | | | |Local Zones | | | |
| | Local | | | | | Local | | |
+-------------->| Zones | | | +-------------->| Zones | | |
| |/ | | |/ |
+---------+ | +---------+ |
Figure 18: Management and publication of local zones in the Figure 18: Management and Publication of Local Zones in
distributed storage. Distributed Storage
The storage key derivation and records block creation is specified in Storage key derivation and record block creation are specified in the
the following sections and illustrated in Figure 19. following sections and illustrated in Figure 19.
+----------+ +-------+ +------------+ +-------------+ +----------+ +-------+ +------------+ +-------------+
| Zone Key | | Label | | Record Set | | Private Key | | Zone Key | | Label | | Record Set | | Private Key |
+----------+ +-------+ +------------+ +-------------+ +----------+ +-------+ +------------+ +-------------+
| | | | | | | |
| | v | | | v |
| | +-----------+ | | | +-----------+ |
| +---------->| S-Encrypt | | | +---------->| S-Encrypt | |
+----------|---------->+-----------+ | +----------|---------->+-----------+ |
| | | | | | | | | |
| | | v v | | | v v
| | | +-------------+ | | | +-------------+
| +---------------|-->| SignDerived | | +---------------|-->| SignDerived |
| | | +-------------+ | | | +-------------+
| | | | | | | |
| v v v | v v v
| +------+ +---------------+ | +------+ +--------------+
+----->| ZKDF |------->| Records Block | +----->| ZKDF |------->| Record Block |
+------+ +---------------+ +------+ +--------------+
| |
v v
+------+ +-------------+ +------+ +-------------+
| Hash |------->| Storage Key | | Hash |------->| Storage Key |
+------+ +-------------+ +------+ +-------------+
Figure 19: Storage key and records block creation overview. Figure 19: Storage Key and Record Block Creation Overview
6.1. The Storage Key 6.1. The Storage Key
The storage key is derived from the zone key and the respective label The storage key is derived from the zone key and the respective label
of the contained records. The required knowledge of both zone key of the contained records. The required knowledge of both the zone
and label in combination with the similarly derived symmetric secret key and the label in combination with the similarly derived symmetric
keys and blinded zone keys ensures query privacy (see [RFC8324], secret keys and blinded zone keys ensures query privacy (see
Section 3.5). [RFC8324], Section 3.5).
Given a label, the storage key q is derived as follows: Given a label, the storage key q is derived as follows:
q := SHA-512 (ZKDF(zk, label)) q := SHA-512(ZKDF(zkey, label))
label is a UTF-8 string under which the resource records are label: A UTF-8 string under which the resource records are
published. published.
zk is the zone key. zkey: The zone key.
q Is the 512-bit storage key under which the resource records block q: The 512-bit storage key under which the resource record block is
is published. It is the SHA-512 hash [RFC6234] over the derived published. It is the SHA-512 hash [RFC6234] over the derived zone
zone key. key.
6.2. Plaintext Record Data (RDATA) 6.2. Plaintext Record Data (RDATA)
GNS records from a zone are grouped by their labels such that all GNS records from a zone are grouped by their labels such that all
records under the same label published together as a single block in records under the same label are published together as a single block
the storage. Such grouped record sets MAY be paired with in storage. Such grouped record sets MAY be paired with supplemental
supplemental records. records.
Record data (RDATA) is the format used to encode such a group of GNS Record data (RDATA) is the format used to encode such a group of GNS
records. The binary format of RDATA is illustrated in Figure 20. records. The binary format of RDATA is illustrated in Figure 20.
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| EXPIRATION | | EXPIRATION |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| SIZE | FLAGS | TYPE | | SIZE | FLAGS | TYPE |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
skipping to change at page 34, line 32 skipping to change at line 1541
/ / / /
/ / / /
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| EXPIRATION | | EXPIRATION |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| SIZE | FLAGS | TYPE | | SIZE | FLAGS | TYPE |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| DATA / | DATA /
/ / / /
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
/ PADDING / | PADDING /
/ / / /
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 20: The RDATA Wire Format. Figure 20: The RDATA Wire Format
EXPIRATION, SIZE, TYPE, FLAGS and DATA These fields were defined in EXPIRATION, SIZE, TYPE, FLAGS, and DATA: Definitions for these
the resource record format in Section 5. fields are provided below Figure 7 in Section 5.
PADDING When serializing records into RDATA, a GNS implementation PADDING: When serializing records into RDATA, a GNS implementation
MUST ensure that the size of the RDATA is a power of two using the MUST ensure that the size of the RDATA is a power of two using
padding field. The field MUST be set to zero and MUST be ignored this field. The field MUST be set to zero and MUST be ignored on
on receipt. As a special exception, record sets with (only) a receipt. As a special exception, record sets with (only) a zone
zone delegation record type are never padded. delegation record type are never padded.
6.3. The Resource Records Block 6.3. The Resource Record Block
The resource records grouped in an RDATA are encrypted using the The resource records grouped in an RDATA are encrypted using the
S-Encrypt() function defined by the zone type of the zone to which S-Encrypt() function defined by the zone type of the zone to which
the resource records belong and prefixed with meta data into a the resource records belong and prefixed with metadata into a
resource record block (RRBLOCK) for remote storage. The GNS RRBLOCK resource record block (RRBLOCK) for remote storage. The GNS RRBLOCK
wire format is illustrated in Figure 21. wire format is illustrated in Figure 21.
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| SIZE | ZONE TYPE | | SIZE | ZONE TYPE |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
/ ZONE KEY / | ZONE KEY /
/ (BLINDED) / / (BLINDED) /
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| SIGNATURE | | SIGNATURE |
/ / / /
/ / / /
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| EXPIRATION | | EXPIRATION |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| BDATA / | BDATA |
/ /
/ / / /
/ |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 21: The RRBLOCK Wire Format. Figure 21: The RRBLOCK Wire Format
SIZE A 32-bit value containing the length of the block in bytes in SIZE: A 32-bit value containing the length of the block in bytes in
network byte order. Despite the message format's use of a 32-bit network byte order. Despite the message format's use of a 32-bit
value, implementations MAY refuse to publish blocks beyond a value, implementations MAY refuse to publish blocks beyond a
certain size significantly below the theoretical block size limit certain size significantly below the theoretical block size limit
of 4 GB. of 4 GB.
ZONE TYPE is the 32-bit ztype in network byte order. ZONE TYPE: The 32-bit ztype in network byte order.
ZONE KEY (BLINDED) is the blinded zone key "ZKDF(zk, label)" to be ZONE KEY (BLINDED): The blinded zone key "ZKDF(zkey, label)" to be
used to verify SIGNATURE. The length and format of the blinded used to verify SIGNATURE. The length and format of the blinded
public key depends on the ztype. public key depend on the ztype.
SIGNATURE The signature is computed over the EXPIRATION and BDATA SIGNATURE: The signature is computed over the EXPIRATION and BDATA
fields as detailed in Figure 22. The length and format of the fields as shown in Figure 22. The length and format of the
signature depends on the ztype. The signature is created using signature depend on the ztype. The signature is created using the
the SignDerived() function of the cryptosystem of the zone (see SignDerived() function of the cryptosystem of the zone (see
Section 4). Section 4).
EXPIRATION Specifies when the RRBLOCK expires and the encrypted EXPIRATION: Specifies when the RRBLOCK expires and the encrypted
block SHOULD be removed from the storage and caches as it is block SHOULD be removed from storage and caches, as it is likely
likely stale. However, applications MAY continue to use non- stale. However, applications MAY continue to use non-expired
expired individual records until they expire. The value MUST be individual records until they expire. The RRBLOCK expiration
set to the maximum of the expiration time of the resource record value MUST be computed by first determining for each record type
contained within this block with the smallest expiration time and present in the RRBLOCK the maximum expiration time of all records
the previous EXPIRATION value (if any) plus one to ensure strict of that type, including shadow records. Then, the minimum of all
monotonicity (see Section 9.3). If the RDATA includes shadow of these expiration times is taken. The final expiration time is
records, then the maximum expiration time of all shadow records then the larger value of (1) the previous EXPIRATION value of a
with matching type and the expiration times of the non-shadow previous RRBLOCK for the same storage key plus one (if any) and
records is considered. This is a 64-bit absolute date in (2) the computed minimum expiration time across the contained
microseconds since midnight (0 hour), January 1, 1970 UTC in record types. This ensures strict monotonicity (see Section 9.3).
network byte order. 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 computed using S-Encrypt() with the zone BDATA: The encrypted RDATA computed using S-Encrypt() with the zone
key, label and expiration time as additional inputs. Its ultimate key, label, and expiration time as additional inputs. Its
size and content are determined by the S-Encrypt() function of the ultimate size and content are determined by the S-Encrypt()
ztype. function of the ztype.
The signature over the public key covers a 32-bit pseudo header The signature over the public key covers a 32-bit pseudo header
conceptually prefixed to the EXPIRATION and the BDATA fields. The conceptually prefixed to the EXPIRATION and BDATA fields. The wire
wire format is illustrated in Figure 22. format is illustrated in Figure 22.
0 8 16 24 32 40 48 56 0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| SIZE | PURPOSE (0x0F) | | SIZE | PURPOSE (0x0F) |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| EXPIRATION | | EXPIRATION |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| BDATA | | BDATA |
/ / / /
/ / / /
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 22: The Wire Format used for creating the signature of the Figure 22: The Wire Format Used for Creating the Signature of the
RRBLOCK. RRBLOCK
SIZE A 32-bit value containing the length of the signed data in SIZE: A 32-bit value containing the length of the signed data in
bytes in network byte order. bytes in network byte order.
PURPOSE A 32-bit signature purpose flag in network byte order. The PURPOSE: A 32-bit signature purpose flag in network byte order. The
value of this field MUST be 15. It defines the context in which value of this field MUST be 15. It defines the context in which
the signature is created so that it cannot be reused in other the signature is created so that it cannot be reused in other
parts of the protocol including possible future extensions. The parts of the protocol that might include possible future
value of this field corresponds to an entry in the GANA "GNUnet extensions. The value of this field corresponds to an entry in
Signature Purpose" registry [GANA]. the GANA "GNUnet Signature Purposes" registry [GANA].
EXPIRATION Field as defined in the RRBLOCK message above. EXPIRATION: Field as defined in the RRBLOCK message above.
BDATA Field as defined in the RRBLOCK message above. BDATA: Field as defined in the RRBLOCK message above.
7. Name Resolution 7. Name Resolution
Names in GNS are resolved by recursively querying the record storage. Names in GNS are resolved by recursively querying the record storage.
Recursive in this context means that a resolver does not provide Recursive in this context means that a resolver does not provide
intermediate results for a query to the application. Instead, it intermediate results for a query to the application. Instead, it
MUST respond to a resolution request with either the requested MUST respond to a resolution request with either the requested
resource record or an error message in case resolution fails. resource record or an error message if resolution fails. Figure 23
Figure 23 illustrates how an application requests the lookup of a GNS illustrates how an application requests the lookup of a GNS name (1).
name (1). The application MAY provide a desired record type to the The application MAY provide a desired record type to the resolver.
resolver. Subsequently, a Start Zone is determined (2) and the Subsequently, a Start Zone is determined (2) and the recursive
recursive resolution process started. This is where the desired resolution process started. This is where the desired record type is
record type is used to guide processing. For example, if a zone used to guide processing. For example, if a zone delegation record
delegation record type is requested, the resolution of the apex label type is requested, the resolution of the apex label in that zone must
in that zone must be skipped, as the desired record is already found. be skipped, as the desired record is already found. Details on how
Details on how the resolution process is initiated and each iterative the resolution process is initiated and each iterative result (3a,3b)
result (3a,3b) in the resolution is processed are provided in the in the resolution is processed are provided in the sections below.
sections below. The results of the lookup are eventually returned to The results of the lookup are eventually returned to the application
the application (4). The implementation MUST NOT filter the returned (4). The implementation MUST NOT filter the returned resource record
resource record sets according to the desired record type. Filtering sets according to the desired record type. Filtering of record sets
of record sets is typically done by the application. is typically done by the application.
Local Host | Remote Local Host | Remote
| Storage | Storage
| |
| +---------+ | +---------+
| / /| | / /|
| +---------+ | | +---------+ |
+-----------+ (1) Name +----------+ | | | | +-----------+ (1) Name +----------+ | | | |
| | Lookup | | (3a) GET(q) | | Record | | | | Lookup | | (3a) GET(q) | | Record | |
|Application|----------| Resolver |---------------|->| Storage | | |Application|----------| Resolver |---------------|->| Storage | |
skipping to change at page 38, line 5 skipping to change at line 1702
| | | |
+---------+ | +---------+ |
/ | /| | / | /| |
+---------+ | | +---------+ | |
| | | | | | | |
| Start | | | | Start | | |
| Zones | | | | Zones | | |
| |/ | | |/ |
+---------+ | +---------+ |
Figure 23: The recursive GNS resolution process. Figure 23: The Recursive GNS Resolution Process
7.1. Start Zones 7.1. Start Zones
The resolution of a GNS name starts by identifying the start zone The resolution of a GNS name starts by identifying the Start Zone
suffix. Once the start zone suffix is identified, recursive suffix. Once the Start Zone suffix is identified, recursive
resolution of the remainder of the name is initiated (see resolution of the remainder of the name is initiated (see
Section 7.2). There are two types of start zone suffixes: zTLDs and Section 7.2). There are two types of Start Zone suffixes: zTLDs and
local suffix-to-zone mappings. The choice of available suffix-to- local suffix-to-zone mappings. The choice of available suffix-to-
zone mappings is at the sole discretion of the local system zone mappings is at the sole discretion of the local system
administrator or user. This property addresses the issue of a single administrator or user. This property addresses the issue of a single
hierarchy with a centrally controlled root and the related issue of hierarchy with a centrally controlled root and the related issue of
distribution and management of root servers in DNS (see [RFC8324], distribution and management of root servers in DNS (see Sections 3.12
Sections 3.10 and 3.12). and 3.10 of [RFC8324], respectively).
For names ending with a zTLD the start zone is explicitly given in For names ending with a zTLD, the Start Zone is explicitly given in
the suffix of the name to resolve. In order to ensure uniqueness of the suffix of the name to resolve. In order to ensure uniqueness of
names with zTLDs any implementation MUST use the given zone as start names with zTLDs, any implementation MUST use the given zone as the
zone. An implementation MUST first try to interpret the rightmost Start Zone. An implementation MUST first try to interpret the
label of the given name as the beginning of a zTLD (see Section 4.1). rightmost label of the given name as the beginning of a zTLD (see
If the rightmost label cannot be (partially) decoded or if it does Section 4.1). If the rightmost label cannot be (partially) decoded
not indicate a supported ztype, the name is treated as a normal name or if it does not indicate a supported ztype, the name is treated as
and start zone discovery MUST continue with finding a local suffix- a normal name and Start Zone discovery MUST continue with finding a
to-zone mapping. If a valid ztype can be found in the rightmost local suffix-to-zone mapping. If a valid ztype can be found in the
label, the implementation MUST try to synthesize and decode the zTLD rightmost label, the implementation MUST try to synthesize and decode
to retrieve the start zone key according to Section 4.1. If the zTLD the zTLD to retrieve the Start Zone key according to Section 4.1. If
cannot be synthesized or decoded, the resolution of the name fails the zTLD cannot be synthesized or decoded, the resolution of the name
and an error is returned to the application. Otherwise, the zone key fails and an error is returned to the application. Otherwise, the
MUST be used as the start zone: zone key MUST be used as the Start Zone:
Example name: www.example.<zTLD> Example name: www.example.<zTLD>
=> Start zone: zk of type ztype => Start Zone: zkey of type ztype
=> Name to resolve from start zone: www.example => Name to resolve from Start Zone: www.example
For names not ending with a zTLD the resolver MUST determine the For names not ending with a zTLD, the resolver MUST determine the
start zone through a local suffix-to-zone mapping. Suffix-to-zone Start Zone through a local suffix-to-zone mapping. Suffix-to-zone
mappings MUST be configurable through a local configuration file or mappings MUST be configurable through a local configuration file or
database by the user or system administrator. A suffix MAY consist database by the user or system administrator. A suffix MAY consist
of multiple GNS labels concatenated with a label separator. If of multiple GNS labels concatenated with a label separator. If
multiple suffixes match the name to resolve, the longest matching multiple suffixes match the name to resolve, the longest matching
suffix MUST be used. The suffix length of two results MUST NOT be suffix MUST be used. The suffix length of two results MUST NOT be
equal. This indicates a misconfiguration and the implementation MUST equal. This indicates a misconfiguration, and the implementation
return an error. The following is a non-normative example mapping of MUST return an error. The following is a non-normative example
start zones: mapping of Start Zones:
Example name: www.example.xyz.gns.alt Example name: www.example.xyz.gns.alt
Local suffix mappings: Local suffix mappings:
xyz.gns.alt = zTLD0 := Base32GNS(ztype0||zk0) xyz.gns.alt = zTLD0 := Base32GNS(ztype0||zkey0)
example.xyz.gns.alt = zTLD1 := Base32GNS(ztype1||zk1) example.xyz.gns.alt = zTLD1 := Base32GNS(ztype1||zkey1)
example.com.gns.alt = zTLD2 := Base32GNS(ztype2||zk2) example.com.gns.alt = zTLD2 := Base32GNS(ztype2||zkey2)
... ...
=> Start zone: zk1 => Start Zone: zkey1
=> Name to resolve from start zone: www => Name to resolve from Start Zone: www
The process given above MAY be supplemented with other mechanisms if The process given above MAY be supplemented with other mechanisms if
the particular application requires a different process. If no start the particular application requires a different process. If no Start
zone can be discovered, resolution MUST fail and an error MUST be Zone can be identified, resolution MUST fail and an error MUST be
returned to the application. returned to the application.
7.2. Recursion 7.2. Recursion
In each step of the recursive name resolution, there is an In each step of the recursive name resolution, there is an
authoritative zone zk and a name to resolve. The name MAY be empty. authoritative zone zkey and a name to resolve. The name MAY be
If the name is empty, it is interpreted as the apex label "@". empty. If the name is empty, it is interpreted as the apex label
Initially, the authoritative zone is the start zone. "@". Initially, the authoritative zone is the Start Zone.
From here, the following steps are recursively executed, in order: From here, the following steps are recursively executed, in order:
1. Extract the right-most label from the name to look up. 1. Extract the rightmost label from the name to look up.
2. Calculate q using the label and zk as defined in Section 6.1. 2. Calculate q using the label and zkey as defined in Section 6.1.
3. Perform a storage query GET(q) to retrieve the RRBLOCK. 3. Perform a storage query GET(q) to retrieve the RRBLOCK.
4. Check that (a) the block is not expired, (b) the SHA-512 hash of 4. Check that (a) the block is not expired, (b) the SHA-512 hash of
the derived authoritative zone key zk' from the RRBLOCK matches the derived authoritative zone key zkey' from the RRBLOCK matches
the query q, and (c) the signature is valid. If any of these the query q, and (c) the signature is valid. If any of these
tests fail, the RRBLOCK MUST be ignored and, if applicable, the tests fail, the RRBLOCK MUST be ignored and, if applicable, the
storage lookup GET(q) MUST continue to look for other RRBLOCKs. storage lookup GET(q) MUST continue to look for other RRBLOCKs.
5. Obtain the RDATA by decrypting the BDATA contained in the RRBLOCK 5. Obtain the RDATA by decrypting the BDATA contained in the RRBLOCK
using S-Decrypt() as defined by the zone type, effectively using S-Decrypt() as defined by the zone type, effectively
inverting the process described in Section 6.3. inverting the process described in Section 6.3.
Once a well-formed block has been decrypted, the records from RDATA Once a well-formed block has been decrypted, the records from RDATA
are subjected to record processing. are subjected to record processing.
7.3. Record Processing 7.3. Record Processing
In record processing, only the valid records obtained are considered. In record processing, only the valid records obtained are considered.
To filter records by validity, the resolver MUST at least check the To filter records by validity, the resolver MUST at least check the
expiration time and the FLAGS field of the respective record. expiration time and the FLAGS field of the respective record.
Specifically, the resolver MUST disregard expired records. Specifically, the resolver MUST disregard expired records.
Furthermore, SHADOW and SUPPLEMENTAL flags can also exclude records Furthermore, SHADOW and SUPPLEMENTAL flags can also exclude records
from being considered. If the resolver encounters a record with the from being considered. If the resolver encounters a record with the
CRITICAL flag set and does not support the record type the resolution CRITICAL flag set and does not support the record type, the
MUST be aborted and an error MUST be returned. The information that resolution MUST be aborted and an error MUST be returned.
the critical record could not be processed SHOULD be returned in the Information indicating that the critical record could not be
error description. The implementation MAY choose not to return the processed SHOULD be returned in the error description. The
reason for the failure, merely complicating troubleshooting for the implementation MAY choose not to return the reason for the failure,
user. merely complicating troubleshooting for the user.
The next steps depend on the context of the name that is being The next steps depend on the context of the name that is being
resolved: resolved:
* Case 1: If the filtered record set consists of a single REDIRECT Case 1: If the filtered record set consists of a single REDIRECT
record, the remainder of the name is prepended to the REDIRECT record, the remainder of the name is prepended to the REDIRECT
data and the recursion is started again from the resulting name. DATA and the recursion is started again from the resulting name.
Details are described in Section 7.3.1. Details are provided in Section 7.3.1.
* Case 2: If the filtered record set consists exclusively of one or Case 2: If the filtered record set consists exclusively of one or
more GNS2DNS records resolution continues with DNS. Details are more GNS2DNS records, resolution continues with DNS. Details are
described in Section 7.3.2. provided in Section 7.3.2.
* Case 3: If the remainder of the name to be resolved is of the Case 3: If the remainder of the name to be resolved is of the format
format "_SERVICE._PROTO" and the record set contains one or more "_SERVICE._PROTO" and the record set contains one or more matching
matching BOX records, the records in the BOX records are the final BOX records, the records in the BOX records are the final result
result and the recursion is concluded as described in and the recursion is concluded as described in Section 7.3.3.
Section 7.3.3.
* Case 4: If the current record set consist of a single delegation Case 4: If the current record set consists of a single delegation
record, resolution of the remainder of the name is delegated to record, resolution of the remainder of the name is delegated to
the target zone as described in Section 7.3.4. the target zone as described in Section 7.3.4.
* Case 5: If the remainder of the name to resolve is empty the Case 5: If the remainder of the name to resolve is empty, the record
record set is the final result. If any NICK records are in the set is the final result. If any NICK records are in the final
final result set, they MUST first be processed according to result set, they MUST first be processed according to
Section 7.3.5. Otherwise, the record result set is directly Section 7.3.5. Otherwise, the record result set is directly
returned as the final result. returned as the final result.
* Finally, if none of the above is applicable, resolution fails and Finally, if none of the above cases are applicable, resolution fails
the resolver MUST return an empty record set. and the resolver MUST return an empty record set.
7.3.1. REDIRECT 7.3.1. REDIRECT
If the remaining name is empty and the desired record type is If the remaining name is empty and the desired record type is
REDIRECT, in which case the resolution concludes with the REDIRECT REDIRECT, the resolution concludes with the REDIRECT record. If the
record. If the rightmost label of the redirect name is the extension rightmost label of the REDIRECT NAME is the extension label (U+002B
label (U+002B, "+"), resolution continues in GNS with the new name in ("+")), resolution continues in GNS with the new name in the current
the current zone. Otherwise, the resulting name is resolved via the zone. Otherwise, the resulting name is resolved via the default
default operating system name resolution process. This can in turn operating system name resolution process. This can in turn trigger a
trigger a GNS name resolution process depending on the system GNS name resolution process, depending on the system configuration.
configuration. In case resolution continues in DNS, the name MUST If resolution continues in DNS, the name MUST first be converted to
first be converted to an IDNA compliant representation [RFC5890]. an IDNA-compliant representation [RFC5890].
In order to prevent infinite loops, the resolver MUST implement loop In order to prevent infinite loops, the resolver MUST implement loop
detection or limit the number of recursive resolution steps. The detection or limit the number of recursive resolution steps. The
loop detection MUST be effective even if a REDIRECT found in GNS loop detection MUST be effective even if a REDIRECT found in GNS
triggers subsequent GNS lookups via the default operating system name triggers subsequent GNS lookups via the default operating system name
resolution process. resolution process.
7.3.2. GNS2DNS 7.3.2. GNS2DNS
When a resolver encounters one or more GNS2DNS records and the A resolver returns GNS2DNS records when all of the following
remaining name is empty and the desired record type is GNS2DNS, the conditions are met:
GNS2DNS records are returned.
1. The resolver encounters one or more GNS2DNS records;
2. The remaining name is empty; and
3. The desired record type is GNS2DNS.
Otherwise, it is expected that the resolver first resolves the IP Otherwise, it is expected that the resolver first resolves the IP
addresses of the specified DNS name servers. The DNS name MUST be addresses of the specified DNS name servers. The DNS name MUST be
converted to an IDNA compliant representation [RFC5890] for converted to an IDNA-compliant representation [RFC5890] for
resolution in DNS. GNS2DNS records MAY contain numeric IPv4 or IPv6 resolution in DNS. GNS2DNS records MAY contain numeric IPv4 or IPv6
addresses, allowing the resolver to skip this step. The DNS server addresses, allowing the resolver to skip this step. The DNS server
names might themselves be names in GNS or DNS. If the rightmost names might themselves be names in GNS or DNS. If the rightmost
label of the DNS server name is the extension label (U+002B, "+"), label of the DNS server name is the extension label (U+002B ("+")),
the rest of the name is to be interpreted relative to the zone of the 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 GNS2DNS record. If the DNS server name ends in a label
representation of a zone key, the DNS server name is to be resolved representation of a zone key, the DNS server name is to be resolved
against the GNS zone zk. against the GNS zone zkey.
Multiple GNS2DNS records can be stored under the same label, in which Multiple GNS2DNS records can be stored under the same label, in which
case the resolver MUST try all of them. The resolver MAY try them in 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 any order or even in parallel. If multiple GNS2DNS records are
present, the DNS name MUST be identical for all of them. Otherwise, present, the DNS name MUST be identical for all of them. Otherwise,
it is not clear which name the resolver is supposed to follow. If it is not clear which name the resolver is supposed to follow. If
different DNS names are present the resolution fails and an different DNS names are present, the resolution fails and an
appropriate error is SHOULD be returned to the application. appropriate error SHOULD be returned to the application.
If there are DNSSEC DS records or any other records used to secure 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 the connection with the DNS servers stored under the label, the DNS
resolver SHOULD use them to secure the connection with the DNS resolver SHOULD use them to secure the connection with the DNS
server. server.
Once the IP addresses of the DNS servers have been determined, the 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 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). name to be resolved and is resolved by querying the DNS name
The synthesized name has to be converted to an IDNA compliant server(s). The synthesized name has to be converted to an IDNA-
representation [RFC5890] for resolution in DNS. If such a conversion compliant representation [RFC5890] for resolution in DNS. If such a
is not possible, the resolution MUST be aborted and an error MUST be conversion is not possible, the resolution MUST be aborted and an
returned. The information that the critical record could not be error MUST be returned. Information indicating that the critical
processed SHOULD be returned in the error description. The record could not be processed SHOULD be returned in the error
implementation MAY choose not to return the reason for the failure, description. The implementation MAY choose not to return the reason
merely complicating troubleshooting for the user. for the failure, merely complicating troubleshooting for the user.
As the DNS servers specified are possibly authoritative DNS servers, As the DNS servers specified are possibly authoritative DNS servers,
the GNS resolver MUST support recursive DNS resolution and MUST NOT the GNS resolver MUST support recursive DNS resolution and MUST NOT
delegate this to the authoritative DNS servers. The first successful delegate this to the authoritative DNS servers. The first successful
recursive name resolution result is returned to the application. In recursive name resolution result is returned to the application. In
addition, the resolver SHOULD return the queried DNS name as a addition, the resolver SHOULD return the queried DNS name as a
supplemental LEHO record (see Section 5.3.1) with a relative supplemental LEHO record (see Section 5.3.1) with a relative
expiration time of one hour. expiration time of one hour.
Once the transition from GNS into DNS is made through a GNS2DNS Once the transition from GNS to DNS is made through a GNS2DNS record,
record, there is no "going back". The (possibly recursive) there is no "going back". The (possibly recursive) resolution of the
resolution of the DNS name MUST NOT delegate back into GNS and should DNS name MUST NOT delegate back into GNS and should only follow the
only follow the DNS specifications. For example, names contained in DNS specifications. For example, names contained in DNS CNAME
DNS CNAME records MUST NOT be interpreted by resolvers that support records MUST NOT be interpreted by resolvers that support both DNS
both DNS and GNS as GNS names. and GNS as GNS names.
GNS resolvers SHOULD offer a configuration option to disable DNS GNS resolvers SHOULD offer a configuration option to disable DNS
processing to avoid information leakage and provide a consistent processing to avoid information leakage and provide a consistent
security profile for all name resolutions. Such resolvers would security profile for all name resolutions. Such resolvers would
return an empty record set upon encountering a GNS2DNS record during return an empty record set upon encountering a GNS2DNS record during
the recursion. However, if GNS2DNS records are encountered in the the recursion. However, if GNS2DNS records are encountered in the
record set for the apex label and a GNS2DNS record is explicitly record set for the apex label and a GNS2DNS record is explicitly
requested by the application, such records MUST still be returned, requested by the application, such records MUST still be returned,
even if DNS support is disabled by the GNS resolver configuration. even if DNS support is disabled by the GNS resolver configuration.
skipping to change at page 43, line 13 skipping to change at line 1939
inseparable from the corresponding address records. inseparable from the corresponding address records.
7.3.4. Zone Delegation Records 7.3.4. Zone Delegation Records
When the resolver encounters a record of a supported zone delegation 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 record type (such as PKEY or EDKEY) and the remainder of the name is
not empty, resolution continues recursively with the remainder of the not empty, resolution continues recursively with the remainder of the
name in the GNS zone specified in the delegation record. name in the GNS zone specified in the delegation record.
Whenever a resolver encounters a new GNS zone, it MUST check against Whenever a resolver encounters a new GNS zone, it MUST check against
the local revocation list (see Section 4.2) whether the respective the local revocation list (see Section 4.2) to see whether the
zone key has been revoked. If the zone key was revoked, the respective zone key has been revoked. If the zone key was revoked,
resolution MUST fail with an empty result set. the resolution MUST fail with an empty result set.
Implementations MUST NOT allow multiple different zone delegations Implementations MUST NOT allow multiple different zone delegations
under a single label (except if some are shadow records). under a single label (except if some are shadow records).
Implementations MAY support any subset of ztypes. Implementations Implementations MAY support any subset of ztypes. Implementations
MUST NOT process zone delegation records stored under the apex label MUST NOT process zone delegation records stored under the apex label
("@"). If a zone delegation record is encountered under the apex ("@"). If a zone delegation record is encountered under the apex
label, resolution fails and an error MUST be returned. The label, resolution fails and an error MUST be returned. The
implementation MAY choose not to return the reason for the failure, implementation MAY choose not to return the reason for the failure,
merely impacting troubleshooting information for the user. merely impacting troubleshooting information for the user.
If the remainder of the name to resolve is empty and a record set was If the remainder of the name to resolve is empty and a record set was
received containing only a single delegation record, the recursion is received containing only a single delegation record, the recursion is
continued with the record value as authoritative zone and the apex continued with the record value as the authoritative zone and the
label "@" as remaining name. Except in the case where the desired apex label "@" as the remaining name. The exception is the case
record type as specified by the application is equal to the ztype, in where the desired record type as specified by the application is
which case the delegation record is returned. equal to the ztype, in which case the delegation record is returned.
7.3.5. NICK 7.3.5. NICK
NICK records are only relevant to the recursive resolver if the 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 record set in question is the final result, which is to be returned
the application. The encountered NICK records can either be to the application. The encountered NICK records can be either
supplemental (see Section 5) or non-supplemental. If the NICK record supplemental (see Section 5) or non-supplemental. If the NICK record
is supplemental, the resolver only returns the record set if one of is supplemental, the resolver only returns the record set if one of
the non-supplemental records matches the queried record type. It is the non-supplemental records matches the queried record type. It is
possible that one record set contains both supplemental and non- possible that one record set contains both supplemental and non-
supplemental NICK records. supplemental NICK records.
The differentiation between a supplemental and non-supplemental NICK The differentiation between a supplemental and non-supplemental NICK
record allows the application to match the record to the record allows the application to match the record to the
authoritative zone. Consider the following example: authoritative zone. Consider the following example:
skipping to change at page 44, line 4 skipping to change at line 1978
supplemental NICK records. supplemental NICK records.
The differentiation between a supplemental and non-supplemental NICK The differentiation between a supplemental and non-supplemental NICK
record allows the application to match the record to the record allows the application to match the record to the
authoritative zone. Consider the following example: authoritative zone. Consider the following example:
Query: alice.example.gns.alt (type=A) Query: alice.example.gns.alt (type=A)
Result: Result:
A: 192.0.2.1 A: 192.0.2.1
NICK: eve (non-supplemental) NICK: eve (non-supplemental)
In this example, the returned NICK record is non-supplemental. For In this example, the returned NICK record is non-supplemental. For
the application, this means that the NICK belongs to the zone the application, this means that the NICK belongs to the zone
"alice.example.gns.alt" and is published under the apex label along "alice.example.gns.alt" and is published under the apex label along
with an A record. The NICK record is interpreted as: The zone with an A record. The NICK record is interpreted as follows: the
defined by "alice.example.gns.alt" wants to be referred to as "eve". zone defined by "alice.example.gns.alt" wants to be referred to as
In contrast, consider the following: "eve". In contrast, consider the following:
Query: alice.example.gns.alt (type=AAAA) Query: alice.example.gns.alt (type=AAAA)
Result: Result:
AAAA: 2001:DB8::1 AAAA: 2001:db8::1
NICK: john (supplemental) NICK: john (supplemental)
In this case, the NICK record is marked as supplemental. This means In this case, the NICK record is marked as supplemental. This means
that the NICK record belongs to the zone "example.gns.alt" and is that the NICK record belongs to the zone "example.gns.alt" and is
published under the label "alice" along with an AAAA record. Here, published under the label "alice" along with a AAAA record. Here,
the NICK record should be interpreted as: The zone defined by the NICK record should be interpreted as follows: the zone defined by
"example.gns.alt" wants to be referred to as "john". This "example.gns.alt" wants to be referred to as "john". This
distinction is likely useful for other records published as distinction is likely useful for other records published as
supplemental. supplemental.
8. Internationalization and Character Encoding 8. Internationalization and Character Encoding
All names in GNS are encoded in UTF-8 [RFC3629]. Labels MUST be All names in GNS are encoded in UTF-8 [RFC3629]. Labels MUST be
canonicalized using Normalization Form C (NFC) [Unicode-UAX15]. This canonicalized using Normalization Form C (NFC) [Unicode-UAX15]. This
does not include any DNS names found in DNS records, such as CNAME does not include any DNS names found in DNS records, such as CNAME
record data, which is internationalized through the IDNA record data, which is internationalized through the IDNA
specifications [RFC5890]. specifications; see [RFC5890].
9. Security and Privacy Considerations 9. Security and Privacy Considerations
9.1. Availability 9.1. Availability
In order to ensure availability of records beyond their absolute In order to ensure availability of records beyond their absolute
expiration times, implementations MAY allow to locally define expiration times, implementations MAY allow relative expiration time
relative expiration time values of records. Records can then be values of records to be locally defined. Records can then be
published recurringly with updated absolute expiration times by the published recurringly with updated absolute expiration times by the
implementation. implementation.
Implementations MAY allow users to manage private records in their Implementations MAY allow users to manage private records in their
zones that are not published in the storage. Private records are zones that are not published in storage. Private records are treated
considered just like regular records when resolving labels in local just like regular records when resolving labels in local zones, but
zones, but their data is completely unavailable to non-local users. their data is completely unavailable to non-local users.
9.2. Agility 9.2. Agility
The security of cryptographic systems depends on both the strength of The security of cryptographic systems depends on both the strength of
the cryptographic algorithms chosen and the strength of the keys used the cryptographic algorithms chosen and the strength of the keys used
with those algorithms. The security also depends on the engineering with those algorithms. This security also depends on the engineering
of the protocol used by the system to ensure that there are no non- of the protocol used by the system to ensure that there are no non-
cryptographic ways to bypass the security of the overall system. cryptographic ways to bypass the security of the overall system.
This is why developers of applications managing GNS zones SHOULD This is why developers of applications managing GNS zones SHOULD
select a default ztype considered secure at the time of releasing the select a default ztype considered secure at the time of releasing the
software. For applications targeting end users that are not expected software. For applications targeting end users that are not expected
to understand cryptography, the application developer MUST NOT leave to understand cryptography, the application developer MUST NOT leave
the ztype selection of new zones to end users. the ztype selection of new zones to end users.
This document concerns itself with the selection of cryptographic This document concerns itself with the selection of cryptographic
algorithms used in GNS. The algorithms identified in this document algorithms used in GNS. The algorithms identified in this document
skipping to change at page 45, line 31 skipping to change at line 2048
current time, and cryptographic research so far leads us to believe current time, and cryptographic research so far leads us to believe
that they are likely to remain secure into the foreseeable future. that they are likely to remain secure into the foreseeable future.
However, this is not necessarily forever, and it is expected that new However, this is not necessarily forever, and it is expected that new
revisions of this document will be issued from time to time to revisions of this document will be issued from time to time to
reflect the current best practices in this area. reflect the current best practices in this area.
In terms of crypto-agility, whenever the need for an updated In terms of crypto-agility, whenever the need for an updated
cryptographic scheme arises to, for example, replace ECDSA over cryptographic scheme arises to, for example, replace ECDSA over
Ed25519 for PKEY records, it can simply be introduced through a new Ed25519 for PKEY records, it can simply be introduced through a new
record type. Zone administrators can then replace the delegation record type. Zone administrators can then replace the delegation
record type for future records. The old record type remains and record type for future records. The old record type remains, and
zones can iteratively migrate to the updated zone keys. To ensure zones can iteratively migrate to the updated zone keys. To ensure
that implementations correctly generate an error message when that implementations correctly generate an error message when
encountering a ztype that they do not support, current and future encountering a ztype that they do not support, current and future
delegation records must always have the CRITICAL flag set. delegation records must always have the CRITICAL flag set.
9.3. Cryptography 9.3. Cryptography
The following considerations provide background on the design choices The following considerations provide background on the design choices
of the ztypes specified in this document. When specifying new ztypes of the ztypes specified in this document. When specifying new ztypes
as per Section 4, the same considerations apply. as per Section 4, the same considerations apply.
GNS PKEY zone keys use ECDSA over Ed25519. This is an unconventional GNS PKEY zone keys use ECDSA over Ed25519. This is an unconventional
choice, as ECDSA is usually used with other curves. However, choice, as ECDSA is usually used with other curves. However,
standardized ECDSA curves are problematic for a range of reasons standardized ECDSA curves are problematic for a range of reasons, as
described in the Curve25519 and EdDSA papers [ed25519]. Using EdDSA described in the Curve25519 and EdDSA papers [RFC7748] [ed25519].
directly is also not possible, as a hash function is used on the Using EdDSA directly is also not possible, as a hash function is used
private key which destroys the linearity that the key blinding in GNS on the private key and will destroy the linearity that the key
depends upon. We are not aware of anyone suggesting that using blinding in GNS depends upon. We are not aware of anyone suggesting
Ed25519 instead of another common curve of similar size would lower that using Ed25519 instead of another common curve of similar size
the security of ECDSA. GNS uses 256-bit curves because that way the would lower the security of ECDSA. GNS uses 256-bit curves; that
encoded (public) keys fit into a single DNS label, which is good for way, the encoded (public) keys fit into a single DNS label, which is
usability. good for usability.
In order to ensure ciphertext indistinguishability, care must be In order to ensure ciphertext indistinguishability, care must be
taken with respect to the initialization vector in the counter block. taken with respect to the IV in the counter block. In our design,
In our design, the IV always includes the expiration time of the the IV always includes the expiration time of the record block. When
record block. When applications store records with relative applications store records with relative expiration times,
expiration times, monotonicity is implicitly ensured because each monotonicity is implicitly ensured because each time a block is
time a block is published into the storage, its IV is unique as the published in storage, its IV is unique, as the expiration time is
expiration time is calculated dynamically and increases monotonically calculated dynamically and increases monotonically with the system
with the system time. Still, an implementation MUST ensure that when time. Still, an implementation MUST ensure that when relative
relative expiration times are decreased, the expiration time of the expiration times are decreased, the expiration time of the next
next record block MUST be after the last published block. For record block MUST be after the last published block. For records
records where an absolute expiration time is used, the implementation where an absolute expiration time is used, the implementation MUST
MUST ensure that the expiration time is always increased when the ensure that the expiration time is always increased when the record
record data changes. For example, the expiration time on the wire data changes. For example, the expiration time on the wire could be
could be increased by a single microsecond even if the user did not increased by a single microsecond even if the user did not request a
request a change. In case of deletion of all resource records under change. In the case of deletion of all resource records under a
a label, the implementation MUST keep track of the last absolute label, the implementation MUST keep track of the last absolute
expiration time of the last published resource block. expiration time of the last published resource block.
Implementations MAY define and use a special record type as a Implementations MAY define and use a special record type as a
tombstone that preserves the last absolute expiration time, but then tombstone that preserves the last absolute expiration time but then
MUST take care to not publish a block with such a tombstone record. MUST take care to not publish a block with such a tombstone record.
When new records are added under this label later, the implementation When new records are added under this label later, the implementation
MUST ensure that the expiration times are after the last published MUST ensure that the expiration times are after the last published
block. Finally, in order to ensure monotonically increasing block. Finally, in order to ensure monotonically increasing
expiration times the implementation MUST keep a local record of the expiration times, the implementation MUST keep a local record of the
last time obtained from the system clock, so as to construct a last time obtained from the system clock, so as to construct a
monotonic clock in case the system clock jumps backwards. monotonic clock if the system clock jumps backwards.
9.4. Abuse Mitigation 9.4. Abuse Mitigation
GNS names are UTF-8 strings. Consequently, GNS faces similar issues GNS names are UTF-8 strings. Consequently, GNS faces issues with
with respect to name spoofing as DNS does for internationalized respect to name spoofing similar to those for DNS with respect to
domain names. In DNS, attackers can register similar sounding or internationalized domain names. In DNS, attackers can register
looking names (see above) in order to execute phishing attacks. GNS similar-sounding or similar-looking names (see above) in order to
zone administrators must take into account this attack vector and execute phishing attacks. GNS zone administrators must take into
incorporate rules in order to mitigate it. 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 Further, DNS can be used to combat illegal content on the Internet by
having the respective domains seized by authorities. However, the having the respective domains seized by authorities. However, the
same mechanisms can also be abused in order to impose state same mechanisms can also be abused in order to impose state
censorship. Avoiding that possibility is one of the motivations censorship. Avoiding that possibility is one of the motivations
behind GNS. In GNS, TLDs are not enumerable. By design, the start behind GNS. In GNS, TLDs are not enumerable. By design, the Start
zone of the resolver is defined locally and hence such a seizure is Zone of the resolver is defined locally, and hence such a seizure is
difficult and ineffective in GNS. difficult and ineffective in GNS.
9.5. Zone Management 9.5. Zone Management
In GNS, zone administrators need to manage and protect their zone In GNS, zone administrators need to manage and protect their zone
keys. Once a private zone key is lost, it cannot be recovered and keys. Once a private zone key is lost, it cannot be recovered, and
the zone revocation message cannot be computed anymore. Revocation the zone revocation message cannot be computed anymore. Revocation
messages can be pre-calculated if revocation is required in case a messages can be precalculated if revocation is required in cases
private zone key is lost. Zone administrators, and for GNS this where a private zone key is lost. Zone administrators, and for GNS
includes end-users, are required to responsibly and diligently this includes end users, are required to responsibly and diligently
protect their cryptographic keys. GNS supports signing records in protect their cryptographic keys. GNS supports signing records in
advance ("offline") in order to support processes (such as air gaps) advance ("offline") in order to support processes (such as air gaps)
which aim to protect private keys. that aim to protect private keys.
Similarly, users are required to manage their local start zone Similarly, users are required to manage their local Start Zone
configuration. In order to ensure integrity and availability or configuration. In order to ensure the integrity and availability of
names, users must ensure that their local start zone information is names, users must ensure that their local Start Zone information is
not compromised or outdated. It can be expected that the processing not compromised or outdated. It can be expected that the processing
of zone revocations and an initial start zone is provided with a GNS of zone revocations and an initial Start Zone are provided with a GNS
implementation ("drop shipping"). Shipping an initial start zone implementation ("drop shipping"). Shipping an initial Start Zone
configuration effectively establishes a root zone. Extension and configuration effectively establishes a root zone. Extension and
customization of the zone is at the full discretion of the user. customization of the zone are at the full discretion of the user.
While implementations following this specification will be While implementations following this specification will be
interoperable, if two implementations connect to different remote interoperable, if two implementations connect to different remote
storages they are mutually unreachable. This can lead to a state storage entities, they are mutually unreachable. This can lead to a
where a record exists in the global namespace for a particular name, state where a record exists in the global namespace for a particular
but the implementation is not communicating with the remote storage name, but the implementation is not communicating with the remote
that contains the respective block and is hence unable to resolve it. storage entity that contains the respective block and is hence unable
This situation is similar to a split-horizon DNS configuration. to resolve it. This situation is similar to a split-horizon DNS
Which remote storages are implemented usually depends on the configuration. The remote storage entity used will most likely
application it is built for. The remote storage used will most depend on the specific application context using GNS resolution. For
likely depend on the specific application context using GNS example, one application is the resolution of hidden services within
resolution. For example, one application is the resolution of hidden the Tor network [TorRendSpec], which would suggest using Tor routers
services within the Tor network, which would suggest using Tor for remote storage. Implementations of "aggregated" remote storage
routers for remote storage. Implementations of "aggregated" remote entities are conceivable but are expected to be the exception.
storages are conceivable, but are expected to be the exception.
9.6. DHTs as Remote Storage 9.6. DHTs as Remote Storage
This document does not specify the properties of the underlying This document does not specify the properties of the underlying
remote storage which is required by any GNS implementation. It is remote storage, which is required by any GNS implementation. It is
important to note that the properties of the underlying remote important to note that the properties of the underlying remote
storage are directly inherited by the GNS implementation. This storage are directly inherited by the GNS implementation. This
includes both security as well as other non-functional properties includes both security and other non-functional properties such as
such as scalability and performance. Implementers should take great scalability and performance. Implementers should take great care
care when selecting or implementing a DHT for use as remote storage when selecting or implementing a DHT for use as remote storage in a
in a GNS implementation. DHTs with reasonable security and GNS implementation. DHTs with reasonable security and performance
performance properties exist [R5N]. It should also be taken into properties exist [R5N]. It should also be taken into consideration
consideration that GNS implementations which build upon different DHT that GNS implementations that build upon different DHT overlays are
overlays are unlikely to be interoperable with each other. unlikely to be mutually reachable.
9.7. Revocations 9.7. Revocations
Zone administrators are advised to pre-generate zone revocations and Zone administrators are advised to pregenerate zone revocations and
to securely store the revocation information in case the zone key is to securely store the revocation information if the zone key is lost,
lost, compromised or replaced in the future. Pre-calculated compromised, or replaced in the future. Precalculated revocations
revocations can cease to be valid due to expirations or protocol can cease to be valid due to expirations or protocol changes such as
changes such as epoch adjustments. Consequently, implementers and epoch adjustments. Consequently, implementers and users must take
users must take precautions in order to manage revocations precautions in order to manage revocations accordingly.
accordingly.
Revocation payloads do not include a 'new' key for key replacement. Revocation payloads do not include a "new" key for key replacement.
Inclusion of such a key would have two major disadvantages: Inclusion of such a key would have two major disadvantages:
1. If a revocation is published after a private key was compromised, 1. If a revocation is published after a private key was compromised,
allowing key replacement would be dangerous: if an adversary took allowing key replacement would be dangerous: if an adversary took
over the private key, the adversary could then broadcast a over the private key, the adversary could then broadcast a
revocation with a key replacement. For the replacement, the revocation with a key replacement. For the replacement, the
compromised owner would have no chance to issue a revocation. compromised owner would have no chance to issue a revocation.
Thus, allowing a revocation message to replace a private key Thus, allowing a revocation message to replace a private key
makes dealing with key compromise situations worse. makes dealing with key compromise situations worse.
2. Sometimes, key revocations are used with the objective of 2. Sometimes, key revocations are used with the objective of
changing cryptosystems. Migration to another cryptosystem by changing cryptosystems. Migration to another cryptosystem by
replacing keys via a revocation message would only be secure as replacing keys via a revocation message would only be secure as
long as both cryptosystems are still secure against forgery. long as both cryptosystems are still secure against forgery.
Such a planned, non-emergency migration to another cryptosystem Such a planned, non-emergency migration to another cryptosystem
should be done by running zones for both cipher systems in should be done by running zones for both cipher systems in
parallel for a while. The migration would conclude by revoking parallel for a while. The migration would conclude by revoking
the legacy zone key only once it is deemed no longer secure, and the legacy zone key only when it is deemed no longer secure and,
hopefully after most users have migrated to the replacement. hopefully, after most users have migrated to the replacement.
9.8. Zone Privacy 9.8. Zone Privacy
GNS does not support authenticated denial of existence of names GNS does not support authenticated denial of existence of names
within a zone. Record data is published in encrypted form using keys within a zone. Record data is published in encrypted form using keys
derived from the zone key and record label. Zone administrators derived from the zone key and record label. Zone administrators
should carefully consider if a label and zone key are public, or if should carefully consider whether (1) a label and zone key are public
one or both of these should be used as a shared secret to restrict or (2) one or both of these should be used as a shared secret to
access to the corresponding record data. Unlike public zone keys, restrict access to the corresponding record data. Unlike public zone
low-entropy labels can be guessed by an attacker. If an attacker keys, low-entropy labels can be guessed by an attacker. If an
knows the public zone key, the use of well known or guessable labels attacker knows the public zone key, the use of well-known or
effectively threatens the disclosure of the corresponding records. guessable labels effectively threatens the disclosure of the
corresponding records.
It should be noted that the guessing attack on labels only applies if It should be noted that the guessing attack on labels only applies if
the zone key is somehow disclosed to the adversary. GNS itself does the zone key is somehow disclosed to the adversary. GNS itself does
not disclose it during a lookup or when resource records are not disclose it during a lookup or when resource records are
published (as only the blinded zone keys are used on the network). published (as only the blinded zone keys are used on the network).
However, zone keys do become public during revocation. However, zone keys do become public during revocation.
It is thus RECOMMENDED to use a label with sufficient entropy to It is thus RECOMMENDED to use a label with sufficient entropy to
prevent guessing attacks if any data in a resource record set is prevent guessing attacks if any data in a resource record set is
sensitive. sensitive.
9.9. Zone Governance 9.9. Zone Governance
While DNS is distributed, in practice it relies on centralized, While DNS is distributed, in practice it relies on centralized,
trusted registrars to provide globally unique names. As the trusted registrars to provide globally unique names. As awareness of
awareness of the central role DNS plays on the Internet rises, the central role DNS plays on the Internet increases, various
various institutions are using their power (including legal means) to institutions are using their power (including legal means) to engage
engage in attacks on the DNS, thus threatening the global in attacks on the DNS, thus threatening the global availability and
availability and integrity of information on the Internet. While a integrity of information on the Internet. While a wider discussion
wider discussion of this issue is out of scope for this document, of this issue is out of scope for this document, analyses and
analyses and investigations can be found in recent academic research investigations can be found in recent academic research works,
works including [SecureNS]. including [SecureNS].
GNS is designed to provide a secure, privacy-enhancing alternative to GNS is designed to provide a secure, privacy-enhancing alternative to
the DNS name resolution protocol, especially when censorship or the DNS name resolution protocol, especially when censorship or
manipulation is encountered. In particular, it directly addresses manipulation is encountered. In particular, it directly addresses
concerns in DNS with respect to query privacy. However, depending on concerns in DNS with respect to query privacy. However, depending on
the governance of the root zone, any deployment will likely suffer the governance of the root zone, any deployment will likely suffer
from the issues of a "Single Hierarchy with a Centrally Controlled from the issue of a single hierarchy with a centrally controlled root
Root" and "Distribution and Management of Root Servers" as raised in and the related issue of distribution and management of root servers
[RFC8324]. In DNS, those issues are a direct result from the in DNS, as raised in Sections 3.12 and 3.10 of [RFC8324],
respectively. In DNS, those issues directly result from the
centralized root zone governance at the Internet Corporation for centralized root zone governance at the Internet Corporation for
Assigned Names and Numbers (ICANN) which allows it to provide Assigned Names and Numbers (ICANN), which allows it to provide
globally unique names. globally unique names.
In GNS, start zones give users local authority over their preferred In GNS, Start Zones give users local authority over their preferred
root zone governance. It enables users to replace or enhance a root zone governance. It enables users to replace or enhance a
trusted root zone configuration provided by a third party (e.g. the trusted root zone configuration provided by a third party (e.g., the
implementer or a multi-stakeholder governance body like ICANN) with implementer or a multi-stakeholder governance body like ICANN) with
secure delegation of authority using local petnames while operating secure delegation of authority using local petnames while operating
under a very strong adversary model. In combination with zTLDs, this under a very strong adversary model. In combination with zTLDs, this
provides users of GNS with a global, secure and memorable mapping provides users of GNS with a global, secure, and memorable mapping
without a trusted authority. without a trusted authority.
Any GNS implementation MAY provide a default governance model in the Any GNS implementation MAY provide a default governance model in the
form of an initial start zone mapping. form of an initial Start Zone mapping.
9.10. Namespace Ambiguity 9.10. Namespace Ambiguity
Technically, the GNS protocol can be used to resolve names in the Technically, the GNS protocol can be used to resolve names in the
namespace of the global DNS. However, this would require the namespace of the global DNS. However, this would require the
respective governance bodies and stakeholders (e.g. IETF and ICANN) respective governance bodies and stakeholders (e.g., the IETF and
to standardize the use of GNS for this particular use case. ICANN) to standardize the use of GNS for this particular use case.
However, this capability implies that GNS names may be This capability implies that GNS names may be indistinguishable from
indistinguishable from DNS names in their respective common display DNS names in their respective common display format [RFC8499] or
format [RFC8499] or other special-use domain names [RFC6761] if a other special-use domain names [RFC6761] if a local Start Zone
local start zone configuration maps suffixes from the global DNS to configuration maps suffixes from the global DNS to GNS zones. For
GNS zones. For applications, it is then ambiguous which name system applications, which name system should be used in order to resolve a
should be used in order to resolve a given name. This poses a risk given name will then be ambiguous. This poses a risk when trying to
when trying to resolve a name through DNS when it is actually a GNS resolve a name through DNS when it is actually a GNS name, as
name as discussed in [RFC8244]. In such a case, the GNS name is discussed in [RFC8244]. In such a case, the GNS name is likely to be
likely to be leaked as part of the DNS resolution. leaked as part of the DNS resolution.
In order to prevent disclosure of queried GNS names it is RECOMMENDED In order to prevent disclosure of queried GNS names, it is
that GNS-aware applications try to resolve a given name in GNS before RECOMMENDED that GNS-aware applications try to resolve a given name
any other method taking into account potential suffix-to-zone in GNS before any other method, taking into account potential suffix-
mappings and zTLDs. Suffix-to-zone mappings are expected to be to-zone mappings and zTLDs. Suffix-to-zone mappings are expected to
configured by the user or local administrator and as such the be configured by the user or local administrator, and as such the
resolution in GNS is in line with user expectations even if the name resolution in GNS is in line with user expectations even if the name
could also be resolved through DNS. If no suffix-to-zone mapping for could also be resolved through DNS. If no suffix-to-zone mapping for
the name exists and no zTLD is found, resolution MAY continue with the name exists and no zTLD is found, resolution MAY continue with
other methods such as DNS. If a suffix-to-zone mapping for the name other methods such as DNS. If a suffix-to-zone mapping for the name
exists or the name ends with a zTLD, it MUST be resolved using GNS exists or the name ends with a zTLD, it MUST be resolved using GNS,
and resolution MUST NOT continue by any other means independent of and resolution MUST NOT continue by any other means independent of
the GNS resolution result. the GNS resolution result.
Mechanisms such as the Name Service Switch (NSS) of Unix-like Mechanisms such as the Name Service Switch (NSS) of UNIX-like
operating systems are an example of how such a resolution process can operating systems are an example of how such a resolution process can
be implemented and used. It allows system administrators to be implemented and used. The NSS allows system administrators to
configure host name resolution precedence and is integrated with the configure hostname resolution precedence and is integrated with the
system resolver implementation. system resolver implementation.
For use cases where GNS names may be confused with names of other For use cases where GNS names may be confused with names of other
name resolution mechanisms (in particular DNS), the ".gns.alt" domain name resolution mechanisms (in particular, DNS), the ".gns.alt"
SHOULD be used. For use cases like implementing sinkholes to block domain SHOULD be used. For use cases like implementing sinkholes to
malware sites or serving DNS domains via GNS to bypass censorship, block malware sites or serving DNS domains via GNS to bypass
GNS MAY be deliberately used in ways that interfere with resolution censorship, GNS MAY be deliberately used in ways that interfere with
of another name system. resolution of another name system.
10. GANA Considerations 10. GANA Considerations
GANA has assigned signature purposes in its "GNUnet Signature 10.1. GNUnet Signature Purposes Registry
Purpose" registry as listed in Figure 24.
Purpose | Name | References | Comment GANA [GANA] has assigned signature purposes in its "GNUnet Signature
--------+-----------------+------------+-------------------------- Purposes" registry as listed in Table 1.
3 | GNS_REVOCATION | [This.I-D] | GNS zone key revocation
15 | GNS_RECORD_SIGN | [This.I-D] | GNS record set signature
Figure 24: Requested Changes in the GANA GNUnet Signature Purpose +=========+=================+============+==========================+
Registry. | Purpose | Name | References | Comment |
+=========+=================+============+==========================+
| 3 | GNS_REVOCATION | RFC 9498 | GNS zone key revocation |
+---------+-----------------+------------+--------------------------+
| 15 | GNS_RECORD_SIGN | RFC 9498 | GNS record set |
| | | | signature |
+---------+-----------------+------------+--------------------------+
10.1. GNS Record Types Registry Table 1: The GANA GNUnet Signature Purposes Registry
GANA [GANA] manages the "GNS Record Types" registry. Each entry has 10.2. GNS Record Types Registry
the following format:
* Name: The name of the record type (case-insensitive ASCII string, GANA [GANA] manages the "GNS 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 restricted to alphanumeric characters). For zone delegation
records, the assigned number represents the ztype value of the records, the assigned number represents the ztype value of the
zone. zone.
* Number: 32-bit, above 65535 Number: A 32-bit number above 65535.
* Comment: Optionally, a brief English text describing the purpose Comment: Optionally, brief English text describing the purpose of
of the record type (in UTF-8) the record type (in UTF-8).
* Contact: Optionally, the contact information of a person to Contact: Optionally, the contact information for a person to contact
contact for further information. for further information.
* References: Optionally, references describing the record type References: Optionally, references (such as an RFC) describing the
(such as an RFC). record type.
The registration policy for this registry is "First Come First The registration policy for this registry is "First Come First
Served". This policy is modeled on that described in [RFC8126], and Served". This policy is modeled on that described in [RFC8126] and
describes the actions taken by GANA: describes the actions taken by GANA:
Adding new entries is possible after review by any authorized GANA * Adding new entries is possible after review by any authorized GANA
contributor, using a first-come-first-served policy for unique name contributor, using a first-come-first-served policy for unique
allocation. Reviewers are responsible to ensure that the chosen name allocation. Reviewers are responsible for ensuring that the
"Name" is appropriate for the record type. The registry will define chosen "Name" is appropriate for the record type. The registry
a unique number for the entry. will define a unique number for the entry.
Authorized GANA contributors for review of new entries are reachable * Authorized GANA contributors for review of new entries are
at gns-registry@gnunet.org. reachable at <gns-registry@gnunet.org>.
Any request MUST contain a unique name and a point of contact. The * Any request MUST contain a unique name and a point of contact.
contact information MAY be added to the registry given the consent of The contact information MAY be added to the registry, with the
the requester. The request MAY optionally also contain relevant consent of the requester. The request MAY optionally also contain
references as well as a descriptive comment as defined above. relevant references as well as a descriptive comment, as defined
above.
GANA has assigned numbers for the record types defined in this GANA has assigned numbers for the record types defined in this
specification in the "GNU Name System Record Types" registry as specification in the "GNS Record Types" registry as listed in
listed in Figure 25. Table 2.
Number | Name | Contact | References | Comment +========+==========+=========+============+====================+
-------+---------+---------+------------+------------------------- | Number | Name | Contact | References | Comment |
65536 | PKEY | (*) | [This.I-D] | GNS zone delegation (PKEY) +========+==========+=========+============+====================+
65537 | NICK | (*) | [This.I-D] | GNS zone nickname | 65536 | PKEY | (*) | RFC 9498 | GNS zone |
65538 | LEHO | (*) | [This.I-D] | GNS legacy hostname | | | | | delegation (PKEY) |
65540 | GNS2DNS | (*) | [This.I-D] | Delegation to DNS +--------+----------+---------+------------+--------------------+
65541 | BOX | (*) | [This.I-D] | Boxed records | 65537 | NICK | (*) | RFC 9498 | GNS zone nickname |
65551 | REDIRECT| (*) | [This.I-D] | Redirection record. +--------+----------+---------+------------+--------------------+
65556 | EDKEY | (*) | [This.I-D] | GNS zone delegation (EDKEY) | 65538 | LEHO | (*) | RFC 9498 | GNS legacy |
| | | | | hostname |
+--------+----------+---------+------------+--------------------+
| 65540 | GNS2DNS | (*) | RFC 9498 | Delegation to DNS |
+--------+----------+---------+------------+--------------------+
| 65541 | BOX | (*) | RFC 9498 | Box records |
+--------+----------+---------+------------+--------------------+
| 65551 | REDIRECT | (*) | RFC 9498 | Redirection record |
+--------+----------+---------+------------+--------------------+
| 65556 | EDKEY | (*) | RFC 9498 | GNS zone |
| | | | | delegation (EDKEY) |
+--------+----------+---------+------------+--------------------+
| (*): gns-registry@gnunet.org |
+---------------------------------------------------------------+
(*): gns-registry@gnunet.org Table 2: The GANA GNS Record Types Registry
Figure 25: The GANA Resource Record Registry. 10.3. .alt Subdomains Registry
10.2. .alt Subdomains Registry GANA [GANA] manages the ".alt Subdomains" registry. This GANA-
operated .alt registry may or may not be taken into account by any
particular implementer, and it is not in any way associated with or
sanctioned by the IETF or ICANN.
GANA [GANA] manages the ".alt Subdomains" registry. Each entry has Each entry has the following format:
the following format:
* Label: The label of the subdomain (in DNS LDH format as defined in Label: The label of the subdomain (in DNS "letters, digits, hyphen"
Section 2.3.1 of [RFC5890]). (LDH) format as defined in Section 2.3.1 of [RFC5890]).
* Comment: Optionally, a brief English text describing the purpose Description: Optionally, brief English text describing the purpose
of the subdomain (in UTF-8) of the subdomain (in UTF-8).
* Contact: Optionally, the contact information of a person to Contact: Optionally, the contact information for a person to contact
contact for further information. for further information.
* References: Optionally, references describing the record type References: Optionally, references (such as an RFC) describing the
(such as an RFC). record type.
The registration policy for this registry is "First Come First The registration policy for this registry is "First Come First
Served". This policy is modeled on that described in [RFC8126], and Served". This policy is modeled on that described in [RFC8126] and
describes the actions taken by GANA: describes the actions taken by GANA:
Adding new entries is possible after review by any authorized GANA * Adding new entries is possible after review by any authorized GANA
contributor, using a first-come-first-served policy for unique contributor, using a first-come-first-served policy for unique
subdomain allocation. Reviewers are responsible to ensure that the subdomain allocation. Reviewers are responsible for ensuring that
chosen "Subdomain" is appropriate for the purpose. the chosen "Subdomain" is appropriate for the purpose.
Authorized GANA contributors for review of new entries are reachable * Authorized GANA contributors for review of new entries are
at alt-registry@gnunet.org. reachable at <alt-registry@gnunet.org>.
Any request MUST contain a unique subdomain and a point of contact. * Any request MUST contain a unique subdomain and a point of
The contact information MAY be added to the registry given the contact. The contact information MAY be added to the registry,
consent of the requester. The request MAY optionally also contain with the consent of the requester. The request MAY optionally
relevant references as well as a descriptive comment as defined also contain relevant references as well as a descriptive comment,
above. as defined above.
GANA has assigned the subdomain defined in this specification in the GANA has assigned the subdomain defined in this specification in the
".alt subdomains" registry as listed in Figure 26. ".alt Subdomains" registry as listed in Table 3.
Subdomain | Contact | References | Comment
----------+---------+------------+----------------------------
gns | (*) | [This.I-D] | The .alt subdomain for GNS.
(*): alt-registry@gnunet.org +=======+=========+============+============================+
| Label | Contact | References | Description |
+=======+=========+============+============================+
| gns | (*) | RFC 9498 | The .alt subdomain for GNS |
+-------+---------+------------+----------------------------+
| (*): alt-registry@gnunet.org |
+-----------------------------------------------------------+
Figure 26: The GANA .alt Subdomains Registry. Table 3: The GANA .alt Subdomains Registry
11. IANA Considerations 11. IANA Considerations
This document makes no requests for IANA action. This section may be This document has no IANA actions.
removed on publication as an RFC.
12. Implementation and Deployment Status 12. Implementation and Deployment Status
There are two implementations conforming to this specification There are two implementations conforming to this specification,
written in C and Go, respectively. The C implementation as part of written in C and Go, respectively. The C implementation as part of
GNUnet [GNUnetGNS] represents the original and reference GNUnet [GNUnetGNS] represents the original and reference
implementation. The Go implementation [GoGNS] demonstrates how two implementation. The Go implementation [GoGNS] demonstrates how two
implementations of GNS are interoperable if they are built on top of implementations of GNS are interoperable if they are built on top of
the same underlying DHT storage. the same underlying DHT storage.
Currently, the GNUnet peer-to-peer network [GNUnet] is an active Currently, the GNUnet peer-to-peer network [GNUnet] is an active
deployment of GNS on top of its [R5N] DHT. The [GoGNS] deployment of GNS on top of its DHT [R5N]. The Go implementation
implementation uses this deployment by building on top of the GNUnet [GoGNS] uses this deployment by building on top of the GNUnet DHT
DHT services available on any GNUnet peer. It shows how GNS services available on any GNUnet peer. It shows how GNS
implementations can attach to this existing deployment and implementations can attach to this existing deployment and
participate in name resolution as well as zone publication. participate in name resolution as well as zone publication.
The self-sovereign identity system re:claimID [reclaim] is using GNS The self-sovereign identity system re:claimID [reclaim] is using GNS
in order to selectively share identity attributes and attestations in order to selectively share identity attributes and attestations
with third parties. with third parties.
The Ascension tool [Ascension] facilitates the migration of DNS zones The Ascension tool [Ascension] facilitates the migration of DNS zones
to GNS zones by translating information retrieved from a DNS zone to GNS zones by translating information retrieved from a DNS zone
transfer into a GNS zone. transfer into a GNS zone.
13. Acknowledgements 13. References
The authors thank all reviewers for their comments. In particular,
we thank D. J. Bernstein, S. Bortzmeyer, A. Farrel, E. Lear and
R. Salz for their insightful and detailed technical reviews. We
thank J. Yao and J. Klensin for the internationalization reviews.
We thank NLnet and NGI DISCOVERY for funding work on the GNU Name
System.
14. Normative References 13.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
skipping to change at page 56, line 30 skipping to change at line 2567
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>. January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC9106] Biryukov, A., Dinu, D., Khovratovich, D., and S. [RFC9106] Biryukov, A., Dinu, D., Khovratovich, D., and S.
Josefsson, "Argon2 Memory-Hard Function for Password Josefsson, "Argon2 Memory-Hard Function for Password
Hashing and Proof-of-Work Applications", RFC 9106, Hashing and Proof-of-Work Applications", RFC 9106,
DOI 10.17487/RFC9106, September 2021, DOI 10.17487/RFC9106, September 2021,
<https://www.rfc-editor.org/info/rfc9106>. <https://www.rfc-editor.org/info/rfc9106>.
[GANA] GNUnet e.V., "GNUnet Assigned Numbers Authority (GANA)", [GANA] GNUnet e.V., "GNUnet Assigned Numbers Authority (GANA)",
November 2022, <https://gana.gnunet.org/>. 2023, <https://gana.gnunet.org/>.
[MODES] Dworkin, M., "Recommendation for Block Cipher Modes of [MODES] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Methods and Techniques", December 2001, Operation: Methods and Techniques", NIST Special
<https://doi.org/10.6028/NIST.SP.800-38A>. Publication 800-38A, DOI 10.6028/NIST.SP.800-38A, December
2001, <https://doi.org/10.6028/NIST.SP.800-38A>.
[CrockfordB32] [CrockfordB32]
Douglas, D., "Base32", March 2019, Crockford, D., "Base 32", March 2019,
<https://www.crockford.com/base32.html>. <https://www.crockford.com/base32.html>.
[XSalsa20] Bernstein, D., "Extending the Salsa20 nonce", 2011, [XSalsa20] Bernstein, D. J., "Extending the Salsa20 nonce", 2011,
<https://cr.yp.to/snuffle/xsalsa-20110204.pdf>. <https://cr.yp.to/papers.html#xsalsa>.
[Unicode-UAX15] [Unicode-UAX15]
The Unicode Consortium, "Unicode Standard Annex #15: Davis, M., Whistler, K., and M. Dürst, "Unicode Standard
Unicode Normalization Forms, Revision 31", September 2009, Annex #15: Unicode Normalization Forms", Revision 31, The
<http://www.unicode.org/reports/tr15/tr15-31.html>. Unicode Consortium, Mountain View, September 2009,
<https://www.unicode.org/reports/tr15/tr15-31.html>.
[Unicode-UTS46] [Unicode-UTS46]
The Unicode Consortium, "Unicode Technical Standard #46: Davis, M. and M. Suignard, "Unicode Technical Standard
Unicode IDNA Compatibility Processing, Revision 27", #46: Unicode IDNA Compatibility Processing", Revision 31,
August 2021, <https://www.unicode.org/reports/tr46>. The Unicode Consortium, Mountain View, September 2023,
<https://www.unicode.org/reports/tr46>.
15. Informative References 13.2. Informative References
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and
L. Jones, "SOCKS Protocol Version 5", RFC 1928, L. Jones, "SOCKS Protocol Version 5", RFC 1928,
DOI 10.17487/RFC1928, March 1996, DOI 10.17487/RFC1928, March 1996,
<https://www.rfc-editor.org/info/rfc1928>. <https://www.rfc-editor.org/info/rfc1928>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>. <https://www.rfc-editor.org/info/rfc4033>.
skipping to change at page 57, line 44 skipping to change at line 2632
<https://www.rfc-editor.org/info/rfc8806>. <https://www.rfc-editor.org/info/rfc8806>.
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
RFC 6761, DOI 10.17487/RFC6761, February 2013, RFC 6761, DOI 10.17487/RFC6761, February 2013,
<https://www.rfc-editor.org/info/rfc6761>. <https://www.rfc-editor.org/info/rfc6761>.
[RFC8244] Lemon, T., Droms, R., and W. Kumari, "Special-Use Domain [RFC8244] Lemon, T., Droms, R., and W. Kumari, "Special-Use Domain
Names Problem Statement", RFC 8244, DOI 10.17487/RFC8244, Names Problem Statement", RFC 8244, DOI 10.17487/RFC8244,
October 2017, <https://www.rfc-editor.org/info/rfc8244>. October 2017, <https://www.rfc-editor.org/info/rfc8244>.
[I-D.ietf-dnsop-alt-tld] [RFC9476] Kumari, W. and P. Hoffman, "The .alt Special-Use Top-Level
Kumari, W. A. and P. E. Hoffman, "The ALT Special Use Top Domain", RFC 9476, DOI 10.17487/RFC9476, September 2023,
Level Domain", Work in Progress, Internet-Draft, draft- <https://www.rfc-editor.org/info/rfc9476>.
ietf-dnsop-alt-tld-25, 4 May 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop- [TorRendSpec]
alt-tld-25>. Tor Project, "Tor Rendezvous Specification - Version 3",
commit b345ca0, June 2023,
<https://github.com/torproject/torspec/blob/main/rend-
spec-v3.txt>.
[Tor224] Goulet, D., Kadianakis, G., and N. Mathewson, "Next- [Tor224] Goulet, D., Kadianakis, G., and N. Mathewson, "Next-
Generation Hidden Services in Tor", November 2013, Generation Hidden Services in Tor", Appendix A.2 ("Tor's
key derivation scheme"), November 2013,
<https://gitweb.torproject.org/torspec.git/tree/ <https://gitweb.torproject.org/torspec.git/tree/
proposals/224-rend-spec-ng.txt#n2135>. proposals/224-rend-spec-ng.txt#n2135>.
[SDSI] Rivest, R. and B. Lampson, "SDSI - A Simple Distributed [SDSI] Rivest, R. L. and B. Lampson, "SDSI - A Simple Distributed
Security Infrastructure", April 1996, Security Infrastructure", October 1996,
<http://people.csail.mit.edu/rivest/Sdsi10.ps>. <https://citeseerx.ist.psu.edu/document?repid=rep1&type=pd
f&doi=3837e0206bf73e5e8f0ba6db767a2f714ea7c367>.
[Kademlia] Maymounkov, P. and D. Mazieres, "Kademlia: A peer-to-peer [Kademlia] Maymounkov, P. and D. Mazières, "Kademlia: A Peer-to-peer
information system based on the xor metric.", 2002, Information System Based on the XOR Metric",
<http://css.csail.mit.edu/6.824/2014/papers/kademlia.pdf>. DOI 10.1007/3-540-45748-8_5, 2002,
<https://css.csail.mit.edu/6.824/2014/papers/
kademlia.pdf>.
[ed25519] Bernstein, D., Duif, N., Lange, T., Schwabe, P., and B. [ed25519] Bernstein, D. J., Duif, N., Lange, T., Schwabe, P., and
Yang, "High-Speed High-Security Signatures", 2011, B-Y. Yang, "High-speed high-security signatures",
DOI 10.1007/s13389-012-0027-1, 2011,
<https://ed25519.cr.yp.to/ed25519-20110926.pdf>. <https://ed25519.cr.yp.to/ed25519-20110926.pdf>.
[GNS] Wachs, M., Schanzenbach, M., and C. Grothoff, "A [GNS] Wachs, M., Schanzenbach, M., and C. Grothoff, "A
Censorship-Resistant, Privacy-Enhancing and Fully Censorship-Resistant, Privacy-Enhancing and Fully
Decentralized Name System", 2014, Decentralized Name System", 13th International Conference
on Cryptology and Network Security (CANS),
DOI 10.13140/2.1.4642.3044, October 2014,
<https://sci-hub.st/10.1007/978-3-319-12280-9_9>. <https://sci-hub.st/10.1007/978-3-319-12280-9_9>.
[R5N] Evans, N. S. and C. Grothoff, "R5N: Randomized recursive [R5N] Evans, N. S. and C. Grothoff, "R5N: Randomized Recursive
routing for restricted-route networks", 2011, Routing for Restricted-Route Networks", 5th International
Conference on Network and System Security (NSS),
DOI 10.1109/ICNSS.2011.6060022, September 2011,
<https://sci-hub.st/10.1109/ICNSS.2011.6060022>. <https://sci-hub.st/10.1109/ICNSS.2011.6060022>.
[SecureNS] Grothoff, C., Wachs, M., Ermert, M., and J. Appelbaum, [SecureNS] Grothoff, C., Wachs, M., Ermert, M., and J. Appelbaum,
"Towards secure name resolution on the Internet", 2018, "Toward secure name resolution on the Internet", Computers
<https://sci-hub.st/https://doi.org/10.1016/ and Security, Volume 77, Issue C, pp. 694-708,
j.cose.2018.01.018>. DOI 10.1016/j.cose.2018.01.018, August 2018, <https://sci-
hub.st/https://doi.org/10.1016/j.cose.2018.01.018>.
[GNUnetGNS] [GNUnetGNS]
GNUnet e.V., "The GNUnet GNS Implementation", GNUnet e.V., "gnunet.git - GNUnet core repository", 2023,
<https://git.gnunet.org/gnunet.git/tree/src/gns>. <https://git.gnunet.org/gnunet.git>.
[Ascension] [Ascension]
GNUnet e.V., "The Ascension Implementation", GNUnet e.V., "ascension.git - DNS zones to GNS migrating
using incremental zone transfer (AXFR/IXFR)", 2023,
<https://git.gnunet.org/ascension.git>. <https://git.gnunet.org/ascension.git>.
[GNUnet] GNUnet e.V., "The GNUnet Project", <https://gnunet.org>. [GNUnet] GNUnet e.V., "The GNUnet Project (Home Page)", 2023,
<https://gnunet.org>.
[reclaim] GNUnet e.V., "re:claimID", <https://reclaim.gnunet.org>. [reclaim] GNUnet e.V., "re:claimID - Self-sovereign, Decentralised
Identity Management and Personal Data Sharing", 2023,
<https://reclaim.gnunet.org>.
[GoGNS] Fix, B., "The Go GNS Implementation", [GoGNS] Fix, B., "gnunet-go (Go GNS)", commit 5c815ba, July 2023,
<https://github.com/bfix/gnunet- <https://github.com/bfix/gnunet-
go/tree/master/src/gnunet/service/gns>. go/tree/master/src/gnunet/service/gns>.
[nsswitch] GNU Project, "System Databases and Name Service Switch", [nsswitch] GNU Project, "System Databases and Name Service Switch
(Section 29)",
<https://www.gnu.org/software/libc/manual/html_node/Name- <https://www.gnu.org/software/libc/manual/html_node/Name-
Service-Switch.html>. Service-Switch.html>.
Appendix A. Usage and Migration Appendix A. Usage and Migration
This section outlines a number of specific use cases which may help This section outlines a number of specific use cases that may help
readers of the technical specification to understand the protocol readers of this technical specification better understand the
better. The considerations below are not meant to be normative for protocol. The considerations below are not meant to be normative for
the GNS protocol in any way. Instead, they are provided in order to the GNS protocol in any way. Instead, they are provided in order to
give context and to provide some background on what the intended use give context and to provide some background on what the intended use
of the protocol is by its designers. Further, this section contains of the protocol is by its designers. Further, this section provides
pointers to migration paths. pointers to migration paths.
A.1. Zone Dissemination A.1. Zone Dissemination
In order to become a zone owner, it is sufficient to generate a zone In order to become a zone owner, it is sufficient to generate a zone
key and a corresponding secret key using a GNS implementation. At key and a corresponding secret key using a GNS implementation. At
this point, the zone owner can manage GNS resource records in a local this point, the zone owner can manage GNS resource records in a local
zone database. The resource records can then be published by a GNS zone database. The resource records can then be published by a GNS
implementation as defined in Section 6. For other users to resolve implementation as defined in Section 6. For other users to resolve
the resource records, respective zone information must be the resource records, the respective zone information must be
disseminated first. The zone owner may decide to make the zone key disseminated first. The zone owner may decide to make the zone key
and labels known to a selected set of users only or to make this and labels known to a selected set of users only or to make this
information available to the general public. information available to the general public.
Sharing zone information directly with specific users not only allows Sharing zone information directly with specific users not only allows
to potentially preserve zone and record privacy, but also allows the an implementation to potentially preserve zone and record privacy but
zone owner and the user to establish strong trust relationships. For also allows the zone owner and the user to establish strong trust
example, a bank may send a customer letter with a QR code which relationships. For example, a bank may send a customer letter with a
contains the GNS zone of the bank. This allows the user to scan the QR code that contains the GNS zone of the bank. This allows the user
QR code and establish a strong link to the zone of the bank and with to scan the QR code and establish a strong link to the zone of the
it, for example, the IP address of the online banking web site. bank and with it, for example, the IP address of the online banking
web site.
Most Internet services likely want to make their zones available to Most Internet services likely want to make their zones available to
the general public as efficiently as possible. First, it is the general public in the most efficient way possible. First, it is
reasonable to assume that zones which are commanding high levels of reasonable to assume that zones that are commanding high levels of
reputation and trust are likely included in the default suffix-to- reputation and trust are likely included in the default suffix-to-
zone mappings of implementations. Hence dissemination of a zone zone mappings of implementations. Hence, dissemination of a zone
through delegation under such zones can be a viable path in order to through delegation under such zones can be a viable path in order to
disseminate a zone publicly. For example, it is conceivable that disseminate a zone publicly. For example, it is conceivable that
organizations such as ICANN or country-code top-level domain organizations such as ICANN or country-code TLD registrars also
registrars also manage GNS zones and offer registration or delegation manage GNS zones and offer registration or delegation services.
services.
Following best practices in particularly those relating to security Following best practices, particularly those related to security and
and abuse mitigation are methods which allow zone owners and aspiring abuse mitigation, are methods that allow zone owners and aspiring
registrars to gain a good reputation and eventually trust. This registrars to gain a good reputation and, eventually, trust. This
includes, of course, diligent protection of private zone key includes, of course, diligent protection of private zone key
material. Formalizing such best practices is out of scope of this material. Formalizing such best practices is out of scope for this
specification and should be addressed in a separate document and take specification and should be addressed in a separate document that
Section 9 into account. takes Section 9 of this document into account.
A.2. Start Zone Configuration A.2. Start Zone Configuration
A user is expected to install a GNS implementation if it is not A user is expected to install a GNS implementation if it is not
already provided through other means such as the operating system or already provided through other means such as the operating system or
the browser. It is likely that the implementation ships with a the browser. It is likely that the implementation ships with a
default start zone configuration. This means that the user is able default Start Zone configuration. This means that the user is able
to resolve GNS names ending on a zTLD or ending on any suffix-to-name to resolve GNS names ending on a zTLD or ending on any suffix-to-name
mapping that is part of the default start zone configuration. At mapping that is part of the default Start Zone configuration. At
this point the user may delete or otherwise modify the this point, the user may delete or otherwise modify the
implementation's default configuration: implementation's default configuration:
Deletion of suffix-to-zone mappings may become necessary of the zone * Deletion of suffix-to-zone mappings may become necessary if the
owner referenced by the mapping has lost the trust of the user. For zone owner referenced by the mapping has lost the trust of the
example, this could be due to lax registration policies resulting in user. For example, this could be due to lax registration policies
phishing activities. Modification and addition of new mappings are resulting in phishing activities. Modification and addition of
means to heal the namespace perforation which would occur in the case new mappings are means to heal the namespace perforation that
of a deletion or to simply establish a strong direct trust would occur in the case of a deletion or to simply establish a
relationship. However, this requires the user's knowledge of the strong direct trust relationship. However, this requires the
respective zone keys. This information must be retrieved out of user's knowledge of the respective zone keys. This information
band, as illustrated in Appendix A.1: A bank may send the user a must be retrieved out of band, as illustrated in Appendix A.1: a
letter with a QR code which contains the GNS zone of the bank. The bank may send the user a letter with a QR code that contains the
user scans the QR code and adds a new suffix-to-name mapping using a GNS zone of the bank. The user scans the QR code and adds a new
chosen local name for his bank. Other examples include scanning zone suffix-to-name mapping using a chosen local name for their bank.
information off the device of a friend, from a storefront, or an Other examples include scanning zone information off the device of
advertisement. The level of trust in the respective zone is a friend, from a storefront, or from an advertisement. The level
contextual and likely varies from user to user. Trust in a zone of trust in the respective zone is contextual and likely varies
provided through a letter from a bank which may also include a credit from user to user. Trust in a zone provided through a letter from
card is certainly different from a zone found on a random a bank that may also include a credit card is certainly different
advertisement in the streets. However, this trust is immediately from a zone found on a random advertisement on the street.
tangible to the user and can be reflected in the local naming as However, this trust is immediately tangible to the user and can be
well. reflected in the local naming as well.
User clients should facilitate the modification of the start zone * Users that are also clients should facilitate the modification of
configuration, for example by providing a QR code reader or other the Start Zone configuration -- for example, by providing a QR
import mechanisms. Implementations are ideally implemented according code reader or other import mechanisms. Implementations are
to best practices and addressing applicable points from Section 9. ideally implemented according to best practices and addressing
Formalizing such best practices is out of scope of this applicable points from Section 9. Formalizing such best practices
specification. is out of scope for this specification.
A.3. Globally Unique Names and the Web A.3. Globally Unique Names and the Web
HTTP virtual hosting and TLS Server Name Indication are common use HTTP virtual hosting and TLS Server Name Indication (SNI) are common
cases on the Web. HTTP clients supply a DNS name in the HTTP "Host"- use cases on the Web. HTTP clients supply a DNS name in the HTTP
header or as part of the TLS handshake, respectively. This allows "Host"-header or as part of the TLS handshake, respectively. This
the HTTP server to serve the indicated virtual host with a matching allows the HTTP server to serve the indicated virtual host with a
TLS certificate. The global uniqueness of DNS names are a matching TLS certificate. The global uniqueness of DNS names is a
prerequisite of those use cases. prerequisite of those use cases.
Not all GNS names are globally unique. But, any resource record in Not all GNS names are globally unique. However, any resource record
GNS can be represented as a concatenation of of a GNS label and the in GNS can be represented as a concatenation of a GNS label and the
zTLD of the zone. While not human-readable, this globally unique GNS zTLD of the zone. While not memorable, this globally unique GNS name
name can be leveraged in order to facilitate the same use cases. can be leveraged in order to facilitate the same use cases. Consider
Consider the GNS name "www.example.gns" entered in a GNS-aware HTTP the GNS name "www.example.gns.alt" entered in a GNS-aware HTTP
client. At first, "www.example.gns" is resolved using GNS yielding a client. At first, "www.example.gns.alt" is resolved using GNS,
record set. Then, the HTTP client determines the virtual host as yielding a record set. Then, the HTTP client determines the virtual
follows: host as follows:
If there is a LEHO record (Section 5.3.1) containing If there is a LEHO record (Section 5.3.1) containing
"www.example.com" in the record set, then the HTTP client uses this "www.example.com" in the record set, then the HTTP client uses this
as the value of the "Host"-header field of the HTTP request: as the value of the "Host"-header field of the HTTP request:
GET / HTTP/1.1 GET / HTTP/1.1
Host: www.example.com Host: www.example.com
If there is no LEHO record in the record set, then the HTTP client In the absence of a LEHO record, an additional GNS resolution is
tries to find the zone of the record and translates the GNS name into required to check whether "www.example.gns.alt" itself points to a
a globally unique zTLD-representation before using it in the "Host"- zone delegation record, which implies that the record set that was
header field of the HTTP request: originally resolved is published under the apex label.
If it does, the unique GNS name is simply the zTLD representation of
the delegated zone:
GET / HTTP/1.1 GET / HTTP/1.1
Host: www.000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W Host: 000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W
In order to determine the canonical representation of the record with On the other hand, if there is no zone delegation record for
a zTLD, at most two queries are required: First, it must be checked "www.example.gns.alt", then the unique GNS name is the concatenation
whether "www.example.gns.alt" itself points to a zone delegation of the leftmost label (e.g., "www") and the zTLD representation of
record which would imply that the record set which was originally the zone:
resolved is published under the apex label. If it does, the unique
GNS name is simply the zTLD representation of the delegated zone:
GET / HTTP/1.1 GET / HTTP/1.1
Host: 000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W Host: www.000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W
If it does not, the unique GNS name is the concatenation of the label Note that this second GNS resolution does not require any additional
"www" and the zTLD representation of the zone as given in the example network operation, as only the local record processing differs as per
above. In any case, this representation is globally unique. As the exception mentioned in the last sentence of Section 7.3.4.
such, it can be configured by the HTTP server administrator as a
virtual host name and respective certificates may be issued.
If the HTTP client is a browser, the use of a unique GNS name for If the HTTP client is a browser, the use of a unique GNS name for
virtual hosting or TLS SNI does not necessarily have to be shown to virtual hosting or TLS SNI does not necessarily have to be shown to
the user. For example, the name in the URL bar may remain as the user. For example, the name in the URL bar may remain as
"www.example.gns.alt" even if the used unique name differs. "www.example.gns.alt" even if the used unique name in the "Host"-
header differs.
A.4. Migration Paths A.4. Migration Paths
DNS resolution is built into a variety of existing software DNS resolution is built into a variety of existing software
components. Most significantly operating systems and HTTP clients. components -- most significantly, operating systems and HTTP clients.
This section illustrates possible migration paths for both in order This section illustrates possible migration paths for both in order
to enable "legacy" applications to resolve GNS names. to enable legacy applications to resolve GNS names.
One way to efficiently facilitate the resolution of GNS names are One way to efficiently facilitate the resolution of GNS names is via
GNS-enabled DNS server implementations. Local DNS queries are GNS-enabled DNS server implementations. Local DNS queries are
thereby either rerouted or explicitly configured to be resolved by a thereby either rerouted or explicitly configured to be resolved by a
"DNS-to-GNS" server that runs locally. This DNS server tries to "DNS-to-GNS" server that runs locally. This DNS server tries to
interpret any incoming query for a name as a GNS resolution request. interpret any incoming query for a name as a GNS resolution request.
If no start zone can be found for the name and it does not end in a If no Start Zone can be found for the name and it does not end in a
zTLD, the server tries to resolve the name in DNS. Otherwise, the zTLD, the server tries to resolve the name in DNS. Otherwise, the
name is resolved in GNS. In the latter case, the resulting record name is resolved in GNS. In the latter case, the resulting record
set is converted to a DNS answer packet and is returned accordingly. set is converted to a DNS answer packet and is returned accordingly.
An implementation of a DNS-to-GNS server can be found in [GNUnet]. An implementation of a DNS-to-GNS server can be found in [GNUnet].
A similar approach is to use operating systems extensions such as the A similar approach is to use operating system extensions such as the
name service switch [nsswitch]. It allows the system administrator NSS [nsswitch]. It allows the system administrator to configure
to configure plugins which are used for hostname resolution. A GNS plugins that are used for hostname resolution. A GNS nsswitch plugin
name service switch plugin can be used in a similar fashion as the can be used in a fashion similar to that used for the DNS-to-GNS
"DNS-to-GNS" server. An implementation of a glibc-compatible server. An implementation of a glibc-compatible nsswitch plugin for
nsswitch plugin for GNS can be found in [GNUnet]. GNS can be found in [GNUnet].
The methods above are usually also effective for HTTP client The methods above are usually also effective for HTTP client
software. However, HTTP clients are commonly used in combination software. However, HTTP clients are commonly used in combination
with TLS. TLS certificate validation and in particular server name with TLS. TLS certificate validation, and SNI in particular, require
indication (SNI) requires additional logic in HTTP clients when GNS additional logic in HTTP clients when GNS names are in play
names are in play (Appendix A.3). In order to transparently enable (Appendix A.3). In order to transparently enable this functionality
this functionality for migration purposes, a local GNS-aware SOCKS5 for migration purposes, a local GNS-aware SOCKS5 proxy [RFC1928] can
proxy [RFC1928] can be configured to resolve domain names. The be configured to resolve domain names. The SOCKS5 proxy, similar to
SOCKS5 proxy, similar to the DNS-to-GNS server, is capable of the DNS-to-GNS server, is capable of resolving both GNS and DNS
resolving both GNS and DNS names. In the event of a TLS connection names. In the event of a TLS connection request with a GNS name, the
request with a GNS name, the SOCKS5 proxy can act as a man-in-the- SOCKS5 proxy can terminate the TLS connection and establish a secure
middle, terminating the TLS connection and establishing a secure
connection against the requested host. In order to establish a connection against the requested host. In order to establish a
secure connection, the proxy may use LEHO and TLSA records stored in secure connection, the proxy may use LEHO and TLSA records stored in
the record set under the GNS name. The proxy must provide a locally the record set under the GNS name. The proxy must provide a locally
trusted certificate for the GNS name to the HTTP client which usually trusted certificate for the GNS name to the HTTP client; this usually
requires the generation and configuration of a local trust anchor in requires the generation and configuration of a local trust anchor in
the browser. An implementation of this SOCKS5 proxy can be found in the browser. An implementation of this SOCKS5 proxy can be found in
[GNUnet]. [GNUnet].
Appendix B. Example flows Appendix B. Example Flows
B.1. AAAA Example Resolution B.1. AAAA Example Resolution
Local Host | Remote Local Host | Remote
| Storage | Storage
| |
| +---------+ | +---------+
| / /| | / /|
| +---------+ | | +---------+ |
+-----------+ (1) +----------+ | | | | +-----------+ (1) +----------+ | | | |
skipping to change at page 63, line 34 skipping to change at line 2922
| | | |
+---------+ | +---------+ |
/ v /| | / v /| |
+---------+ | | +---------+ | |
| | | | | | | |
| Start | | | | Start | | |
| Zones | | | | Zones | | |
| |/ | | |/ |
+---------+ | +---------+ |
Figure 27: Example resolution of an IPv6 address. Figure 24: Example Resolution of an IPv6 Address
1. Lookup AAAA record for name: www.example.gnu.gns.alt. 1. Look up AAAA record for name: "www.example.gnu.gns.alt".
2. Determine start zone for www.example.gnu.gns.alt. 2. Determine Start Zone for "www.example.gnu.gns.alt".
3. Start zone: zk0 - Remainder: www.example. 3. Start Zone: zkey0 - Remainder: "www.example".
4. Calculate q0=SHA512(ZKDF(zk0, "example")) and initiate GET(q0). 4. Calculate q0=SHA512(ZKDF(zkey0, "example")) and initiate GET(q0).
5. Retrieve and decrypt RRBLOCK consisting of a single PKEY record 5. Retrieve and decrypt RRBLOCK consisting of a single PKEY record
containing zk1. containing zkey1.
6. Calculate q1=SHA512(ZKDF(zk1, "www")) and initiate GET(q1). 6. Calculate q1=SHA512(ZKDF(zkey1, "www")) and initiate GET(q1).
7. Retrieve RRBLOCK consisting of a single AAAA record containing 7. Retrieve RRBLOCK consisting of a single AAAA record containing
the IPv6 address 2001:db8::1. the IPv6 address 2001:db8::1.
8. Return record set to application 8. Return record set to application.
B.2. REDIRECT Example Resolution B.2. REDIRECT Example Resolution
Local Host | Remote Local Host | Remote
| Storage | Storage
| |
| +---------+ | +---------+
| / /| | / /|
| +---------+ | | +---------+ |
+-----------+ (1) +----------+ | | | | +-----------+ (1) +----------+ | | | |
skipping to change at page 64, line 32 skipping to change at line 2969
| | | |
+---------+ | +---------+ |
/ v /| | / v /| |
+---------+ | | +---------+ | |
| | | | | | | |
| Start | | | | Start | | |
| Zones | | | | Zones | | |
| |/ | | |/ |
+---------+ | +---------+ |
Figure 28: Example resolution of an IPv6 address with redirect. Figure 25: Example Resolution of an IPv6 Address with Redirect
1. Lookup AAAA record for name: www.example.tld.gns.alt. 1. Look up AAAA record for name: "www.example.tld.gns.alt".
2. Determine start zone for www.example.tld.gns.alt. 2. Determine Start Zone for "www.example.tld.gns.alt".
3. Start zone: zk0 - Remainder: www.example. 3. Start Zone: zkey0 - Remainder: "www.example".
4. Calculate q0=SHA512(ZKDF(zk0, "example")) and initiate GET(q0). 4. Calculate q0=SHA512(ZKDF(zkey0, "example")) and initiate
GET(q0).
5. Retrieve and decrypt RRBLOCK consisting of a single PKEY record 5. Retrieve and decrypt RRBLOCK consisting of a single PKEY record
containing zk1. containing zkey1.
6. Calculate q1=SHA512(ZKDF(zk1, "www")) and initiate GET(q1). 6. Calculate q1=SHA512(ZKDF(zkey1, "www")) and initiate GET(q1).
7. Retrieve and decrypt RRBLOCK consisting of a single REDIRECT 7. Retrieve and decrypt RRBLOCK consisting of a single REDIRECT
record containing www2.+. record containing "www2.+".
8. Calculate q2=SHA512(ZKDF(zk1, "www2")) and initiate GET(q2). 8. Calculate q2=SHA512(ZKDF(zkey1, "www2")) and initiate GET(q2).
9. Retrieve and decrypt RRBLOCK consisting of a single AAAA record 9. Retrieve and decrypt RRBLOCK consisting of a single AAAA record
containing the IPv6 address 2001:db8::1. containing the IPv6 address 2001:db8::1.
10. Return record set to application. 10. Return record set to application.
B.3. GNS2DNS Example Resolution B.3. GNS2DNS Example Resolution
Local Host | Remote Local Host | Remote
| Storage | Storage
skipping to change at page 65, line 30 skipping to change at line 3015
|Application|----------| Resolver |------------------|->| Storage | | |Application|----------| Resolver |------------------|->| Storage | |
| |<---------| |<-----------------|--| |/ | |<---------| |<-----------------|--| |/
+-----------+ (8) +----------+ (5) | +---------+ +-----------+ (8) +----------+ (5) | +---------+
A A | A A |
| | (6,7) | | | (6,7) |
(2,3) | +----------+ | (2,3) | +----------+ |
| | | | | |
| v | | v |
+---------+ +------------+ | +---------+ +------------+ |
/ v /| | System DNS | | / v /| | System DNS | |
+---------+ | | resolver | | +---------+ | | Resolver | |
| | | +------------+ | | | | +------------+ |
| Start | | | | Start | | |
| Zones | | | | Zones | | |
| |/ | | |/ |
+---------+ | +---------+ |
Figure 29: Example resolution of an IPv6 address with DNS handover. Figure 26: Example Resolution of an IPv6 Address with DNS Handover
1. Lookup AAAA record for name: www.example.gnu.gns.alt 1. Look up AAAA record for name: "www.example.gnu.gns.alt".
2. Determine start zone for www.example.gnu.gns.alt. 2. Determine Start Zone for "www.example.gnu.gns.alt".
3. Start zone: zk0 - Remainder: www.example. 3. Start Zone: zkey0 - Remainder: "www.example".
4. Calculate q0=SHA512(ZKDF(zk0, "example")) and initiate GET(q0). 4. Calculate q0=SHA512(ZKDF(zkey0, "example")) and initiate GET(q0).
5. Retrieve and decrypt RRBLOCK consisting of a single GNS2DNS 5. Retrieve and decrypt RRBLOCK consisting of a single GNS2DNS
record containing the name example.com and the DNS server IPv4 record containing the name "example.com" and the DNS server IPv4
address 192.0.2.1. address 192.0.2.1.
6. Use system resolver to lookup an AAAA record for the DNS name 6. Use system resolver to look up a AAAA record for the DNS name
www.example.com. "www.example.com".
7. Retrieve a DNS reply consisting of a single AAAA record 7. Retrieve a DNS reply consisting of a single AAAA record
containing the IPv6 address 2001:db8::1. containing the IPv6 address 2001:db8::1.
8. Return record set to application. 8. Return record set to application.
Appendix C. Base32GNS Appendix C. Base32GNS
Encoding converts a byte array into a string of symbols. Decoding Encoding converts a byte array into a string of symbols. Decoding
converts a string of symbols into a byte array. Decoding fails if converts a string of symbols into a byte array. Decoding fails if
the input string has symbols outside the defined set. the input string has symbols outside the defined set.
This table defines the encode and decode symbols for a given symbol Table 4 defines the encoding and decoding symbols for a given symbol
value. Each symbol value encodes 5 bits. It can be used to value. Each symbol value encodes 5 bits. It can be used to
implement the encoding by reading it as: A symbol "A" or "a" is implement the encoding by reading it as follows: a symbol "A" or "a"
decoded to a 5 bit value 10 when decoding. A 5 bit block with 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 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 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 padded to the next multiple with zeroes. In order to further
increase tolerance for failures in character recognition, the letter increase tolerance for failures in character recognition, the letter
"U" MUST be decoded to the same value as the letter "V" in Base32GNS. "U" MUST be decoded to the same value as the letter "V" in Base32GNS.
Symbol Decode Encode +==============+=================+=================+
Value Symbol Symbol | Symbol Value | Decoding Symbol | Encoding Symbol |
0 0 O o 0 +==============+=================+=================+
1 1 I i L l 1 | 0 | 0 O o | 0 |
2 2 2 +--------------+-----------------+-----------------+
3 3 3 | 1 | 1 I i L l | 1 |
4 4 4 +--------------+-----------------+-----------------+
5 5 5 | 2 | 2 | 2 |
6 6 6 +--------------+-----------------+-----------------+
7 7 7 | 3 | 3 | 3 |
8 8 8 +--------------+-----------------+-----------------+
9 9 9 | 4 | 4 | 4 |
10 A a A +--------------+-----------------+-----------------+
11 B b B | 5 | 5 | 5 |
12 C c C +--------------+-----------------+-----------------+
13 D d D | 6 | 6 | 6 |
14 E e E +--------------+-----------------+-----------------+
15 F f F | 7 | 7 | 7 |
16 G g G +--------------+-----------------+-----------------+
17 H h H | 8 | 8 | 8 |
18 J j J +--------------+-----------------+-----------------+
19 K k K | 9 | 9 | 9 |
20 M m M +--------------+-----------------+-----------------+
21 N n N | 10 | A a | A |
22 P p P +--------------+-----------------+-----------------+
23 Q q Q | 11 | B b | B |
24 R r R +--------------+-----------------+-----------------+
25 S s S | 12 | C c | C |
26 T t T +--------------+-----------------+-----------------+
27 V v U u V | 13 | D d | D |
28 W w W +--------------+-----------------+-----------------+
29 X x X | 14 | E e | E |
30 Y y Y +--------------+-----------------+-----------------+
31 Z z Z | 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 30: The Base32GNS Alphabet Including the Additional U Table 4: The Base32GNS Alphabet, Including the
Encode Symbol. Additional Encoding Symbol "U"
Appendix D. Test Vectors Appendix D. Test Vectors
The following test vectors can be used by implementations to test for The following test vectors can be used by implementations to test for
conformance with this specification. Unless indicated otherwise, the conformance with this specification. Unless indicated otherwise, the
test vectors are provided as hexadecimal byte arrays. test vectors are provided as hexadecimal byte arrays.
D.1. Base32GNS en-/decoding D.1. Base32GNS Encoding/Decoding
The following are test vectors for the Base32GNS encoding used for The following are test vectors for the Base32GNS encoding used for
zTLDs. The input strings are encoded without the zero terminator. zTLDs. The input strings are encoded without the zero terminator.
Base32GNS-Encode: Base32GNS-Encode:
Input string: "Hello World" Input string: "Hello World"
Output string: "91JPRV3F41BPYWKCCG" Output string: "91JPRV3F41BPYWKCCG"
Input bytes: 474e55204e616d652053797374656d Input bytes: 474e55204e616d652053797374656d
Output string: "8X75A82EC5PPA82KF5SQ8SBD" Output string: "8X75A82EC5PPA82KF5SQ8SBD"
Base32GNS-Decode: Base32GNS-Decode:
Input string: "91JPRV3F41BPYWKCCG" Input string: "91JPRV3F41BPYWKCCG"
Output string: "Hello World" Output string: "Hello World"
Input string: "91JPRU3F41BPYWKCCG" Input string: "91JPRU3F41BPYWKCCG"
Output string: "Hello World" Output string: "Hello World"
D.2. Record sets D.2. Record Sets
The test vectors include record sets with a variety of record types The test vectors include record sets with a variety of record types
and flags for both PKEY and EDKEY zones. This includes labels with and flags for both PKEY and EDKEY zones. This includes labels with
UTF-8 characters to demonstrate internationalized labels. UTF-8 characters to demonstrate internationalized labels.
*(1) PKEY zone with ASCII label and one delegation record* *(1) PKEY zone with ASCII label and one delegation record*
Zone private key (d, big-endian): Zone private key (d, big-endian):
50 d7 b6 52 a4 ef ea df 50 d7 b6 52 a4 ef ea df
f3 73 96 90 97 85 e5 95 f3 73 96 90 97 85 e5 95
skipping to change at page 69, line 50 skipping to change at line 3234
Storage key (q): Storage key (q):
4a dc 67 c5 ec ee 9f 76 4a dc 67 c5 ec ee 9f 76
98 6a bd 71 c2 22 4a 3d 98 6a bd 71 c2 22 4a 3d
ce 2e 91 70 26 c9 a0 9d ce 2e 91 70 26 c9 a0 9d
fd 44 ce f3 d2 0f 55 a2 fd 44 ce f3 d2 0f 55 a2
73 32 72 5a 6c 8a fb bb 73 32 72 5a 6c 8a fb bb
b0 f7 ec 9a f1 cc 42 64 b0 f7 ec 9a f1 cc 42 64
12 99 40 6b 04 fd 9b 5b 12 99 40 6b 04 fd 9b 5b
57 91 f8 6c 4b 08 d5 f4 57 91 f8 6c 4b 08 d5 f4
ZKDF(zkey): ZKDF(zkey, label):
18 2b b6 36 ed a7 9f 79 18 2b b6 36 ed a7 9f 79
57 11 bc 27 08 ad bb 24 57 11 bc 27 08 ad bb 24
2a 60 44 6a d3 c3 08 03 2a 60 44 6a d3 c3 08 03
12 1d 03 d3 48 b7 ce b6 12 1d 03 d3 48 b7 ce b6
Derived private key (d', big-endian): Derived private key (d', big-endian):
0a 4c 5e 0f 00 63 df ce 0a 4c 5e 0f 00 63 df ce
db c8 c7 f2 b2 2c 03 0c db c8 c7 f2 b2 2c 03 0c
86 28 b2 c2 cb ac 9f a7 86 28 b2 c2 cb ac 9f a7
29 aa e6 1f 89 db 3e 9c 29 aa e6 1f 89 db 3e 9c
skipping to change at page 73, line 21 skipping to change at line 3391
Storage key (q): Storage key (q):
af f0 ad 6a 44 09 73 68 af f0 ad 6a 44 09 73 68
42 9a c4 76 df a1 f3 4b 42 9a c4 76 df a1 f3 4b
ee 4c 36 e7 47 6d 07 aa ee 4c 36 e7 47 6d 07 aa
64 63 ff 20 91 5b 10 05 64 63 ff 20 91 5b 10 05
c0 99 1d ef 91 fc 3e 10 c0 99 1d ef 91 fc 3e 10
90 9f 87 02 c0 be 40 43 90 9f 87 02 c0 be 40 43
67 78 c7 11 f2 ca 47 d5 67 78 c7 11 f2 ca 47 d5
5c f0 b5 4d 23 5d a9 77 5c f0 b5 4d 23 5d a9 77
ZKDF(zkey): ZKDF(zkey, label):
a5 12 96 df 75 7e e2 75 a5 12 96 df 75 7e e2 75
ca 11 8d 4f 07 fa 7a ae ca 11 8d 4f 07 fa 7a ae
55 08 bc f5 12 aa 41 12 55 08 bc f5 12 aa 41 12
14 29 d4 a0 de 9d 05 7e 14 29 d4 a0 de 9d 05 7e
Derived private key (d', big-endian): Derived private key (d', big-endian):
0a be 56 d6 80 68 ab 40 0a be 56 d6 80 68 ab 40
e1 44 79 0c de 9a cf 4d e1 44 79 0c de 9a cf 4d
78 7f 2d 3c 63 b8 53 05 78 7f 2d 3c 63 b8 53 05
74 6e 68 03 32 15 f2 ab 74 6e 68 03 32 15 f2 ab
skipping to change at page 74, line 34 skipping to change at line 3453
ac 9b c1 3d 9c 6f e8 29 ac 9b c1 3d 9c 6f e8 29
05 25 d2 a6 d0 f8 84 42 05 25 d2 a6 d0 f8 84 42
67 a1 57 0e 8e 29 4d c9 67 a1 57 0e 8e 29 4d c9
3a 31 9f cf c0 3e a2 70 3a 31 9f cf c0 3e a2 70
17 d6 fd a3 47 b4 a7 94 17 d6 fd a3 47 b4 a7 94
97 d7 f6 b1 42 2d 4e dd 97 d7 f6 b1 42 2d 4e dd
82 1c 19 93 4e 96 c1 aa 82 1c 19 93 4e 96 c1 aa
87 76 57 25 d4 94 c7 64 87 76 57 25 d4 94 c7 64
b1 55 dc 6d 13 26 91 74 b1 55 dc 6d 13 26 91 74
*(3) EDKEY zone with ASCII label and delegation record* *(3) EDKEY zone with ASCII label and one delegation record*
Zone private key (d): Zone private key (d):
5a f7 02 0e e1 91 60 32 5a f7 02 0e e1 91 60 32
88 32 35 2b bc 6a 68 a8 88 32 35 2b bc 6a 68 a8
d7 1a 7c be 1b 92 99 69 d7 1a 7c be 1b 92 99 69
a7 c6 6d 41 5a 0d 8f 65 a7 c6 6d 41 5a 0d 8f 65
Zone identifier (ztype|zkey): Zone identifier (ztype|zkey):
00 01 00 14 3c f4 b9 24 00 01 00 14 3c f4 b9 24
03 20 22 f0 dc 50 58 14 03 20 22 f0 dc 50 58 14
skipping to change at page 76, line 11 skipping to change at line 3526
Storage key (q): Storage key (q):
ab aa ba c0 e1 24 94 59 ab aa ba c0 e1 24 94 59
75 98 83 95 aa c0 24 1e 75 98 83 95 aa c0 24 1e
55 59 c4 1c 40 74 e2 55 55 59 c4 1c 40 74 e2 55
7b 9f e6 d1 54 b6 14 fb 7b 9f e6 d1 54 b6 14 fb
cd d4 7f c7 f5 1d 78 6d cd d4 7f c7 f5 1d 78 6d
c2 e0 b1 ec e7 60 37 c0 c2 e0 b1 ec e7 60 37 c0
a1 57 8c 38 4e c6 1d 44 a1 57 8c 38 4e c6 1d 44
56 36 a9 4e 88 03 29 e9 56 36 a9 4e 88 03 29 e9
ZKDF(zkey): ZKDF(zkey, label):
9b f2 33 19 8c 6d 53 bb 9b f2 33 19 8c 6d 53 bb
db ac 49 5c ab d9 10 49 db ac 49 5c ab d9 10 49
a6 84 af 3f 40 51 ba ca a6 84 af 3f 40 51 ba ca
b0 dc f2 1c 8c f2 7a 1a b0 dc f2 1c 8c f2 7a 1a
nonce := SHA-256 (dh[32..63] || h): nonce := SHA-256(dh[32..63] || h):
14 f2 c0 6b ed c3 aa 2d 14 f2 c0 6b ed c3 aa 2d
f0 71 13 9c 50 39 34 f3 f0 71 13 9c 50 39 34 f3
4b fa 63 11 a8 52 f2 11 4b fa 63 11 a8 52 f2 11
f7 3a df 2e 07 61 ec 35 f7 3a df 2e 07 61 ec 35
Derived private key (d', big-endian): Derived private key (d', big-endian):
3b 1b 29 d4 23 0b 10 a8 3b 1b 29 d4 23 0b 10 a8
ec 4d a3 c8 6e db 88 ea ec 4d a3 c8 6e db 88 ea
cd 54 08 5c 1d db 63 f7 cd 54 08 5c 1d db 63 f7
a9 d7 3f 7c cb 2f c3 98 a9 d7 3f 7c cb 2f c3 98
skipping to change at page 79, line 36 skipping to change at line 3694
Storage key (q): Storage key (q):
ba f8 21 77 ee c0 81 e0 ba f8 21 77 ee c0 81 e0
74 a7 da 47 ff c6 48 77 74 a7 da 47 ff c6 48 77
58 fb 0d f0 1a 6c 7f bb 58 fb 0d f0 1a 6c 7f bb
52 fc 8a 31 be f0 29 af 52 fc 8a 31 be f0 29 af
74 aa 0d c1 5a b8 e2 fa 74 aa 0d c1 5a b8 e2 fa
7a 54 b4 f5 f6 37 f6 15 7a 54 b4 f5 f6 37 f6 15
8f a7 f0 3c 3f ce be 78 8f a7 f0 3c 3f ce be 78
d3 f9 d6 40 aa c0 d1 ed d3 f9 d6 40 aa c0 d1 ed
ZKDF(zkey): ZKDF(zkey, label):
74 f9 00 68 f1 67 69 53 74 f9 00 68 f1 67 69 53
52 a8 a6 c2 eb 98 48 98 52 a8 a6 c2 eb 98 48 98
c5 3a cc a0 98 04 70 c6 c5 3a cc a0 98 04 70 c6
c8 12 64 cb dd 78 ad 11 c8 12 64 cb dd 78 ad 11
nonce := SHA-256 (dh[32..63] || h): nonce := SHA-256(dh[32..63] || h):
f8 6a b5 33 8a 74 d7 a1 f8 6a b5 33 8a 74 d7 a1
d2 77 ea 11 ff 95 cb e8 d2 77 ea 11 ff 95 cb e8
3a cf d3 97 3b b4 ab ca 3a cf d3 97 3b b4 ab ca
0a 1b 60 62 c3 7a b3 9c 0a 1b 60 62 c3 7a b3 9c
Derived private key (d', big-endian): Derived private key (d', big-endian):
17 c0 68 a6 c3 f7 20 de 17 c0 68 a6 c3 f7 20 de
0e 1b 69 ff 3f 53 e0 5d 0e 1b 69 ff 3f 53 e0 5d
3f e5 c5 b0 51 25 7a 89 3f e5 c5 b0 51 25 7a 89
a6 3c 1a d3 5a c4 35 58 a6 3c 1a d3 5a c4 35 58
skipping to change at page 81, line 12 skipping to change at line 3766
cf ca bb dd a8 de 3c 86 cf ca bb dd a8 de 3c 86
ed e2 95 70 d0 17 4b 82 ed e2 95 70 d0 17 4b 82
82 09 48 a9 28 b7 f0 0e 82 09 48 a9 28 b7 f0 0e
fb 40 1c 10 fe 80 bb bb fb 40 1c 10 fe 80 bb bb
02 76 33 1b f7 f5 1b 8d 02 76 33 1b f7 f5 1b 8d
74 57 9c 14 14 f2 2d 50 74 57 9c 14 14 f2 2d 50
1a d2 5a e2 49 f5 bb f2 1a d2 5a e2 49 f5 bb f2
a6 c3 72 59 d1 75 e4 40 a6 c3 72 59 d1 75 e4 40
b2 94 39 c6 05 19 cb b1 b2 94 39 c6 05 19 cb b1
D.3. Zone revocation D.3. Zone Revocation
The following is an example revocation for a PKEY zone: The following is an example revocation for a PKEY zone:
Zone private key (d, big-endian): Zone private key (d, big-endian):
6f ea 32 c0 5a f5 8b fa 6f ea 32 c0 5a f5 8b fa
97 95 53 d1 88 60 5f d5 97 95 53 d1 88 60 5f d5
7d 8b f9 cc 26 3b 78 d5 7d 8b f9 cc 26 3b 78 d5
f7 47 8c 07 b9 98 ed 70 f7 47 8c 07 b9 98 ed 70
Zone identifier (ztype|zkey): Zone identifier (ztype|zkey):
00 01 00 00 2c a2 23 e8 00 01 00 00 2c a2 23 e8
79 ec c4 bb de b5 da 17 79 ec c4 bb de b5 da 17
31 92 81 d6 3b 2e 3b 69 31 92 81 d6 3b 2e 3b 69
55 f1 c3 77 5c 80 4a 98 55 f1 c3 77 5c 80 4a 98
d5 f8 dd aa d5 f8 dd aa
Encoded zone identifier (zkl = zTLD): zTLD:
000G001CM8HYGYFCRJXXXDET2WRS50EP7CQ3PTANY71QEQ409ACDBY6XN8 000G001CM8HYGYFCRJXXXDET2WRS50EP7CQ3PTANY71QEQ409ACDBY6XN8
Difficulty (5 base difficulty + 2 epochs): 7 Difficulty (5 base difficulty + 2 epochs): 7
Signed message: Signed message:
00 00 00 34 00 00 00 03 00 00 00 34 00 00 00 03
00 05 ff 1c 56 e4 b2 68 00 05 ff 1c 56 e4 b2 68
00 01 00 00 2c a2 23 e8 00 01 00 00 2c a2 23 e8
79 ec c4 bb de b5 da 17 79 ec c4 bb de b5 da 17
31 92 81 d6 3b 2e 3b 69 31 92 81 d6 3b 2e 3b 69
skipping to change at page 83, line 18 skipping to change at line 3861
d7 1a 7c be 1b 92 99 69 d7 1a 7c be 1b 92 99 69
a7 c6 6d 41 5a 0d 8f 65 a7 c6 6d 41 5a 0d 8f 65
Zone identifier (ztype|zkey): Zone identifier (ztype|zkey):
00 01 00 14 3c f4 b9 24 00 01 00 14 3c f4 b9 24
03 20 22 f0 dc 50 58 14 03 20 22 f0 dc 50 58 14
53 b8 5d 93 b0 47 b6 3d 53 b8 5d 93 b0 47 b6 3d
44 6c 58 45 cb 48 44 5d 44 6c 58 45 cb 48 44 5d
db 96 68 8f db 96 68 8f
Encoded zone identifier (zkl = zTLD): zTLD:
000G051WYJWJ80S04BRDRM2R2H9VGQCKP13VCFA4DHC4BJT88HEXQ5K8HW 000G051WYJWJ80S04BRDRM2R2H9VGQCKP13VCFA4DHC4BJT88HEXQ5K8HW
Difficulty (5 base difficulty + 2 epochs): 7 Difficulty (5 base difficulty + 2 epochs): 7
Signed message: Signed message:
00 00 00 34 00 00 00 03 00 00 00 34 00 00 00 03
00 05 ff 1c 57 35 42 bd 00 05 ff 1c 57 35 42 bd
00 01 00 14 3c f4 b9 24 00 01 00 14 3c f4 b9 24
03 20 22 f0 dc 50 58 14 03 20 22 f0 dc 50 58 14
53 b8 5d 93 b0 47 b6 3d 53 b8 5d 93 b0 47 b6 3d
skipping to change at page 84, line 32 skipping to change at line 3924
db 96 68 8f 04 ae 26 f7 db 96 68 8f 04 ae 26 f7
63 56 5a b7 aa ab 01 71 63 56 5a b7 aa ab 01 71
72 4f 3c a8 bc c5 1a 98 72 4f 3c a8 bc c5 1a 98
b7 d4 c9 2e a3 3c d9 34 b7 d4 c9 2e a3 3c d9 34
4c a8 b6 3e 04 53 3a bf 4c a8 b6 3e 04 53 3a bf
1a 3c 05 49 16 b3 68 2c 1a 3c 05 49 16 b3 68 2c
5c a8 cb 4d d0 f8 4c 3b 5c a8 cb 4d d0 f8 4c 3b
77 48 7a ac 6e ce 38 48 77 48 7a ac 6e ce 38 48
0b a9 d5 00 0b a9 d5 00
Acknowledgements
The authors thank all reviewers for their comments. In particular,
we thank D. J. Bernstein, S. Bortzmeyer, A. Farrel, E. Lear, and
R. Salz for their insightful and detailed technical reviews. We
thank J. Yao and J. Klensin for the internationalization reviews. We
thank Dr. J. Appelbaum for suggesting the name "GNU Name System" and
Dr. Richard Stallman for approving its use. We thank T. Lange and
M. Wachs for their earlier contributions to the design and
implementation of GNS. We thank NLnet and NGI DISCOVERY for funding
work on the GNU Name System.
Authors' Addresses Authors' Addresses
Martin Schanzenbach Martin Schanzenbach
Fraunhofer AISEC Fraunhofer AISEC
Lichtenbergstrasse 11 Lichtenbergstrasse 11
85748 Garching 85748 Garching
Germany Germany
Email: martin.schanzenbach@aisec.fraunhofer.de Email: martin.schanzenbach@aisec.fraunhofer.de
Christian Grothoff Christian Grothoff
 End of changes. 489 change blocks. 
1353 lines changed or deleted 1449 lines changed or added

This html diff was produced by rfcdiff 1.48.