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