4.1. Zone High-Diploma 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 High-Diploma Domain.
It is a long way a string which encodes the zone form and zone key into a net page title.
The zTLD is worn as a globally queer reference to a particular
namespace at some stage in of title likelihood.
To encode the zone key, a zone key brand zkl is derived from a
concatenation of the zone form and zone key (peep Figure 1)
the utilization of the Crockford Snide32 encoding [CrockfordB32].
In uncover to extra delay tolerance for failures in persona
recognition, the letter “U” MUST be decoded to the same Snide32 price because the
letter “V”.
The encoding and decoding symbols for Crockford Snide32 together with this transformation are outlined in
Figure 2.
The capabilities for encoding and decoding in step with this table are known as
GNSCrockfordEncode and GNSCrockfordDecode, respectively.¶

Symbol      Decode            Encode
Designate       Symbol            Symbol
0           0 O o             0
1           1 I i L l         1
2           2                 2
3           3                 3
4           4                 4
5           5                 5
6           6                 6
7           7                 7
8           8                 8
9           9                 9
10          A a               A
11          B b               B
12          C c               C
13          D d               D
14          E e               E
15          F f               F
16          G g               G
17          H h               H
18          J j               J
19          Okay ok               Okay
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               V U
28          W w               W
29          X x               X
30          Y y               Y
31          Z z               Z

The Snide32-Crockford Alphabet Including the Extra U Encode Symbol.¶

For the string representation of a zTLD we clarify:¶

zkl := GNSCrockfordEncode(ztype|zkey)
ztype|zkey := GNSCrockfordDecode(zkl)

If zkl is no longer as a lot as 63 characters, it’ll without delay be
worn as a zTLD.
If zkl is longer than 63 characters, the
zTLD is constructed by dividing zkl into smaller labels separated by the
brand separator “.”.
Right here, the main bytes of the “ztype|zkey” concatenation must be contained
within the rightmost brand of the resulting string and the least major
bytes within the leftmost brand of the resulting string. This permits the
resolver to search out out the zone form and zkl dimension from the rightmost brand.
For instance, assuming a zkl of 130 characters, the encoding would be:¶

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

4.2. Zone Revocation

On every occasion a resolver encounters a original GNS zone, it MUST
test in opposition to the local revocation listing whether the respective
zone key has been revoked. If the zone key was revoked, the
likelihood MUST fail with an empty end result situation.¶

In uncover to revoke a zone key, a signed revocation object MUST be
published.
This object MUST be signed the utilization of the non-public key.
The revocation object is broadcast to the community.
The specification of the published mechanism is out of scope of this
doc.
A seemingly broadcast mechanism for efficient flooding in a disbursed
community is utilized in [GNUnet].
Alternatively, revocation objects might perhaps perchance perhaps presumably moreover be disbursed by map of a
disbursed ledger or a relied on central server.
To discontinue
flooding assaults, the revocation message MUST have a proof of labor
(PoW).
The revocation message together with the PoW MAY be calculated
sooner than time to present a have to effectively timed revocation.¶

For all occurrences beneath, “Argon2id” is the Password-primarily based mostly Key
Derivation Feature as outlined in [RFC9106]. For the
PoW calculations the algorithm is instantiated with the
following parameters:¶

S

The salt. Fixed 16-byte string: “GnsRevocationPow”.¶

t

Decision of iterations: 3¶

m

Memory dimension in KiB: 1024¶

T

Output dimension of hash in bytes: 64¶

p

Parallelization parameter: 1¶

v

Algorithm version: 0x13¶

y

Algorithm form (Argon2id): 2¶

X

Unused¶

Okay

Unused¶

Figure 3 illustrates the wire layout
of the message string “P” on which the PoW is calculated.¶

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

The Wire Format of the PoW Message String.¶

POW

A 64-bit resolution to the PoW. In community byte uncover.¶

TIMESTAMP

denotes the absolute 64-bit date when the revocation was computed.
In microseconds since hour of darkness (0 hour), January 1, 1970 in community
byte uncover.¶

ZONE TYPE

is the 32-bit zone form.¶

ZONE KEY

