The GNU Name System

4.1. Zone Top-Level Domain

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|       ZONE TYPE       |      ZONE KEY         /
+-----+-----+-----+-----+                       /
/                                               /
/                                               /

The decoded binary representation of the zTLD¶

The zTLD is the Zone Top-Level Domain. It is a string which encodes the zone type and zone key into a domain name. The zTLD is used as a globally unique reference to a specific namespace in the process of name resolution. To encode the zone key, a zone key label zkl is derived from a concatenation of the zone type and zone key (see Figure 1). The result is encoded using a variation of the Crockford Base32 encoding [CrockfordB32] called Base32GNS. The encoding and decoding symbols for Base32GNS including this modification are defined in Figure 23. The functions for encoding and decoding based on this table are called Base32GNS-Encode and Base32GNS-Decode, respectively.¶

For the string representation of a zTLD we define:¶

zkl := Base32GNS-Encode(ztype||zkey)
ztype||zkey := Base32GNS-Decode(zkl)

If zkl is less than 63 characters, it can directly be used as a zTLD. If zkl is longer than 63 characters, the zTLD is constructed by dividing zkl into smaller labels separated by the label separator ".". Here, the most significant bytes of the "ztype||zkey" concatenation must be contained in the rightmost label of the resulting string and the least significant bytes in the leftmost label of the resulting string. This allows the resolver to determine the ztype and zkl length from the rightmost label and to subsequently determine how many labels the zTLD should span. For example, assuming a zkl of 130 characters, the encoding would be:¶

zTLD := zkl[126..129].zkl[63..125].zkl[0..62]

4.2. Zone Revocation

Whenever a resolver encounters a new GNS zone, it MUST check against the local revocation list whether the respective zone key has been revoked. If the zone key was revoked, the resolution MUST fail with an empty result set.¶

In order to revoke a zone key, a signed revocation message MUST be published. This message MUST be signed using the private key. The revocation message is broadcast to the network. The specification of the broadcast mechanism is out of scope for this document. A possible broadcast mechanism for efficient flooding in a distributed network is implemented in [GNUnet]. Alternatively, revocation messages could also be distributed via a distributed ledger or a trusted central server. To prevent flooding attacks, the revocation message MUST contain a proof of work (PoW). The revocation message including the PoW MAY be calculated ahead of time to support timely revocation.¶

For all occurrences below, "Argon2id" is the Password-based Key Derivation Function as defined in [RFC9106]. For the PoW calculations the algorithm is instantiated with the following parameters:¶

S

The salt. Fixed 16-byte string: "GnsRevocationPow".¶

t

Number of iterations: 3¶

m

Memory size in KiB: 1024¶

T

Output length of hash in bytes: 64¶

p

Parallelization parameter: 1¶

v

Algorithm version: 0x13¶

y

Algorithm type (Argon2id): 2¶

X

Unused¶

K

Unused¶

Figure 2 illustrates the format of the data "P" on which the PoW is calculated.¶

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                      POW                      |
+-----------------------------------------------+
|                   TIMESTAMP                   |
+-----------------------------------------------+
|       ZONE TYPE       |    ZONE KEY           |
+-----+-----+-----+-----+                       |
/                                               /
/                                               /
+-----+-----+-----+-----+-----+-----+-----+-----+

The Format of the PoW Data.¶

POW

A 64-bit value that is a solution to the PoW. In network byte order.¶

TIMESTAMP

denotes the absolute 64-bit date when the revocation was computed. In microseconds since midnight (0 hour), January 1, 1970 UTC in network byte order.¶

ZONE TYPE

is the 32-bit zone type.¶

ZONE KEY

is the 256-bit public key zk of the zone which is being revoked. The wire format of this value is defined by the ZONE TYPE.¶

Traditionally, PoW schemes require to find a POW value such that at least D leading zeroes are found in the hash result. D is then referred to as the difficulty of the PoW. In order to reduce the variance in time it takes to calculate the PoW, we require that a number Z different PoWs must be found that on average have D leading zeroes.¶

