- Developer Corner
- Recent posts
Questions related to the GNU Name System (GNS), a decentfully decentralized PKI and censorship-resistant replacement for DNS.
The ".gnu" top level domain (TLD) is the root of each user's personal namespace. All GNS names have this TLD. The use of ".gnu" as a TLD is really just a trick to combine the existing DNS hierarchy with the GNS graph as it is seen from an individual user's point of view.
Each individual GNS user will run his own personal ".gnu" top level domain (TLD).
To be more specific, for each user, his own zone is authoritative for the ".gnu" pseudo-TLD (".gnu" is a pseudo-TLD or pTLD, not a normal TLD).
The ".zkey" top level domain (TLD) provides a (reverse) mapping from globally unique hashes to public key. A record in the ".zkey" TLD would look like
Nobody runs the ".zkey" TLD, as names in the ".zkey" TLD are hashes over public keys, no authority is needed. The ".zkey" TLD is essentially a very simple mapping mechanism where there are only public key 'PKEY' records --- each name is mapped to the corresponding PKEY value (which is again the name). Given this, no actual authority is needed: ".zkey" lookups never involve any network operation but rather only consist of a trival conversion from ASCII to binary.
A zone in GNS (like DNS) is a portion of the namespace that a single entity (usually a user) is responsible for. For example, GNU is responsible for the "gnu.org" zone and thus all names ending with ".gnu.org".
In GNS, each user controls three zones:
With GNS you have most of the record types you know from legacy DNS plus some GNS specific record types.
There are actually a few graphical user interfaces for different functions.
gnunet-setup is to configure GNUnet, and gnunet-fs-gtk is for file-sharing. There are a few other gnunet-XXX-gtk GUIs of lesser importance. Note that in order to obtain the GUI, you need to install the gnunet-gtk package, which is a separate download.
gnunet-gtk is a meta GUI that integrates most of the other GUIs in one window. One exception is gnunet-setup, which must still be run separately at this time (as setup requires the peer to be stopped).
We expect that the GNS zone editor will be used by roughly the same user base as equivalent DNS zone editors: administrators that run servers and services as well as advanced (or curious) users. Normal users should have no real need for the GNS zone editor, as they also do not host services.
The short answer is that the database is kept at the user's GNUnet peer. Now, a user may run multiple GNUnet peers, in which case the database could be kept at each peer (however, we don't have code for convenient replication). Similarly, multiple GNUnet peers can share one instance of the database --- the "gnunet-service-namestore" can be accessed from remote (via TCP). The actual data can be stored in a Postgres database, for which various replication options are again applicable. Ultimately, there are many options for how users can store (and secure) their GNS database.
Pretty small. Based on our user study where we looked at browser histories and the number of domains visited, we expect that GNS databases will only grow to a few tens of thousands of entries, small enough to fit even on mobile devices.
We believe so, as there is no entity that any government could force to change the mapping for a name except for each individual user (and then the changes would only apply to the names that this user is the authority for). So if everyone used GNS, the only practical attack of a government would be to force the operator of a server to change the GNS records for his server to point elsewhere. However, if the owner of the private key for a zone is unavailable for enforcement, the respective zone cannot be changed and any other zone delegating to this zone will achieve proper resolution.
CoDoNS decentralizes the DNS database (using a DHT) but preserves the authority structure of DNS. With CoDoNS, IANA/ICANN are still in charge, and there are still registrars that determine who owns a name.
With GNS, we decentralize the database and also decentralize the responsibility for naming: each user runs his own personal root zone and is thus in complete control of the names he uses. GNS also has many additional features (to keep names short and enable migration) which don't even make sense in the context of CoDoNS.
Like GNS, SocialDNS allows each user to create DNS mappings. However, with SocialDNS the mappings are shared through the social network and subjected to ranking. As the social relationships evolve, names can thus change in surprising ways.
With GNS, names are primarily shared via delegation, and thus mappings will only change if the user responsible for the name (the authority) manually changes the record.
ODDNS is primarily designed to bypass the DNS root zone and the TLD registries (such as those for ".com" and ".org"). Instead of using those, each user is expected to maintain a database of (second-level) domains (like "gnu.org") and the IP addresses of the respective name servers. Resolution will fail if the target name servers change IPs.
For security, it is well known that an initial trust path between the two parties must exist. However, for applications where this is not required, weaker mechanisms can be used. For example, we have implemented a first-come-first-served (FCFS) authority which allows arbitrary users to register arbitrary names. The key of this authority is included with every GNUnet installation. Thus, any name registered with FCFS is in fact global and requires no further introduction. However, the security of these names depends entirely on the trustworthiness of the FCFS authority.
Names have no owners in GNS, so there cannot be a "legitimate" domain owner. Any user can claim any name (as his preferred name or 'pseudonym') in his NICK record. Similarly, all other users can choose to ignore this preference and use a name of their choice (or even assign no name) for this user.
The basic idea behind the question is that one should allow users to suggest multiple pseudonyms (possibly with a ranking), and if one of the names is already taken (for shortening) GNS should use one of the alternative names.
If the NICK record is left out, GNS will not apply shortening. This can be done in the GNS zone editor by leaving the pseudonym blank. If this is done for the 'ai' zone, then a delegation from the 'mit' zone to the 'ai' zone will never be shortened to 'ai.short.gnu'. However, other users can still manually give the 'ai' zone any name they wish (for example, 'ki-mit.gnu') --- it just won't happen automatically.
Each record in GNS has a flag "private". Records are shared with other users (via DHT or zone transfers) only if this flag is not set. Thus, users have full control over what information about their zones is made public.
In particular, records that GNS automatically adds (i.e. via name shortening) are always marked 'private' by default. Otherwise, other users might indeed be able to obtain sensitive private information about one's online behavior.
To a limited degree, yes. I can pick my pseudonym to be "bank" and then if then someone else's peer learns about my identity his client would refer to me as "bank", even though I'm unlikely to be the bank of the other user. However, GNS mitigates this problem by placing all shortened records into the shorten zone, so the name will occur as bank.shorten.gnu, not bank.gnu. This hopefully will give most users a strong visual hint. If you believe that this is insufficient, shortening can be disabled.
The question presumes that (a) virtual hosting is only necessary because of IPv4 address scarcity, and (b) that LEHOs are only useful in the context of virtual hosting. However, LEHOs are also useful to help with X.509 certificate validation (as they specify for which legacy hostname the certificate should be valid). Also, even with IPv6 fully deployed and "infinite" IP addresses being available, we're not sure that virtual hosting would disappear. Finally, we don't want to have to wait for IPv6 to become commonplace, GNS should work with today's networks.
Trust metrics have the fundamental problem that they have thresholds. As trust relationships evolve, mappings would change their meaning as they cross each others thresholds. We decided that the resulting unpredictability of the resolution process was not acceptable. Furthermore, trust and consensus might be easy to manipulate by adversaries.
The owner of a private key can create a revocation message. This one can then be flooded throughout the overlay network, creating a copy at all peers. Before using a public key, peers check if that key has been revoked. All names that involve delegation (PKEY) via a revoked zone will then fail to resolve. Peers always automatically check for the existence of a revocation message when resolving names.
Yes, we believe so. Naturally, deployed GNS implementations would have to be updated to support the new signature scheme. The new scheme could then be run in parallel with the existing system by using a new record type (PKEY2) to indicate the use of a different cipher system.
Right now, the simple answer is yes. The reason is that if a relative expiration time is given for a records (i.e. 1 week from now), each time a request for that name is received, a signature is created with an absolute expiration time of 1 week into the future. The simplest implementation for this uses a signing key that is directly available to the resolver.
We don't expect this to be necessary, as GNS records are stored (and replicated) in the R5N DHT. Thus the authority will typically not be contacted whenever clients perform a lookup. Even if the authority goes (temporarily) off-line, the DHT will cache the records for some time. However, should having multiple servers for a zone be considered truly necessary, the owner of the zone can simply run multiple peers (and share the zone's key and database among them).
Yes, it would be feasible to run a DNS server instead. However, in order to run a personal zone, we would need to run a DNS server for each user, not just for each host (which is at least a theoretical problem on multi-user systems, as most operating systems only allow one DNS server to be configured per host). Note that the firewall-based DNS interception suffers from the same problem.
The usual mapping of names in GNS is unproblematic as the browser either does not really see it (with the GNS proxy) or does it itself (in which case policy code would just have to be adjusted). However, there are issues in particular cases which the GNS proxy needs to handle.
GNS should work fine with cookies in most cases. The GNS proxy translates cookies set by the browser for "gnu.org" to the domain name the browser expects (i.e. gnu.gnu). Similarly, if the webserver believes it is 'alice.gnu' the GNS proxy can translate cookies to 'alice.bob.gnu'.
This depends of course largely on the protocol. Our documentation and implementation efforts have largely focused on HTTP/HTTPS as this is the dominant protocol in use and here the devil is sometimes in the details. Some other protocols --- such as most P2P protocols --- do not really use DNS and would thus not be affected by a DNS-GNS transition.
The GNU Name system offers an alternative to DNS that is censorship resistant. As with any security mechanism, this comes at a cost (names are not globally unique). To draw a parallel, HTTPS connections use more bandwidth and have higher latency than HTTP connections. Depending on your application, HTTPS may not be worth the cost. However, for users that are experiencing censorship (or are concerned about it), giving up globally unique names may very well be worth the cost. After all, what is a "globally" unique name worth, if it does not resolve?
We say that DNS is 'centralized' because it has a central component / central point of failure --- the root zone and its management by IANA/ICANN. This centralization creates vulnerabilities. For example, the US government was able to reassign the management of the country-TLDs of Afganistan and Iraq during the wars at the beginning of the 21st century.
TrickleDNS pushes ("critical") DNS records between DNS resolvers of participating domains to provide "better availability, lower query resolution times, and faster update propagation". Thus TrickleDNS is focused on defeating attacks on the availability (and performance) of record propagation in DNS, for example via DDoS attacks on DNS root servers. TrickleDNS is thus concerned with how to ensure distribution of authoritative records, and authority remains derived from the DNS hierarchy.
GNS does not directly help with layer-3 censorship, but it does help indirectly in three ways:
1) Many websites today use virtual hosting, so blocking a particular IP address causes much more collateral damage than blocking a DNS name. It thus raises the cost of censorship.
2) Existing layer-3 circumvention solutions (such as Tor) would benefit from a censorship resistant naming system. Accessing Tor's ".onion" namespace currently requires users to use unmemorable cryptographic identifiers. With nicer names, Tor and tor2web-like services would be even easier to use.
GNS creates no significant problems for search engines, as they can use GNS to perform name resolution as well as any normal user. Naturally, while we typically expect normal users to install custom software for name resolution, this is unlikely to work for search engines today. However, the DNS2GNS gateway allows search engines to use DNS to resolve GNS names, so they can still index GNS resources. However, as using DNS2GNS gateways breaks the cryptographic chain of trust, legacy search engines will obviously not obtain censorship-resistant names.
UIA and GNS both share the same basic naming model, which actually originated with Rivest's SDSI. However, UIA is not concerned about integration with legacy applications and instead focuses on universal connectivity between a user's many machines.
In contrast, GNS was designed to interoperate with DNS as much as possible, and to also work as much as possible with the existing Web infrastructure. UIA is not at all concerned about legacy systems (clean slate).
First of all, in GNS you can explicitly see the trust chain, so you know if a name you are resolving belongs to a friend, or a friend-of-a-friend, and can thus decide how much you trust the result. Naturally, the trusted-computing base (TCB) can become arbitrarily large this way --- however, given the name length restriction, for an individual name it is always less than about 128 entities.