is the 256-bit public key zk of the zone which is being revoked.
The wire layout of this price is printed by the ZONE TYPE.¶

Historically, PoW schemes require to search out a POW such that
no longer no longer as a lot as D leading zeroes are chanced on within the hash end result.
D is then referred to because the situation of the PoW.
In uncover to minimize the variance in time it takes to calculate the
PoW, we require that a number Z diversified PoWs must be
chanced on that on life like contain D leading zeroes.¶

The resulting proofs can also merely then published and disseminated. The concrete
dissemination and newsletter recommendations are out of scope of this
doc. Given a mean situation of D, the proofs contain an
expiration time of EPOCH. With every extra bit situation, the
lifetime of the proof is prolonged for another EPOCH.
In consequence, by calculating a more complex PoW, the lifetime of the
proof might perhaps perchance perhaps moreover be elevated on query by the zone proprietor.¶

The parameters are outlined as follows:¶

Z

The preference of PoWs required is mounted at 32.¶

D

The placement is mounted at 22.¶

EPOCH

A single epoch is mounted at 365 days.¶

The revocation message wire layout is illustrated in
Figure 4.¶

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 hour of darkness (0 hour), January 1, 1970 in community
byte uncover. Right here is a linked price because the timestamp worn within the
particular individual PoW calculations.¶

TTL

denotes the relative 64-bit time to live of the chronicle in
microseconds moreover in community byte uncover. This field is informational
for a verifier. The verifier can also merely discard revocation if the TTL
means that it is already expired. On the choice hand, the actual TTL of the
revocation must make sure by analyzing the leading zeros within the
proof of labor calculation.¶

POW_i

The values calculated as phase of the PoW, in community byte uncover.
Every POW_i MUST be queer within the situation of POW values.
To facilitate lickety-split verification
of specialty, the POW values must be given in strictly
monotonically rising uncover within the message.¶

ZONE TYPE

The 32-bit zone form same to the zone key.¶

ZONE KEY

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

SIGNATURE

A signature over a timestamp and the zone zk of the zone
which is revoked and corresponds to the major worn within the PoW.
The signature is created the utilization of the Signal() feature of
the cryptosystem of the zone and the non-public key
(peep Fragment 4).¶

The signature over the final public key covers a 32-bit pseudo header
conceptually prefixed to the final public key. The pseudo header contains
the major dimension and signature cause. The wire layout is illustrated
in Figure 5.¶

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

The Wire Format of the Revocation Knowledge for Signing.¶

SIZE

A 32-bit price containing the scale of the signed files in bytes
in community byte uncover.¶

PURPOSE

A 32-bit signature cause flag. This field MUST be 3 (in community
byte uncover).¶

ZONE TYPE

The 32-bit zone form same to the zone key.¶

ZONE KEY / TIMESTAMP

Each values as outlined within the revocation files object above.¶

In uncover to verify a revocation the following steps must be taken,
in uncover:¶

1. The signature MUST match the final public key.¶
2. The placement of POW values MUST NOT have duplicates.¶
3. The frequent preference of leading zeroes as a end result of the equipped
   POW values D’ MUST be elevated than and no longer equal to D.¶
4. The validation duration (TTL) of the revocation is calculated as
   (D’-D) EPOCH 1.1. The EPOCH is extended by
   10% in uncover to address unsynchronized clocks.
   The TTL added on high of the TIMESTAMP yields the
   expiration date.¶
5. Essentially the most as a lot as date time MUST be between TIMESTAMP and
   TIMESTAMP+TTL.¶

5.1. Zone Delegation Facts

This fragment defines the preliminary situation of zone delegation chronicle kinds.
Any implementation MUST give a have to all zone kinds outlined here and
MAY give a have to any preference of extra delegation files outlined in
the GNU Title System Narrative Kinds registry Fragment 10.
Zone delegation files MUST NOT be saved and published below the
empty brand.¶

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

zk := d G
PRK_h := HKDF-Extract ("key-derivation", zk)
h := HKDF-Make bigger (PRK_h, brand | "gns", 512 / 8)
d' := (h d) mod L

PRK_h := HKDF-Extract ("key-derivation", zk)
h := HKDF-Make bigger (PRK_h, brand | "gns", 512 / 8)
zk' := (h mod L) zk