The resulting proofs may then published and disseminated. The concrete dissemination and publication methods are out of scope of this document. Given an average difficulty of D, the proofs have an expiration time of EPOCH. With each additional bit difficulty, the lifetime of the proof is prolonged for another EPOCH. Consequently, by calculating a more difficult PoW, the lifetime of the proof can be increased on demand by the zone owner.¶

The parameters are defined as follows:¶

Z

The number of PoWs required is fixed at 32.¶

D

The minimum average difficulty is fixed at 22.¶

EPOCH

A single epoch is fixed at 365 days.¶

The revocation message wire format is illustrated in Figure 3.¶

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   TIMESTAMP                   |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                      TTL                      |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                     POW_0                     |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                       ...                     |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                     POW_Z-1                   |
+-----------------------------------------------+
|       ZONE TYPE       |    ZONE KEY           |
+-----+-----+-----+-----+                       |
/                                               /
/                                               /
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   SIGNATURE                   |
/                                               /
/                                               /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+

The Revocation Message Wire Format.¶

TIMESTAMP

denotes the absolute 64-bit date when the revocation was computed. In microseconds since midnight (0 hour), January 1, 1970 UTC in network byte order. This is the same value as the time stamp used in the individual PoW calculations.¶

TTL

denotes the relative 64-bit time to live of the record in microseconds also in network byte order. This field is informational for a verifier. A verifier MAY discard a revocation without checking the POW values or the signature if the TTL (in combination with TIMESTAMP) indicates that the revocation has already expired. However, the actual TTL of the revocation must be determined by examining the leading zeroes in the proof of work calculation.¶

POW_i

The values calculated as part of the PoW, in network byte order. Each POW_i MUST be unique in the set of POW values. To facilitate fast verification of uniqueness, the POW values must be given in strictly monotonically increasing order in the message.¶

ZONE TYPE

The 32-bit zone type corresponding to the zone key.¶

ZONE KEY

is the public key zk of the zone which is being revoked and the key to be used to verify SIGNATURE.¶

SIGNATURE

A signature over a time stamp and the zone zk of the zone which is revoked and corresponds to the key used in the PoW. The signature is created using the Sign() function of the cryptosystem of the zone and the private key (see Section 4).¶

The signature over the public key covers a 32-bit header prefixed to the time stamp and public key fields. The header includes the key length and signature purpose. The wire format is illustrated in Figure 4.¶

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|         SIZE          |       PURPOSE (0x03)  |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   TIMESTAMP                   |
+-----+-----+-----+-----+-----+-----+-----+-----+
|       ZONE TYPE       |     ZONE KEY          |
+-----+-----+-----+-----+                       |
/                                               /
/                                               /
+-----+-----+-----+-----+-----+-----+-----+-----+

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 including possible future extensions. The value of this field corresponds to an entry in the GANA "GNUnet Signature Purpose" registry Section 10.¶

TIMESTAMP

Field as defined in the revocation message above.¶

ZONE TYPE

Field as defined in the revocation message above.¶

ZONE KEY

Field as defined in the revocation message above.¶

In order to verify a revocation the following steps MUST be taken:¶

