The GNU Name System Specification

Introduction The Domain Name System (DNS) is a unique distributed database and a vital service for most Internet applications. While DNS is distributed, it relies on centralized, trusted registrars to provide globally unique names. As the awareness of the central role DNS plays on the Internet rises, 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. DNS was not designed with security as a goal. This makes it very vulnerable, especially to attackers that have the technical capabilities of an entire nation state at their disposal. This specification describes a censorship-resistant, privacy-preserving and decentralized name system: The GNU Name System (GNS). It is designed to provide a secure alternative to DNS, especially when censorship or manipulation is encountered. GNS can bind names to any kind of cryptographically secured token, enabling it to double in some respects as even as an alternative to some of today’s Public Key Infrastructures, in particular X.509 for the Web. This document contains the GNU Name System (GNS) technical specification of the GNU Name System (GNS), a fully decentralized and censorship-resistant name system. GNS provides a privacy-enhancing alternative to the Domain Name System (DNS). The design of GNS incorporates the capability to integrate and coexist with DNS. GNS is based on the principle of a petname system and builds on ideas from the Simple Distributed Security Infrastructure (SDSI), addressing a central issue with the decentralized mapping of secure identifiers to memorable names: namely the impossibility of providing a global, secure and memorable mapping without a trusted authority. GNS uses the transitivity in the SDSI design to replace the trusted root with secure delegation of authority thus making petnames useful to other users while operating under a very strong adversary model. This document defines the normative wire format of resource records, resolution processes, cryptographic routines and security considerations for use by implementors.

Zones A zone in GNS is defined by a public/private ECDSA key pair (d,zk), where d is the private key and zk the corresponding public key. GNS employs the curve parameters of the twisted edwards representation of Curve25519 (a.k.a. edwards25519) with the ECDSA scheme (). In the following, we use the following naming convention for our cryptographic primitives:

d: is a 256-bit ECDSA private key. In GNS, records are signed using a key derived from "d" as described in .
p: is the prime of edwards25519 as defined in , i.e. 2^255 - 19.
B: is the group generator (X(P),Y(P)) of edwards25519 as defined in .
L: is the prime-order subgroup of edwards25519 in .
zk: is the ECDSA public key corresponding to d. It is defined in as the curve point d*B where B is the group generator of the elliptic curve. The public key is used to uniquely identify a GNS zone and is referred to as the "zone key".

Resource Records A GNS implementor MUST provide a mechanism to create and manage resource records for local zones. A local zone is established by creating a zone key pair. Records may be added to each zone, hence a (local) persistency mechanism for resource records and zones must be provided. This local zone database is used by the GNS resolver implementation and to publish record information. A GNS resource record holds the data of a specific record in a zone. The resource record format is defined as follows:

where:

EXPIRATION: denotes the absolute 64-bit expiration date of the record. In microseconds since midnight (0 hour), January 1, 1970 in network byte order.
DATA SIZE: denotes the 32-bit size of the DATA field in bytes and in network byte order.
TYPE: is the 32-bit resource record type. This type can be one of the GNS resource records as defined in or a DNS record type as defined in or any of the complementary standardized DNS resource record types. This value must be stored in network byte order. Note that values below 2^16 are reserved for allocation via IANA ().
FLAGS: is a 32-bit resource record flags field (see below).
DATA: the variable-length resource record data payload. The contents are defined by the respective type of the resource record.

Flags indicate metadata surrounding the resource record. A flag value of 0 indicates that all flags are unset. The following illustrates the flag distribution in the 32-bit flag value of a resource record:

where:

SHADOW: If this flag is set, this record should be ignored by resolvers unless all (other) records of the same record type have expired. Used to allow zone publishers to facilitate good performance when records change by allowing them to put future values of records into the DHT. This way, future values can propagate and may be cached before the transition becomes active.
EXPREL: The expiration time value of the record is a relative time (still in microseconds) and not an absolute time. This flag should never be encountered by a resolver for records obtained from the DHT, but might be present when a resolver looks up private records of a zone hosted locally.
PRIVATE: This is a private record of this peer and it should thus not be published in the DHT. Thus, this flag should never be encountered by a resolver for records obtained from the DHT. Private records should still be considered just like regular records when resolving labels in local zones.