CIPHERTEXT := CTR-AES256(Okay, IV, DATA)
DATA := CTR-AES256(Okay, IV, CIPHERTEXT)

PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
PRK_n := HKDF-Extract ("gns-aes-ctx-iv", zk)
Okay := HKDF-Make bigger (PRK_k, brand, 256 / 8);
NONCE := HKDF-Make bigger (PRK_n, brand, 32 / 8)

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

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

zk := a G
PRK_h := HKDF-Extract ("key-derivation", zk)
h := HKDF-Make bigger (PRK_h, brand | "gns", 512 / 8)
h[31] &= 7
a1 := a / 8 /8 is the cofactor of Curve25519 */
a2 := (h a1) mod L
a' = a2 8 /8 is the cofactor of Curve25519 */

PRK_h := HKDF-Extract ("key-derivation", zk)
h := HKDF-Make bigger (PRK_h, brand | "gns", 512 / 8)
h[31] &= 7  // Implies h mod L == h
zk' := h zk

dh := SHA-512 (d)
nonce := SHA-256 (dh[32..63] | h)
r := SHA-512 (nonce | M)
R := r G
S := r + SHA-512(R | zk' | M) a' mod L

S G == R + SHA-512(R, zk', M) zk'

CIPHERTEXT := XSalsa20-Poly1305(Okay, IV, DATA)
DATA := XSalsa20-Poly1305(Okay, IV, CIPHERTEXT)

PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
PRK_n := HKDF-Extract ("gns-aes-ctx-iv", zk)
Okay := HKDF-Make bigger (PRK_k, brand, 256 / 8);
NONCE := HKDF-Make bigger (PRK_n, brand, 32 / 8)

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

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

5.2. Auxiliary Facts

This fragment defines the preliminary situation of auxiliary GNS chronicle kinds. Any
implementation MUST be in a situation to direction of the desired chronicle kinds
in step with Fragment 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                   |
/                                               /
/                                               /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+

0     8     16    24    32    40    48    56
+-----+-----+-----+-----+-----+-----+-----+-----+
|          HOSTING PEER PUBLIC KEY              |
|                (256 bits)                     |
|                                               |
|                                               |
+-----------+-----------------------------------+
|   PROTO   |    SERVICE  NAME                  |
+-----------+                                   +
/                                               /
/                                               /
|                                               |
+-----+-----+-----+-----+-----+-----+-----+-----+

6.1. The Storage Key

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

q := SHA-512 (HDKD-Public(zk, brand))

brand

is a UTF-8 string below which the handy resource files are published.¶

zk

is the zone key.¶

q

Is the 512-bit storage key below which the handy resource files block is
published.
It is a long way the SHA-512 hash [RFC6234] over the derived zone key.¶

6.2. The Facts Block (RRBLOCK)

GNS files are grouped by their labels and published as a single
block within the storage. The grouped chronicle sets MAY be paired with any
preference of supplemental files. Supplemental files have to contain the
supplemental flag situation (Be taught about Fragment 5).
The contained handy resource files are encrypted the utilization of a symmetric
encryption map.
A GNS implementation have to publish RRBLOCKs
in accordance to the properties and options of the underlying
storage. This can even merely comprise a periodic refresh newsletter.
The GNS RRBLOCK wire layout is illustrated in
Figure 17.¶

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

The RRBLOCK Wire Format.¶

ZONE TYPE

is the 32-bit zone form.¶

ZONE KEY

is the blinded zone key “ZKDF-Public(zk, brand)”
to be worn to verify SIGNATURE.¶

SIGNATURE

The signature is computed over the records following
this field.
The signature is created the utilization of the Signal() feature of
the cryptosystem of the zone and the derived non-public key
“ZKDF-Deepest(d, brand)” (peep Fragment 4).¶

SIZE

A 32-bit price containing the scale of the signed files following the
PUBLIC KEY field in community byte uncover. This price continually contains the
dimension of the fields SIZE (4), PURPOSE (4) and EXPIRATION (8) in
addition to the scale of the BDATA. Whereas a 32-bit price is worn,
implementations MAY refuse to publish blocks beyond a certain
dimension very a lot beneath 4 GB. On the choice hand, a minimal block dimension of
62 kilobytes MUST be supported.¶

PURPOSE

A 32-bit signature cause flag. For a RRBLOCK the associated fee of this
field MUST be 15. The associated fee is encoded in community byte uncover.
The associated fee of this field corresponds to an entry within the
GANA “GNUnet Signature Goal” registry.¶

EXPIRATION

Specifies when the RRBLOCK expires and the encrypted block
SHOULD be eliminated from the storage and caches as it is probably worn.
On the choice hand, purposes MAY continue to spend non-expired particular individual
files unless they expire. The associated fee MUST be situation to the
expiration time of the handy resource chronicle contained within this block with the
smallest expiration time.
If a files block contains shadow files, then the maximum
expiration time of all shadow files with matching form and the
expiration instances of the non-shadow files is thought of as.
Right here is a 64-bit absolute date in microseconds since hour of darkness
(0 hour), January 1, 1970 in community byte uncover.¶

BDATA

The encrypted RDATA with a total dimension of SIZE – 16.¶

A symmetric encryption map is worn to encrypt the handy resource files
situation RDATA into the BDATA field of a GNS RRBLOCK.
The wire layout of the RDATA is illustrated in
Figure 18.¶

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

The RDATA Wire Format.¶

RR COUNT

A 32-bit price containing the preference of variable-dimension handy resource
files which might perhaps perhaps presumably be
following after this field in community byte uncover.¶

EXPIRATION, DATA SIZE, TYPE, FLAGS and DATA

These fields contain been outlined
within the handy resource chronicle layout in Fragment 5.
There MUST be a total of RR COUNT of these handy resource files
present.¶

PADDING

When publishing an RDATA block, the implementation MUST make sure
the scale of the RDATA WITHOUT the RR COUNT field is a strength of two
the utilization of the padding field. The field MUST be situation to zero and MUST be
uncared for on receipt.
As a certain exception, chronicle sets with (exclusively) a zone delegation
chronicle form are by no map padded.
Show conceal that a chronicle situation with a delegation chronicle MUST NOT
have other files. If other files are encountered, your entire
chronicle block MUST be discarded.¶

7.1. Root Zone

The likelihood of a GNS title have to start in a given start zone
indicated to the resolver the utilization of any zone key.
The local resolver can also merely contain a local start zone configured/laborious-coded
which points to a local or faraway start zone key.
A resolver consumer can also merely moreover resolve the start zone from the
suffix of the title given for likelihood or the utilization of files
retrieved out of band.
The governance model of any zone is on the only real discretion
of the zone proprietor.
On the choice hand, the preference of start zone(s) is on the only real
discretion of the local map administrator or user.
This property addresses the situation of a single hierarchy with a
centrally managed root and the linked situation of distribution and
management of root servers in DNS (peep [RFC8324], Fragment 3.10 and 3.12).¶

In the following, we give examples how a local consumer resolver SHOULD
look the start zone. The map given is no longer exhaustive and
clients MAY supplement it with other mechanisms or ignore it if the
particular utility requires a diversified direction of.¶

GNS clients MUST first are attempting to define the high-stage enviornment of
a GNS title as a zone key representation (i.e. a zTLD).
If the high-stage enviornment is indicated to be a brand representation of
a zone key with a supported zone form price, the muse zone of
the likelihood direction of is implicitly given by the suffix of the title:¶

Instance title: www.example.
=> Root zone: zk of form ztype
=> Title to resolve from root zone: www.example

In GNS, users MAY beget and situation up their beget zones.
Every local zone SHOULD be linked to a single GNS brand,
but users MAY grab to spend longer names consisting of
so a lot of labels.
If the title of a regionally managed zone fits the suffix
of the title to be resolved, likelihood MUST start from the respective local zone:¶

Instance title: www.example.org
Native zones:
fr = (d0,zk0)
org = (d1,zk1)
com = (d2,zk2)
...
=> Root zone: zk1
=> Title to resolve from root zone: www.example

At closing, extra “suffix-to-zone” mappings MAY be configured.
Suffix to zone key mappings MUST be configurable by map of a local
configuration file or database by the user or map administrator.
The suffix MAY comprise so a lot of GNS labels concatenated with a
“.”. If so a lot of suffixes match the title to resolve, the longest
matching suffix MUST be worn. The suffix dimension of two outcomes
MUST NOT be equal. This skill a misconfiguration and the
implementation MUST return an error.
If both a regionally managed zone and a configuration entry exist
for the same suffix, the regionally managed zone MUST contain precedence.¶

Instance title: www.example.org
Native suffix mappings:
org = zk0
example.org = zk1
example.com = zk2
...
=> Root zone: zk1
=> Title to resolve from root zone: www

7.2. Recursion

In every step of the recursive title likelihood, there might perhaps be an
authoritative zone zk and a title to resolve. The title might perhaps perchance perhaps presumably be empty.
Before all the things, the authoritative zone is the start zone. If the title
is empty, it is interpreted because the apex brand “@”.¶

From here, the following steps are recursively performed, in uncover:¶

1. Extract the ideal-most brand from the title to search up.¶
2. Calculate q the utilization of the brand and zk as outlined in
   Fragment 6.1.¶
3. Impact a storage set a query to GET(q) to retrieve the RRBLOCK.¶
4. Examine and direction of the RRBLOCK and decrypt the BDATA contained
   in it as outlined by its zone form (peep moreover Fragment 6.2).¶

Upon receiving the RRBLOCK from the storage, rather than verifying the
equipped signature, the resolver MUST test that the authoritative
zone key was worn to signal the chronicle:
The derived zone key zk’ MUST match the final public key equipped in
the RRBLOCK, in another case the RRBLOCK MUST be uncared for and the storage
look up GET(q) MUST continue.¶

7.3. Narrative Processing

Narrative processing occurs on the high of a single recursion. We engage
that the RRBLOCK has been cryptographically verified and decrypted.
At this point, we have to first resolve if we contain obtained a gracious
chronicle situation within the context of the title we’re making an attempt to resolve:¶

• Case 1:
  If the the relaxation of the title to resolve is empty and the chronicle situation
  does no longer comprise a delegation, CNAME or DNS2GNS chronicle,
  the chronicle situation is the end result and the recursion is concluded.¶
• Case 2:
  If the title to be resolved is of the layout
  “_SERVICE._PROTO” and the chronicle situation incorporates one or more matching BOX
  files, the guidelines within the BOX files are the end result and the recursion
  is concluded (Fragment 7.3.4).¶
• Case 3:
  If the the relaxation of the title to resolve is no longer empty and
  does no longer match the “_SERVICE._PROTO” syntax, then the most as a lot as date chronicle situation
  MUST comprise a single delegation chronicle (Fragment 7.3.1),
  a single CNAME chronicle (Fragment 7.3.3),
  or one or more GNS2DNS files (Fragment 7.3.2),
  which might perhaps perhaps presumably be processed as described within the respective sections beneath.
  The chronicle situation can also merely comprise any preference of supplemental files.
  In another case, likelihood fails
  and the resolver MUST return an empty chronicle situation.

  At closing, after the recursion terminates, the consumer preferences
  for the chronicle form MUST be regarded as and seemingly conversions equivalent to
  outlined in Fragment 7.3.5 MUST be performed.¶

Interrogate: alice.example (form=A)
Consequence:
A: 192.0.2.1
NICK: eve

Interrogate: alice.example (form=AAAA)
Consequence:
AAAA: 2001:DB8::1
NICK: john (Supplemental)

9.1. Cryptography

The security of cryptographic methods relies on both the strength of
the cryptographic algorithms chosen and the strength of the keys worn
with those algorithms. The security moreover relies on the engineering
of the protocol worn by the map to make sure there are no
non-cryptographic ways to circumvent the safety of the overall map.
Right here is why developers of purposes managing GNS zones SHOULD
prefer out a default zone form regarded as receive on the time of
releasing the machine.
For purposes focusing on end users which might perhaps perhaps presumably be no longer expected to
realize cryptography, the utility developer MUST NOT leave
the zone form preference of most as a lot as date zones to end users.¶

This doc concerns itself with the preference of cryptographic
algorithms to be used in GNS.
The algorithms identified on this doc are no longer known to be
broken (within the cryptographic sense) on the most as a lot as date time, and
cryptographic analysis to this point leads us to imagine that they’re
at possibility of remain receive into the foreseeable future. On the choice hand, this
is rarely primarily without slay, and it is expected that original revisions of
this doc will probably be issued on occasion to replicate the most as a lot as date
most attention-grabbing practices on this case.¶

GNS PKEY zone keys spend ECDSA over Curve25519.
Right here is an unconventional alternative,
as ECDSA is most frequently worn with other curves. On the choice hand, used
ECDSA curves are problematic for a range of causes described in
the Curve25519 and EdDSA papers. The spend of EdDSA without delay is moreover
no longer seemingly, as a hash feature is worn on the non-public key which
destroys the linearity that the GNU Title System depends upon.
We don’t appear to be attentive to anybody suggesting that the utilization of Curve25519 as a alternative
of another frequent curve of same dimension would decrease the safety of
ECDSA. GNS uses 256-bit curves as a end result of that methodology the encoded (public)
keys match into a single DNS brand, which is factual for usability.¶

By methodology of crypto-agility, every time the necessity for an updated cryptographic
map arises to, as an instance, change ECDSA over Curve25519 for
PKEY files it’ll also merely merely be presented
by map of a original chronicle form. This type of original chronicle form can also merely then change
the delegation chronicle form for future files.
The veteran chronicle form remains
and zones can iteratively migrate to the updated zone keys.¶

In uncover to make sure ciphertext indistinguishability, care must be
focused on appreciate to the initialization vector within the counter
block. In our fabricate, the IV is continually the expiration time of the
chronicle block.
For blocks with relative expiration instances it is implicitly
ensured that every time a block is published into the storage, its IV is
queer because the expiration time is calculated dynamically and increases
monotonically.
The implementation MUST make sure when relative expiration instances
are decreased that the expiration time of the next chronicle block is
continually after the closing published block.
For blocks with absolute expiration instances, the implementation
MUST make sure the expiration time is elevated when the chronicle
files adjustments. For instance, the expiration time might perhaps perchance perhaps presumably be elevated
by a single microsecond.
In case of deletion of all handy resource files below a brand, the
implementation MUST withhold be aware of the closing absolute expiration time
of the closing published handy resource block.
When original files are added below this brand later, the implementation
MUST make sure the expiration instances are after the closing published
block.
At closing, in uncover to make sure monotonically rising expiration instances
the implementation MUST withhold a local chronicle of the closing time obtained
from the map clock, in uncover to net a monotonic clock in case
the map clock jumps backwards.¶

9.2. Abuse Mitigation

GNS names are UTF-8 strings. In consequence, GNS faces same points
with appreciate to title spoofing as DNS does for internationalized
domains.
In DNS, attackers can also merely register same sounding or having a look
names (peep above) in uncover to attain phishing assaults.
GNS zone administrators have to think this attack vector and
incorporate principles in uncover to mitigate it.¶

Extra, DNS might perhaps perchance perhaps moreover be worn to strive in opposition to illegal speak on the web
by having the respective domains seized by authorities.
On the choice hand, the same mechanisms can moreover be abused in uncover to impose
teach censorship, which is one in every of the motivations within the motivate of GNS.
Due to the this reality, the sort of seizure is, by fabricate, complex to very no longer probably in GNS.¶

9.3. Zone Management

In GNS, zone administrators deserve to manage and protect their zone
keys. Once a zone secret’s lost it is a long way no longer going to be recovered. Once it is
compromised it is a long way no longer going to be revoked (unless a revocation message was
pre-calculated and is mild accessible).
Zone administrators, and for GNS this contains end-users, are
required to responsibly and diligently protect their cryptographic
keys.
GNS helps offline signing of files.
It does no longer give a have to separate zone signing and key-signing keys
(as in [RFC6781]) in uncover to give usable safety.¶

In an identical type, users are required to manage their local root zone.
In uncover to make sure integrity and availability or names, users have to
make sure their local root zone files is no longer compromised or
outdated-fashioned.
It might perhaps perchance perhaps presumably moreover be expected that the processing of zone revocations and an
preliminary root zone is equipped with a GNS consumer implementation
(“drop transport”).
Extension and customization of the zone is on the beefy discretion of
the user.¶

Whereas implementations following this specification will probably be
interoperable, if two implementations join to diversified storages
they’re mutually unreachable.
This can even merely end result in a teach the set a chronicle can also merely exist within the worldwide
namespace for a particular title, but the implementation is no longer
talking with the storage and is as a end result of this reality unable to resolve it.
This distress is same to a destroy up-horizon DNS configuration.
Which storages are utilized most frequently rely upon the utility
it is built for.
The storage worn will perhaps rely upon the actual utility
context the utilization of GNS likelihood.
For instance, one utility might perhaps perchance perhaps presumably be the likelihood of hidden companies and products
within the Tor community.
Implementations of “aggregated” storages are seemingly, but
are expected to be the exception.¶

9.4. Impact of DHTs as Underlying Storage

This doc does no longer specify the properties of the underlying
storage which is required by any GNS implementation.
For implementers the utilization of a DHT as underlying storage, it is a long way needed
to exhibit that the properties of the DHT are without delay inherited by the
GNS implementation. This contains both safety as effectively as
other non-purposeful properties equivalent to scalability and performance.
Implementers should always mild pick monumental care when selecting or enforcing
a DHT to be used in a GNS implementation.
DHTs with sturdy safety and performance ensures exist
[R5N].
It might perhaps perchance perhaps presumably mild moreover be taken into consideration that GNS implementations
which build upon diversified DHT overlays are no longer at possibility of be
interoperable with every other.¶

9.5. Revocations

Zone administrators are instructed to pre-generate zone revocations
and securely store the revocation files in case the zone
secret’s lost, compromised or modified within the long urge.
Pre-calculated revocations can also merely change into invalid as a end result of expirations
or protocol adjustments equivalent to epoch adjustments.
In consequence, implementers and users have to manufacture precautions in uncover
to manage revocations accordingly.¶

Revocation payloads attain NOT comprise a ‘original’ key for key alternative.
Inclusion of the sort of key would contain two major disadvantages:¶

If revocation is worn after a non-public key was compromised,
allowing key alternative would be unhealthy: if an
adversary took over the non-public key, the adversary might perhaps perchance perhaps presumably then
broadcast a revocation with a key alternative. For the choice,
the compromised proprietor would don’t contain any likelihood to situation even a
revocation. Thus, allowing a revocation message to interchange a non-public
key makes coping with key compromise eventualities worse.¶

Most often, key revocations are worn with the fair of altering
cryptosystems. Migration to another cryptosystem by replacing keys
by map of a revocation message would exclusively be receive so long as both
cryptosystems are mild receive in opposition to forgery. This type of deliberate,
non-emergency migration to another cryptosystem must be performed by
running zones for both ciphersystems in parallel for a whereas. The
migration would fabricate by revoking the legacy zone key exclusively as soon as
it is deemed no longer receive, and optimistically after most users contain
migrated to the choice.¶

9.6. Mark Guessing

Narrative blocks are published encrypted the utilization of keys derived from the
zone key and chronicle brand. Zone administrators should always mild
carefully pick into myth if the brand and zone key might perhaps perchance perhaps presumably be public or if
those must be worn and regarded as as a shared secret.
Not like zone keys, labels can moreover be guessed by
an attacker within the community watching queries and responses. Given
a known and centered zone key, the spend of effectively known or without difficulty guessable
labels effectively end result in frequent disclosure of the guidelines to
the final public.
If the labels and as a end result of this reality the guidelines must be saved secret rather than to
those lustrous a secret brand and the zone correct by map of which to search, the
brand must be chosen accordingly. It is a long way urged to then spend a
brand with ample entropy as to discontinue guessing assaults.¶

It must be notorious that this attack on labels exclusively applies if the
zone secret’s somehow disclosed to the adversary. GNS itself
does no longer characterize it at some stage in a look up or when handy resource files are
published because the zone keys are blinded beforehand.¶