1. The signature MUST be verified against the zone key.¶
2. The set of POW values MUST NOT contain duplicates which MUST be checked by verifying that the values are strictly monotonically increasing.¶
3. The average number of leading zeroes D' resulting from the provided POW values MUST be greater than and not equal to D. Implementers MUST NOT use an integer data type to calculate or represent D'.¶
4. The validation period (TTL) of the revocation is calculated as (D'-D) * EPOCH * 1.1. The EPOCH is extended by 10% in order to deal with unsynchronized clocks. The TTL added on top of the TIMESTAMP yields the expiration date. Should the verifier calculate the TTL and find that it differs from the field value, the verifier MUST continue and use the calculated value when forwarding the revocation.¶
5. The current time SHOULD be between TIMESTAMP and TIMESTAMP+TTL. Implementations MAY process the revocation without validating this.¶

5.1. Zone Delegation Records

This section defines the initial set of zone delegation record types. Any implementation SHOULD support all zone types defined here and MAY support any number of additional delegation records defined in the GNU Name System Record Types registry (see Section 10). Zone delegation records MUST have the CRTITICAL flag set. Not supporting some zone types MAY result in resolution failures. This MAY BE a valid choice if some zone delegation record types have been determined to be cryptographically insecure. Zone delegation records MUST NOT be stored and published under the apex label. A zone delegation record type value is the same as the respective ztype value. The ztype defines the cryptographic primitives for the zone that is being delegated to. A zone delegation resource record payload contains the public key of the zone to delegate to. A zone delegation record MUST be the only record under a label. No other records are allowed.¶

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   PUBLIC KEY                  |
|                                               |
|                                               |
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+

ZKDF-Private(d,label):
  zk := d * G
  PRK_h := HKDF-Extract ("key-derivation", zk)
  h := HKDF-Expand (PRK_h, label || "gns", 512 / 8)
  d' := (h * d) mod L
  return d'

ZKDF-Public(zk,label)
  PRK_h := HKDF-Extract ("key-derivation", zk)
  h := HKDF-Expand (PRK_h, label || "gns", 512 / 8)
  zk' := (h mod L) * zk
  return zk'

SignDerived(d,label,message):
  d' := ZKDF-Private(d,label)
  return Sign(d',message)

VerifyDerived(zk,label,message,signature):
  zk' := ZKDF-Public(zk,label)
  return Verify(zk',message,signature)

S-Encrypt(zk,label,expiration,plaintext):
  PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
  PRK_n := HKDF-Extract ("gns-aes-ctx-iv", zk)
  K := HKDF-Expand (PRK_k, label, 256 / 8)
  NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
  IV := NONCE || expiration || 0x0000000000000001
  return CTR-AES256(K, IV, plaintext)

S-Decrypt(zk,label,expiration,ciphertext):
  PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
  PRK_n := HKDF-Extract ("gns-aes-ctx-iv", zk)
  K := HKDF-Expand (PRK_k, label, 256 / 8)
  NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
  IV := NONCE || expiration || 0x0000000000000001
  return CTR-AES256(K, IV, ciphertext)

0     8     16    24    32
+-----+-----+-----+-----+
|         NONCE         |
+-----+-----+-----+-----+
|       EXPIRATION      |
|                       |
+-----+-----+-----+-----+
|      BLOCK COUNTER    |
+-----+-----+-----+-----+

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   PUBLIC KEY                  |
|                                               |
|                                               |
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+

ZKDF-Private(d,label):
  /* EdDSA clamping */
  a := SHA-512 (d)
  a[0] &= 248
  a[31] &= 127
  a[31] |= 64
  /* Calculate zk from d */
  zk := a * G

  /* Calculate the blinding factor */
  PRK_h := HKDF-Extract ("key-derivation", zk)
  h := HKDF-Expand (PRK_h, label || "gns", 512 / 8)
  /* Ensure that h == h mod L */
  h[31] &= 7

  a1 := a >> 3
  a2 := (h * a1) mod L
  d' := a2 << 3
  return d'

ZKDF-Public(zk,label):
  /* Calculate the blinding factor */
  PRK_h := HKDF-Extract ("key-derivation", zk)
  h := HKDF-Expand (PRK_h, label || "gns", 512 / 8)
  /* Ensure that h == h mod L */
  h[31] &= 7

  zk' := h * zk
  return zk'

SignDerived(d,label,message):
  /* EdDSA clamping */
  a := SHA-512 (d)
  a[0] &= 248
  a[31] &= 127
  a[31] |= 64
  /* Calculate zk from d */
  zk := a * G

  /* Calculate blinding factor */
  PRK_h := HKDF-Extract ("key-derivation", zk)
  h := HKDF-Expand (PRK_h, label || "gns", 512 / 8)

  d' := ZKDF-Private(d,label)
  dh := SHA-512 (d)
  nonce := SHA-256 (dh[32..63] || h)
  r := SHA-512 (nonce || message)
  R := r * G
  S := r + SHA-512(R || zk' || message) * d' mod L
  return (R,S)

VerifyDerived(zk,label,message,signature):
  zk' := ZKDF-Public(zk,label)
  (R,S) := signature
  return S * G == R + SHA-512(R, zk', message) * zk'

S-Encrypt(zk,label,expiration,message):
  PRK_k := HKDF-Extract ("gns-xsalsa-ctx-key", zk)
  PRK_n := HKDF-Extract ("gns-xsalsa-ctx-iv", zk)
  K := HKDF-Expand (PRK_k, label, 256 / 8)
  NONCE := HKDF-Expand (PRK_n, label, 128 / 8)
  IV := NONCE || expiration
  return XSalsa20-Poly1305(K, IV, message)

S-Decrypt(zk,label,expiration,ciphertext):
  PRK_k := HKDF-Extract ("gns-xsalsa-ctx-key", zk)
  PRK_n := HKDF-Extract ("gns-xsalsa-ctx-iv", zk)
  K := HKDF-Expand (PRK_k, label, 256 / 8)
  NONCE := HKDF-Expand (PRK_n, label, 128 / 8)
  IV := NONCE || expiration
  return XSalsa20-Poly1305(K, IV, ciphertext)

0     8     16    24    32
+-----+-----+-----+-----+
|         NONCE         |
|                       |
|                       |
|                       |
+-----+-----+-----+-----+
|       EXPIRATION      |
|                       |
+-----+-----+-----+-----+

5.2. Redirection Records

Redirect records may be used to redirect resolution. Any implementation SHOULD support all redirection record types defined here and MAY support any number of additional redirection records defined in the GNU Name System Record Types registry (see Section Section 10). Redirection records MUST have the CRTITICAL flag set. Not supporting some record types MAY result in resolution failures. This MAY BE a valid choice if some redirection record types have been determined to be insecure, or if an application has reasons to not support redirection to DNS for reasons such as complexity or security. Redirection records MUST NOT be stored and published under the apex label.¶

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   REDIRECT NAME               |
/                                               /
/                                               /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                    DNS NAME                   |
/                                               /
/                                               /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                 DNS SERVER NAME               |
/                                               /
/                                               /
|                                               |
+-----------------------------------------------+

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.¶

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                 LEGACY HOSTNAME               |
/                                               /
/                                               /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                  NICKNAME                     |
/                                               /
/                                               /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|   PROTO   |    SVC    |       TYPE            |
+-----------+-----------------------------------+
|                 RECORD DATA                   |
/                                               /
/                                               /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+

6.1. The Storage Key

Given a label, the storage key q is derived as follows:¶

q := SHA-512 (ZKDF-Public(zk, label))

label

is a UTF-8 string under which the resource records are published.¶

zk

is the zone key.¶

q

Is the 512-bit storage key under which the resource records block is published. It is the SHA-512 hash [RFC6234] over the derived zone key.¶

6.2. The Records Block

GNS records are grouped by their labels and published as a single block in the storage. The grouped record sets MAY be paired with any number of supplemental records. Supplemental records MUST have the supplemental flag set (See Section 5). The contained resource records are encrypted using a symmetric encryption scheme. A GNS implementation publish RRBLOCKs in accordance to the properties and recommendations of the underlying storage. This may include a periodic refresh operation to ensure the availability of the published RRBLOCKs. The GNS RRBLOCK wire format is illustrated in Figure 18.¶

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|          SIZE         |    ZONE TYPE          |
+-----+-----+-----+-----+-----+-----+-----+-----+
/                  ZONE KEY                     /
/                  (BLINDED)                    /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   SIGNATURE                   |
/                                               /
/                                               /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   EXPIRATION                  |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                    BDATA                      /
/                                               /
/                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+

The RRBLOCK Wire Format.¶

SIZE

A 32-bit value containing the length of the block. While a 32-bit value is used, implementations MAY refuse to publish blocks beyond a certain size significantly below 4 GB.¶

ZONE TYPE

is the 32-bit ztype.¶

ZONE KEY

is the blinded zone key "ZKDF-Public(zk, label)" to be used to verify SIGNATURE. The length and format of the public key depends on the ztype.¶

SIGNATURE

The signature is computed over the EXPIRATION and BDATA fields as detailed in Figure 19. The length and format of the signature depends on the ztype. The signature is created using the Sign() function of the cryptosystem of the zone and the derived private key "ZKDF-Private(d, label)" (see Section 4).¶

EXPIRATION

Specifies when the RRBLOCK expires and the encrypted block SHOULD be removed from the storage and caches as it is likely stale. However, applications MAY continue to use non-expired individual records until they expire. The value MUST be set to the expiration time of the resource record contained within this block with the smallest expiration time. If a records block includes shadow records, then the maximum expiration time of all shadow records with matching type and the expiration times of the non-shadow records is considered. This is a 64-bit absolute date in microseconds since midnight (0 hour), January 1, 1970 UTC in network byte order.¶

BDATA

The encrypted RDATA. Its size is determined by the S-Encrypt() function of the ztype.¶

The signature over the public key covers a 32-bit pseudo header conceptually prefixed to the EXPIRATION and the BDATA fields. The wire format is illustrated in Figure 19.¶

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|         SIZE          |       PURPOSE (0x0F)  |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   EXPIRATION                  |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                    BDATA                      |
/                                               /
/                                               /
+-----+-----+-----+-----+-----+-----+-----+-----+

The Wire Format used for creating the signature of the RRBLOCK.¶

SIZE

A 32-bit value containing the length of the signed data in bytes in network byte order.¶

PURPOSE

A 32-bit signature purpose flag. The value of this field MUST be 15. The value is encoded in network byte order. It defines the context in which the signature is created so that it cannot be reused in other parts of the protocol including possible future extensions. The value of this field corresponds to an entry in the GANA "GNUnet Signature Purpose" registry Section 10.¶

EXPIRATION

Field as defined in the RRBLOCK message above.¶

BDATA

Field as defined in the RRBLOCK message above.¶

A symmetric encryption scheme is used to encrypt the resource records set RDATA into the BDATA field of a GNS RRBLOCK. The wire format of the RDATA is illustrated in Figure 20.¶

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|                 EXPIRATION                    |
+-----+-----+-----+-----+-----+-----+-----+-----+
|    SIZE   |    FLAGS  |        TYPE           |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                      DATA                     /
/                                               /
/                                               /
+-----+-----+-----+-----+-----+-----+-----+-----+
|                   EXPIRATION                  |
+-----+-----+-----+-----+-----+-----+-----+-----+
|    SIZE   |    FLAGS  |        TYPE           |
+-----+-----+-----+-----+-----+-----+-----+-----+
|                     DATA                      /
/                                               /
+-----+-----+-----+-----+-----+-----+-----+-----+
/                     PADDING                   /
/                                               /

The RDATA Wire Format.¶

EXPIRATION, SIZE, TYPE, FLAGS and DATA

These fields were defined in the resource record format in Section 5.¶

PADDING

When publishing an RDATA block, the implementation MUST ensure that the size of the RDATA is a power of two using the padding field. The field MUST be set to zero and MUST be ignored on receipt. As a special exception, record sets with (only) a zone delegation record type are never padded. Note that a record set with a delegation record MUST NOT contain other records. If other records are encountered, the whole record block MUST be discarded.¶

7.1. Start Zones

The resolution of a GNS name starts in an initial start zone. The resolver may have one or more local start zones configured which point to local or remote zone keys. A resolver may also determine the start zone from the suffix of the name given for resolution, or using information retrieved out of band.¶

The governance model of any zone is at the sole discretion of the zone owner. However, the choice of start zone(s) is at the sole discretion of the local system administrator or user. This property addresses the issue of a single hierarchy with a centrally controlled root and the related issue of distribution and management of root servers in DNS (see [RFC8324], Section 3.10 and 3.12).¶

In the following, we give examples how a resolver SHOULD discover the start zone. The process given is not exhaustive and resolvers MAY supplement it with other mechanisms or ignore it if the particular application requires a different process.¶

GNS implementations MUST first try to interpret the top-level domain of a GNS name as a zone key representation (i.e. a zTLD). If the top-level domain can be converted to a valid ztype and zone key value, the resulting zone key is used as the start zone:¶

Example name: www.example.<zTLD>
=> Start zone: zk of type ztype
=> Name to resolve from start zone: www.example

In GNS, users MAY own and manage their own zones. Each local zone SHOULD be associated with a single GNS label, but users MAY choose to use longer names consisting of multiple labels. If the name of a locally managed zone matches the suffix of the name to be resolved, resolution MUST start from the respective local zone with the longest matching suffix:¶

Example name: www.example.org
Local zones:
fr = (d0,zk0)
org = (d1,zk1)
com = (d2,zk2)
...
=> Start zone: zk1
=> Name to resolve from start zone: www.example

Finally, additional "suffix-to-zone" mappings MAY be configured. Suffix to zone key mappings MUST be configurable through a local configuration file or database by the user or system administrator. The suffix MAY consist of multiple GNS labels concatenated with a ".". If multiple suffixes match the name to resolve, the longest matching suffix MUST be used. The suffix length of two results MUST NOT be equal. This indicates a misconfiguration and the implementation MUST return an error. If both a locally managed zone and a configuration entry exist for the same suffix, the locally managed zone MUST have priority.¶

Example name: www.example.org
Local suffix mappings:
org = zk0
example.org = zk1
example.com = zk2
...
=> Start zone: zk1
=> Name to resolve from start zone: www

7.2. Recursion

In each step of the recursive name resolution, there is an authoritative zone zk and a name to resolve. The name may be empty. Initially, the authoritative zone is the start zone. If the name is empty, it is interpreted as the apex label "@".¶

From here, the following steps are recursively executed, in order:¶

1. Extract the right-most label from the name to look up.¶
2. Calculate q using the label and zk as defined in Section 6.1.¶
3. Perform a storage query GET(q) to retrieve the RRBLOCK.¶
4. Verify and process the RRBLOCK and decrypt the BDATA contained in it as defined by its zone type (see also Section 6.2).¶

Upon receiving the RRBLOCK from the storage, as part of verifying the provided signature, the resolver MUST check that the SHA-512 hash of the derived authoritative zone key zk' from the RRBLOCK matches the query q and that the overall block is not yet expired. If the signature does not match or the block is expired, the RRBLOCK MUST be ignored and, if applicable, the storage lookup GET(q) MUST continue to look for other RRBLOCKs.¶

7.3. Record Processing

Record processing occurs once a well-formed block was decrypted. In record processing, only the valid records obtained are considered. To filter records by validity, the resolver MUST at least check the expiration time and the FLAGS of the respective record. In particular, FLAGS may exclude shadow and supplemental records from being considered. If the resolver encounters a record with the CRITICAL flag set and does not support the record type the resolution MUST be aborted and an error MUST be returned. The information that the critical record could not be processed SHOULD be returned in the error description. The implementation MAY choose not to return the reason for the failure, merely complicating troubleshooting for the user. The next steps depend on the context of the name we are trying to resolve:¶

• Case 1: If the filtered record set consists of a single REDIRECT record, the remainder of the name is prepended to the REDIRECT data and the recursion is started again from the resulting name. Details are described in Section 7.3.1.¶
• Case 2: If the filtered record set consists exclusively of one or more GNS2DNS records resolution continues with DNS. Details are described in Section 7.3.2.¶
• Case 3: If the remainder of the name to be resolved is of the format "_SERVICE._PROTO" and the record set contains one or more matching BOX records, the records in the BOX records are the final result and the recursion is concluded as described in Section 7.3.3.¶
• Case 4: If the current record set consist of a single delegation record, resolution of the remainder of the name is delegated to the target zone as described in Section 7.3.4.¶
• Case 5: If the remainder of the name to resolve is empty the record set (including supplemental records) is the final result and the recursion is concluded.¶
• Otherwise, resolution fails and the resolver MUST return an empty record set.¶

Query: alice.example (type=A)
Result:
A: 192.0.2.1
NICK: eve (non-Supplemental)

Query: alice.example (type=AAAA)
Result:
AAAA: 2001:DB8::1
NICK: john (Supplemental)

9.1. Availability

In order to ensure availability of records beyond their absolute expiration times, implementations MAY allow to locally define relative expiration time values of records. Records can then be published recurringly with updated absolute expiration times by the implementation.¶

Implementations MAY allow users to manage private records in their zones that are not published in the storage. Private records are considered just like regular records when resolving labels in local zones, but their data is completely unavailable to non-local users.¶

9.2. Agility

The security of cryptographic systems depends on both the strength of the cryptographic algorithms chosen and the strength of the keys used with those algorithms. The security also depends on the engineering of the protocol used by the system to ensure that there are no non-cryptographic ways to bypass the security of the overall system. This is why developers of applications managing GNS zones SHOULD select a default ztype considered secure at the time of releasing the software. For applications targeting end users that are not expected to understand cryptography, the application developer MUST NOT leave the ztype selection of new zones to end users.¶

This document concerns itself with the selection of cryptographic algorithms used in GNS. The algorithms identified in this document are not known to be broken (in the cryptographic sense) at the current time, and cryptographic research so far leads us to believe that they are likely to remain secure into the foreseeable future. However, this is not necessarily forever, and it is expected that new revisions of this document will be issued from time to time to reflect the current best practices in this area.¶

In terms of crypto-agility, whenever the need for an updated cryptographic scheme arises to, for example, replace ECDSA over Ed25519 for PKEY records it may simply be introduced through a new record type. Such a new record type may then replace the delegation record type for future records. The old record type remains and zones can iteratively migrate to the updated zone keys. To ensure that implementations correctly generate an error message when encountering a ztype that they do not support, current and future delegation records must always have the CRITICAL flag set.¶

9.3. Cryptography

GNS PKEY zone keys use ECDSA over Ed25519. This is an unconventional choice, as ECDSA is usually used with other curves. However, traditional ECDSA curves are problematic for a range of reasons described in the Curve25519 and EdDSA papers. Using EdDSA directly is also not possible, as a hash function is used on the private key which destroys the linearity that the GNU Name System depends upon. We are not aware of anyone suggesting that using Ed25519 instead of another common curve of similar size would lower the security of ECDSA. GNS uses 256-bit curves because that way the encoded (public) keys fit into a single DNS label, which is good for usability.¶

In order to ensure ciphertext indistinguishability, care must be taken with respect to the initialization vector in the counter block. In our design, the IV always includes the expiration time of the record block. When applications store records with relative expiration times, monotonicity is implicitly ensured because each time a block is published into the storage, its IV is unique as the expiration time is calculated dynamically and increases monotonically with the system time. Still, an implementation MUST ensure that when relative expiration times are decreased, the expiration time of the next record block MUST be after the last published block. For records where an absolute expiration time is used, the implementation MUST ensure that the expiration time is always increased when the record data changes. For example, the expiration time on the wire may be increased by a single microsecond even if the user did not request a change. In case of deletion of all resource records under a label, the implementation MUST keep track of the last absolute expiration time of the last published resource block. Implementations MAY use a PADDING record as a tombstone that preserves the last absolute expiration time, but then MUST take care to not publish a block with just a PADDING record. When new records are added under this label later, the implementation MUST ensure that the expiration times are after the last published block. Finally, in order to ensure monotonically increasing expiration times the implementation MUST keep a local record of the last time obtained from the system clock, so as to construct a monotonic clock in case the system clock jumps backwards.¶

9.4. Abuse Mitigation

GNS names are UTF-8 strings. Consequently, GNS faces similar issues with respect to name spoofing as DNS does for internationalized domain names. In DNS, attackers may register similar sounding or looking names (see above) in order to execute phishing attacks. GNS zone administrators must take into account this attack vector and incorporate rules in order to mitigate it.¶

Further, DNS can be used to combat illegal content on the internet by having the respective domains seized by authorities. However, the same mechanisms can also be abused in order to impose state censorship, which is one of the motivations behind GNS. Hence, such a seizure is, by design, difficult to impossible in GNS.¶

9.5. Zone Management

In GNS, zone administrators need to manage and protect their zone keys. Once a zone key is lost, it cannot be recovered or revoked. Revocation messages may be pre-calculated if revocation is required in case a zone key is lost. Zone administrators, and for GNS this includes end-users, are required to responsibly and diligently protect their cryptographic keys. GNS supports offline signing of records.¶

Similarly, users are required to manage their local start zone configuration. In order to ensure integrity and availability or names, users must ensure that their local start zone information is not compromised or outdated. It can be expected that the processing of zone revocations and an initial start zone is provided with a GNS implementation ("drop shipping"). Shipping an initial start zone with an entry for the root (".") effectively establishes a root zone. Extension and customization of the zone is at the full discretion of the user.¶

While implementations following this specification will be interoperable, if two implementations connect to different storages they are mutually unreachable. This may lead to a state where a record may exist in the global namespace for a particular name, but the implementation is not communicating with the storage and is hence unable to resolve it. This situation is similar to a split-horizon DNS configuration. Which storages are implemented usually depends on the application it is built for. The storage used will most likely depend on the specific application context using GNS resolution. For example, one application may be the resolution of hidden services within the Tor network, which may suggest using Tor routers for storage. Implementations of "aggregated" storages are conceivable, but are expected to be the exception.¶

9.6. Impact of DHTs as Underlying Storage

This document does not specify the properties of the underlying storage which is required by any GNS implementation. It is important to note that the properties of the underlying storage are directly inherited by the GNS implementation. This includes both security as well as other non-functional properties such as scalability and performance. Implementers should take great care when selecting or implementing a DHT for use as storage in a GNS implementation. DHTs with reasonable security and performance properties exist [R5N]. It should also be taken into consideration that GNS implementations which build upon different DHT overlays are unlikely to be interoperable with each other.¶

9.7. Revocations

Zone administrators are advised to pre-generate zone revocations and to securely store the revocation information in case the zone key is lost, compromised or replaced in the future. Pre-calculated revocations may become invalid due to expirations or protocol changes such as epoch adjustments. Consequently, implementers and users must take precautions in order to manage revocations accordingly.¶

Revocation payloads do NOT include a 'new' key for key replacement. Inclusion of such a key would have two major disadvantages:¶

1. If a revocation is published after a private key was compromised, allowing key replacement would be dangerous: if an adversary took over the private key, the adversary could then broadcast a revocation with a key replacement. For the replacement, the compromised owner would have no chance to issue even a revocation. Thus, allowing a revocation message to replace a private key makes dealing with key compromise situations worse.¶
2. Sometimes, key revocations are used with the objective of changing cryptosystems. Migration to another cryptosystem by replacing keys via a revocation message would only be secure as long as both cryptosystems are still secure against forgery. Such a planned, non-emergency migration to another cryptosystem should be done by running zones for both cipher systems in parallel for a while. The migration would conclude by revoking the legacy zone key only once it is deemed no longer secure, and hopefully after most users have migrated to the replacement.¶

9.8. Label Guessing

Record blocks are published in encrypted form using keys derived from the zone key and record label. Zone administrators should carefully consider if the label and zone key may be public or if those should be used and considered as a shared secret. Unlike zone keys, labels can also be guessed by an attacker in the network observing queries and responses. Given a known and targeted zone key, the use of well known or easily guessable labels effectively result in general disclosure of the records to the public. If the labels and hence the records should be kept secret except to those knowing a secret label and the zone in which to look, the label must be chosen accordingly. It is recommended to then use a label with sufficient entropy as to prevent guessing attacks.¶

It should be noted that this attack on labels only applies if the zone key is somehow disclosed to the adversary. GNS itself does not disclose it during a lookup or when resource records are published as the zone keys are blinded beforehand. However, zone keys do become public during revocation.¶