Record Types GNS-specific record type numbers start at 2^16, i.e. after the record type numbers for DNS. The following is a list of defined and reserved record types in GNS:

PKEY In GNS, a delegation of a label to a zone is represented through a PKEY record. A PKEY resource record contains the public key of the zone to delegate to. A PKEY record MUST be the only record under a label. No other records are allowed. A PKEY DATA entry has the following format:

where:

PUBLIC KEY: A 256-bit ECDSA zone key.

GNS2DNS It is possible to delegate a label back into DNS through a GNS2DNS record. 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 for DNS names. A GNS2DNS DATA entry has the following format:

where:

DNS NAME: The name to continue with in DNS (0-terminated).
DNS SERVER NAME: The DNS server to use. May be an IPv4/IPv6 address in dotted decimal form or a DNS name. It may also be a relative GNS name ending with a "+" top-level domain. (all 0-terminated)

LEHO Legacy hostname records can be used by applications that are expected to supply a DNS name on the application layer. The most common use case is HTTP virtual hosting, which as-is would not work with GNS names as those may not be globally unique. A LEHO resource record is expected to be found together in a single resource record with an IPv4 or IPv6 address. A LEHO DATA entry has the following format:

where:

LEGACY HOSTNAME: A UTF-8 string (which is not 0-terminated) representing the legacy hostname.

NOTE: If an application uses a LEHO value in an HTTP request header (e.g. "Host:" header) it must be converted to a punycode representation .

NICK Nickname records can be used by zone administrators to publish an indication on what label this zone prefers to be referred to. This is a suggestion to other zones what label to use when creating a PKEY record containing this zone's public zone key. This record SHOULD only be stored under the empty label "@". A NICK DATA entry has the following format:

where:

NICKNAME: A UTF-8 string (which is not 0-terminated) representing the preferred label of the zone. This string MUST NOT inlcude a "." character.

BOX In GNS, every "." in a name delegates to another zone, and GNS lookups are expected to return all of the required useful information in one record set. This 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.foo.gnu" will be stored in the record set of "foo.gnu" as a BOX record with service (SVC) 443 (https) and protocol (PROTO) 6 (tcp) and record_type "TLSA". For reference, see also A BOX DATA entry has the following format:

where:

PROTO: the 16-bit protocol number, e.g. 6 for tcp. In network byte order.
SVC: the 16-bit service value of the boxed record, i.e. the port number. In network byte order.
TYPE: is the 32-bit record type of the boxed record. In network byte order.
RECORD DATA: is a variable length field containing the "DATA" format of TYPE as defined for the respective TYPE in DNS.

VPN A VPN DATA entry has the following format:

Publishing Records GNS resource records are published in a distributed hash table (DHT). We assume that a DHT provides two functions: GET(key) and PUT(key,value). In GNS, resource records are grouped by their respective labels, encrypted and published together in a single resource records block (RRBLOCK) in the DHT under a key "q": PUT(q, RRBLOCK). The key "q" which is derived from the zone key "zk" and the respective label of the contained records.

Key Derivations Given a label, the DHT key "q" is derived as follows: We use a hash-based key derivation function (HKDF) as defined in . We use HMAC-SHA512 for the extraction phase and HMAC-SHA256 for the expansion phase.

PRK_h: is key material retrieved using an HKDF using the string "key-derivation" as salt and the public zone key "zk" as initial keying material.
h: is the 512-bit HKDF expansion result. The expansion info input is a concatenation of the label and string "gns".
d: is the 256-bit private zone key as defined in .
label: is a UTF-8 string under which the resource records are published.
d_h: is a 256-bit private key derived from the "d" using the keying material "h".
zk_h: is a 256-bit public key derived from the zone key "zk" using the keying material "h".
L: is the prime-order subgroup as defined in .
q: Is the 512-bit DHT key under which the resource records block is published. It is the SHA512 hash over the public key "zk_h" corresponding to the derived private key "d_h".

