You are here

Resource Records in GNS

Primary tabs

GNS supports the majority of the DNS records as defined in RFC 1035. Additionally, GNS defines some new record types the are unique to the GNS system. For example, GNS-specific resource records are use to give petnames for zone delegation, revoke zone keys and provide some compatibility features.

For some DNS records, GNS does extended processing to increase their usefulness in GNS. In particular, GNS introduces special names referred to as "zone relative names". Zone relative names are allowed in some resource record types (for example, in NS and CNAME records) and can also be used in links on webpages. Zone relative names end in ".+" which indicates that the name needs to be resolved relative to the current authoritative zone. The extended processing of those names will expand the ".+" with the correct delegation chain to the authoritative zone (replacing ".+" with the name of the location where the name was encountered) and hence generate a valid .gnu name.

GNS currently supports the following record types:


A NICK record is used to give a zone a name. With a NICK record, you can essentially specify how you would like to be called. GNS expects this record under the name "+" in the zone's database (NAMESTORE); however, it will then automatically be copied into each record set, so that clients never need to do a separate lookup to discover the NICK record.


Name: +; RRType: NICK; Value: bob

This record in Bob's zone will tell other users that this zone wants to be referred to as 'bob'. Note that nobody is obliged to call Bob's zone 'bob' in their own zones. It can be seen as a recommendation ("Please call me 'bob'").


PKEY records are used to add delegation to other users' zones and give those zones a petname.


Let Bob's zone be identified by the hash "ABC012". Bob is your friend so you want to give him the petname "friend". Then you add the following record to your zone:

Name: friend; RRType: PKEY; Value: ABC012;

This will allow you to resolve records in bob's zone under "*.friend.gnu".


BOX records are there to integrate information from TLSA or SRV records under the main label. In DNS, TLSA and SRV records use special names of the form _port._proto.(label.)*tld to indicate the port number and protocol (i.e. tcp or udp) for which the TLSA or SRV record is valid. This causes various problems, and is elegantly solved in GNS by integrating the protocol and port numbers together with the respective value into a "BOX" record. Note that in the GUI, you do not get to edit BOX records directly right now -- the GUI will provide the illusion of directly editing the TLSA and SRV records, even though they internally are BOXed up.


The LEgacy HOstname of a server. Some webservers expect a specific hostname to provide a service (virtiual hosting). Also SSL certificates usually contain DNS names. To provide the expected legacy DNS name for a server, the LEHO record can be used. To mitigate the just mentioned issues the GNS proxy has to be used. The GNS proxy will use the LEHO information to apply the necessary transformations.


GNS allows easy access to services provided by the GNUnet Virtual Public Network. When the GNS resolver encounters a VPN record it will contact the VPN service to try and allocate an IPv4/v6 address (if the queries record type is an IP address) that can be used to contact the service.


I want to provide access to the VPN service "web.gnu." on port 80 on peer ABC012:
Name: www; RRType: VPN; Value: 80 ABC012 web.gnu.

The peer ABC012 is configured to provide an exit point for the service "web.gnu." on port 80 to it's server running locally on port 8080 by having the following lines in the gnunet.conf configuration file:

TCP_REDIRECTS = 80:localhost4:8080


Those records work in exactly the same fashion as in traditional DNS.


As specified in RFC 1035 whenever a CNAME is encountered the query needs to be restarted with the specified name. In GNS a CNAME can either be:

  • A zone relative name,
  • A zkey name or
  • A DNS name (in which case resolution will continue outside of GNS with the systems DNS resolver)


GNS can delegate authority to a legacy DNS zone. For this, the name of the DNS nameserver and the name of the DNS zone are specified in a GNS2DNS record.


Name: pet; RRType: GNS2DNS; Value:

Any query to pet.gnu will then be delegated to the DNS server at
For example, will result in a DNS query for to the server at Delegation to DNS via NS records in GNS can be useful if you do not want to start resolution in the DNS root zone (due to issues such as censorship or availability).

Note that you would typically want to use a relative name for the nameserver, i.e.
Name: pet; RRType: GNS2DNS; Value:
Name: ns-joker; RRType: A; Value:

This way, you can avoid involving the DNS hierarchy in the resolution of In the example above, the problem may not be obvious as the nameserver for "" is in the ".com" zone. However, imagine the nameserver was "". In this case, delegating to "" would mean that despite using GNS, censorship in the DNS ".org" zone would still be effective.


The domain names in those records can, again, be either

  • A zone relative name,
  • A zkey name or
  • A DNS name

The resolver will expand the zone relative name if possible. Note that when using MX records within GNS, the target mail server might still refuse to accept e-mails to the resulting domain as the name might not match. GNS-enabled mail clients should use the ZKEY zone as the destination hostname and GNS-enabled mail servers should be configured to accept e-mails to the ZKEY-zones of all local users.