RFC 9498 | The GNU Name System | November 2023 |
Schanzenbach, et al. | Informational | [Page] |
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).¶
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 (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.¶
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.¶
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.¶
GNS exhibits the three properties that are commonly used to describe a petname system:¶
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).¶
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.¶
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].¶
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.¶
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.¶
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:¶
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.¶
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.¶
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]¶
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:¶
Figure 4 illustrates the format of the data "P" on which the PoW is calculated.¶
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:¶
The revocation message wire format is illustrated in Figure 5.¶
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.¶
In order to validate a revocation, the following steps MUST be taken:¶
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).¶
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.¶
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:¶
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.¶
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.¶
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:¶
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.¶
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.¶
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:¶
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.¶
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.¶
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.¶
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.¶
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].¶
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.¶
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.¶
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].¶
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.¶
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.¶
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.¶
Storage key derivation and record block creation are specified in the following sections and illustrated in Figure 19.¶
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))¶
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.¶
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.¶
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.¶
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.¶
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.¶
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:¶
Once a well-formed block has been decrypted, the records from RDATA are subjected to 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:¶
Finally, if none of the above cases are applicable, resolution fails and the resolver MUST return an empty record set.¶
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.¶
A resolver returns GNS2DNS records when all of the following conditions are met:¶
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.¶
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.¶
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.¶
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.¶
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].¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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:¶
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.¶
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.¶
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.¶
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 |
GANA [GANA] manages the "GNS Record Types" registry.¶
Each entry has the following format:¶
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:¶
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) |
(*): gns-registry@gnunet.org |
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:¶
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:¶
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 |
(*): alt-registry@gnunet.org |
This document has no IANA actions.¶
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.¶
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.¶
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 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:¶
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:¶
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:¶
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:¶
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.¶
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].¶
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 |
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.¶
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"¶
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¶
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¶
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.¶