We point out that the multiplication of "zk" with "h" is a point multiplication, while the multiplication of "d" with "h" is a scalar multiplication.

Resource Records Block GNS records are grouped by their labels and published as a single block in the DHT. The contained resource records are encrypted using a symmetric encryption scheme. A GNS implementation must publish RRBLOCKs in accordance to the properties and recommendations of the underlying DHT. This may include a periodic refresh publication. A GNS RRBLOCK has the following format:

where:

SIGNATURE: A 512-bit ECDSA deterministic signature compliant with . The signature is computed over the data following the PUBLIC KEY field. The signature is created using the derived private key "d_h" (see ).
PUBLIC KEY: is the 256-bit public key "zk_h" to be used to verify SIGNATURE. The wire format of this value is defined in , Section 5.1.5.
SIZE: A 32-bit value containing the length of the signed data following the PUBLIC KEY field in network byte order. This value always includes the length of the fields SIZE (4), PURPOSE (4) and EXPIRATION (8) in addition to the length of the BDATA. While a 32-bit value is used, implementations MAY refuse to publish blocks beyond a certain size significantly below 4 GB. However, a minimum block size of 62 kilobytes MUST be supported.
PURPOSE: A 32-bit signature purpose flag. This field MUST be 15 (in network byte order).
EXPIRATION: Specifies when the RRBLOCK expires and the encrypted block SHOULD be removed from the DHT 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 in network byte order.
BDATA: The encrypted resource records with a total size of SIZE - 16.

Record Data Encryption and Decryption 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 looks as follows:

where:

RR COUNT: A 32-bit value containing the number of variable-length resource records which are following after this field in network byte order.
EXPIRATION, DATA SIZE, TYPE, FLAGS and DATA: These fields were defined in the resource record format in . There MUST be a total of RR COUNT of these resource records present.
PADDING: The padding MUST contain the value 0 in all octets. The padding MUST ensure that the size of the RDATA WITHOUT the RR COUNT field is a power of two. As a special exception, record sets with (only) a PKEY record type are never padded. Note that a record set with a PKEY record MUST NOT contain other records.

The symmetric keys and initialization vectors are derived from the record label and the zone key "zk". For decryption of the resource records block payload, the key material "K" and initialization vector "IV" for the symmetric cipher are derived as follows: HKDF is a hash-based key derivation function as defined in . Specifically, HMAC-SHA512 is used for the extraction phase and HMAC-SHA256 for the expansion phase. The output keying material is 64 octets (512 bit) for the symmetric keys and 32 octets (256 bit) for the initialization vectors. We divide the resulting keying material "K" into a 256-bit AES key and a 256-bit TWOFISH key:

Similarly, we divide "IV" into a 128-bit initialization vector and a 128-bit initialization vector:

The keys and IVs are used for a CFB128-AES-256 and CFB128-TWOFISH-256 chained symmetric cipher. Both ciphers are used in Cipher FeedBack (CFB) mode .

Internationalization and Character Encoding All labels in GNS are encoded in UTF-8 . This does not include any DNS names found in DNS records, such as CNAME records, which are internationalized through the IDNA specifications .

Name Resolution TODO

Entry Zone There are three sources from which the entry zone can be determined which MUST be queried in this order:

Check if top-level domain maps to a local zone key.
Check if top-level domain maps to a local zone name.
Check if a configuration exists that maps a prefix to an external zone key.

If the TLD is a Base32-encoded public zone key "zk", the entry zone of the resolution process is implicitly given by the name. => Entry zone: zk => Name to resolve from entry zone: www.example ]]> Each local zone is associated with a single GNS label. If this label is the top-level domain (TLD) of the name to resolve, resolution MUST start from this local zone. Entry zone: zk1 => Name to resolve from entry zone: www.example ]]> If no matching local zone for the TLD is found, external prefix to zone mappings are checked. External prefix to zone key mapping SHOULD be configurable through the GNS implementation. A mapping has the form "prefix = public zone key". The prefix may consist of multiple GNS labels concatenated with a ".". If multiple prefixes match the name to resolve, the longest prefix is chosen. The prefix length of two results cannot be equal, as this would indicate a misconfiguration. Entry zone: zk1 => Name to resolve from entry zone: www ]]>

Record Retrieval In order to resolve a name in GNS, a type MAY be given. However, filtering of record results according to type is done after the resource record set is retrieved. In each step of the recursive name resolution, there is an authoritative zone zk and a name to resolve which may be empty. Initially, the authoritative zone is the entry zone. If the name is empty, it is interpreted as the apex label "@".

Extract the right-most label from the name to look up.
Calculate q using the label and zk.
Perform a DHT query GET(q) to retrieve the RRBLOCK.
Verify the RRBLOCK and decrypt the BDATA contained in it.

Upon receiving the RRBLOCK from the DHT, apart from verifying the provided signature, the resolver MUST check that the authoritative zone key was used to sign the record: The derived zone key "h*zk" must match the public key provided in the RRBLOCK.

Record Processing If the remainder of the name to resolve is not empty, the records result MUST consist of a single PKEY record or one or more GNS2DNS records. The recursion is then continued with the PKEY record value as new authoritative zone or using the specified DNS server(s) as defined int the following. If the remainder of the name to resolve is empty but we have received a record set containing only a single PKEY record, the recursion is continued with the PKEY as authoritative zone and the empty apex label "@" as remaining name. If the record type to be resolved is PKEY, the PKEY record set is returned and the resolution is concluded. If the remainder of the name to resolve is empty and the records set does not consist of a PKEY record, the record set is the result and the resolution is concluded.

PKEY When a resolver encounters a PKEY record, resolution continues recursively with the remainder of the name in the newly discovered GNS zone as defined in .

GNS2DNS When a resolver encounters a GNS2DNS record it is expected that it first resolves the IP(s) of the DNS specified name server(s). GNS2DNS records MAY contain numeric IPv4 or IPv6 addresses, allowing the resolver to skip this step. The DNS server names may themselves be names in GNS or DNS. If the DNS server name ends in ".+", the rest of the name is to be interpreted relative to the zone of the GNS2DNS record. Then, the DNS name from the GNS2DNS record is appended to the remainder of the name to be resolved, and resolved by querying the name server(s). Multiple GNS2DNS records may be stored under the same label, in which case the resolver MUST try all of them. However, if multiple GNS2DNS records are present, the DNS name MUST be identical for all of them.

CNAME Upon encountering a CNAME record, the resolver must continue the resolution using the CNAME unless the queried record type is a CNAME and we have reached the leftmost label of the name. Resolution may continue either in GNS if GNS is authoritative of the respective TLD or if the TLD is a relative zone indicator ("+") and we have found the CNAME in a GNS zone. Otherwise, the resolver should continue the resolution recursively through DNS. The recursive DNS resolution process may yield a CNAME as well which in turn may either point into the DNS or GNS namespace. In order to prevent infinite loops, the resolver should implement loop detections or limit the recursive resolution of CNAMEs using an upper bound.

BOX When a BOX record is received, a GNS resolver must unbox it if the name to be resolved continues with "_SERVICE._PROTO", otherwise it 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.

VPN If the queried record type is either A or AAAA and the retrieved record set contains at least one VPN record, the resolver must open a tunnel and return the IPv4 or IPv6 tunnel address, respectively. The type of tunnel depends on the contents of the VPN record data. No result is returned if the resolver implementation does not support any of the tunnnels provided in the VPN records.

Zone Revocation In order to revoke a zone, a signed revocation object must be published. This object must be signed using the private zone key. The revocation object is flooded in the overlay network. To prevent flooding attacks, the revocation message must contain a proof-of-work. The revocation message may be calculated ahead of time. A revocation message is defined as follows:

Security Considerations TODO

IANA Considerations This will be fun

Test Vectors The following represents a test vector for a record of type MX with a priority of 10 and the mail hostname mail.example.com.