FAKULTÄT FÜR INFORMATIK

DER TECHNISCHEN UNIVERSITÄT MÜNCHEN

Masterarbeit in Informatik

Design and Implementation of a Censorship Resistant and Fully Decentralized Name System
Martin Schanzenbach, B.Sc.

FAKULTÄT FÜR INFORMATIK
DER TECHNISCHEN UNIVERSITÄT MÜNCHEN

Masterarbeit in Informatik

Design and Implementation of a Censorship Resistant and Fully Decentralized Name System Design und Implementierung eines zensurresistenten und vollständig dezentralisierten Namenssystems
Author: Supervisor: Advisor: Date: Martin Schanzenbach, B.Sc. Christian Grothoff, Ph.D. (UCLA) Dipl.Inform. Matthias Wachs September 25, 2012

.

.I assure the single handed composition of this master’s thesis only supported by declared resources. 2012 Martin Schanzenbach. B. September 24. Munich.Sc.

.

Ralph Holz. Simon Josefsson. Niels Möller.Acknowledgments This work is based on a paper with the title “A Censorship Resistant and Fully Decentralized Replacement for DNS” from Christian Grothoff. Matthias Wachs and Martin Schanzenbach. compiled as FAQ in Appendix A. Stefan Monnier. I thank Christian Grothoff and Matthias Wachs for their extensive support and invaluable advice throughout the making of this thesis. vii . I thank Jacob Appelbaum for suggestions to improve our design for firewall-based DNS interception and Ludovic Courtès. Martin Pool. Finally. Luke Leighton. Neal Walfield and Zooko Wilcox-O’Hearn for insightful comments. Ondrej Mikle. Chris Palmer. Nikos Mavrogiannopoulos. I also thank everyone who submitted information about their browser history for the study on surfing behavior. Richard Stallman. I want to thank my family for making it possible to start and successfully finish my studies in the first place.

.

proxies can be used to enable legacy applications to function with GADS. We discuss how GADS and legacy DNS can interoperate during a transition period and what additional security advantages GADS offers over DNS with Security Extensions (DNSSEC). secure and memorable mapping is impossible without a trusted authority. provides technical details on how GADS has been implemented and discusses deployment issues for using GADS with existing systems. SDSI offers an alternative by linking local name spaces. GADS uses the transitivity provided by the SDSI design to build a decentralized and censorship resistant name system without a trusted root based on secure delegation of authority. The system builds on ideas from Rivest’s Simple Distributed Security Infrastructure (SDSI) to address a central issue with providing a decentralized mapping of secure identifiers to memorable names: providing a global. This work presents the fundamental goals and ideas behind GADS. secure name system providing memorable names for the Internet as an alternative to the Domain Name System (DNS). Additional details need to be considered in order to enable GADS to integrate smoothly with the World Wide Web.Abstract This thesis presents the design and implementation of the GNU Alternative Domain System (GADS). the existing HTTP-based infrastructure makes many assumptions about globally unique names. While following links on the Web matches following delegations in GADS. we present the results of a survey into surfing behavior. a decentralized. which suggests that the manual introduction of new direct links in GADS will be infrequent. ix . however. Finally.

.

mit GADS funktionieren. vertrauenswürdige Instanz. welche nahelegt. welches einprägsame Namen für das Internet bietet. um ein dezentralisiertes. wie die Interoperabilität von GADS und DNS in einer Übergangsperiode gewährleistet werden kann und welche zusätzlichen Sicherheitsvorteile GADS gegenüber DNS mit seinen Sicherheitserweiterungen (DNSSEC) bietet. Es wird dabei erörtert. dass Applikationen. durch den Einsatz von Proxies ist es jedoch möglich. sicheren und einpräsamen Zuordnung ist unmöglich ohne globale. Während das Folgen von Links im Web den Delegierungen in GADS entspricht. liefert technische Details zur Implementierung von GADS und erläutert Probleme bei dem Einsatz von GADS in existierenden Systemen. xi . Zusätzliche Details müssen bei der Integrierung von GADS in das World Wide Web beachtet werden. Dieses Ziel wird erreicht durch sichere Delegation von Zuständigkeit. dass keine zentralen Vertrauensanker benötigt. macht die existierende HTTP-basierte Infrastruktur viele Annahmen in Bezug auf global einzigartige Namen. die solche Annahmen machen. Schliesslich werden die Ergebnisse einer Umfrage zum Surfverhalten von Nutzern diskutiert. als Alternative zu dem Domain Name System (DNS). SDSI bietet hierfür eine Alternative. um das zentrale Problem zu lösen. GADS nutzt transitive Delegation von lokalen Namensräumen. dass das manuelle Einführen neuer direkter Verbindungen in GADS nur gelegentlich nötig ist. dezentralisiert sichere Bezeichner einprägsamen Namen zuzuordnen: Das Bereitstellen einer globalen. bereitgestellt durch das SDSI Design.Zusammenfassung Diese Arbeit präsentiert das Design und die Implementierung des GNU Alternative Domain System (GADS). Diese Arbeit stellt die fundamentalen Ziele und Ideen hinter GADS vor. zensurresistentes Namenssystem zu erschaffen. sicheren Namenssystem. einem dezentralisierten. GADS baut auf Ideen von Rivest’s Simple Distributed Security Infrastructure (SDSI) auf.

xii .

. . . . . . . . . . . . . . Signatures. . . . . .1. .2. . . . . . . . . . . . . . . . . . . . . . . . .2. . . . . . . . 3. . . . . . . . . . .2. . . 2. . . . . Distributed Hash Tables . . . . . . . 3. . . . .1. . . . .2. .4. . . . . . . . .2. Design of the Name System . . . . . xiii . . . . . . . . . . . . . . . 3. .3. . . . . . . . . . . . . . . . . . .3. . . 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Name Systems . . . . . . . . . . . . . . . . . . . .4. . . .2. . . . . . . .1. Zone Revocation . . Privacy and Usability 3.1. . . . . . . . . . . vii ix 1 1 2 2 5 5 6 8 9 11 12 14 15 15 16 18 21 21 22 23 23 25 26 27 28 28 33 33 34 35 36 37 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. . . . . . . . . .1. . . . . . . . . . 2. . . . . . . .1. . . . . . . . . . . . . . . . . . . . . . . . .3. . . . . . . . . .5. . . . . Tor . . . . . . . . . . . . . . . .2. . .5.1. . . . . Zone Delegation . . . . . . . . . . . . . . . . . . . . . . . . 2. . . . . . . . . . . . .7. . . 2. . . 1. . . . . . . 3.1. . . . . . . . . Accessing GADS without Installation . . . . . . . . . Integration with Legacy Applications . . . . . . . . DNSSEC . . . . . . . . . .1. . . . . . . . . .4. . . .3. . . . . . . . 3.1. . . . .onion System .3. . . . . . . . . . . Network Protocol and Routing . . . . . . . . . Enabling Replies (e-mail) . . . . .1. . . . . . . . . Related Work 2. . Three Zones for Security.3. . . . Petname Systems . Timeline Systems . . . . . . . Surfing with Pseudonyms and Petnames . . . . . . . .2. . . . . . . .2. . . . . . . 3.2. . .Contents Acknowledgments Abstract 1. . . Domain Name System . . . . . .1. . . . . . . . . . . The GNU Alternative Domain System 3. .2. . . . . . . . . . . . . . . . . . . . . . 2. . Names and Record Types . . . . X-Vine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2. R5 N . .3. . . . . . .6. . 2. Organization . . . . . . . . 3. . .3. 3. . . . . . .5. . 3. . . . . . . . . . . . . . . . . . . 2. . Contribution . . . . . . . . . 2. .8. . Context dependent Names . . . .2. . . . . . . . . . . . .2. . . . . . .2. . . . . . . . . . . . . . . Incompatible Applications . . . . 3. .3. Adversary Model . Globally Unique and Secure Names . . . 1. . . . . . . Whanau . . . . . . . . . . . . . . . .1. . . . . . . . . . . . 3. . . . . .1. . Virtual Hosting and SSL Certificates . . . .2. . . . . . . . . . . . . . . . . . .1. . . . . Expiration and Freshness . . . Simple Distributed Security Infrastructure 2. . . . . . . . . . . . 3. . . . . . . 3. 3. . . . . . . . . . . . . . . . . . . . . . .2. . . . Introduction 1. .

. . . . Alternative GADS resolvers . . . . . . . . . gnunet-namestore (1) . . . .1. . . . B. . . . . . . . . . . . . . . . . . . . . . . . . . 5. . . . . . DNS packets . . . . . . . .4. . . . . . . .2. . . . . . . . . . . . . . . . . . .1. . . . . .3. . . . . 4. . . . . . . . . . . . . . . . . .1. . . . . . GNUnet Name System . . . 6. . . .2. . . . . . . . . .3. . . . . . . . .1. . . . . gnunet-gns (1) . . . .1. . . B. . . . . . See Also . . . . The VPN Service . . . . . . . . . . . . . . . . . . Discussion 5. . . . . . . . . . . . .4. . . Appendix A. . . . . . .5. . Integration into Operating Systems . . . . . . . . . . . . . . .3. Command-Line Tools . . .1. . . . . . . . . . . . . . . . . . . . . . . . .2. . . . . . . . . . . . B. .1. . Bugs . 4. . . . . . . Network Integration . . B. . .2. . . . . . . . . . .2. . . . . . . .4. . . . . The GADS Zone Editor and GADS QR codes 4. . . . . . . . . .1. . . . . . . . . . . . . . . . . . . . Synopsis . . . . . B. . . . . . . . . . . . . . . . Improved Migration for Legacy Networks . . . . . . . . . . . Name . . . . . . .3. 5. .2. .4. . . . . . Complementary Tools and Programs . . . . . . . . . . . . . . . . . . . . . . . . . . B. Conclusion and Future Work 41 41 41 42 43 44 44 45 48 49 49 51 55 56 56 57 57 59 59 60 61 61 62 64 67 . . . . . . . . B. Name . . . . . .1. GNS API .1. . . . . . . . 4. . . . . . B. . . . .1. . . . . Integration into Applications . .2. . . . . . Description . . . . . . . . 5. . 4. . 4. . . . . . . . . 4. . . . .6. . . . . . . . . . . . . .Contents 4. . . . . . . . . . . . . . . . .1. . . . . . . . . . . . . . . . . . . . . . xiv . . . Fork-and-exec . . . . . . . . . . . . . . .2. 4. . . . . . . . . . . . . . . .3. . . . . . 4. . . Usability Evaluation: Surfing Behavior . .1. Firewall-based DNS Interception . . . . . . . . . . . . . . 71 71 81 81 81 81 81 81 82 82 82 82 82 82 82 . .3. . . .3. . . . .2. . . 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1. . .2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Options . . . . . . . . . . . . . . . . . . .3. . . . . . . . . . . Automated Name Shortening and Security 5. . . . .4. . . . . . 5. . . . .3. .2. . . . . . . 5. . . . . .1. . . . . . . . . . .2. . . . . . . . . . . . . . . . . . . . . . . . . .2. . . . . . . . . . . . . DNS-to-GADS Gateway . B. . . . . . .1. . . . . . . Description . . . . . . . . . . . . .6. . . . . . . . . . . . . . . . 4. . . . 4. . . . . . . . . . . . . . . . . . . . . . . .2. . . . . . .3. .2. Options . . Establishing Trust with GADS . . . . . . . . HTTP Proxy . . . . . . . . . . . . . . . Usability and Bootstrapping . . . . . . . . Synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4. . . . . . . . . . . . 4. . Command-Line Tool Reference B. . . . . . . . . . . . The Namestore Implementation . . . . . . B. .1. . . . . . 4. . . . . . .4. . . . . .3. . . . .5. . . . . . . . . . .1. . . . . . . . Frequently Asked Questions B. . . . . . . . . . . . . . . . 4. . . . . . . . . . . . . . . . . . . . . . . Implementation 4. . B. . . . . . . . . . . NSS Plugin . . . . . . . . .2. .

. . . .5. . . . . . . . . . . . . . . . C. E. . . . . . . . . . . . . . . . GNUNET_GNS_cancel_shorten_request C. . . . . . . . . . . GNUNET_GNS_lookup_zone . C. .2. . .3. . .1. . . . D. . . . . . . . GADS Record Types and Flags D. . . . . . . . . . . . . . . GNUNET_GNS_shorten_zone . . . . . . . . . . Chromium and Chrome E. . . .2. . . . . . . . .1. . . . . . . . . . . GNUNET_GNS_connect . C. . . . . .1. . . . . . . . . . .1. . . . . Browsing Survey E. .1. . . . . . Firefox . . . . . . . . . . . . . . . . . . . . . . . . .8. . . . C. . . . GNUNET_GNS_cancel_lookup_request . . . . . . . . . . . . . . . . . . . . . . . . . .2. . . . . .1. . . . . . . . . . . . . . . . .1. . . . . . . . . . . . . . . GNUNET_GNS_disconnect . . . C. . . . . . . . . . . . . . . . . . . . . . . . .2. . . . . . . . . . . . . . . E. . . . . . . . . . . . . . . . . . .4. Record Flags . . . . . . .1. . . . . .6. . . . . . . . . . . . . . . . . . . .1. . . . . .1. . . Bugs . . . . . . . . . .6. . . . . . Bibliography . .1. . . . . B. . . . . . . . . . . . . . .10. . . . . . . . . . . .2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Contents B. . . C. . .2.7. . . C. . . . . . . . .5. . . . . . . . . . . . . . . . . Scripts . . . Record Types . . . . . . . . . . . . . . . . .1. .1.1. . . . . GNUNET_GNS_shorten . . . . . . . . C. . . . . . . . Function Documentation . . . . . 83 83 85 85 85 85 85 85 86 86 86 87 87 88 89 89 90 91 91 91 92 94 97 D. E. . . . . . . . . . . . . . GNUnet Name System API C.1. See Also . GNUNET_GNS_lookup .1. . . . . User Data . . . . . C. . . . . GNUNET_GNS_cancel_get_auth_request C. . . . . xv .9. . . . . . . . . . . . . . . . . . . . . . .1. GNUNET_GNS_get_authority . . .

.

DNSSEC is designed to provide data integrity and origin authentication for replies to DNS queries. Our approach borrows a central idea from Rivest’s Simple Distributed Security Infrastructure (SDSI) [46]. it relies on centralized. SDSI is a distributed public-key infrastructure without a global name space where every participant is a certification authority issuing his own certificates. The use of globally unique names causes significant frustration for new users that find that many reasonable names are already owned.1. corporations and their lobbies can legally compel operators of DNS authorities to manipulate entries and certify the changes.1. As a result. a replacement for DNS which is fully decentralized and eliminates ownership of names. ” – Tim Berners-Lee The Domain Name System (DNS) is a unique distributed database and a key service for most Internet applications. Introduction “The Domain Name System is the Achilles heel of the Web. writes [50]: “When a program has an owner. As the awareness of the central role DNS plays on the Internet rises. One current effort to secure DNS is DNSSEC [2]. trusted registrars to provide globally unique names. As a result of its adversary model. Governments. mappings cannot be globally unique. While DNS is distributed. various institutions are engaged in legal attacks on the DNS which threaten the availability and integrity of the Internet [14]. DNSSEC fails to prevent issues such as the recent brief disappearance of thousands of legitimate domains due to a data management accident in the execution of established censorship procedures [24]. the users lose freedom to control part of their own lives. thereby eliminating most1 legal attacks on the name system and offering users relief from DNS censorship. Richard Stallman. founder of the GNU project. 1.509 certificates [49]. 1 . because prosecuting individual users for using software remains a possible legal attack vector. The important thing is that it’s managed responsibly. We advocate a solution to those issues in line with the ideas of GNU. this paper presents the design and implementation of the GNU Alternative Domain System (GADS). Contribution Our contribution is a petname system [51] where every individual user is able to freely and securely map names to values.” In contrast to ownership-based name systems. Soghoian and Stamm warned that this might happen for X. Certificates 1 We say “most”. The adversary model of DNSSEC excludes legal attacks.

we provide some technical background on Distributed Hash Tables. in particular. if Alice has a name for Bob. we systematically position related designs in the context of distributed name systems and highlight their relationship to GADS. specifically. The ability to delegate is central to achieving our goal of providing a practical alternative to globally unique names.1. • Compatibility: the system is compatible with the existing DNS and provides all key capabilities of DNS (except globally unique names) 1. 1. We describe GADS’s design in Chapter 3. In Chapter 2. the adversary is unable to break cryptographic primitives and cannot prevent communication between benign participants.2. Furthermore. then Alice will also have a name for Carol. GADS uses a censorshipresistant Distributed Hash Table as a decentralized database. Adversary Model Our adversary model is significantly different from that of DNSSEC as the adversary may participate in any possible role in the system and there is no bound on the percentage of malicious participants. This definition excludes the possibility of having a trusted third party. Our adversary model allows the adversary to assume multiple identities (Sybils) and to have more computational resources than benign users. Organization The remainder of this work is structured as follows. following common network-usage patterns. Additionally. Introduction are used for delegation.3. we describe additional application-specific techniques that enable the use of GADS in the context of various common Internet applications. and Bob has a name for Carol. A central idea in GADS is the replacement of the DNS root zone and DNS delegation with individual petnames assigned by each user in combination with SDSI-like secure delegation of subdomains. they certify the mapping of local names to public keys of other participants. the WWW and e-mail. for example by confiscating names or forcing operators to direct people to adversary-controlled impostor sites. In addition. In Chapter 4 we provide details on our reference implementation. including all benign users combined. The adversary can attempt to take over control of names using legal means. Our system exhibits certain benefits for Internet security in general. a central component in our distributed design. we discuss these in Chap- 2 . However. The contribution of this thesis is thus a fully decentralized name system which provides the following features: • Usability: cryptographic keys identify entities and are bound to memorable names • Security: malicious participants cannot prevent the creation of such bindings or censor existing bindings • Transitivity: names can be passed conveniently between users.

1.3. 3 . in Chapter 6. Finally. Organization ter 5. In this chapter we also present the results of a survey to answer some key questions about how GADS would perform in practice from the user’s point of view. we review the results of this work and evaluate the contribution.

Introduction 4 .1.

namely prominent examples of distributed hash tables and their properties. 2.509 PKI. There is no global name space in SDSI that allows to uniquely identify principals by name. making it possible to verify the mapping. Related Work In this chapter we will discuss two major fields of research that form the basis of this work. SDSI allows any principal to create and sign certificates. A principal in SDSI is a public key. After all. Simple Distributed Security Infrastructure SDSI. Since the principal is a public signature verification key. This is a process that all CAs have to do. [46]. The ideas in SDSI greatly influence the design of our name system. SDSI has no notion of individuals or groups but only of principals. The ownership validation processes and policies define the trustworthiness of the authority.1.509 PKI is overly complex and incomplete because it relies on global name spaces. Bob exports certificates asserting that his local name “alice” maps to a specific principal. like those in the X. if the principal “bob” is known and trusted. the first section deals with Rivest and Lampson’s Simple Distributed Security Infrastructure (SDSI) design. The final section of the related work chapter is about the networking aspects that are required for our design goals. 5 . For example: If principal “dave” refers to another principal as “bob” in his local name space and “bob” refers to yet another principal as “alice” in his local name space. in which he can refer to other principals using arbitrarily chosen names. Three central design concepts of SDSI that are particularly important for our work are principals. revolves around the idea of a simple public-key infrastructure (PKI) and linked local name spaces. a principal can manage his own local name space. However. local name spaces and using certificates to create and assert name-value bindings. he can verify signed statements or requests made by other principals. it is possible to link local name spaces by issuing name/value certificates.2. Additionally. Instead. as defined by Rivest et al. The binding establishes a trust link from one principal to another and is an important process in the SDSI design. then “dave” can refer to the principal that “bob” calls “alice” as “bob’s alice”. effectively making all principals Certification Authorities (CAs). The authors of SDSI claim that the present X. The authors state that the process of creating a binding in a local name space from name to principal must be manual. judgment is required to validate that a specific public-key is actually owned by the individual or group that controls the principal. The second section describes the theory of name systems.

2. Principals can also bind other arbitrary values to their local names. however. The authors claim that for the average user the creation of around 5-20 manual bindings is sufficient because linked name spaces allow principals to transitively follow bindings to foreign name spaces in a secure fashion by validating the exported certificates. making it an ideal concept for a secure name system. 1 We realize this appears to be a negative definition. to structure our discussion of related work: Theorem 2. Definition 2.2.1 Definition 2. The influence of SDSI on our design of a secure name system will become apparent in Chapter 3. secure and global names at the same time. The system supports an unlimited. Referring to “bob’s alice’s www” can be easily transformed into a very familiar format: www. It is impossible to have a name system that achieves memorable. Note that this model excludes a trusted third party acting as an authority. the definition is meant to highlight the trade off between the simplicity of the name and the complexity needed to defeat enumeration attacks. The adversary model for Zooko’s triangle is the same as in GADS. The linking of name spaces can be interpreted as secure subdomain delegation and principals as users controlling their own name space root. open number of participants without prior coordination or certification of participants.3 (Secure).bob. In other words. Related Work In SDSI. All benign participants receive the same global values for the same names. malicious participants. Name Systems We use Zooko’s triangle [60]. Definition 2.1 (Zooko’s triangle). The description of the adversary model for such participants is found in the introduction of this work. 6 . the number of bits of entropy in the name is insufficient against enumeration attacks.2 (Memorable).4 (Global).alice. an insightful hypothesis on the design space for name systems. 2. A name is memorable if it is feasible for an attacker in our adversary model to obtain it by enumerating names (bit strings). We now clarify the meaning of key terms in this conjecture. all principals are CAs and need to create initial bindings in their respective local name space manually. A secure name system must enable benign participants to install and retrieve correct key-value mappings while experiencing active.

As a result any decentralized name system must compromise and choose a property to deemphasize.1.1 describes the three major design approaches in this context. We start with the edges of the triangle which represent the three simple (and extreme) designs: 7 . On this basis we will now show as to why Zooko’s triangle is a valid conjecture in our hypothesis: Proof.2. are able to add name-value mappings to the system. global name system where memorable names are guaranteed to be available for registration by normal users without use of a trusted authority. All participants.o n To rm Sy ne UR mo Ls nic ste ms DS GA Global DNSSEC DNS Memorable Figure 2. Figure 2.: Illustration of Zooko’s triangle and key approaches to name systems in this context. Secure t Pe na ion me To r. adversaries can enumerate all possible names. Thus. the creator of Zooko’s triangle. As the number of memorable names can be enumerated and the adversary can assume many identities. that these definitions accurately represent the intended meaning of his formulation. it is impossible to make a secure. including the adversary. This would prevent the assignment of any additional memorable names at some point due to names having to be global and secure. a powerful adversary can then add name-value mappings for all memorable names. As names are memorable. Name Systems We have confirmed with Zooko Wilcox-O’Hearn.2.

GADS proceeds to add a “. but the name-value mappings are not globally unique. The key idea behind petname systems is that users rarely have to deal with globally unique keys and instead usually deal with petnames: the petname system provides a mapping from petnames to keys.2. Related Work DNS Globally unique and memorable names are managed by centralized organizations with no security guarantees [39]. DNSSEC is not robust enough in our adversary model. which is chosen by the entity and used to generate a suggestion for the petname. Tor mnemonic URLs The proposed Tor mnemonic URL system [48] begins with a secure and globally unique name system (“. DNSSEC begins with a globally unique and memorable system (DNS) and improves security by adding integrity protection and data origin authentication. This reduces the impact of not having global names. Tor . A simple example of a petname system is the /etc/hosts file on UNIX systems. this component is not vital to the system as such.e. the resulting names will not be memorable by Definition 2.onion” name space [11] uses bit strings derived from public keys as names. however. Petnames In a petname system.zkey” TLD which adds secure and globally unique names equivalent to Tor’s “. we will now give some additional background on some specific name systems that are particularly relevant to our work. However. Petname Systems A petname system is a name system where each user is in control of a name set. achieving strong security and global uniqueness at the expense of names not being memorable. the key) 8 .1 also shows three attempts to move toward satisfying all three properties: DNSSEC DNSSEC [2] is a set of security extensions for DNS. each user establishes a name of his choice for other entities [51].2 as the high entropy of the original names remains. Figure 2. A user is free to replace the suggested nickname for an entity with a petname of his choice. 2.2.onion Tor’s “. GADS The GNU Alternative Domain System presented in this paper begins with a secure and memorable petname system and makes the names transitive. Such a system can provide security and memorability.onion”) and aims to make it memorable by encoding the hashes in “. In order to be able to later highlight the differences between our design and existing systems.onion” names into human-meaningful and memorable sentences. The nickname is an optional extension that enables users to suggest a name by which they want to be called. Users usually have one more-or-less cryptic name (i. and a memorable but not globally unique nickname. a local petname used by the owner of the name set to identify the entity. Each named entity in the set consists of three elements: a secure and globally unique key controlled by the entity.onion” name space. As trusted authorities remain. A simple real-world example of such a system is the so-called buddy list used in instant messenger applications.1. This is a mnemonic system.

and the right-most label in a name is known as the top-level domain (TLD).us Zone (.example..example. it is possible for an authority to delegate responsibility for particular subdomains to other authorities. type...us. This authority has unrestricted autonomy over its domain.2.. 2.. The most common record types are “A” and “AAAA” records which provide IPv4 and IPv6 addresses respectively.1. . . . Names in DNS consist of labels delimited by dots.us. one name can be associated with many records of various types.2. The instant messaging system may use the friend’s real name (if given) as a nickname or to automatically derive a nickname. value and expiration time..us (www. Domain Name System The Domain Name System [40. however.example.g. Each record consists of a name. .com.2. Name Systems that uniquely identifies the user in the system. The record type specifies kind and function of the value that is associated with a name. Root Zone (. In most cases..com. “Jonathan Doe” with identifier “A174UX342” becomes “John”. The hierarchy of the name system enables the partitioning of the database into zones. .. Figure 2.) . e.us. may refer to a user by a petname. This is done by adding a 9 ..example..) ....com Zone (. 41] is a distributed and hierarchical name system.) Zone ..example.2. “..com”) where the administrative responsibility is given to a particular authority.. This nickname can then be suggested to the user for use as a petname. The root is the empty label.2. DNS is a distributed database of records. Names with a common suffix (where the suffix must begin with the delimiting dot) are said to be in the same domain... .. Friends.2.. A petname is created when a friend adds a user’s ID to his buddy list. . Names are organized in a hierarchy.g. .) . A zone is a portion of the name space with a common suffix for the names (e.: Illustration of the DNS zone hierarchy... . .. It is considered to be an essential part of the Internet because it provides mappings from host names to IP addresses. We describe how GADS uses nicknames in Section 3.

The actual technical management of the DNS root zone and servers is done by VeriSign. it is impossible to implement caching of the results (except on the client machine).net” as the authority for “.doc.gov/category/domain-name-system.2. The value of the “NS” record then specifies the name of the DNS server which is the authority for the subdomain. In this case the client sends the original query again. which is in turn currently operated by the Internet Corporation for Assigned Names and Numbers (ICANN).gtld-servers. Consequently. Related Work “NS” record with the name of the subdomain. In Figure 2.ntia. An example lookup for iterative and recursive resolution is illustrated in Figure 2. This process continues until a DNS server can actually answer the query or the authoritative server asserts that no record for the name exists.com”. The root zone is the zone corresponding to the empty label. By using a timeout of days or even weeks. This means that the content of the DNS root is controlled by ICANN. In DNS terms an authoritative DNS server for a particular zone answers queries for names mapped into this zone. Additionally. On the 2 http://www. zones with “NS” delegations typically contain glue records (of type “A” or “AAAA”) which provide a mapping of the names given in the “NS” records to the actual IP address for the authoritative DNS servers. caching can significantly reduce the load and latency of the DNS. For example. As a result the DNS server needs to maintain state information on all pending recursive queries. However the National Telecommunications and Information Administration (NTIA) under control of the United States Department of Commerce assumes the legal authority over the root zone.”2 . This multi-stakeholder approach is wanted and endorsed by the US Department of Commerce to ”ensure the long-term viability of the Internet as a force for innovation and economic growth. accessed 07/05/2012 10 . Caching is controlled by the expiration value that is part of each record. to provide consistency of the information despite caching.2 illustrates the DNS zone hierarchy. DNS servers configured for a client system usually resolve iteratively because it allows them to cache results for other clients or repeated lookups. this time to the DNS server specified in the previous reply. TLDs are categorized into country code (ccTLD) and generic TLDs (gTLD) [44]. DNS resolution can be done either iteratively. Country code TLDs are based on the official two letter abbreviations of the respective countries as defined in [26]. the “NS” records for “.3.3a we can see that while iterative resolution potentially reduces the load of the root server because it does not have to resolve a name on behalf of the client. The root zone contains “NS” records which specify names for all authoritative DNS servers for all TLDs. Whenever a client sends a recursive query to a DNS server it expects to receive a reply containing the value associated with the name or an indication that no value exists. It is managed by the Internet Assigned Numbers Authority (IANA). But any change to the root zone must be approved by the NTIA. If the query is iterative the DNS server can send a reply containing an “NS” record to the client indicating that another DNS server is responsible for this name. a DNS server receiving such a query either has to know the value associated with the name or forward the query to another DNS server.com” may specify “x. The authority must ensure that the mapping is valid until the timeout is reached. recursively or a combination of both. Figure 2.

example. like the DNS root servers. Figure 2.com authoritative DNS Server for example. 2 w. DNSSEC does not provide transaction confidentiality or denial of service protection. but all affected servers have to keep state for the pending lookups.2.0. 2010.3 ? 2.2. In general. depicted in Figure 2.org/tcr/selection-2010/.com (a) Iterative resolution.g. We have to differentiate between a DNSSEC enabled “validating” stub resolver and a DNSSEC enabled “non-validating” stub resolver.2. It establishes a trust chain from a zone’s authoritative server to the trust anchor.com ? IP: 192.3b.2. Servers that only answer queries for names that the administrator manually configured are called ”authoritative-only” DNS servers.2. A non-validating stub resolver must trust the replies of the queried DNS server. 2. do not support recursive resolution.0 . DNSSEC introduces new record types for public keys (“DNSKEY”) and for signatures on resource records (“RRSIG”).0.1 www. Name Systems www.2 . which is associated with the root zone. It relies on a public-key infrastructure in which all DNSSEC operators must participate.3 Name resolution in DNS with DNSSEC is different from plain DNS resolution.com TLD Server www. The key of the root zone is held as a split secret between currently 21 trusted community representatives chosen by ICANN.com ? IP: 192.2. “Trust” here refers to both trusting the DNS server to correctly 3 http://www. co 92 m .co Client DNS Root Server www. authoritative name servers.3 authoritative DNS Server for example.: DNS name resolution.example.2. In practice both resolution types are implemented: A so-called “stub resolver” is sending recursive queries to a DNS server that performs resolution on behalf of the client and employs extensive caching of results.example.root-dnssec.3. the recursive resolution technique.example.3. allows the servers to cache answers resulting in very fast response times of frequently queried names.3 Client ww w. As of July 15.2. a root zone trust anchor exists and root zone operators have started to deploy signatures and zone keys.com ? IP: 192.3 try w m w . other hand. accessed 09/07/2012 11 . ex am IP pl :1 e.com ? try 192. (b) Recursive resolution.0. This association is achieved out-of-band by distributing the root zone’s public key e.0.0 ? . DNSSEC The Domain Name System Security Extensions (DNSSEC) [2] extend the current DNS system with integrity protection and data origin authentication.com TLD Server . in operating systems.e x 19 DNS Root Server am ple .

the resolver has to validate a corresponding “RRSIG” signature that signs the RRset that includes the “DNSKEY”. it is possible to access Tor hidden services using their “.onion” name space are not resolvable by any DNS resolver because the “. the “. It is obvious that such names are very hard to remember. However. stub resolvers either drop the non-authenticated responses or accept the response anyway and forward the results to the client. In modern operating systems. Signature verification is performed by checking the signature in “RRSIG” records with the corresponding public key found in the “DNSKEY” record of the authoritative zone.onion” name also provides a mapping to the public key of the service adding strong security to the name system. By using such a web proxy it is possible to use the “. especially where censorship is already established. A “validating” stub resolver sends queries in recursive mode but additionally performs the signature verification itself. A “.torproject. accessed 08/14/2012 12 .onion web proxies referred to as tor2web services.org/download/download. much like an IP address. However. Basically the hash can be seen as the raw address of a Tor hidden service. Tor .2.onion” name space without having a 4 https://www. The Tor Project additionally offers .onion could point to a valid hidden service.onion” TLD. with the appropriate proxy software installed or using the “Tor Browser”4 . the connection can be considered as trusted if IPSec is used [2].onion” TLD is not part of the root zone.2. The label is generated by hashing the first 80 bit of the hidden service identity key using SHA-1 and encoding the result in base32. “DS” records must be present for all “NS” delegation records where the DNS server is DNSSEC enabled and verifying. To verify the public key. This is done either by using the trust anchor or by following a delegation chain using “Delegation Signer (DS)” records. With TLD operators being typically subjected to the same jurisdiction as the domain operators in their zone. The trust chains established by DNSSEC mirror the zone delegations of DNS. “RRSIG” records are associated with RRsets – sets of Resource Records that share the same domain and type. these trust chains are at a certain risk to legal attacks. For example https://jv6g2ucbhrjcnwgi.onion” name consists of a 16 character alphanumeric hash followed by the “.onion” name.onion” System is used to access hidden services [11] in the Tor network.html. Names in the “. Since the stub resolver is non-validating the only thing that is checked in the incoming DNS response is the “Authenticated Data” (AD) bit. The APIs offered by operating systems are not designed to provide the user or program with authentication information and need to be changed appropriately for DNSSEC to be actually useful.onion System The Tor “.en. 2. For example. Related Work verify the DNSSEC data and trusting the connection that is used to communicate. This results in end-to-end security for the client.4. But at the same time they provide strong security because Tor can use the identity key (in combination with the name) to authenticate the service. The “DS” record of a parent zone points to a “DNSKEY” record in the subzone and is part of a signed RRset in the parent zone. A resolver can follow the trust chain up to the trust anchor.

accessed 08/14/2012 http://www. For instance “reg foobar” means that the hidden service would like to have the name “foobar”.tor2web. For this scheme to be feasible. all tor2web nodes need some kind of synchronization protocol to enforce the first-come-first-served policy and to ensure the consistency of the databases. onion without having a local Tor installation on the client the user can simply point his browser to https://jv6g2ucbhrjcnwgi.onion” web proxy located at http://tor2web. onion nyms By using onion nyms a hidden service administrator can register a memorable name for his . Inside this file the desired name is specified. In the following we will discuss the onion nym and mnemonic URL system that try to solve the problem with different approaches.2. For example there is a “. 2.txt” file and retrieve the desired name.thc. This highlights the importance of memorable names for a secure name system.onion he might falsely recognize the hash of the benign service and fall victim to a Man-in-the-Middle attack.2.txt.1.txt” into his hidden service web root7 .torproject.onion” name system memorable. From then on it is possible to access the hidden service via the tor2web gateway by pointing the web browser to http://foobar.4. Two proposals are currently discussed in the Tor community to make the “. An attacker could try to generate an identity key with a hash similar to the hash of the benign service.org.2.2. onion.org) is used to access the hidden service it will look for the “onion.onion name at tor2web gateways. Name Systems client proxy or Tor Browser installed.git/blob/HEAD:/proposals/ideas/ xxx-onion-nyms. One particularly dangerous attack against “. To access the hidden service at https://jv6g2ucbhrjcnwgi.org.org.tor2web.org.html.org/papers/ffp. accessed 09/07/2012 7 Note that we assume here that the hidden service is in fact a web service 8 https://gitweb. The resulting sentence should be grammatically sound and contain a simple set of vocabulary. For example the name http://tor2web. accessed 09/07/2012 6 5 13 .4.onion name and generate a human meaningful sentence that is easy to remember.org/torspec.onion” names are partial-match fuzzing attacks6 . Of course this defeats the security assertions granted by the Tor software. If the user encounters a link to the attackers service at https: //jv6g2uebnricnwgi. Unless the name is already taken the gateway will store a mapping from the memorable name “foobar” to the hidden service address v2cbb2l4lsnpio4q. 2. Imagine a user that regularly visits the service at https://jv6g2ucbhrjcnwgi.onion. Mnemonic URLs The idea of Tor mnemonic URLs is to take the hash of the . When a tor2web gateway (for example http://tor2web.2. This issue has not yet been addressed8 .5 Tor2web services are DNS-to-Tor gateways that allow anyone to access Tor hidden services. To do so the administrator adds a text file “onion.

especially if registration costs are set to be lower than for traditional DNS. This scheme is less susceptible to partial-match fuzzing attacks than the original . 2. they generally rely on DNS (or DNSSEC with DANE [3]) to establish initial trust in certificates.2. the problem of name squatting and the resulting unavailability of names is also ultimately not addressed by Namecoin. 9 http://dot-bit. This is supposed to make it computationally infeasible to produce an alternative valid timeline. timeline-based systems in the style of Bitcoin [43] have been proposed as a way to create a global. the idea is to create a single. Finally. onion.5. It also limits the rate of registrations. First of all. Sovereign Keys [13] and Certificate Transparency [32] are related systems which also use timelines to persistently map a host name to a public key or certificate. which is fairly simple and easy to remember. It is also not entirely clear if a single global timeline can be managed in a distributed fashion and still handle the transaction rate that global use might require. 27]. In our example the URL resulting from the mnemonic could look like this: https://quick-brown-fox-jumps-lazy-dog.org/. This inter dependency of technological and economic aspects literally forces users to waste energy and possibly creates legal issues associated with alternative currencies [23. The authors of the proposal also mention that simple translation of the sentences to other languages will not work due to the different meanings of words and possibly incompatible grammar. a user needs to expend computational power on finding (partial) hash collisions in order to be able to append a new mapping. there are definitively some theoretical issues with this approach. depending on their level of English. Since there is no implementation of mnemonic URLs at this point in time it is difficult to thoroughly evaluate the feasibility of this idea. Related Work v2cbb2l4lsnpio4q.onion could be converted to the sentence “The quick brown fox jumps over the lazy dog”. The need to spend CPU cycles on a proof-of-work just to register a name is also questionable.2. A key difference is that these systems focus on providing additional security for SSL/TLS and not on DNS. As a result. Client Software – like the Tor Browser – should make it easy for the user to convert from mnemonic to hash and vice versa. However. In the Namecoin system9 . globally accessible timeline of name registrations that is append-only. Timeline Systems Recently. non-native English speakers might have trouble understanding and memorizing the sentences. accessed 09/07/2012 14 . following some rules to strip unnecessary minimal words. secure and memorable name system [53]. A possible drawback of the Namecoin system is that it is non-trivial for a user to verify the entire history.onion names. Here. The actual URL should be generated by the software as well.

1. 29.3. If data is not available in the DHT.cornell. The attacker usually has to fall back on social engineering strategies 10 http://www. 6. censorship-resistance and fault-tolerance. the information is fetched from the normal DNS. Distributed Hash Tables are often weak against the “Sybil” attack. The project claims that their approach is more resilient to denial-of-service attacks and equipment failures and reduces latency to “less than a single network hop”10 . However. just as the performance of the cryptographic operations follows directly from performance studies on cryptographic primitives [10]. 47. Whanau Whanau’s [34] primary goal is to provide a “Sybil”-proof DHT by using social connections between users. It should be noted that building a DNS replacement on top of a DHT does not introduce a dependency on DNS: all of the mentioned DHTs function just fine without an underlying DNS system as DHT routing protocols typically directly exchange IP addresses and not (DNS) names. Distributed Hash Tables 2. 58. 9. 2. The Cooperative Domain Name System (CoDoNS) [45] is one example. accessed 09/07/2012 15 .3. Design Social networks have the useful property that it is hard for an adversary to convince honest users to peer with him. In the following sections we will present some of the mentioned DHT designs in more detail to justify our decision. 17. By doing so an attacker is able to disrupt the routing and maintenance operations of basic DHT designs [12]. 8. However. 59]).1.cs. we do not provide experimental measurements in this thesis. while possibly being less resistant to Sybil attacks. Among the DHTs with freely available implementations.3. For this reason.3. as the expected network performance and resistance to attacks follows directly from the extensive body of literature ([5. 35. other secure and censorship-resistant DHT designs such as Whanau [34] or X-Vine [38] could theoretically be used as well. we settled for the R5 N Byzantine fault-tolerant DHT [15] as it best meets our needs. When performing a Sybil attack an adversary tries to create a large number of Sybil (phony) nodes. for a reference implementation it is necessary to choose or develop a DHT with suitable properties to achieve our goals. Distributed Hash Tables Some approaches attempt to improve the availability of DNS data by storing it in a distributed hash table (DHT). The name system presented in this work also uses a DHT to store and look up names.2.edu/people/egs/beehive/codons. It can be used with any DHT and then inherits the advantages and disadvantages of the respective DHT in terms of network performance.1. it is not bound to a specific DHT. Whanau relies on a social network like DBLP or Flickr to bootstrap its routing tables and counter the attack. R5 N has the advantage that it does not require the use of a social network.php. 2. However. 22. 52. CoDoNS preserves ownership over names and is thus in the same legal position as DNSSEC. 21.

1. If the random walk is long enough. This process is repeated until a successful lookup is performed or a timeout is reached. X-Vine X-Vine [38] builds upon the idea of Whanau to use a social network for DHT routing and Sybil resistance. 2. On lookup a random layer is chosen. a weak point in terms of privacy that is also mentioned by the authors of X-Vine [38]. 16 .2. A node “uses a random walk to choose a random key as its layer-0 ID” [34]. The clustering attack is mitigated if there are at least O(log n) layers for each node. it becomes unlikely that an adversary is able to flood an honest node’s routing table with Sybils. 2.3.. the maintenance operations require nodes to expose their social connections to the network. it can only handle moderate churn because rebuilding of routing tables is costly. Lookups use O(1) bandwidth making them very cheap. In this layer the appropriate finger is queried for the key. Whanau also tries to counter Sybil clustering attacks by implementing so-called “layered IDs” [34]. Sybil nodes will mostly be connected to other Sybil nodes and only a few “attack edges” [34] connect Sybils with honest nodes. Because routing tables are maintained in this fashion and not by asking other nodes to disclose their routes. honest nodes will mimic Sybil nodes in other layers.2. the authors do not make clear as to why this is the case. The layer-n IDs where n > 0 are chosen by randomly selecting an ID from the finger table in layer-n−1. Honest nodes pick IDs uniformly in the ID space. According to the authors this ensures that “[. If there is a clustering attack present in layer-0. with a probability distribution proportional to its degree. When performing a clustering attack multiple Sybil nodes choose IDs very close to a specific key. Unfortunately.2.3. However.] honest nodes’ layer-0 IDs are distributed evenly over the keyspace” [34]. On √ the other hand. At the same time it performs like other one-hop DHTs. one ID per “layer”. The sampling technique is simply a random walk. it will approach the stationary distribution [7] and the end of the walk will be a random node in the network. In Whanau each peer has multiple IDs.. Furthermore. In combination with the “fast-mixing” property of social networks Whanau tries to sample mostly honest nodes into its peers’ routing tables. routing tables are expensive to maintain and rather large with Ω( n log n) space. What makes X-Vine special is that it embeds the DHT “directly into the social network fabric” [38]. which is considered to be rather costly. This anomaly in the social network graph can be identified by looking for a sparse-cut in the graph. Related Work to connect his Sybil nodes with honest peers. Assessment Whanau provides strong defense against Sybil and related attacks. Due to this fact. possibly making it impossible for other peers to look up.

Design Nodes in X-Vine only communicate directly with their neighbors in the social network graph. The dotted paths are representing trails from node X to its successors in the name space overlay. A node in X-Vine is uniquely identified by a global and random numeric identifier. it maintains a set of so-called “trails” in the network – paths to neighbors in the DHT name space. Since it is recognized that in a social network graph creating trust relationships with honest nodes is costly for an attacker. The properties of the social network graph also allow X-Vine to provide some resistance against Sybil attacks. A trail consists of a number of “records” stored on each node along the trail. On this basis.2. The table shows node W’s routing table based on this topology. this limit will bound the number of Sybils in an honest node’s routing table. This is done by limiting the number of trails that traverse a single edge in the social network. Distributed Hash Tables 2. succ2(X) Z W Y succ1(X) X succ3(X) Endpoint 1 X ··· W’s routing table Next Hop 1 Endpoint 2 Z succ1 (X) ··· ··· Next Hop 2 Y ··· Figure 2.2. not the DHT name space neighbors. It shows the social network graph and the friend relations of the nodes.3.: An overview of the X-Vine overlay taken from [38]. The information in a record includes the originating node and a destination node (the originating node’s successor) as well as the next and previous hop along the trail. 17 .1.4 illustrates X-Vine’s design.4.3. Figure 2. This results in a system where information always has to follow a path in the social network graph and the set of records a node has stored serves as a routing table. Additionally. X-Vine provides pseudonymous communication. by only exposing a node’s IP address to its neighbors in the social graph.

In particular. First. Related Work What distinguishes X-Vine from Whanau is the fact that its protocol does not require the users to expose their social network connections. Also. Whenever a peer performs an operation in Kademlia it tries to find k closest peers to a specific key. Design The original Kademlia routing algorithm [22] follows an iterative approach. and with it communication between two nodes. This lookup process is performed iteratively until no closer peers for a given key can be found. This is a definitive improvement in terms of privacy.com) as a possible decentralized social network that could be used in the future. sensor and wireless networks. mobile.2. However X-Vine also has some limitations. 2. The fact that peers can freely connect to each other is an imperative assumption made by most modern DHTs. because the mapping from IP address to DHT identifier is only known between directly connected nodes in the social network. R5 N works around this issue by combining a random walk with recursive style Kademlia routing. To actually deduce the (direct) connection.3. 2.3. Without this premise. it is not possible for an attacker to infer the communication between two nodes.2. 2. the performance and reliability of DHTs like Kademlia can be diminished greatly. 11 The authors have mentioned Diaspora (http://www. “closer” peers learned through those queries will be stored in the peers routing table. New.1. R5 N R5 N is a Byzantine fault-tolerant DHT that works particularly well in restricted route topologies.3. The distance metric used is XOR. Assessment X-Vine provides a robust and performant DHT on the basis of a social network that provides decent protection against common attacks on routing and maintenance operations as well as Sybil attacks.diaspora. an attacker needs to have direct trust relationships with both parties. discovered through iterative lookups. An inherent problem of this algorithm in restricted route topologies becomes obvious here: Peers closest to the key.3. the initiating peer queries the k closest neighbors in its routing table to find peers “closer” to the desired key.2. Restricted route topologies contain nodes that are not able to directly connect to any other arbitrary node in the network. might be inaccessible for the initiating peer. depending on the number of peers with impaired connectivity [15]. This can be due to Network Address Translation (NAT) middleboxes or the limited connectivity of friend-to-friend (F2F). 18 . due to the pseudonymous communication. The authors have provided proof of concept applications that prove the viability of the design but without the existence of a wide-spread decentralized social network this dependency is hard to meet at this point in time11 .3. the hard requirement on an existing social network where a user’s contact list can be used to bootstrap the DHT.

Finally. the randomized routing algorithm and integrated DHT replication techniques provide excellent censorship-resistance. it does not rely on a social network to bootstrap and maintain routing tables.3. at the risk of possibly being less resistant to Sybil attacks. Routing in R5 N is split into two phases. R5 N also employs a different strategy for routing replies back to the initiator. This factor is derived from the mixing time of small world topologies that is also used by Whanau. Instead it is based on the established Kademlia algorithms for routing and routing table maintenance. PUT requests are forwarded in the same fashion unless the current peer is already one of the k closest peers.2. DHTs like Kademlia can use their normal routing algorithm to route replies making it unnecessary to keep a list of pending requests.3. Distributed Hash Tables R5 N is able to work around this issue by implementing a modified recursive Kademlia routing algorithm. at the expense of requiring more state. 2. in which case the data is stored locally. resulting in a higher state requirement than other DHTs [15]. The first phase is a random walk of length T ≈ log n where n is the number of peers in the network. 19 . Because of path randomization each peer along the request path has to keep a list of active requests. However. R5 N has a complexity of √ O( n log n) bandwidth. Assessment R5 N does not provide the same protection against Sybil attacks like Whanau or X-Vine.2. The random walk ensures that the starting point of the second phase is a random peer in the network.3. In the end we settled for this DHT because it has the advantage that it does not require the use of a social network. It basically follows the standard Kademlia algorithm with the exception that routing is performed recursively: GET requests are forwarded to the closest neighbor in the routing table according to the XOR metric. Phase two is a recursive style Kademlia protocol.

2. Related Work 20 .

21 . Records can be private or public. Consequently. Names in “. Example: www.zkey” are cryptographic identifiers and thus globally unique and secure names.1. In particular. This allows name resolution and verification by other users. We will first provide a detailed description of our name system. GADS allows applications (and stub resolvers) to use DNS-like names by providing two TLDs.1.1). It is a secure. Each label in this name is a mapping in a GADS zone.alice. names in the “.zkey” TLD is an alternative to these context-dependent names. Having the user in full control of his zones is the basis for censorship resistance in GADS.zkey” name is always the cryptographic identifier of a specific zone. secure zone delegation is possible by adding appropriate delegation records to a zone. Thereafter.L1G6. The GNU Alternative Domain System This chapter is split into two major parts.zkey” TLD is independent of the individual user. per-user name space.zkey refers to zone L1G6’s Alice’s web server called “www”. his own personal master zone. Record validity is established by the signatures and controlled using expiration values (Section 3.1.gads” TLD are very similar to SDSI’s linked name spaces.zkey”. GADS.gads” and “. because the user can freely assign memorable names in his personal master zone. including zones managed by other users (Section 3.alice.gads refers to Bob’s Alice’s web server called “www”. The mappings of a zone are stored as records in a database on a machine under the control of the zone’s owner. we discuss important aspects regarding the integration of GADS into modern applications and protocols.gads” TLD. Names in the “. Example: www. The result of resolving requests in the “.3. in Section 3. 3.2). The “. a user runs his own zones. memorable. The “.gads” TLD always corresponds to the individual user’s master zone. In practice. Design of the Name System GADS is fully decentralized. resolution results will depend on the individual user. as an adversary cannot manipulate individually managed zone data. However.1. “. The second label in a “.3).zkey” TLD are not memorable.2.gads”. For “. The user can create a GADS zone simply by generating a public-private key pair. Public records are cryptographically signed with the user’s private key and published in a DHT (Section 3.bob. A user can freely manage mappings for memorable names in his zones and delegate control over subdomains to other zones. Instead of having a few US-based organizations manage the DNS root zone.1. in Section 3. All following labels are transitive zone delegations in the style of SDSI and names in the “.

a “PKEY” record delegates resolution for the subdomain to the owner of the specified public-private key pair. PKEY.0.1. Section 3.gads” TLD are always relative. Zone Delegation Secure delegation of control over subdomains is central to GADS.da Carol (QXDA) dave.dave. “PKEY” records have essentially the same purpose as “NS” records in traditional DNS.1 Figure 3. Dave’s server would simply be “www.gads” names. it replaces the tree structure of DNS (with its inherent central point of attack) with a directed graph that is fully decentralized by nature. which is the hash of the zone’s public key. which incidentally both refer to Dave’s server at IP “192. TX12 carol. QXDA Dave (L1G6) www. . type. “PKEY” records delegate control over a subdomain to another zone.3.: Illustration of name resolution in GADS. However. L1G6 ve bob. for Carol. GADS introduces new record types required for its operation. Most of the record types known from DNS are also supported by GADS (Section 3. PKEY. To realize this we use “PKEY” records that contain the fingerprint of the authority for a zone. The figure illustrates the paths Alice’s GADS resolver would follow to resolve the “www.carol.1. Each user is shown with the fingerprint of the respective master zone and the public records from this zone (in the format name. The GNU Alternative Domain System In the style of a petname system the user can create pseudonyms for his zones.8).2.2. value). specifying a preferred name.gads” and “www.1. Additionally. Note that names in the “.1”. As names can consist of many labels. 22 .buddy.bob . Figure 3. 3.dave. instead of delegating resolution for the subdomain to a nameserver specified by name. this is not visible in memorable “. 192.1.bob.0. A.ca ro l Bob (TX12) . repeated delegation allows GADS to achieve transitivity of names.bu dd y buddy.2 provides more details on record types that are relevant for specific application scenarios. PKEY. While users are internally identified using public keys and records must be cryptographically signed.gads” names. PKEY.gads Alice (RTA7) . L1G6 . Users creating delegations into this zone can use the pseudonym or an arbitrary name in their local master zone.1 illustrates the use of “PKEY” records for delegation and name resolution.gads”.

0.2. Figure 3.2).2.1 mail.. b Bo b pu )) DHT 192.2. For instance. Network Protocol and Routing GADS uses a DHT as an efficient mechanism for obtaining records from zones that are managed by other users. K Bob pub 192. Since additional records provided by resolvers often include additional records with the same name.: In the GADS architecture.. GADS will sign this set once with the zone’s private key.2.. Signatures. The user can delegate names to other users using “PKEY” records.0.3.0.0. most requests will be answered by the local database which is the authority for all names in the user’s personal “.bob.2 www AAAA 2001:DB8::1 . all public records for a given name are stored in a cryptographically signed block in the DHT under a key created by computing the XOR of the hash of the public key of the zone and the hash of the name.3.1.2 2001:DB8::1 2 Local GADS Resolver B pu ob b 4 ('w (H bo b ww T (K GE or H ') x K 5 3 Namestore bob PKEY eve A + MX + PSEU . which is freely determined by the authoritative zone’s administrator.gads” TLD.. To minimize the load on the network and to reduce latency. these expiration values are used to control caching. Design of the Name System 3. Expiration and Freshness To reduce the number of required signatures and in particular the number of signature validation operations. those names are then resolved using a DHT..2.gads 6 192.2 www A www AAAA 2001:DB8::1 + PSEU bob .1. 23 .1. all validated records are cached in the local database. As in DNS. Each record in GADS has an individual expiration time. this reduces the amount of cryptographic validation that has to be done. if there is an “A” and a “AAAA” record for the name “www” in the local master zone. 1 www. 3.+ alice www A 192. It is also the primary database for all of the zones for which the peer is authoritative (Figure 3.2. GADS always signs blocks containing the complete set of all records for the same name in the zone. If not cached. For this..

A single DHT record block contains one or more records with the following wire format. When the freshness time stamp indicates that the signature is no longer fresh. large expiration values for records should be used if possible to improve performance. the overall block in the DHT (which combines all records for a given name and the signature) also has a freshness time stamp. Here. As with DNS. matching non-expired records that already exist in the local database (from now stale blocks) are used. but continue to use non-expired records from stale blocks to provide mappings to the user in the meantime. The first field holds the 264 byte RSA Public Key Data including the Public Key of the records’ authoritative zone. Generally. as we expect ordinary users to run GADS authorities. followed by the name and actual record data in the Records field. We thus expect users to use long expiration values for delegations (“PKEY” records) and short expiration values for mappings to IP addresses (“A” records).3. all records associated with the record expire in the DHT — a fresh block needs to be published by the respective authority. This per-name freshness time stamp controls how often GADS attempts to obtain up-to-date information from the respective zone’s authority via the network. The hosts running the authoritative peers for a particular zone do not really experience any significant load because record data is published in and resolved using the DHT and not on the host itself. whereas users that do not operate servers will likely only use delegation to other authorities which will rarely. as those users that do operate servers are likely to be online most of the time and can thus perform frequent republication. Record caching primarily benefits the user performing resolutions. but not the lifetime of individual records in the cache of a local database. Records is a variable length field containing Record Count records. need to be updated. using large expiration values can make it impossible for administrators to quickly change the destination IP address for a service. GADS attempts a DHT lookup to obtain a fresh block. Another consideration for choosing expiration values is the possibility of individual authorities being offline. it first checks if a fresh block is available for the desired name and zone in the local database. The GNU Alternative Domain System In addition to the expiration values of individual records. Fast changes to records are sometimes needed for load-balancing or to direct users to a backup site in case of failures at the primary site. the system will attempt to obtain a fresh mapping. 24 . The first field of the signed data portion is used to specify the number of records in the block. Specifically. Specifically. Signature expiration is also tied to the freshness time stamp of a block. Caching and large expiration values can enable GADS to resolve names (especially as part of delegations) for which the authority is currently unavailable. if ever. Long expiration values allow peers to cache records longer and thus minimizes name resolution latency. While the lookup is pending. as caching records enables the local GADS resolver to perform fewer DHT lookups. the freshness time stamp determines the lifetime of blocks in the DHT. individual records in the local database of an individual user persist. However. some of them will most likely be online only for a few hours each day. a DHT lookup is not performed even if that block lacks a record of the appropriate type or is expired. A 2048 bit RSA signature of the block signs all data following the 2048 bit RSA Signature field. If no block exists or the local block is stale. when GADS resolves a name. This should work. Note that if a fresh block exists.

The contents of the Record Data field are determined by the record type.3.1. 3. the Record Type and Record Flags. For example. the size of the payload Data Size (in bytes). excluding it from DHT publication.1. 25 . The use of these three zones is purely by convention (which is reinforced via the user interfaces). In the following we present the three zones along with the issues they are meant to solve. All values for GADS specific record flags and types can be found in Appendix D for reference. Design of the Name System 0 0 ··· 65 66 ··· 129 130 131 ··· 8 16 RSA Public Key Data 24 2048 bit RSA Signature Record Count 0-Terminated Name Records This is the wire data format used for a single record: 0 0 1 2 3 4 5 ··· 8 16 Expiration Time Data Size Record Type Record Flags Record Data 24 A record contains the Expiration Time. Individual wire data formats of the supported record types can be found in Section 3.4.1. Three Zones for Security. Privacy and Usability The design presented so far suffers from a few usability issues. which are resolved in GADS by having three zones for each user instead of just the master zone. Record flags specify metadata information regarding this record for internal use. the GADS network protocol does not know about the three zones and additional zones could be created if necessary.8. a flag can be set to make the record private.

1” as the IP address for “www” in Dave’s zone. Private Zone: This zone contains all records and delegations that are confidential and that the user does not share.gads” in the master zone. It is possible to follow delegations created by “PKEY” records from within “. Name shortening in GADS addresses the problem of long delegation chains.zkey” names. As each “. For example.dave. The label after the “.0. “alice. We will now describe the use of the shorten zone in more detail. Naturally.zkey” TLD are resolved by querying the respective zone for the name that follows the hash label. If the name “carol” is available in Victor’s shorten zone. Names in the “.gads” with the equivalent “alice. The GNU Alternative Domain System By default. with the zones from Figure 3. Victor’s system will automatically enter Alice’s public key under “carol.bob. The master zone can contain entries to delegate to foreign zones as well as other resource records.1. “www. In this case.3.zkey” TLD must be the base32hex [28] encoded fingerprint of a zone. Now suppose Victor’s zone does not yet have a record for Alice’s public key. Victor can disable this feature or later manually edit his zone to correct unfortunate choices that might be created by this first-encountered-first-assigned policy.3 illustrates the import algorithm.bob.gads”. Globally Unique and Secure Names The “.gads”).zkey” would lookup “dave” in Carol’s zone and then return “192.private.dave. If a user.shorten. While records can be individually marked as private and private records can exist in other zones. These records are not published in the DHT.QXDA.gads”. The user’s master zone is where lookups start (“.1.gads” simply improves readability. a GADS installation uses the following three zones: Master Zone: This zone contains all records and delegations that are available for the user himself as well as all other users.5.shorten.gads”.zkey” TLD is used in GADS to provide a name space with globally unique and secure names.dave. name shortening will replace the long delegation chain with the existing name. The shorten zone appears under “. Victor’s GADS resolver will then check if “carol” is already taken in Victor’s shorten zone. Figure 3.zkey” TLD. Victor’s resolver will consider Alice’s pseudonym. in which case substituting “alice. This zone appears by default in the master zone under the the name “. 3. no authority is required to manage the “. Let this pseudonym be “carol”.2.gads” might already be known to Victor as “alice. say Victor. Names created by this shortening mechanism are stored in the shorten zone and marked as private by default to ensure that Victor is aware of the automatic shortening process and to ensure that his name bindings are not accidentally leaked to the DHT by publishing shortened names.zkey” name uniquely identifies a publicprivate key pair. already has a name for a public key in his zone. Shorten Zone: This zone is automatically populated by GADS to achieve short names. 26 . collecting all private records in a special zone makes it more obvious to the user as to which records are private and thus useless for sharing with other users. For example.

Our user survey in Section 5. and for integration with legacy systems (Section 3. The “.zkey” TLD is expected to be used under rare circumstances where globally unique names are required. but it is hard for him to remove the valid “REV” record from the censorship resistant DHT.3).bob. Automatic insertion of a PKEY record only happens if an equivalent delegation record cannot be found in any of the user’s zones and the pseudonym name is not yet taken in the shorten zone.6. Design of the Name System Input: alice.zkey” TLD would be required if GADS was widely used.2. 3.gads PKEY: RTA7 PSEU: carol PKEY in Master Zone? Yes End No PKEY in Private Zone? Yes End No PKEY in Shorten Zone? Yes End No carol taken in Shorten Zone? Yes End No Add carol PKEY RTA7 to Shorten Zone Figure 3. If the private key of a zone is compromised — but not lost — this record can simply be created on the fly and put into the zone in question.3. Whenever a user decides to revoke a zone and with it the zone key a revocation record of type “REV” must be published in that zone. In case the key is lost there needs 27 .1.dave.: A flowchart illustrating the GADS PKEY import logic. Any attacker in possession of the compromised key can publish records for this zone.1.3. Zone Revocation In case a zone key gets lost or compromised it is important that the key can be revoked.5 shows just how rarely the “.

com” instead of “www. This results in a scenario where the authority of a zone cannot know what his zone is called by others. To maximize backwards compatibility. the name is interpreted as referring to “www. The GNU Alternative Domain System to be a backup of a signed “REV” record available that can be used for the revocation. To solve this problem GADS assigns a special meaning to the label “+”.com”. The apex of a DNS zone contains records under the name of the zone itself.3.+” from the “alice.7. In GADS a user does not know what his zone is called by other people. Adding additional record types — especially existing ones from DNS — largely only requires writing the respective parsing and serialization routines.gads” zone. GADS checks for the existence of a “REV” record when resolving “PKEY” delegations. This record type works exactly as in DNS and it has the same wire data format: 0 0 8 16 32 bit Address 24 28 . which is used as a symbol for the zone of origin.com” might have an “A” record in its apex which will make it possible to access a service using “example. GADS defines a few additional GADSspecific record types.1.gads” from the user’s perspective. It is used to identify records that are stored under the empty label. DNS has a similar semantic sometimes referred to as the “apex” of a zone. GADS uses the same binary format and — with a few minor exceptions — identical semantics for the DNS resource records (RRs) that are defined in RFC 1035 [41] and RFC 3596 [54].1. Note that “PKEY” and “CNAME” record types are not allowed in the apex of a GADS zone. 3. Some records types.+”. Delegation will not happen if a revocation record is present. A: Mapping of host name to IPv4 address. DNSSEC also uses the apex of a zone to store the DNSKEY public keys. these records have record type numbers larger than 216 to avoid conflicts with DNS record types.example. A zone in GADS can also contain mappings with the name “+”. For example the subdomain “example. This allows expressing that a particular name must be interpreted relative to the originating zone by ending it with “.8.alice. if a user receives a name of “www. But a user can use the label “+” to indicate that a record is in the apex of his zone. Furthermore. Context dependent Names In GADS a user can delegate to another zone using any name he likes. 3. The following DNS-compatible record types are currently supported by our implementation. like “CNAME”s are not allowed in the zone apex. Names and Record Types We now discuss the various record types supported by GADS in detail. For example.

2.hash. The RFC specifies the following wire data format of the record: 0 0 1 2 3 8 16 128 bit Address 24 CNAME: Mapping of a name to a canonical name.hash. This is the CNAME wire data format: 0 0 ··· 8 16 0-Terminated CNAME 24 29 .gads server.0.zkey RRType A CNAME A A Value hn.ex. As specified in RFC 1035 [41]. GADS expands the relative name and continues the lookup with the result: Q: A: Q: A: Name www. if there is a “CNAME” record for a name.gads www. the canonical name can be a relative name (ending in “+”).+ 192.1 Note: hash is a fingerprint of the public key (53-character base32hex encoded hash) in this table. This record type works exactly as in DNS.example.example.us 192. we have to restart the query with the new name in the respective zone.zkey hn. In GADS.example.3.zkey”) or a DNS name: In the first case.gads www. For example: Q: A: Q: A: Name www.ex.example.gads www.example. In the third case.1 As with DNS. the query can (and in GADS will) be restarted using the specified “canonical name”.us (DNS) www. an absolute name (ending in “.gads server. the second query and answer are exchanged with DNS instead of GADS: Q: A: Q: A: Name www.2.example.2. there must not be any other records for the same name.gads www.gads hn.example. Design of the Name System AAAA: Mapping of host name to IPv6 address.1.0.zkey 192.ex.us (DNS) RRType A CNAME A A Value www.1 In the second case.hash.0.example.gads RRType A CNAME A A Value server.

ex. Thus.0.gads mail.ex.com (DNS) www.gads example. For example: Q: A: Q: A: Name example.com (DNS) RRType A NS A A A Value ex.gads example.gads mail.2. they can contain relative names which are expanded in the same manner as “CNAME” records. a name with a “NS” record must also always have “A” (or “AAAA”) records for the same name.2. Note that this record type enables delegation to DNS from within GADS. MX: 0 0 1 ··· 8 Preference 16 24 0-Terminated MX Name 30 .1 based on the “A” record. we need both a DNS name (to give to the DNS server for the resolution) as well as the IP address of the DNS authority.0. SRV. Delegation within GADS is done using “PKEY” records.2. The GNU Alternative Domain System NS: In DNS. “NS” records delegate resolution for a subdomain. As a result. PTR and MX: These record types work the same way as in DNS. The resolution then continues using DNS. For example: Q: A: A: Q: A: Name www.0. The “NS” record tells us the name of the authoritative DNS zone of the DNS server and the “A” records provide the DNS server’s IP addresses.gads example. GADS will synthesize the DNS name “www. “NS” delegation works slightly differently: “NS” records are used in GADS to delegate resolution of the GADS subdomain to a DNS zone.example.ex. The wire formats are identical in DNS and GADS.gads www.com 192.+ 192.0.example.com” from the “NS” record and the “www” remaining from the GADS name and send a DNS query to the DNS server at 192. except that.3. in GADS. The value in the “NS” record is the name the respective DNS authority.2.example.1 “SRV” and “PTR” records are post-processed in a similar fashion.2 Given the first response. and this name has a separate “A” record: 0 0 ··· 8 16 0-Terminated NS Name 24 In GADS. like “CNAME” records.1 192.gads RRType MX MX A A Value mail.

The record associates various certificate related data necessary to validate a server certificate.3. 31 . Certificate usages define whether the given certificate is the trust anchor that needs to be used to verify the certificate given by a host or if it actually is the host certificate and must completely match the certificate provided by the host. Design of the Name System SRV: 0 0 1 2 ··· PTR: 0 0 ··· 8 16 0-Terminated PTR 24 8 Priority Port 16 24 Weight 0-Terminated SRV Target Name SOA: GADS typically has little use for information from “SOA” records.509 certificates without a trusted authority. The certificate data can be either the certificate or just selected parts of it (see “Selector”). 0 0 8 16 0-Terminated MNAME 0-Terminated RNAME ··· 32 bit Serial 32 bit Refresh 32 bit Expire 24 TXT: Association of user-defined text with a name.4) and can thus be stored within GADS. “SOA” records might be useful for DNS-to-GADS gateways (Section 3.2. Relative names are again supported and expanded. However. It is possible to select that only the public keys must match or even the whole DER encoded certificate. The “Certificate Usage” field provides details regarding the certificate data present in the record. The “Matching Type” field specifies the data format of the “Certificate Association Data”. As with DNSSEC.1. the trust chain that is established by GADS can be used to validate X. It’s content depends on the location of the record in the name space: 0 0 ··· 8 16 TXT Data 24 TLSA: This record is defined by the DNS-based Authentication of Names Entities (DANE) working group [3]. This record type works exactly as in DNS. On the other hand the “Selector” field specifies what parts of the certificate must match. Furthermore the data can be hashed.

ex.2.gads RRType A A LEHO Value 192.1 and 3. 0 0 1 2 3 4 5 6 7 8 16 24 SHA-256 PKEY Data PSEU: This record type is used to specify the desired pseudonym (or nickname) for a zone.2.gads www. 0 0 ··· 8 16 24 0-Terminated PSEUdonym LEHO: This record type specifies the legacy (DNS) host name for a name in GADS.com The host located at www.3. Section 3. Typically a SSL host certificate would contain the LEHO and not the GADS name. The respective target zone’s records are then typically resolved by querying the DHT and the PKEY hash is used to calculate the query key.com in DNS.1 contains more details on the purpose and usage of “PKEY” records. The GNU Alternative Domain System 0 Cert. Sections 3.1 www. 0 0 ··· 8 16 24 0-Terminated LEgacy HOstname 32 .1.gads can also be referred to as www.ex.2.ex. A “PKEY” record maps a name to the SHA-256 hash of the public key of the subzone’s authority. “PSEU” records must be put under the name “+” into the apex of the respective zone.gads www.0. Usage 8 Selector 16 Matching Type 24 0 1 ··· Certificate Association Data In addition to supporting the above DNS-compatible record types.2 explain the use of “PSEU” records in detail. For example: Q: A: A: Name www. GADS defines the following new record types: PKEY: “PKEY” records are used to delegate resolution to other GADS zones similar to “NS” records delegating resolution to authoritative DNS servers. “LEHO” records are used to enable backwards-compatibility for virtual hosting and SSL certificate validation in combination with the client side proxy as explained in Section 3.ex. The value of the record consists of a single label with the 63-character limit from DNS.ex.ex.2.2.

Bob.2. Integration with Legacy Applications This section will discuss various application-specific issues that need to be addressed before deploying GADS.gads + RRType REV REV Value NULL Additional record types may be defined in the future. existing input methods and APIs for name resolution with DNS will continue to work with GADS. SHA-512 for signing and SHA-256 for generating the “. Bob’s software will default to Alice’s preferences and suggest “carol”. should a need arise to revisit the choice of ciphers in GADS. she sets an “MX” record using the name “+” (as with “PSEU” records. 33 . For her web server she creates an appropriate “A” or “AAAA” record under the name “www”. For example: Q: A: Name example. Our current implementation uses RSA-2048. “REV” records need to be put into the apex (“+”) of the respective zone. it is possible to change the cipher suite by adding support for a “PKEY2” record type which would again delegate to an authority based on it’s public key. After the public-private key pair was generated. GADS limits labels to 63 characters and names to a total of 253 characters including delimiters to maximize compatibility with DNS. The focus is on supporting tools and infrastructure which is needed to improve the user’s experience for important use-cases that a viable replacement for DNS needs to handle. Bob gets to know Alice in real life and obtains her public key. GADS also follows RFC 3490 [16] for encoding internationalized domain names. Surfing with Pseudonyms and Petnames Suppose Alice runs a web server and a mail server and sets up her master zone using GADS. as long as “carol” is not already taken. For mail.2. In particular. we use “+” for her own zone). This is important as it gives Alice an incentive to pick a pseudonym that is sufficiently unique to be available among the users that would delegate to her zone. He performs the same setup on his system. Now suppose we have a second user. Nevertheless. Bob can easily check if a name is taken by performing the respective query against his local database for his personal master zone. Alice creates a “PSEU” record where she states that her preferred pseudonym is “carol”. He then adds her to his zone by adding a “PKEY” record. except this time using a different hash function or a different public key cryptosystem. Bob can choose any name for Alice’s zone in his zone. 3.3. except that his preferred pseudonym is just “bob”. As a result. Integration with Legacy Applications REV: If a “REV” record is present the resolution will fail.2.1. SHA-256 is used as 512 bits cannot be encoded with 63 case-insensitive alpha-numerical characters for this is the DNS label length limitation. 3.zkey” names and for keys in the DHT.

example. Virtual Hosting and SSL Certificates Virtual hosting (the practice of hosting multiple domains on the same IP address using HTTP 1. it replaces “+” with the name of the GADS authority of the site of origin. Once Dave’s client translates “www.carol.gads"> .buddy.carol.3.gads <html>. As before. Dave’s client would be his GADS-enabled browser. Dave can resolve the name to Alice’s public key (Figure 3. When surfing.509 certificates (which certify that a particular private key is used for a particular domain name) cause additional complications for any alternative name system.gads HTTP GET Local Proxy Host: www.gads” and Bob can now e-mail her at “username@carol. For example.4) and eventually the “www” record in her zone.carol.carol.gads” subdomain to Alice.gads”. Bob’s website is “www. 3.buddy.carol. Due to delegation. except that it works with host names. from Bob’s point of view. Dave <a href ="www. HTTP GET Host: www. For Bob.buddy. Thus. <a href ="www. Bob wants to put on his web page a link to Alice’s web page.: Illustration of HTTP download with the GADS proxy...2) if the browser does not support GADS natively.+” to “www. The reason is that giving additional names to an existing service breaks a fundamental assumption of these protocols.4. Bob delegates queries to the “*.com and the HTTP server will fail to return the correct site if the browser sends Host: www.. Overall.2.+"> . When Dave’s client encounters “+” at the end of a domain name. Alice’s website is “www. The GNU Alternative Domain System By adding Alice’s “PKEY” under “carol”.2. Now suppose Dave is Bob’s friend. the “+” stands for the originating zone. Dave has added a “PKEY” record for Bob under the name “buddy” — ignoring Bob’s preference to be called “bob”. which is that they are used on top of a name space with globally unique names..buddy.3. 34 . translating relative DNS names.gads”. However.1) and SSL with X.gads” and for Dave.example..gads”. Bob’s website cannot contain that link: Bob may not even know that he is “buddy” for Dave — not to mention that the HTML of Bob’s website should ideally be the same for all of Bob’s visitors.</html> <html>.buddy.buddy. a virtually hosted website may expect to see the HTTP header Host: www. Alice’s web server is “www. We solve this issue by having Bob use “www. or a client-side HTTP proxy (Section 4.carol.carol.</html> Figure 3.+” when linking to Alice’s website. this mechanism is equivalent to relative URLs [18]..carol.carol..gads”. Dave can access Alice’s website under “www..gads instead.

zkey” name is only used in the network protocols and can be hidden from the users. As a result.3.gads” and reject a certificate for “www.2. it is possible for Alice to have a name for Bob (i.com” as this name does not match the browser’s expectations.2. “bob. This record type specifies that “www. As a result.: Illustration of a HTTPS download with the GADS proxy validating legacy SSL certificates based on “LEHO” records and creating new certificates as expected by the browser on-the-fly.1).example. The receiver can then use GADS to determine a memorable domain name for “hash”. HTTP GET Host: www.gads www.gads:443 HTTP GET Local Proxy Host: www. these problems cannot be solved by adding an additional alias to the HTTP server configuration or the SSL certificate. The sender would use a “Reply-to:” address with the fingerprint of his master zone (“username@hash. The primary example for this scenario is e-mail.example. either by finding an existing name in the local database or by looking up the “PSEU” record for the zone and creating an appropriate entry in the local user’s shorten zone.example. Integration with Legacy Applications Similarly. Enabling Replies (e-mail) Delegations in GADS create a directed graph among the zones.bobswebsite. Naturally.3.zkey”). 3. A proxy between the browser and the web server (or a GADS-enabled browser) can then use the name from this record in the Host: header or for SSL validation (Figure 3.bobswebsite. 35 . the “. The resulting graph is typically not strongly connected. If in this situation Alice contacts Bob.gads”) even if Bob has no such name for Alice. the necessary modifications are relatively simple.5).com Server Figure 3. these are only legacy issues as the public-key infrastructure provided by GADS provides an alternative to X. a new HTTP header with a hostname and a zone key could be introduced to address the virtual hosting problem.509 certificates (see Section 5.e. the browser will expect the certificate to contain the requested domain name “www.5. she needs to supply him with her zone’s fingerprint to enable Bob to respond.example. Fortunately.buddy.gads” would like to be identified as “www.com”.buddy. Similarly. Because with GADS each user is free to pick his own petname for the service. Our solution to this problem is to add a legacy hostname record type (“LEHO”) for the name.com:443 Dave www.

QXDA. A gateway will serve as a GADS resolver for a specific DNS suffix.2 w w.4.tum.eu) where the DNS authority passes all requests on to GADS.2.0 u . 9 ? w 5.zkey” TLD.com will be resolved in GADS. The IP addresses used in this figure are real world IP addresses pointing to an authoritative .0.eu.zkey.eu ? try 91.0. This approach is similar to the tor2web gateways (Section 2.zkey” name space. Accessing GADS without Installation A DNS-to-GADS gateway is useful to allow legacy systems to access the GADS distributed database without installing GADS or changing their system configuration. Anyone controlling a name in DNS can setup a DNS-to-GADS gateway.eu) and appends the “. The GADS gateway behaves just like a regular DNS server.eu would be resolved by the gateway querying the “www” record in the GADS zone QXDA. www.nic.6 illustrates an example lookup of a GADS record using the DNS-to-GADS gateway.zk ey.6.: Example lookup for GADS record www. 34 .1 . The server queries the result in GADS and returns a DNS response. a gateway can only serve specific zones or the globally unique “. 36 .zkey by using our DNS-toGADS gateway at zkey.eu DNS server (a. For example.gads.1 Figure 3.eu) and our own authoritative DNS server (toxic.100 DHT DNS Root Server Client ww DA .com then a query for www. However.2.16.in. It answers queries for DNS names. The labels following the suffix will be interpreted as GADS names.QXDA. Our server strips the name in the DNS query of the relevant parts (zkey.zkey.de). Since names in GADS are not unique.zkey.eu TLD Server www. eu 8.QXDA. The equivalent GADS name to query would be www.net.4) for the Tor network.QXDA.zkey ? GADS authoritative DNS Server for zkey.eu IP: 192. www.2 ? .1 try 18 w.2.e . if the resolution of a name in a specific zone is requested then the gateway will resolve the name using GADS.QXDA.3. If the designated DNS-to-GADS zone of our gateway is gads.4 Q XD A. QXDA is referring to a GADS zone.2.QXDA.Q X GET QXDA xor H('www') IP: 192.200. Figure 3. IP zk :1 ey 92 . We have registered a domain name in DNS (zkey. The GNU Alternative Domain System 3.

2. Incompatible Applications In rare cases applications are completely incompatible with the GADS design. as DNS is used to access the proxy and thus DNS and the proxy operator would need to be trusted.2 92. 3.gads” or “. While this trick can help users access GADS information without installing GADS.: A DNS-to-GADS gateway that is also a DNS proxy. it encapsulates 1 http://code. Integration with Legacy Applications The DNS-to-GADS gateway can also be used as a proxy DNS resolver for a local subnet. Iodine is used to tunnel IPv4 traffic in DNS packets. y? .0.1 QXDA xor H('www') . exa m ple.2.2 Recursive DNS Server Figure 3.7.QX www zke DA.3.zkey” will be resolved by the gateway in GADS.0 . it does not offer any of the security or censorship resistance advantages of GADS. One such application is Iodine 1 . Clients are configured to use the DNS-to-GADS proxy as DNS server.0 IP: 1 www . In this case the gateway will proxy all DNS request to an actual recursive DNS resolver.7 shows such a setup. com ? .2. This allows the client machines to send DNS queries to the gateway containing GADS names. Basically.1 Client Subnet IP: 1 92. DHT GET IP: 192. All GADS names ending in “.5. users must install GADS locally and manage their own zone.se/iodine/ 37 . Normal DNS queries will be proxied to a recursive DNS resolver. This feature can only help users as a transition mechanism.kryo. This results mostly from assumptions made on the network protocol of DNS. Figure 3.2 GADS DNS Query DNS Response DNS-to-GADS proxy gateway . A client using the gateway as its DNS server will be able to resolve names in GADS without having a GADS resolver installed. For GADS to provide improved censorship resistance and security.

The DNS query will eventually reach the Iodine server and it will extract the IP payload and forward it to its original destination specified in the IP header.8 illustrates the scenario where the client is behind a firewall without direct access to the Internet.3. The Iodine server is configured as an authoritative DNS server for that specific domain. However. The viability of DNS Tunneling in various practical contexts has been thoroughly investigated in respective works [57]. it is allowed to use a DNS server to resolve host names. The Iodine client puts IP packets into DNS queries for a specific domain. Hence Iodine is one of those applications that are inherently incompatible with GADS and we cannot provide additional tools to “make it work”. Figure 3.: The client is behind a firewall and unable to access the Internet. For GADS this approach cannot work because there is no such thing as an “authoritative GADS server” that could be used as the Iodine server. the query for the authoritative records is answered by the DHT and not the authority itself. The GNU Alternative Domain System IP packets in DNS queries and replies respectively. Internet Firewall DNS Server Figure 3. The authority in GADS is a specific peer.9). However. Using Iodine it is possible to bypass the firewall by tunneling all IP traffic via the DNS resolver.8. 38 . The dotted red line illustrates the tunnel that is established between Iodine client and server (Figure 3.

Integration with Legacy Applications Internet Firewall DNS Server DNS Root Server DNS .com Server DNS example.2.com”.9.3.: The client uses Iodine to tunnel IP packets to the authoritative DNS server for “example.com Server iodine Server Figure 3. The authoritative DNS server is running an Iodine server instance and forwards the IP packets to their destination. 39 .

The GNU Alternative Domain System 40 .3.

4. Implementation
In this chapter we present our reference implementation of the GADS design. Initially, we discuss how to integrate a DNS replacement into modern Operating Systems in Section 4.1. In Section 4.2, we provide implementation details on the GNUnet Name System (GNS), our GADS implementation based on the GNUnet peer-to-peer framework. Finally, in Section 4.3, we introduce a few useful tools to manage a local GNS installation and take a look at application integration in Section 4.4.

4.1. Integration into Operating Systems
Programs that are unaware of the existence and semantics of the GADS name space will inevitably try to resolve GADS names in the same way as DNS names. Consequently, a GADS implementation needs to intercept all DNS queries for the “.gads” and “.zkey” TLDs and inject appropriate responses. All other TLDs are forwarded to the traditional DNS system. Our current implementation provides three alternative methods to do so: • On GNU systems, a plugin for the name services switch (NSS) [19] in GNU libc can be used to answer GADS queries before a DNS request is ever created. Mechanisms similar to NSS exist for other platforms. We also have an equivalent plugin working on Microsoft Windows. • The resolver configuration (for example, /etc/resolv.conf) can be changed to point to an IP address (i.e. 127.0.0.1) with a modified DNS resolver. We have implemented a DNS-to-GADS gateway (Section 3.2.4) which resolves “.gads” and “.zkey” TLDs internally, and acts as a proxy for all other TLDs by passing those requests to an actual DNS server. • Rules in a host-based firewall can be created to intercept and redirect DNS requests before they can leave the host. All three methods have advantages and disadvantages. In the following sections we will provide details on how the different options are realized.

4.1.1. Firewall-based DNS Interception
A host-based firewall, like iptables in Linux, can be used to intercept all outgoing DNS requests, preventing applications from bypassing modifications to the operating system’s stub resolver. The requests are redirected to a service that processes the DNS queries. Depending on the queried name in the DNS request the service can either use DNS or

41

4. Implementation GADS for name resolution. The result will be sent back to the application as if it was answered by the DNS server specified originally. While this approach allows us to transparently resolve GADS names in DNS queries we cannot distinguish between users on the same host. A UDP packet with DNS payload does not tell us anything about the user that issued the query. Consequently, the GADS zone that is used for GADS queries is the same for any user on the system. On true multi-user systems this contradicts the idea of GADS where each user manages his own zones. Figure 4.1 illustrates our implementation of this approach. Here, we use a virtual network interface (using TUN [30]) and configure the system’s firewall to redirect all outgoing UDP traffic on port 53 to the TUN interface — except for outgoing UDP traffic from users in the gads group. The only process running in this group runs the DNS resolver of the GADS system.

Stub Resolver

.com .gads
s re om re , .u sp s, on ... se ns po e .c

iptables
redirect

DNS Interceptor

.g ad s e sp re s on

DNS

GADS

Figure 4.1.: Our GADS implementation uses iptables to intercept all DNS packets and appropriately handle GADS requests locally. Traditional DNS requests are proxied to an actual DNS resolver. The GADS installation reads the DNS traffic from the TUN interface, resolves “.gads” and “.zkey”requests and forwards non-GADS requests to the original destination using the process running in the gads group (which is not affected by the firewall rule). In either case, the reply is sent back to the originating application via the TUN interface.

4.1.2. DNS-to-GADS Gateway
An alternative to the interception of DNS queries using the firewall is the configuration of an alternative DNS resolver which resolves requests to “.gads” and “.zkey” using GADS. Our implementation includes such a DNS-to-GADS proxy, which facilitates deployment of GADS to larger groups of users without the need to install a GADS resolver on each host.

42

4.1. Integration into Operating Systems Both network-level approaches, firewall interception and proxy gateways, limit the personalization of GADS requests to per-IP zones. However, GADS is designed with a peruser scenario in mind. This limits the utility of these setups to scenarios where users do not share hosts. Furthermore, if users use a local DNS-to-GADS proxy server, the local server would have to be trusted to perform the cryptographic verification. Finally, the DNS transfer between the host and the DNS-to-GADS proxy would not be cryptographically secured.

4.1.3. NSS Plugin
On GNU systems, the NSS-based approach has the key advantage that it allows our GADS implementation to learn the identity of the user that issued the query. As a result, we can fully personalize the GADS lookup on a per-user basis by maintaining a simple mapping between local user names and the respective zone keys. A potential disadvantage is that some applications may bypass the operating system functions and directly contact a DNS resolver. Tools such as host or nslookup do exactly that. Whenever an application calls any of the gethostbyname() functions provided by glibc to resolve IP addresses, the name services switch is used. The name services switch consists of various plugins. Traditionally, at least one plugin reads a specific file for host information (/etc/hosts) and another plugin performs DNS queries. Our plugin is called gns in accordance with our GADS implementation discussed later in Section 4.2. A name services switch (NSS) plugin is usually configured in the file /etc/nsswitch.conf on a GNU/Linux system. An example configuration can look like this: ... hosts: ...

files gns [NOTFOUND=return] dns

In this case the plugin gns will be asked before DNS to resolve a specific name. If our plugin is unable to resolve, it will return NOTFOUND. The string [NOTFOUND=return] tells the NSS system that it should return in this case and not ask DNS. This ensures that we do not leak the information of using GADS into DNS or the network in general whenever the resolution in GADS fails. Of course this does not affect non “.gads” or “.zkey” queries. In that case the GNS NSS plugin will always return UNAVAIL and the NSS will continue with the DNS plugin dns. NSS is the most suitable approach for GADS integration on multiuser systems. To also support applications that bypass the operating system resolver, one of the other two solutions can be used in parallel.

43

Command line interface (CLI) tools are available to manage local records in the Namestore.4.2. The Namestore Implementation The “Namestore” service provides a local database of GADS records.2. In the following sections we provide implementation details on the before mentioned services. Hence. Implementation 4. GNUnet implements the R5 N Distributed Hash Table discussed in Chapter 2 and provides us with all the necessary tools for a GADS implementation. GADS Gateway and NSS plugin rely on the functionality provided by GNS.: GNS is built on top of the GNUnet services “Namestore”. 1 https://gnunet.2 provides an overview of the design. “VPN”. It is designed following a modular. DNS-to-GADS Gateway Firewall Interceptor NSS Plugin GNUnet Name System Namestore SQL Postgres R5N DHT VPN GNUnet Infrastructure Figure 4. Figure 4. In GNS this service is also used to cache lookup results from the network. accessed 08/15/2012 44 . “DHT”. It’s main component is a GADS resolver. signature creation and verification.org. the record data stored in the Namestore is not limited to authoritative records. cryptography. The “VPN” service is used for “VPN” record processing. 4. removing and querying of GADS records as well as signature verification of GADS network blocks. For data storage. The Firewall interceptor.1. layered structure consisting of various services. network operations and record handling GNS uses existing GNUnet services. The GADS service we implemented for the GNUnet framework is called the GNUnet Name System (GNS). The API supports adding.2. We implemented the “Namestore” service for local record storage. GNUnet Name System GNUnet is a “framework for secure peer-to-peer networking”1 released under the GNU General Public License version 3+. For networking operations we use GNUnet’s existing R5 N DHT implementation.

In GNS. If the signature is invalid. Block plugins are executed on every hop in the network for any “GET” request or “PUT” reply that is routed through the peer. For on the fly signature creation the signing key – the private key of the respective zone – needs to be online. In GNS. GNUnet Name System However. the signing needs to be done right before the record is published into the DHT and not when the record is created. Figure 4. Unfortunately whenever a user creates a record with a relative expiration value like “1 day” and the system publishes it into the DHT on the “1st of January 2012”. By design. The block is only considered valid and forwarded if all checks pass. For non-authoritative (i. however. Another important function that is performed using the DHT service is record propagation. Whenever an authoritative record is queried.3 allowing the user to manage the three GADS zone in a more usable manner. the expiration value needs to be converted to the absolute value “2nd of January 2012”. the Namestore is in charge of creating signatures for authoritative GADS record blocks. By dropping the reply before corrupt or incorrect data is forwarded to the initiating peer. cached) record data the signatures provided in the DHT blocks are stored and returned appropriately. As soon as the peer is started. the load on the DHT can be reduced. For R5 N it is advantageous to regularly perform “PUT” operations to achieve good balancing and replication of the data in the DHT. we apply a Bloom filter [4] to identify and drop duplicate replies. Consequently. online signing is necessary.4. Network Integration Our implementation uses the R5 N DHT [15]. the reply is dropped. There are various block plugins implemented in GNUnet for various different purposes. Finally. the Namestore will create a signature for the block on the fly. This limits replies to properly signed data that matches the request. the signing key has to be online for GNS. a Byzantine fault-tolerant DHT that can con√ duct lookups with O(log n n) messages. Offline signing of records with absolute expiration values is no problem. Systems like DNSSEC provide offline signing of record data to provide additional security.3.3 illustrates the block plugin logic. The second check verifies that the key KQuery used to query for the record actually matches the zone information Kpub and record name name in the block: KQuery ≡ H(Kpub ) ⊕ H(name) where H is a cryptographic hash function. Since this converted value is signed data. For GADS. one of the interesting features of R5 N is the ability to do custom processing of replies within the network. there is also a graphical user interface discussed later in Section 4. this process is called zone iteration. Our custom processing logic in the gns block plugin verifies the signature for any reply that is routed through a peer. In the GNUnet R5 N implementation this is done using block plugins. GNS uses our custom block plugin gns.2.e. all public records are put into the DHT. The Namestore service supports two different backends to store the record data either in MySQL or PostgresSQL databases and offers a plugin API that can be used to add support for arbitrary databases. The third check makes sure that the record data is semantically correct and can be deserialized. For example. the fs block plugin for file-sharing data or the test block plugin for arbitrary data. after the signature has been successfully verified. This also counters 45 .2. 4.2. This is due to the relative expiration values of the records. Our block plugin first checks if the incoming block is of the correct block type.

For this very reason the Namestore API does not even expose such a functionality. On the other hand very conservative record propagation intervals will cause zone iterations with a large number of records to take a long time. the number of records is unknown initially and GNS will on startup attempt to propagate all record data reasonably fast into the DHT. All subsequent intervals between puts are calculated using a predefined initial “PUT” inPU terval IinitT divided by the current number of records numrecords . even if configurable. After this initial propagation an adjustment algorithm is used to adapt the interval to the record count. The GNS service needs to determine dynamically the optimal interval for a zone iteration. are not really a sensible option. The number of current current 46 . Counting all records in the Namestore can be extremely resource intensive if the number of records is very large. As a result. Consequently.4.: The GNS block plugin logic. data loss caused by block expiration. Intervals between “PUT” operations should not be too short or the zone iteration will cause heavy network load and performance on lookup will suffer.3. static intervals. Implementation New DHT block Block Type is GADS? No Block Type Unsupported Yes Query Key matches Data? No Block Invalid Yes Record Data Valid? No Block Invalid Yes Block Signature Valid? No Block Invalid Yes Bloomfilter Check Pass? No Block Invalid Yes Block Valid Figure 4.

4.2. GNUnet Name System records is updated after each “PUT” accordingly. If the resulting interval is below a certain PU threshold IminT , the threshold value will be used as “PUT” interval instead. The interval P UT Icurrent for the next zone iteration is calculated using the following formula:
Ç
P UT Icurrent

= max

PU IinitT , IP UT numrecords min current

å

(4.1)

P UT For the next zone iteration Icurrent will be used as the time to wait between PUTs. The only problem left is that the Namestore database can be populated while a zone iteration is in progress. If the number of records increases by order of magnitudes then the zone iteration will take a very long time because the interval was calculated based on a much PU lower number of records. For instance, let us assume that numrecords = 5 and IinitT = 5 h. current The next zone iteration interval is calculated as follows: P UT Icurrent =

5h =1h 5

Furthermore, let us assume that after the first record is put, the user adds 45 more records P UT to the Namestore. The zone iteration will not complete before Ttotal = 49 · 1 h = 49 h. Not only will this drastically delay the next zone iteration, but it will also cause the new records to be available only after two days. To counteract this phenomenon the current PUT interval is adjusted while a zone iteration is in progress if the number of records numrecords that current were already “PUT” in this zone iteration exceeds the total number of records numrecords last counted in the previous zone iteration. In the example above after the 6th record is put P UT into the DHT the interval Icurrent is instantly adjusted using the Formula 4.1. Additionally, the interval is halved: PU IinitT P UT (4.2) Icurrent = 2 · numrecords current The total required time to put all 50 records can be calculated using the following formula:
numrecords last P UT Ttotal numrecords total P UT Icurrent i=1 numrecords last

=

+
i=numrecords +1 last

PU IinitT 2·i

(4.3)

=
i=1

P UT Icurrent +

PU IinitT · Hnumrecords − Hnumrecords +1 total last 2

(4.4)

Where Hn is the n-th partial sum of the diverging harmonic series Hn := n 1 , also i=1 i known as the n-th harmonic number. In our example the resulting total time for the zone iteration is:
5 P UT Ttotal = i=1

1h+

5 h 2·i i=5+1

50

(4.5) (4.6) (4.7) (4.8)

= 5 h + 2.5 h · (H50 − H5 ) ≈ 5 h + 2.5 h · (4.5 − 2.3) = 10.5 h

47

4. Implementation Needless to say this is a significant improvement over the 2 days and 1 hour the zone iteration would have taken without this small adjustment. Of course simply setting the P UT PU interval Icurrent to a very low value like 1 minute or the default initial value IinitT would reduce the duration even more. However, we think this is the better approach if we keep the properties of the DHT in terms of load balancing and performance in mind.

4.2.3. The VPN Service
GNUnet’s VPN provides features such as IP tunneling and IPv4-to-IPv6 as well as IPv6to-IPv4 protocol translation. In other words, each peer that is part of the VPN can provide access for other VPN peers to services and networks that might be otherwise unreachable. Here is an example: Peers 0 to 4 are nodes in the GNUnet peer-to-peer network running the VPN service. Peer 2 is behind a NAT in the local subnet 192.168.0.1/24. A web server with IP 192.168.0.1 is located in this subnet as well. Peer 2 decides to offer a VPN service with name “mywebservice” on port 80. If another peer wants to access the private web server in Peer 2’s local subnet it has to establish a tunnel via Peer 2. Any peer can request a temporary IP address from the VPN service to Peer 2 by supplying the correct VPN service name (“mywebservice”), port (80) and peer ID (2). Figure 4.4 illustrates the discussed use case. Any packets sent by the requesting peer to the temporary IP address will be tunneled by Peer 2 to the private web server.
Private Webserver

IP: 192.168.0.2

Peer 1 IP: 192.168.0.1

IP: 10.0.0.1
Peer 0

VPN

IP: 10.0.0.2
Peer 2 offers: "mywebservice" port 80

Peer 3

Peer 4

Figure 4.4.: Peer 0 requests a temporary IP address to access the service offered by Peer 2. The allocated IP addresses used by Peer 0 are 10.0.0.1 and 10.0.0.2. Peer 2 offers the service under the name “mywebservice” on port 80. The traffic received by Peer 2 is tunneled to a web server located in a private subnet that only Peer 2 has access to.

48

4.3. Complementary Tools and Programs The required information to establish the VPN tunnel can be embedded into the “VPN” record type. Naturally, the record can be resolved by any application that uses the VPN functionality. Our GADS resolver supports on-the-fly “A” and “AAAA” record synthesis. Whenever the resolver encounters a “VPN” record and the queried record type is an IP address it will use the information in the “VPN” record to request a temporary address. The address will be put into a freshly created “A” or “AAAA” record that is returned to the application. Given that Peer 0 and 2 in our example are using GNS, the process of accessing the private web server becomes trivial. Peer 2 creates a record in its local GADS zone of type “VPN” under “www” containing the service name, port and the peer ID. If Peer 0 refers to this zone as “alice” it can access the private web server using the name www.alice.gads. GNS will transparently allocate an IP address whenever Peer 0 tries to access the web server using that name. This is the VPN record data format: 0 0 1 2 3 4 5 6 7 8 9 ··· 8 16 24

SHA-256 GNUnet Peer Identity

Port 0-Terminated VPN Service Name

4.3. Complementary Tools and Programs
To assist the user in zone management and improve the usability we have created a few complementary programs. Mainly for headless systems like servers or for automated scripting GADS provides command-line tools (Section 4.3.1) to manage the local zone database and to query GADS names. As discussed in previous chapters, a proxy is necessary to deal with GADS names in HTTP sessions. In Section 4.3.2 we discuss a SOCKS proxy implementation for this purpose. Furthermore we provide a graphical user interface written in Gtk+. Section 4.3.3 introduces the program that ships with GNS.

4.3.1. Command-Line Tools
We have implemented two command-line tools that let the user manage the GADS zone and query the GADS system. The gnunet-namestore tool provides access to the Namestore databases. It queries the GNUnet Namestore service and requires a running service instance. To view all records in the root zone a user can issue:

49

1.gads is an “A” record in alice’s zone.example.gads This GNS feature is also used by the HTTP proxy discussed in the next section.dave.gads www. gnunet-gns provides similar functionality to the nslookup and host programs found on most GNU/Linux systems.-delete switch.1.1.bob.-value is checked for syntactic and semantic validity. To lookup the previously added records for the name www.dave.example.gads where “alice” is already in our root zone as “carol” we can use gnunet-gns to shorten the name: $ gnunet-gns --shorten www.bob.gads shortened to www. it provides functionality to extract the authority of the name.1.4. Finally.gads: Got A record: 1. gnunet-gns allows us to determine the authority of a record.1. If we want to lookup our “LEHO” record we can issue: $ gnunet-gns --lookup=www.alice.-lookup switch: $ gnunet-gns --lookup=www.dave.1 The record type for the lookup defaults to “A”.gads is the authority: 50 . the data provided with .alice. A second tool called gnunet-gns is used to query and shorten names.dave. Furthermore.1 --expiration="1 day" $ gnunet-namestore --add --type=LEHO --name=www \ --value=www.gads the user can use the . Given a name like www.carol. A complete description of the gnunet-namestore program can be found in Appendix B.1.alice.1 as well as a “LEHO” record pointing to www.com Another feature of the gnunet-gns program is name shortening.gads --type=LEHO www. if the “www” label in the name www.alice.com --expiration="1 day" The expiration for the records is set to one day. When adding records. then alice.example.bob.gads: Got LEHO record: www. For instance. Implementation $ gnunet-namestore --display gnunet-namestore can also be used to add and remove records.gads www.bob.dave. Similarly records can be removed using the .bob.com: $ gnunet-namestore --add --type=A --name=www \ --value=1.1. These commands can be used to add an “A” record with the name www and the IP address 1.

gads alice. 4.4. Connections to systems using DNS names are simply proxied without processing the content. Complementary Tools and Programs $ gnunet-gns --authority www.: Flow chart showing the connection setup of the proxy using the information provided in the SOCKS4a protocol. Another issue the client proxy tackles is the Same-Origin-Policy (SOP) imposed by modern browsers. The SOP forbids scripts or cookies to access a different name in the do- 51 . which allows the browser to delegate resolution of domain names to the proxy. A more detailed description of gnunet-gns can be found in Appendix B. This logic is illustrated in Figure 4. This is important as it allows the proxy to perform GADS resolution and obtain “LEHO” and “TLSA” records for certificate verification.2.2.bob. A proxy implementation has the advantage that it works with virtually all browsers. If the target server is accessed using a GADS name. SOCKS4a request Name is GADS? No Proxy TCP traffic Yes Connection is HTTPS? No Proxy HTTP traffic Yes Generate Certificate Proxy HTTPS traffic Figure 4.3.alice.bob.gads Resolving the authority of a name is useful for relative links.2.dave.5. the proxy replaces relative GADS names in the HTML. The “+” in relative links will be replaced with the authority of the name.dave. If the proxy supports the SOCKS4a extension.2. the client can provide a domain name instead of an IP address. The proxy speaks the SOCKS4a [33] protocol.5.3. In the SOCKS4 protocol a browser usually sends the IP address and port of the desired connection to the proxy. HTTP Proxy Our current implementation uses a client side proxy to do the expansion of relative names and SSL verification as explained in Section 3.

. the following CORS headers are added as well: HTTP/1.1 200 OK Content-type: text/html Set-Cookie: Session=XXX. This is implemented using HTTP header and HTML content rewriting and the use of Cross-Origin-Resource-Sharing (CORS) [56] headers..gads would be translated to: HTTP/1. This will allow the browser to execute scripts referred to using the LEHO. However.4.example.example...com . Implementation main name space. Domain=.gads . where example.example. The proxy also uses GADS domain name shortening as described in Section 3.gads Access-Control-Allow-Origin: http://example.1 200 OK Content-type: text/html Set-Cookie: Session=XXX.. Otherwise.. GADS provides an API that shortens long delegation chains resulting in significantly shorter names.com .example.gads then JavaScript code from www. for example if a link is generated when the browser executes JavaScript code. For example. If “PSEU” records are unavailable locally. Domain=.com is the LEHO for example.1. This can be an issue as the cookies and JavaScript code might use the legacy hostname (LEHO) instead of the GADS name and would then be ignored in accordance with the SOP. Note that the “PSEU” import and name shortening API are two complementary functionalities.1 200 OK Content-type: text/html Set-Cookie: Session=XXX. For instance a “Set-Cookie” HTTP header field set by the server like this: HTTP/1. Note that the browser will use the DNS name in those cases and the GADS advantages will be gone. the GNS service itself will 52 . waiting for GADS to retrieve “PSEU” records for each link from the network would result in a significant increase in latency. if you browse www. To solve this issue. The first is part of the GADS resolver and the basis for name shortening. As to not break the functionality of the web server. For performance reasons shortening of names in the HTML is done only if the necessary information is already available in the local GADS cache. the proxy translates links pointing to the LEHO and modifies the domain names in cookies to satisfy the SOP. In some rare cases the proxy cannot replace LEHO links.example. we think that it is more important to the user that the web page is working as expected.com is forbidden to run.4. The latter is the API that actually makes use of the automatically imported “PKEY”s. Domain=.

this does not have any security or privacy implications.gads”). The proxy also needs to implement a trivial HTML rewrite engine so that users can follow relative links found on websites.gads/ which is mapped by GADS to the host name and certificate of https://portal. In order for this to work.gnu. This behavior is important though for two reasons. To generate certificates for GADS names we use gnutls 2 . https://myisoc. Complementary Tools and Programs initiate a query for the respective authority in the background. similar to how sslsniff works [36].: Screen shot of a browser accessing. The result of the background lookup will be cached in the local Namestore database. Figure 4. both tasks impossible if the content is encrypted. If a connection request to the HTTPS port 443 is received the host certificate is checked using the LEHO by libcurl and a freshly generated GADS certificate is served to the browser in the SSL/TLS handshake.6 shows a screen shot of a browser visiting an ISOC web page with the GADS SOCKS proxy performing certificate validation based on the respective GADS records. the proxy generates a second certificate on-the-fly which is valid for the user’s name for the site (here “myisoc.3.6. shortening will then be used the next time the name is encountered. isoc. The first reason is that the certificate given by the host contains the DNS name and so the browser will not accept it. Figure 4. The other reason is that the GADS proxy needs to perform HTML and HTTP header rewriting. The signing key is generated for each proxy instance on installation. For web browsing it is necessary to use the proxy to be able to use functionality like virtual hosting and SSL. The browser accepts this certificate.org/. accessed 09/07/2012 53 . The GADS proxy validates the site’s certificate and creates a certificate for the browser on-the-fly. the proxy’s signing key needs to be imported into the browser’s certificate root store. 2 http://www.4. Since the proxy is meant to be operated by the user and run on the users machine.org/software/gnutls/. Essentially this results in a SSL-Man-in-the-Middle situation where the proxied data is available unencrypted to the proxy.

If the port is HTTPS.gads” certificates • A GADS post-processor that processes the HTML content and headers • libcurl 4 is used to access remote web servers via HTTP Figure 4.4. libcurl is used to handle the HTTP(S) communication with the server (7).7. Finally.7 illustrates the interaction of the various components that are part of the proxy. providing host name and port of the desired connection (1). A GADS post processor modifies HTTP headers and HTML content to translate the GADS name to it’s LEHO counterpart (if applicable) and vice versa (6). GADS Proxy 2 GADS + HTTP GADS + HTTPS DNS + HTTP(S) 6 1 Client SOCKS4a 3 HTTP/HTML content processing 7 libcurl Server 4 5 Figure 4. the connection will simply be proxied to the desired server using DNS for name resolution (5). the proxy will generate a SSL certificate for the client on the fly and a HTTPS GNU libmicrohttpd instance will handle the request using that certificate (3).haxx. accessed 09/07/2012 http://curl. In both cases the name will be resolved using the GADS resolver.gnu. the request will be handled by a GNU libmicrohttpd instance. 3 4 http://www. accessed 09/07/2012 54 .org/software/libmicrohttpd/.se/libcurl/. The client uses the SOCKS4a protocol to connect to the proxy. If the host name is in the GADS domain and the port is the standard HTTP port. If the host name is not in the GADS name space (4). Implementation The implemented client side proxy consists of four major components: • A SOCKS4a interface to communicate with modern browsers • A GNU libmicrohttpd 3 component in charge of serving HTTP and HTTPS requests as well as to serve generated “.: This Figure illustrates the inner workings of the GADS proxy.

We expect that most names will be learned from links as discussed in Section 5. “NS”. “VPN” records.3. Our GADS zone editor allows users to create or delete DNS and GADS records in the master.3. we provide the possibility to create and export QR codes [1]. users are encouraged to place private records into their private zone to avoid accidentally using those names in links. Still. The QR code contains the fingerprint and desired pseudonym as a link of the form gads://hash/pseudonym. To safely introduce direct trust relationships between GADS users we provide two different mechanisms. “LEHO”. “PTR”. The pseudonym for the user’s zone can be specified using a dedicated text input box.8. The application performs an automatic syntactic and semantic validity check for the record data to prevent invalid records.3. users may want to create new names or manage the names that have been created by auto shortening.: Screen shot of the GADS zone editor. Relative values are converted to absolute values upon publication in the DHT. private and shorten zones. which users can use to conveniently share keys in print. Complementary Tools and Programs 4. The user can specify the desired validity duration for each record as an absolute (using a calender widget) or relative (“1 day”. It supports the creation of “A”.8. “AAAA”. “TLSA” and “SRV” records and the GADS specific “PKEY”. Alternatively. “never”) value. it is important to allow the users to manage their GADS zones in a convenient way. A screen shot of our GADS zone editor is shown in Figure 4. with the consequence that private records are invisible to other peers and will not be published in the DHT. “SOA”. “1 year”. For one. “1 week”. “PSEU”. Figure 4. The QR code reader would be configured to create a new name and delegation records in GADS 55 . The GADS Zone Editor and GADS QR codes To give users the freedom GADS is intended to provide. “TXT”. the user can export his fingerprint to the clipboard to share it with other users out-of-band. “REV”. email or instant messengers. Users can mark records in any of their zones as “public” or “private”. A QR code reader can recognize the QR code. Naturally. “MX”.4. “CNAME”.5 and a few will be imported from out-ofband mechanisms manually.

4. Street Name 23 Phone: 555-12345 Mobile: 666-54321 Mail: schanzen@schanzen.4.: A business card template featuring the QR code for the holders personal GADS zone. Hence. A major disadvantage is that. business cards could easily be fashioned with a QR code containing the GADS zone information of the company.Sc. The advantage is that the code needs little to no changes to resolve GADS names. B.4. The first option is to use the DNS packet interceptor and manually create DNS queries.1. 56 . Martin Schanzenbach. as mentioned in Section 4.fcfs. Alternatively. Similarly.3.1. Implementation when it recognizes this type of URI.1. such QR code could be put onto official mail by companies that is sent to their customers. All three options have their advantages and disadvantages discussed below. the GNS API can be used directly. Address: Country.9. person or both as well. For example. The last option is to fork-and-exec the GNS command line tools discussed in Section 4.4. 4.gads Figure 4.9 shows the authors GADS QR code on a business card template. the important per-user zone management feature of the GADS system cannot be used on multi-user systems. DNS packets Creating DNS packets that are in turn intercepted by our Interceptor is probably the most straight forward solution for any application that already deals with DNS packets. the intercepted query can only be associated with the system and not with a specific user. Figure 4. Integration into Applications To use the full potential of GADS a developer has three options.

" r " ) . the parent. 4 s t r u c t in_addr i p . GNS API The most common way of accessing the functionality of system services is through their libraries and APIs. Integration into Applications 4. Programmers usually want full control over their applications. GNUnet features its own event loop. including main loop and threads.2.4. 4. The problem is that applications calling a GNUnet service API need to run in the GNUnet event loop. i f ( (NULL == p ) || (NULL == f g e t s ( l i n e . Here is a stripped down example taken from the code: FILE * p . The advantage of this method is that a programmer can entirely avoid linking against the GNUnet library. so that programmers can avoid the use of threads and services can be controlled in a simple and effective fashion. GNS is part of the GNUnet framework and has a well defined API (Appendix C).4. 1 5 6 7 8 9 10 11 12 13 14 15 16 i f (−1 == a s p r i n t f (&cmd . 3 char l i n e [ 1 2 8 ] . it is possible to use the CLI tools since they expose most of the functionality of the GNS API.3. p = popen ( cmd .4.4. The GNS nsswitch plugin discussed in the beginning of this chapter uses fork-and-exec to invoke gnunet-gns and resolve GADS names. l i n e [ s t r l e n ( l i n e ) − 1 ] = ’ \0 ’ . To avoid the GNUnet event loop. Fork-and-exec Fork-and-exec is a common method for program interaction on Unix Systems. fclose (p) . Any program can execute the GNS command-line tools using fork-and-exec and gain access to the full functionality of the GNS API. Unfortunately. name ) ) r e t u r n −1. 2 char * cmd . p ) ) || ( ’ \n ’ ! = l i n e [ s t r l e n ( l i n e ) − 1 ] ) ) error ( ) . The fork() system call spawns a new program that is executed. "%s %s\n " . f r e e (cmd) . Input and output of the spawned program (known as the child) are controlled by the spawning program. unless a programmer actually wants to write a GNUnet service or application. this dependence on GNUnet might be a hindrance. 57 . " gnunet−gns −r −u " . s i z e o f ( l i n e ) .

58 .4. l i n e . In this snippet the popen() system call is used to execute gnunet-gns and resolve the IP for the name in the variable name. return ip . Implementation 17 18 19 20 i f ( 1 ! = i n e t _ p t o n ( af . In the subsequent lines the output of the command is parsed and if a well formed answer is received from GADS the IP is returned. &i p ) ) error ( ) .

Discussion In this chapter we discuss various specific security and usability issues associated with the migration from DNS to GADS. In Section 5.5 presents the results of a small-scale survey into browsing behaviour.1. only the authority of the parent zone (which is typically the respective TLD) would be able to certify a given domain name.5. Establishing Trust with GADS To replace X. Section 5. As fewer entities with more direct relationships are involved.2 we highlight some security weaknesses related GADS name shortening and corresponding countermeasures. 5. the security of the weakest CA determines the security of the system.509 validation. With DANE. The use of reverse proxies for host migration is outlined in Section 5. The trust chain established by GADS allows the GADS proxy to use “TLSA” records to perform X.3 discusses the bootstrapping process for GADS. Section 5.509 Certificate Authorities (CAs). Finally. the TLD administration is a particularly bad choice as it is typically subject to the laws of the country under administration and will thus be a prime target for censorship and “lawful” intercept [31] activities. similar to IETF’s DANE effort [3] for DNSSEC.6 discusses the viability of alternative GADS resolver implementations. We show how GADS can be integrated into existing security infrastructures and reinforce their security assertions in Section 5. “TLSA” records in combination with GADS can be used. As a result. the resulting trust chains would be much harder to compromise. for example by furnishing them with the QR code of their respective GADS zone. The continued stream of security incidents with X.4. Institutions with high security requirements can use GADS to establish more direct trust relationships with their clients. Trust anchors in distant parts of the world would be much less likely to comply with unethical requests as local laws might not apply to them. Given the threat model of this paper. A central problem with current CA-based security is that any CA can create certificates for any domain name [25]. Section 5.509 Certificate Authorities (CAs) [42] — which currently play a central role in securing SSL/TLS connections and thus transactions on the World Wide Web — has boosted the idea of reinforcing or even replacing these intermediaries.1. 59 .

60 . Bob’s slander has a higher chance of being visible to Alice. as users can freely determine their trust anchors and site operators can choose to be certified by a multitude of trust anchors. Automated Name Shortening and Security It is important that mappings that are created from automatic name shortening are placed into the special shorten zone. but shortening would usually automatically sanitize the name.gads” from those he managed manually. In fact. as the domain names then precisely correspond to trust chains in the web of trust.2. Using the shorten zone limits this attack as the user can easily distinguish names ending in “. or establish direct relationships with individual users. and thus creates a larger incentive to pick a unique pseudonym. This link is clearly not flattering for Dave. equivalent to registering a slanderous name in DNS and pointing it to some victim’s server). Bob can no longer sever the link. Furthermore. if name shortening is disabled. In terms of trust relationships. if Dave failed to pick a sufficiently unique pseudonym. they were only used as a default suggestion when manually adding name mappings using public keys. 5. GADS resembles the PGP web of trust [55]. Name shortening not only generates more memorable names but also improves censorship resistance.gads”. Discussion It is conceivable that businesses might try to operate as trust anchors by offering a GADS zone with certain identity “guarantees” for their subdomains. In this context. Alice’s proxy would initially see “www.freak.2. Once Alice’s record is added to Dave’s zone.gads” and translate it to “www. GADS provides maximum trust agility [37]. the user always receives rather explicit information about the trust graph. the scope of a trust anchor is its subdomain and is thus limited and well-defined. users that pick names for their pseudonyms which are too common are not only punished with long delegation chains for their names. This restriction is particularly important as GADS supports internationalized domain names and thus the homograph attack [20] might be used to create names that look identical to those known to the user. suppose Alice obtains a link to Dave’s website from Bob. If this was not the case. Name shortening also reinforces a user’s incentive to pick a good pseudonym as a good pseudonym will dramatically increase the chance to appear under the same petname in all delegations. an adversary might set his pseudonym to “bank” and automated shortening might then import this pseudonym into the zone of a user under “www. however. resulting in Dave caching her information virtually indefinitely.shorten.freak.+” as a link from “bob. who likes to refer to Dave as “freak” in his zone (this is a slander attack. they may also appear by default under names they would not choose for themselves.gads”. Automatic assignment of names via name shortening is a much stronger method to establish a name. When we introduced “PSEU” records in Section 3.5.1. Alice can give her records a very long lifetime.bob. Furthermore. For example. Furthermore. enabling phishing attacks.bank.

the owner of the “2012-com.3.gads” in case “evil. We expect that various registrars with diverse registration policies will ultimately help with the bootstrapping problem by reducing the number of records users need to manually enter.gads” zone could be created to preserve a snapshot of the 2012 “. migration of websites can be facilitated using a reverse proxy that translates links in HTML pages from DNS names to GADS names depending on the name system supported by the client. the proposed solution is to use a reverse proxy to generate the appropriate output based on the capabilities of the client.4. The corresponding zone key is installed by default under the name “fcfs” in fresh GADS installations. 5. To address this issue. Naturally.com”) to populate additional built-in zones with useful information. Even if the problem of providing users an initial set of names is solved. especially when compared to DNS. This is crucial in the migration from DNS to GADS as during the transition period sites will need to work well with both name systems.engine.3.com” TLD. However. Instead. 61 .gads” would generate a link “result.+” which would first be mapped to “result. In particular. Given such archived TLDs.gads” zone key would need to be trusted. we are considering using a zone transfer from legacy TLDs (such as “.engine. For example. a “2012-com. One possible approach would be to use the “zkey. it is likely that GADS will initially be limited to a small set of administrators offering a rather small set of name data.5. In order to give early adopters an immediate way to use the system without manually importing a large number of records into their personal zone. DNS users need to be enabled to follow GADS links.shorten.search. 5. this would not result in readable links.gads” zone.com” is censored in 2013). In particular. Usability and Bootstrapping One major problem we anticipate is that bootstrapping the use of GADS will be difficult as initially few GADS zones will exist and thus introduction via zone delegation will rarely be available.eu” migration mechanism described in Section 3. a search engine at “search.4. but the decentralized nature of GADS would make it easy to switch operators. DNS-level censorship would be easily circumvented (by using “evil. For example. we have created a website where users can freely register names on a first-come-first-served basis for the “fcfs. as a result.2.gads” and then likely be shortened to “result. Usability and Bootstrapping Shortening and relative domain names work nicely with search engines and other normal “surfing” activities where users click on links.gads”. Improved Migration for Legacy Networks Clearly migration to GADS cannot happen instantly. tools are need to enable a gradual migration of services and in particular websites to GADS during a phase where some users and some links may use GADS.2012-com.

1 Host: www. Specifically. Usability Evaluation: Surfing Behavior Unlike DNS..5. we did a survey on surfing behavior. If the reverse proxy encounters this Gads header. If there is no “LEHO” record for a GADS name. However.2). or GADS-enabled browsers.html HTTP/1. This can again be done using the “LEHO” records for the given GADS names. A domain name is “new” if the user has never visited it before. visiting domains they visited before. This determines how often a GADS request can be satisfied from the local database vs. GADS requires a trust anchor to be supplied via a registrar or out-of-band mechanisms such as QR codes. it should try to translate DNS names to GADS names..com Gads: YES . 62 . if the HTTP header does NOT include a Gads header or a value indicating that GADS is not available. when users want to visit a fresh domain that is not discovered via a link. we wanted to find out how often users would typically type in a new domain name for a site. On the other hand. 5. and if the user is typing it in the name is also not easily available via some link.5. This raises the question: how often are these inconvenient methods needed in practice? To answer this question. This can be done if the local GADS zone includes “LEHO” records matching the DNS names from the website. it cannot be replaced and DNS-only users will be unable to use the link. replacing the GADS names with their “LEHO” values in the HTML.example. we wanted to know how often users visit new domains via some link vs. Furthermore. Combined.2. how often a network query (with possibly significantly higher latency) would be necessary. the DNS name can still be used. the reverse proxy needs to translate any GADS name (if there are any in the HTML) to a corresponding DNS name. can include whenever a HTTP request is transmitted to the server: GET /index. Typed in new domain names are thus the case where GADS would need to use some external mechanism to obtain the fingerprint of the zone. Discussion The capabilities of the client can be detected by looking for a special HTTP header which the GADS proxy (Section 3. If no appropriate “LEHO” record is found. these two properties essentially determine the usability of our proposed system in terms of convenience (need to use out-of-band information) and performance (need to query the network). the user’s experience when using GADS depends on high-level user behavior: following a link corresponds to traversing the delegation graph and resolution is fully automatic.

172 Unique domains visited 4.: This table presents the representative results from our surfing behavior survey for a few representative users as well as the total over all 59 users that participated in our survey so far. especially compared to timeline systems where the authors estimate that they would need to store about 190 million records and thus require between 16 GB and 300 GB of storage space [13. the number of unique domain names visited (which determines the expected size of a local GADS database) and the number of manually typed in unique domain names that were not previously visited via a link.213 (8.513 1.7%) 109 (13. and include a finite view of the history as old entries are expired. 53].0%) 22 (3.027. Table 5.1 shows this negative correlation between the size of the history (in terms of number of sites visited) and the fraction of fresh domain names typed in. User 1 2 3 4 5 ··· Total URLs visited 57. the numbers we obtained should be seen as lower bounds: if we had access to a longer history.651 22. users of various mailing lists and visitors of our website to participate in a survey. the browser history databases which were used in the survey are often incomplete as they are per-account.7%) 179 (9.313 3.3%) 61 (1.935 Fresh domains typed in 274 (6. Thus.5%) Naturally.696 5. The full table and the shell scripts can be found in Appendix E.836 840 576 ··· 107.5.8%) ··· 9.1. Table 5. As a result. it would become more likely that domain names that are currently classified as fresh and manually typed in might have been previously discovered via links. This is rather small and thus good news. We provided these volunteers with a simple shell script that would extract from the history database the number of URLs they visited.210 ··· 1. Figure 5. Users can also purge their history manually. a GADS system which would over time have access to a much longer history can be expected to do even better than the data from Table 5. we asked friends.1 summarizes the results from our survey.407 13.5. 63 .1 might suggest.608 1. The survey shows that the number of entries in a typical user’s GADS database will be at the order of tens of thousands of entries. The database includes a flag that indicates if a name was typed in. Usability Evaluation: Surfing Behavior Our method for answering these two questions exploits the fact that Firefox and Chrome keep a database with history information about the sites the user has visited. To get access to this database.

insecure (registrars) or hard to memorize (“. If an implementation is using a different DHT 64 . Each point represents the data obtained from an individual browser profile. In theory. could be problematic in terms of compatibility and consistency. Discussion 60 % of new domains manually typed User 50 40 30 20 10 0 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 # of unique domains visited Figure 5.5. Alternative GADS resolvers With GNS we have presented a GADS resolver implementation that uses the R5 N Distributed Hash Table.6.zkey” TLD) alternatives and how often we can expect users to use the desirable “. however. it remains unclear how close this upper bound is to the actual behavior.: This figure shows a (negative) correlation between the percentage. While 8% is still somewhat high. the GADS design could be implemented using other DHTs or frameworks. of new domain names typed in and the length of the available browsing history based on our user survey.gads” TLD. Furthermore. this survey thus only partially answers the question of how often users would be forced to use the inconvenient (QR codes). In terms of usability. 5. This. registrars or even the “.zkey” TLD. Other implementations need store and retrieve record data from the same database.1. In the case of GADS this database is a DHT. the survey suggests that on average (for the limited timeline available in the browser’s history) about 8% of the domain names are not obtained from following links and might thus require introduction using QR codes.

though. Another more complex option is to bridge different DHT overlays. it is not a matter of name space collision. but of split-brain name spaces. Alternative resolvers could be built on top of the existing DHT overlay. only some name-value mappings are available.5. This will inevitably influence both DHTs’ properties because assumptions made by the routing algorithms are no longer valid. GNS compatible GADS system on top of a different DHT overlay. and depending on what implementation is used. Due to the above mentioned problems it is infeasible to implement an alternative. 65 .6. Hence the alternative implementation needs to be built upon this framework as well. there needs to be at least one peer in the GNUnet network that bridges the R5 N overlay with whatever DHT the alternative implementation uses. Alternative GADS resolvers overlay. it will become incompatible to the reference implementation. Since we can assume that zone ID’s are unique. In this case. If the alternative DHT operates independent of the GNUnet R5 N overlay. Our implementation uses the DHT of the GNUnet peer-to-peer framework. The bridge will be connected to both overlays at the same time. A meta resolver could check all known GADS DHT overlays one by one. the name space is split. But this will result in high network load because of unnecessary queries and high latency in the resolution process. even beyond the DHT boundary.

Discussion 66 .5.

2. Large-scale critical infrastructure like DNS is never replaced overnight. DNS also cannot guarantee globally unique names as “trusted” DNS providers even today often change DNS results for technical. However. we will begin deployment to actual users and perform experiments to find out which usability problems arise with GADS. application and protocol designers may need to add support for context-dependent resolution of memorable names and for mapping globally unique cryptographic identifiers to memorable names. The current implementation includes all of the features described in this work. However. 67 . in addition to the proxy a browser plugin could be implemented. secure and transitive. Furthermore. The GNUnet Name System is part of GNUnet which is available to the public as free software under the GNU General Public License. Placing names in the context of each individual user eliminates ownership. GADS can be operated alongside DNS and begins to offer its advantages as soon as two parties using the system interact. Future work also includes a tighter integration of GADS with user applications to increase user acceptance. Conclusion and Future Work While DNS often provides globally unique names. there are many cases where this is not desired (i. We have demonstrated the use of delegation in a name system to achieve transitivity and are thus able to provide a censorship-resistant (secure). For GADS adaptation. as well as cryptographic identifiers which are secure and global but not memorable. except for a reverse proxy (Section 5. enabling incremental. as it needs to be understandable for the general public.3).4) and integration with e-mail systems (Section 3. usable (memorable) replacement for DNS. what is important on the modern Internet is not so much global uniqueness but transitivity. GADS is a censorship resistant name system which provides two types of names to users: nicknames which are memorable.6. For example. for name shortening and PKEY import the user could be notified by a desktop applet. reduces their scope and thus the competition for names. In the future. We have explained how deploying GADS requires only minor modifications to existing applications as the system is largely suitable as a drop-in replacement for DNS. especially from the point of view of a user. for load balancing). incentive-driven migration. The overall design is deliberately simple. legal or adversarial reasons.e.

6. Conclusion and Future Work 68 .

Appendix 69 .

.

globally unique address. Naturally. no actual authority is needed: “.gads” top level domain? The “. such as email. as names in the “. The “. Frequently Asked Questions This FAQ answers various questions related to the GNU Alternative Domain System. Given this. a fully decentralized and censorship-resistant replacement for DNS. What is the “.A. A record in the “. which may require a secure.zkey and a lookup for this name would return a delegation to the zone of the respective public key.gads” top level domain? Each individual GADS user will run his own personal “. Who runs the “.gads” as a TLD is really just a trick to combine the existing DNS hierarchy with the GADS graph as it is seen from an individual user’s point of view. they are still presented here to make the answers easier to find.zkey” TLD are hashes over public keys. for each user. his own zone is authoritative for the “. The “.zkey” lookups never involve any network operation but rather only consist of a trivial conversion from ASCII to binary. All GADS names have this TLD. To be more specific. The ". Some of the questions are explicitly or indirectly answered in this thesis.gads” top level domain (TLD) is the root of each user’s personal name space. we expect that “.zkey” anyway. the “.zkey” names will be hidden from the user by mapping them to memorable names in the “. remarks or design suggestions we got from reviewers on a previous draft of a GADS paper.zkey” TLD is essentially a very simple mapping mechanism where only public key ’PKEY’ records are stored — each name is mapped to the corresponding PKEY value (which is again the name). users that need secure and globally unique names could use “. As hash codes are used for the names.zkey” top level domain (TLD) provides a (reverse) mapping from globally unique hashes to public key. These questions are based on actual questions. Who runs the “.zkey” TLD is not memorable (but globally unique and secure).gads” TLD in most applications.zkey” TLD would look like HEK9TEBUQ5AT5V3FLL0HHNDA12HGH6BIM04TN7RDVOQ5B7TIEU80.zkey” TLD is expected to be used internally by some protocols. What is the “.zkey” top level domain? The “.zkey” TLD. no authority is needed. The use of “.zkey" TLD is really 71 . This should be seen as similar to users typing in IP addresses instead of hostnames.zkey” TLD? Nobody runs the “. However.gads” TLD.gads” top level domain (TLD).

org”. except that GADS uses cryptographic keys to establish the delegation instead of delegating to an IP address.gnu. • The Shorten zone. which is supposed to be used for private records which the user does not want to make public (like secretserver. In GADS. you control personal “. 72 . you may delegate “bob. Records in each user’s master zone control under which names the Shorten and Private zones appear in the “.gads” top-level domain. Then. In DNS. Records in a GADS zone. the “www” name will be resolved in Bob’s master zone (which is most likely managed by a user called ’bob’). not by the GADS protocol. • The Private zone. which is called your master zone. subdomains (names with additional dots) may or may not belong to the same zone. Whenever multiple dots come into play in GADS. Frequently Asked Questions only a way for users to explicitly say that they want to access the zone of a given public key (hash). This is equivalent to delegation with NS records in DNS. each user in GADS is given control over three zones with different purposes.org” zone and thus all names ending with “. By default.”).gads”. In other words.private.gads is resolved by first looking in the user’s master zone for a PKEY (or NS) record under the name of “bob”. Example: A domain name like www. However.gads” to your friend Bob.gads” TLD of the respective user. these purposes and functions are established by conventions and the user interface. you are responsible for and have complete authority over all names in the zone “. if “bob” is a PKEY record in that master zone. For example. consist only of a single label. The three zones are: • The master zone. you would typically add records for all of your hosts and services either under “+” (which is used to represent the empty name) or under a simple service name without dots (“.A. by using delegation you can declare that some other user is responsible for any subdomain in your “.bob. by design. which should be used mostly for records that the owner wants to make available to other users. For example.gads). What is a zone in GADS? A zone in GADS (like DNS) is a portion of the name space that a single entity (usually a user) is responsible for.gads” zone. and the delegation via NS records is “invisible” to the (normal) user. GNU is responsible for the “gnu. however. In GADS. delegation to another zone is in play. which can populated internally by your local GADS resolver to keep GADS names short.

a QR reader that de- 73 . Very useful if you don’t want to ’accidently’ make some records public for privacy reasons (bank. MX. for the configuration and management of the zones.gads) is controlled directly by you. AAAA.private. CNAME.gads) Shorten zone The Shorten zone is populated internally by the GADS resolver to keep GADS names short. Private zone This zone can be used by users to add private records they don’t ever want to make public. What record types are supported by GADS? With GADS you have most of the record types you know from legacy DNS plus some GADS specific record types. Do you really expect normal users to use the GADS zone editor? We expect that the GADS 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. • A. each user controls three zones: Master zone This zone is your personal . as they also do not host services. we expect that automatic name shortening will populate their shorten zone. For normal users. PTR. and that they will import names from the shorten zone into their private or global zones using either (1) little helper programs integrated into their desktop or browser or (2) QR code readers which detect QR codes that were generated by service administrators and distributed using promotional materials.What are the different zones in GADS for? In GADS. Normal users should have no real need for the GADS zone editor. Thus. The GADS proxy uses this zone to shorten long GADS names on HTML web pages. NS. Any record mapped directly into this zone (www. Those QR codes include a URI which when passed to ’gads-uri’ will automatically update the user’s global zone (unless the name is already taken). used for SSL validation or virtual hosting. SRV • PKEY: the hash over a public key • PSEU: the desired pseudonym the user picked for his zone • LEHO: a legacy hostname. TXT.gads Top-Level-Domain zone. Usually found in combination with a corresponding A/AAAA records under the same name • REV: record for zone revocation Is there a graphical user interface? Yes.

A. Based on our user study where we looked at browser histories and the number of domains visited. Now. Ultimately. if the owner of the private key for a zone is unavailable for enforcement. Naturally. we don’t have code for convenient replication). small enough to fit even on mobile devices. we expect that normal users will have their database on their local PC whereas expert users might have it on a router or “in the cloud”. we expect that GADS databases will only grow to a few tens of thousands of entries. in which case the database could be kept at each peer (however. So if everyone used GADS. What is the expected average size of a GADS namestore database? Pretty small. Sybil and eclipse attacks).e. the only practical attack of a government would be to force the operator of a server to change the GADS records for his server to point elsewhere. for which various replication options are again applicable. However. 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). Where is the per-user GADS database kept? The short answer is that the database is kept at the user’s peer. a user may run multiple peers. the respective zone cannot be changed and any other zone delegating to this zone will achieve proper resolution. multiple peers can share one instance of the database — the namestore service can be accessed from remote (via TCP). however. Frequently Asked Questions tects a ’gads://’-URI can easily be used for adding delegations (PKEY records) to the global zone. The actual data can be stored in a Postgres database. but simple removal is obviously way simpler than expecting users to perform the full functionality of DNS/GADS record management that system administrators might require. 74 . Is GADS resistant to attacks on DNS used by the US? We believe so. Naturally. GADS uses a pretty robust DHT so we expect that the attacker would need to be quite resourceful to have a significant impact. normal users may choose to use the GADS zone editor to remove names. there are various attacks on the P2P network (a government might be able to filter all P2P traffic) and the DHT itself (i. Similarly. there are many options for how users can store (and secure) their GADS database. which in addition to shortening is the only relevant operation for normal users. However.

resolution would not fail if the target name server is forced to change IP addresses. 75 . delegation is not done using hard-coded IP addresses of DNS servers. GADS delegates to public keys and uses the P2P network to determine the current record information (which must be signed by the respective private key). names are primarily shared via delegation. As the social relationships evolve. IANA/ICANN are still in charge. Resolution will fail if the target name servers change IPs. Instead of using those. With CoDoNS. and there are still registrars that determine who owns a name. each user is expected to maintain a database of (second-level) domains (like “gnu. Instead. Thus. How does GADS compare to ODDNS? ODDNS is primarily designed to bypass the DNS root zone and the TLD registries (such as those for “. With GADS.com” and “. Furthermore since GADS supports DNS delegations using so called NS records as well it is a simple matter of adding appropriate records to your zone to emulate ODDNSs behaviour. and thus mappings will only change if the user responsible for the name (the authority) manually changes the record. GADS also has many additional features (to keep names short and enable migration) which don’t even make sense in the context of CoDoNS. with SocialDNS the mappings are shared through the social network and subjected to ranking.What is the difference between GADS and CoDoNS? CoDoNS decentralizes the DNS database (using a DHT) but preserves the authority structure of DNS.org”).org”) and the IP addresses of the respective name servers. SocialDNS allows each user to create DNS mappings. What is the difference between GADS and SocialDNS? Like GADS. With GADS. With GADS. names can thus change in surprising ways. 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. However.

it will be completely ignored — we hope that users will think harder about this choice. The key of this authority is included with every GADS installation. we have implemented a first-come-first-served (FCFS) authority which allows arbitrary users to register arbitrary names. so there cannot be a “legitimate” domain owner. the security of these names depends entirely on the trustworthiness of the FCFS authority. We expect that users will use direct trust relationships for critical activities (such as banking and political resistance) and rely on semi-reliable third parties for entertainment and other uncritical functions. Why do you only allow one pseudonym (PSEU record) per user in GADS? The basic idea behind the question is that one should allow users to suggest multiple pseudonyms (possibly with a ranking). for applications where this is not required. Such authorities allow each user to register a pseudonym on a first-come first-served basis. users have complete freedom in selecting such authorities (and their names). Similarly. Essentially. weaker mechanisms can be used. if you have one and only choice — and if your choice is not good. How can a legitimate domain owner tell other people to not use his name in GADS? Names have no owners in GADS. it is much more inherently obvious which names a given GADS authority is allowed to assure: only its subdomains. they might just be convenient at times.A. our rationale behind the design decision to only allow one pseudonym is that we want to maximize the incentive to users to pick a really good pseudonym. we freely admit that we have no hard data to confirm that this design decision is correct.509. If the authority is not compromised and trustworthy (which it may not be!). 76 . Finally. all other users can choose to ignore this preference and use a name of their choice (or even assign no name) for this user. Any user can claim any name (as his preferred name or ’pseudonym’) in his PSEU record. The analogous situation is that making users create one good password is better than getting a dozen bad passwords. Users can choose to delegate a subdomain (such as fcfs. However. naming authorities in GADS provide high trust agility (unlike DNS). For example. And unlike trusted certificate authorities on X. Frequently Asked Questions Does GADS require real-world introduction (secure PKEY exchange) in the style of the PGP web of trust? For security. In contrast to DNS. GADS can be used entirely without such authorities. However. those names would then “never” change. However. However. and if one of the names is already taken (for shortening) GADS should use one of the alternative names. any name registered with FCFS is in fact global and requires no further introduction. While this would seem to decrease the chances of unresolvable naming conflicts. there can be many such authorities in GADS (which users can call by any name they wish and change at any time) and obviously authorities can have policies other than FCFS. An exception are the ’first-come first-served’ authorities. As a result. Thus.gads) to such authorities. it is well known that an initial trust path between the two parties must exist.

shorten. Records are shared with other users (via DHT or zone transfers) only if this flag is not set. How do you handle compromised zone keys in GADS? The owner of a private key can create a REVocation record in his zone file (under the name “+”).gads’) — it just won’t happen automatically. even though I’m unlikely to be the bank of the other user. GADS mitigates this problem by placing all shortened records into the shorten zone. In particular. 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”. As trust relationships evolve. via name shortening) are always marked ’private’ by default. GADS should work with today’s networks. shortening can be disabled. However. and (b) that LEHOs are only useful in the context of virtual hosting. However. However. If this is done for the ’ai’ zone. yes. Otherwise. we’re not sure that virtual hosting would disappear. we don’t want to have to wait for IPv6 to become commonplace. Thus. Furthermore. Why does GADS not use a trust metric or consensus to determine globally unique names? Trust metrics have the fundamental problem that they have thresholds.gads. mappings would change their meaning as they cross each others thresholds. this is not required and records with the “private” flag in the global or shorten zone also would not be available to other users.gads’. Also.gads. so the name will occur as bank. If you believe that this is insufficient. Finally. GADS will not apply shortening. other users can still manually give the ’ai’ zone any name they wish (for example.509 certificate validation (as they specify for which legacy hostname the certificate should be valid). all peers will consider all records in this zone 77 . other users might indeed be able to obtain sensitive private information about one’s online behavior.gads)? If the PSEU record is left out. Did you consider the privacy implications of making your personal GADS zone visible? Each record in GADS has a flag “private”.What can I do if name shortening is not desired for a particular zone (such as ai.short. users have full control over what information about their zones is made public. LEHOs are also useful to help with X. Are “Legacy Host” (LEHO) records not going to be obsolete with IPv6? The question presumes that (a) virtual hosting is only necessary because of IPv4 address scarcity. In GADS. Once such a record exists. Note that while we encourage users to put their ’private’ records into the special “private zone”. then a delegation from the ’mit’ zone to the ’ai’ zone will never be shortened to ’ai. This hopefully will give most users a strong visual hint. records that GADS automatically adds (i. We decided that the resulting unpredictability of the resolution process was not acceptable.e.mit. even with IPv6 fully deployed and “infinite” IP addresses being available. This can be done in the GADS zone editor by leaving the pseudonym blank. trust and consensus might be easy to manipulate by adversaries. ’ki-mit. does shortening to pseudonyms picked by other users facilitate phishing attacks? To a limited degree. not bank.

Why are you intercepting DNS queries instead of running a DNS resolver? Our system allows running a DNS resolver instead of using the interception approach. all we would probably need is a new block type and an additional record type. as GADS records are stored (and replicated) in the R5 N DHT. complex key management operations with online and offline keys are not going to help here. e. we feel that especially the first design and implementation should not be burdened by possibly unnecessary complexity.g. Does GADS require a zone’s signing keys to be online? Right now. The reason is that if a relative expiration time is given for a records (i.e. 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. (3) given that it is not clear to what extend this is needed. (2) we would like the first implementation to be usable. the simple answer is yes. one that we use for signing online for a limited period of time and a second one that persists for a long time (or forever) which is only used to periodically sign the online signing key and otherwise kept offline. In the future. All names that involve delegation (PKEY) via a revoked zone will then fail to resolve. Another variation would be to pre-generate signatures for all records periodically (i. To introduce signing keys. First. the owner of the zone can simply run multiple peers (and share the zone’s key and database among them). deployed GADS implementations would have to be updated to support the new signature scheme. Peers always automatically check for the existence of REV records when resolving names. key loss is likely only critical for entities such as banks where there are financial risks and where there are significant costs to securely provide their users with their new key. However. should having multiple servers for a zone be considered truly necessary. We have currently implemented neither scheme as (1) GADS signing keys are likely not all that valuable — most normal users can easily create a new one with little loss. Could the signing algorithm of GADS be upgraded in the future? Yes. in order to run a personal zone. How can a GADS zone maintain several name servers. Naturally. so forward-compatibility is not expected to be a major roadblock should separate keys be required in the future.e. for the next week) and then take the signing key offline again. two variations of this scheme are conceivable. we could have two keys. we would need to run a DNS 78 . Frequently Asked Questions to be invalid. The simplest implementation for this uses a signing key that is directly available to the resolver. 1 week from now). Thus the authority will typically not be contacted whenever clients perform a lookup. the DHT will cache the records for some time. Even if the authority goes (temporarily) off-line. for load balancing? We don’t expect this to be necessary.A. However. each time a request for that name is received. a signature is created with an absolute expiration time of 1 week into the future.

This would be fine if the browser actually accessed “alice.gnu. this does not fundamentally change with GADS. At the surface. The same-origin policy (SOP) of a browser tries to ensure that information (Cookies and JavaScript in particular) obtained from one site (i.org. Example: “alice.iana. so SOP for “.gads’ are the same origin. some websites include resources (such as JavaScript or CSS files) using absolute host names in the HTML. Finally.org”).com/resources.gads”. “fsf.uk” are not related. However. 79 .gnu.gads” can simply assume that only names under “.org”.gnu. Does translating names in GADS break browser’s same-origin policy? The usual mapping of names in GADS is unproblematic as the browser either does not really see it (with the GADS proxy) or does it itself (in which case policy code would just have to be adjusted). the browser would just have to check that “alice. to achieve something like gnu.gads’ or “bob. For example. but as the browser now sees “alice.org”) does not interfere with information from another site (i. “gnu. SOP already has rules to deal with special cases to deal with the fact that entities below “co. Note that the firewall-based DNS interception suffers from the same problem.gads” does not interfere with ’dave.gads” are related if they match exactly. if GADS delegates to DNS via an NS record. Existing websites can create two additional problems. The GADS proxy solves this problem by detecting that “alice.com” is the LEHO value of ’alice. First. here. falling back to DNS names for embedded documents can create problems.bob.gads” might serve a website which includes resources from http: //alice. as most operating systems only allow one DNS server to be configured per host). A better solution would have been for Alice to include a relative link to “/resources”. which would have worked with DNS and GADS. browsers that fully support GADS would see that “www.gads” are both names under the same GADS authority (same public key) and can thus decide that they are the same origin. “www.gads being an alias for gnu.gads”.e.org” might set a cookie for “*.e. A second problem is that sometimes websites set cookies for entire subdomains.gnu.gads’ and then transforms the link. clearly not all subdomains under ’iana. the browser can and should probably assume that the resulting subdomain is a different authority. With GADS and the SOP described above. there are issues in particular cases which the GADS proxy needs to handle.bob. However.org).server for each user. This is in fact a cleaner way to determine that two names belong to the same authority than the heuristics used with the current DNS system.com”. this would not be allowed. But this is more of a theoretical problem when it comes to integrating with legacy DNS. This would only cause problems if GADS records perform NS delegation to DNS TLDs or even IANA (for example. not just for each host (which is at least a theoretical problem on multi-user systems.gads” and “lists.

org”. For further details. Protocols like SMTP will require some work in the software stack (which can again often be done using proxies) to translate GADS names in the appropriate places. the GADS proxy needs to essentially check if all of the domains the cookie is to be set for fall under the same origin. gnu. Some other protocols — such as most P2P protocols — do not really use DNS and would thus not be affected by a DNS-GADS transition.gads).gnu.gads” the GADS proxy can translate cookies to “alice. Similarly.org” to the domain name the browser expects (i. Frequently Asked Questions Will GADS work with cookies? GADS should work fine with cookies in most cases. We have not yet encountered a protocol that absolutely cannot be migrated. In GADS. the same origin is easily determined as all records (that are not NS or PKEY records) signed by the same public key can be assumed to belong to the same authority.gnu. The GADS proxy translates cookies set by the browser for “gnu.org” setting a cookie for “*. see the FAQ entry on GADS and the same origin policy. How will existing network protocols cope with a transition from DNS to GADS? This depends of course largely on the protocol. Here. The problematic case is webservers setting cookies for entire subdomains. but if you have a specific concern we would like to hear from you.A. 80 . if the webserver believes it is “alice. For example “www. 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.gads”.bob.e.

-L LOGLEVEL. "AAAA".e.-add: Desired operation is adding a record -c FILENAME. . . "h" (hours). . -d.-display: Desired operation is listing of matching records -e TIME. "s".1. "A". "MX" etc. gnunet-namestore (1) B. -h. Supported units are "ms". if no expiration is given FOREVER is used 81 .manipulate GNS zones B. "d" (days) and "a" (years).1. . Valid values are DEBUG.-uri=URI: Add PKEY record from gnunet://gns/-URI to our zone. Description gnunet-namestore can be used to create and manipulate a GNS zone.4. . .-expiration=TIME: Specifies expiration time of record to add.1. Command-Line Tool Reference B.-delete: Desired operation is deleting a record -D. . . .3.) -u URI.-name=NAME: Name of the record to add/delete/display -t TYPE.B.1. "PKEY". i.-config=FILENAME Use the configuration file FILENAME.-loglevel=LOGLEVEL: Use LOGLEVEL for logging.-type=TYPE: Type of the record to add/delete/display (i.e "1 h" or "7 d 30 m". . Options -a. "NS".-help: Print short help on options. the record type is always PKEY.1. WARNING and ERROR -n NAME.2. format is relative time. INFO. Name gnunet-namestore . B.1. Synopsis gnunet-namestore [options] B. "min" or "minutes".

Access to GNUnet Name Service B.2. B. . . -r.2. -z FILENAME. A records expect a dotted decimal IPv4 address.-version: Print GNUnet version number. See Also gnunet-gns(1) B.org/bugs/> or by sending electronic mail to <gnunet-developers@gnu.gads".-zonekey=FILENAME: Specifies the filename with the private key for the zone (mandatory option) B. AAAA records an IPv6 address. For example the authority for "www.5. -V VALUE.4.2. and CNAME and NS records should be a domain name.6.-config=FILENAME Use the configuration file FILENAME.1. Specific format depends on the record type. Command-Line Tool Reference -v.-authority=NAME Get the authority of a particular name. .-value=VALUE: Value to store or remove from the GNS zone.2. . Name gnunet-gns . gnunet-gns (1) B. Synopsis gnunet-gns [options] B. 82 .-raw No unneeded output.fcfs.B.2.org> B. . Bugs Report bugs by using Mantis <https://gnunet. no descriptive text. Description gnunet-gns can be used to lookup and process GNUnet Name Service names. This is a quiet mode where only important information is displayed.1.3. -c FILENAME.gads" is "fcfs. For example a lookup for an IP address will only yield the IP address.2. .1. PKEY a public key in GNUnet’s printable format. Options -a NAME.

PSEU. SRV. -L LOGLEVEL. B. .-shorten NAME Shorten GNUnet Name Service Name.-type=RRTYPE Resource Record Type (RRTYPE) to look for. .org> B. Valid values are DEBUG. TLSA.org/bugs/> or by sending electronic mail to <gnunet-developers@gnu. -h. gnunet-gns (1) -s NAME. Supported RRTYPE’s are: A.B.6.-lookup=NAME Name to lookup. PTR. MX. Bugs Report bugs by using Mantis <https://gnunet. -v. TXT Defaults to "A". PKEY.-loglevel=LOGLEVEL Use LOGLEVEL for logging. LEHO.-version Print GNUnet version number. Resolve the specified name using the GNUnet Name System.2. . -u NAME. WARNING and ERROR. .2. REV. . NS. See Also gnunet-namestore(1) 83 .5. -t RRTYPE. CNAME.2.-help Print short help on options. AAAA. VPN. INFO. SOA. . The service will try to shorten the delegation chain of the name if a "closer" authority chain exists relative to your local root zone.

Command-Line Tool Reference 84 .B.

1.1. void GNUNET_GNS_cancel_get_auth_request ( struct GNUNET_GNS_GetAuthRequest ∗ gar ) Cancel pending get auth request Parameters gar the lookup request to cancel C.1.C.1.1. Function Documentation C. struct GNUNET_GNS_Handle∗ GNUNET_GNS_connect ( const struct GNUNET_CONFIGURATION_Handle ∗ cfg ) Initialize the connection with the GNS service.4.3. 85 .2. void GNUNET_GNS_cancel_shorten_request ( struct GNUNET_GNS_ShortenRequest ∗ sr ) Cancel pending shorten request Parameters sr the lookup request to cancel C.1. GNUnet Name System API C. void GNUNET_GNS_cancel_lookup_request ( struct GNUNET_GNS_LookupRequest ∗ lr ) Cancel pending lookup request Parameters lr the lookup request to cancel C.

or NULL on error C. void ∗ proc_cls ) Perform an authority lookup for a given name. const char ∗ name. struct GNUNET_GNS_GetAuthRequest∗ GNUNET_GNS_get_authority ( struct GNUNET_GNS_Handle ∗ handle. int only_cached. Parameters handle connection to shut down C. void ∗ proc_cls ) Perform an asynchronous lookup operation on the GNS in the default zone.5. GNUNET_GNS_GetAuthResultProcessor proc. struct GNUNET_CRYPTO_RsaPrivateKey ∗ shorten_key. const char ∗ name. Parameters handle name proc proc_cls Returns handle to the operation handle to the GNS service the name to look up authority for function to call on result closure for processor C. void GNUNET_GNS_disconnect ( struct GNUNET_GNS_Handle ∗ handle ) Shutdown connection with the GNS service.C.1.6.7. struct GNUNET_GNS_LookupRequest∗ GNUNET_GNS_lookup ( struct GNUNET_GNS_Handle ∗ handle. Parameters handle handle to the GNS service name the name to look up type the GNUNET_GNS_RecordType to look for 86 .1. enum GNUNET_GNS_RecordType type. GNUnet Name System API Parameters cfg configuration to use Returns handle to the GNS service. GNUNET_GNS_LookupResultProcessor proc.1.

int only_cached. const char ∗ name.8.1. const char ∗ name.9.1. Function Documentation only_cached shorten_key proc proc_cls Returns GNUNET_NO to only check locally not DHT for performance the private key of the shorten zone (can be NULL) function to call on result closure for processor handle to the queued request C. void ∗ proc_cls ) Perform an asynchronous lookup operation on the GNS in the zone specified by ’zone’. struct GNUNET_GNS_ShortenRequest∗ GNUNET_GNS_shorten ( struct GNUNET_GNS_Handle ∗ handle.C. enum GNUNET_GNS_RecordType type. Parameters handle name zone type only_cached shorten_key proc proc_cls Returns handle to the queued request handle to the GNS service the name to look up the zone to start the resolution in the GNUNET_GNS_RecordType to look for GNUNET_YES to only check locally not DHT for performance the private key of the shorten zone (can be NULL) function to call on result closure for processor C. struct GNUNET_CRYPTO_RsaPrivateKey ∗ shorten_key.1. struct GNUNET_CRYPTO_ShortHashCode ∗ shorten_zone. GNUNET_GNS_LookupResultProcessor proc. struct GNUNET_GNS_LookupRequest∗ GNUNET_GNS_lookup_zone ( struct GNUNET_GNS_Handle ∗ handle. struct GNUNET_CRYPTO_ShortHashCode ∗ zone. GNUNET_GNS_ShortenResultProcessor proc. void ∗ proc_cls ) Perform a name shortening operation on the GNS. Parameters handle handle to the GNS service name the name to look up 87 . struct GNUNET_CRYPTO_ShortHashCode ∗ private_zone.

C. Parameters handle name private_zone shorten_zone zone proc proc_cls Returns handle to the operation handle to the GNS service the name to look up the public zone of the private zone the public zone of the shorten zone the zone to start the resolution in function to call on result closure for processor 88 . struct GNUNET_CRYPTO_ShortHashCode ∗ zone. void ∗ proc_cls ) Perform a name shortening operation on the GNS. struct GNUNET_CRYPTO_ShortHashCode ∗ private_zone. GNUNET_GNS_ShortenResultProcessor proc. struct GNUNET_CRYPTO_ShortHashCode ∗ shorten_zone. const char ∗ name. GNUnet Name System API private_zone shorten_zone proc proc_cls Returns the public zone of the private zone the public zone of the shorten zone function to call on result closure for processor handle to the operation C.10.1. struct GNUNET_GNS_ShortenRequest∗ GNUNET_GNS_shorten_zone ( struct GNUNET_GNS_Handle ∗ handle.

Record Types Record Name ANY A NS CNAME SOA PTR MX TXT AAAA SRV TLSA PKEY PSEU LEHO VPN REV Record Number 0 1 2 5 6 12 15 16 28 33 52 65536 65537 65538 65539 65540 89 .1. GADS Record Types and Flags D.D.

This record was added by the system and is pending user confimation This expiration time of the record is a relative time (not an absolute time).D. PRIVATE 2 PENDING RELATIVE_EXPIRATION SHADOW_RECORD 4 8 16 90 . This record should not be used unless all (other) records with an absolute expiration time have expired. GADS Record Types and Flags D. it must thus not be deleted (other records can be deleted if we run out of space). Record Flags Record Flag NONE AUTHORITY Flag Number 0 1 Usage No special options This peer is the authority for this record.2. This is a private record of this peer and it should thus not be handed out to other peers.

Browsing Survey E. * / / " | grep −v \\\ h l i n e \[ | s o r t | uniq | wc −l ‘ echo " You followed $LINKS_FOLLOWED l i n k s and typed i n $LINKS_TYPED " echo " You followed $LINKS_FOLLOWED l i n k s t o $DOMAINS_FOLLOWED_UNIQUE unique domains " echo " You typed i n $LINKS_TYPED l i n k s t o $DOMAINS_TYPED_UNIQUE unique domains " echo " " echo " P l e a s e stand by . " DOMAINS_TYPED= ‘ echo " s e l e c t id . The ’ H i s t o r y ’ f i l e # i s usually in # Chromium on l i n u x : ~ / .1. * // " −e " s / : . E. * / / " | grep −v \\\ h l i n e \[ | s o r t | uniq ‘ PRIOR=0 CNT=0 SEENTMP= ‘mktemp /tmp/seenXXXXXX ‘ f o r n i n $DOMAINS_TYPED 91 . c o n f i g / chromium / D e f a u l t / # G o o g l e Chrome : ~ / . " | s q l i t e 3 " $1 " | sed −e " s/ h t t p s :\/\/// " −e " s/ h t t p :\/\/// " −e " s /\/. * / / " | grep −v \\\ h l i n e \[ | s o r t | uniq | wc −l ‘ DOMAINS_TYPED_UNIQUE= ‘ echo " s e l e c t u r l from u r l s where typed_count > 0 .E. t h i s w i l l t a k e a moment . c o n f i g / g o o g l e −chrome / D e f a u l t / # LINKS_FOLLOWED= ‘ echo " s e l e c t count ( * ) from u r l s where typed_count = 0 . " | s q l i t e 3 " $1 " ‘ LINKS_TYPED= ‘ echo " s e l e c t count ( * ) from u r l s where typed_count > 0 . " | s q l i t e 3 " $1 " | sed −e " s/ h t t p s :\/\/// " −e " s/ h t t p :\/\/// " −e " s /\/. . * // " −e " s / : . Scripts This is a listing of the scripts we used in our user survey. .1. u r l from u r l s where typed_count > 0 . # You n e e d t o h a v e ’ s q l i t e 3 ’ i n s t a l l e d . The scripts crawl the local history databases of Firefox and Chrome browsers respectively. * // " −e " s / : . " | s q l i t e 3 " $1 " ‘ DOMAINS_FOLLOWED_UNIQUE= ‘ echo " s e l e c t u r l from u r l s where typed_count = 0 . Chromium and Chrome 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 # ! / bin / sh # P l e a s e run t h i s s h e l l s c r i p t u s i n g " H i s t o r y " a s t h e argument .1. " | s q l i t e 3 " $1 " | sed −e " s/ h t t p s :\/\/// " −e " s/ h t t p :\/\/// " −e " s /\/.

2. m o z i l l a / f i r e f o x /RANDOMDIRNAME/ p l a c e s . " | s q l i t e 3 " $1 " ‘ LINKS_TYPED= ‘ echo " s e l e c t count ( * ) from moz_places where typed = 1 . s q l i t e ’ f i l e # i s u s u a l l y i n ~ / .E. Firefox 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 # ! / bin / sh # P l e a s e run t h i s s h e l l s c r i p t u s i n g " p l a c e s . s q l i t e # LINKS_FOLLOWED= ‘ echo " s e l e c t count ( * ) from moz_places where typed = 0 . * / / " | grep −v \\\ h l i n e \[ | s o r t | uniq | wc −l ‘ DOMAINS_TYPED_UNIQUE= ‘ echo " s e l e c t u r l from moz_places where typed = 1 . $PRIOR had been v i s i t e d p r e v i o u s l y ( by ID ) v i a l i n k s " echo "Summary : $LINKS_FOLLOWED $LINKS_TYPED $DOMAINS_FOLLOWED_UNIQUE $DOMAINS_TYPED_UNIQUE $PRIOR " echo " " echo " P l e a s e e−mail t h e output t o gns−data@gnunet . * // " −e " s / : . * // " −e " s / : . Browsing Survey 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 do ID = ‘ echo $n | sed −e " s /|. * // " −e " s / : . * // " ‘ DOM= ‘ echo $n | sed −e " s /. org " E. * / / " | s o r t | grep $DOM | head −n 1 | wc −l ‘ PRIOR= ‘ expr $PRIOR + $DOMAINS_PRIOR‘ fi done # rm $SEENTMP echo " " echo " Of $CNT domains typed in . " | s q l i t e 3 " $1 " | sed −e " s/ h t t p s :\/\/// " −e " s/ h t t p :\/\/// " −e " s /\/. " | s q l i t e 3 " $1 " | sed −e " s/ h t t p s :\/\/// " −e " s/ h t t p :\/\/// " −e " s /\/. s q l i t e " a s t h e argument . " | s q l i t e 3 " $1 " | sed −e " s/ h t t p s :\/\/// " −e " s/ h t t p :\/\/// " −e " s /\/. " | s q l i t e 3 " $1 " ‘ DOMAINS_FOLLOWED_UNIQUE= ‘ echo " s e l e c t u r l from moz_places where typed = 0 . # You n e e d t o h a v e ’ s q l i t e 3 ’ i n s t a l l e d . The ’ p l a c e s . * / / " | grep −v \\\ h l i n e \[ | s o r t | uniq | wc −l ‘ echo " You followed $LINKS_FOLLOWED l i n k s and typed i n $LINKS_TYPED " echo " You followed $LINKS_FOLLOWED l i n k s t o $DOMAINS_FOLLOWED_UNIQUE unique domains " echo " You typed i n $LINKS_TYPED l i n k s t o 92 . * |// " ‘ i f ! grep " ^$DOM\$ " $SEENTMP > /dev/ n u l l then CNT= ‘ expr $CNT + 1 ‘ echo "$DOM" >> $SEENTMP DOMAINS_PRIOR= ‘ echo " s e l e c t u r l from u r l s where typed_count =0 AND id < $ID .1.

* // " −e " s / : .E. . " | s q l i t e 3 " $1 " | sed −e " s/ h t t p s :\/\/// " −e " s/ h t t p :\/\/// " −e " s /\/. org " 93 . $PRIOR had been v i s i t e d p r e v i o u s l y ( by ID ) v i a l i n k s " echo "Summary : $LINKS_FOLLOWED $LINKS_TYPED $DOMAINS_FOLLOWED_UNIQUE $DOMAINS_TYPED_UNIQUE $PRIOR " echo " " echo " P l e a s e e−mail t h e output t o gns−data@gnunet . Scripts 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 $DOMAINS_TYPED_UNIQUE unique domains " echo " " echo " P l e a s e stand by . * |// " ‘ i f ! grep " ^$DOM\$ " $SEENTMP > /dev/ n u l l then CNT= ‘ expr $CNT + 1 ‘ echo "$DOM" >> $SEENTMP DOMAINS_PRIOR= ‘ echo " s e l e c t u r l from moz_places where typed =0 AND id < $ID . " | s q l i t e 3 " $1 " | sed −e " s/ h t t p s :\/\/// " −e " s/ h t t p :\/\/// " −e " s /\/. * // " ‘ DOM= ‘ echo $n | sed −e " s /. * / / " | s o r t | grep $DOM | head −n 1 | wc −l ‘ PRIOR= ‘ expr $PRIOR + $DOMAINS_PRIOR‘ fi done # rm $SEENTMP echo " " echo " Of $CNT domains typed in . * // " −e " s / : . * / / " | grep −v \\\ h l i n e \[ | s o r t | uniq ‘ PRIOR=0 CNT=0 SEENTMP= ‘mktemp /tmp/seenXXXXXX ‘ f o r n i n $DOMAINS_TYPED do ID = ‘ echo $n | sed −e " s /|. " DOMAINS_TYPED= ‘ echo " s e l e c t id . . t h i s w i l l t a k e a moment . u r l from moz_places where typed = 1 .1.

7268722467 16.4162487462 12.7619047619 17.3229813665 9.6285240464 10. Browsing Survey E.1023017903 5.7826086957 16.7494553377 6.3398058252 9.2698682533 7.477143459 4.0653594771 14.7376354216 9.91507431 15.2362204724 20.8591549296 5.9929988331 5.9705469846 8.5155709343 10.0705394191 7.8571428571 7. User Data This section consists of the data acquired in our user survey using the scripts in Appendix E.1.6153846154 9.4096385542 9.3528866218 5.8493150685 2.015037594 3.E.8194444444 6.1925601751 14.4485817986 16.8284993695 5.2877138414 12.5957446809 0 3.2702702703 6. User 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 Followed 57651 11457 94068 14114 6639 18728 13178 22407 32898 5726 2665 4485 17799 5475 5608 14854 16566 6540 35886 39415 61374 8173 44826 13696 250 1210 6259 296 1691 93 27841 11042 20692 16499 2859 2469 698 22288 627 678 4723 21133 5045 24791 Typed 1786 591 5406 363 134 230 199 208 336 206 103 157 483 89 159 208 403 181 897 585 7999 337 1540 723 8 51 84 10 57 0 712 145 207 286 143 125 18 684 9 13 114 657 310 625 UD 4313 2353 6025 1747 997 1129 1856 3513 4758 908 457 709 1714 643 840 1244 1809 782 4747 4158 7439 713 4246 1836 133 576 650 92 235 73 2100 1058 623 322 578 508 74 2701 83 71 612 1884 1030 2785 TUD 464 198 944 210 87 190 139 126 210 94 86 138 197 56 149 155 219 131 551 369 1947 172 688 309 8 38 65 9 51 0 168 123 143 85 91 88 16 346 5 8 50 407 233 487 PV TUD 190 74 518 82 33 44 66 65 123 42 12 33 60 22 40 54 81 52 291 171 649 51 317 130 0 16 22 0 12 0 87 44 34 26 36 36 1 161 3 1 19 126 75 220 FT 274 124 426 128 54 146 73 61 87 52 74 105 137 34 109 101 138 79 260 198 1298 121 371 179 8 22 43 9 39 0 81 79 109 59 55 52 15 185 2 7 31 281 158 267 Percentage 6.9331896552 1.1189710611 7.2.5870736086 94 .4669187146 17.4959871589 18.3268460218 5.9317980514 3.9761904762 8.8095909732 7.7364076288 1.

2.6279069767 10.E.3907284768 10.3705486044 57.958166068 6.3209876543 5.305785124 6.8148488679 41.1383061383 6.8947368421 31.0722891566 5.1890389198 4.5356927781 Followed Typed UD TUD PV TUD FT Number of links followed Number of domains typed Unique Domains Typed Unique Domains Previously Typed Unique Domains Freshly Typed 95 .7991631799 8.2564102564 13.4 5.2971576227 18. User Data 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 Avg 13936 4886 8712 19282 53457 17838 91471 2142 6967 8083 9213 5018 13500 51733 235 305 1027172 277 224 608 162 753 459 3043 196 235 494 160 386 1361 754 73 95 36861 1625 774 1259 1782 4733 1720 8701 302 897 1210 1287 808 2241 5195 38 239 107935 175 80 329 135 501 177 1492 147 130 263 129 89 606 483 29 85 15100 71 39 100 58 219 63 551 22 38 102 50 34 201 204 7 9 5887 104 41 229 77 282 114 941 125 92 161 79 55 405 279 22 76 9213 6.8069306931 18.

.

editors. and Paul Syverson. [15] Nathan Evans and Christian Grothoff. Frans M. In ESORICS. Jinyang Li. CA. [2] R. and S.git. Designing a dht for low latency and high throughput. 03/2004 2004. In AIMS’09 . Milan. Chung. https://datatracker. Italy. 43:183–198. Massey. Souverign key cryptography for internet domains. and Antony I. 1970. Springer. Kaashoek. 97 . resistant dht routing. 13:422–426. Space/time trade-offs in hash coding with allowable errors. Austein. Management and Security: Scalability of Networks and Services. Springer. The Netherlands. Journal of Supercomputing. Mar. American Mathematical Society. The sybil attack. M. R. K. Douceur.eff. October 2011. Springer-Verlag.Proceedings of the 1st conference on Symposium on Networked Systems Design and Implementation. ebacs: Ecrypt benchmarking of cryptographic systems. pages 251–260. [11] Roger Dingledine. Emil Sit. Tor: The second-generation onion router. August 2004. page 7–7. 2005.yp. Kaashoek. Rfc 6394: Use cases and requirements for dns-based authentication of named entities (dane). 1997. [3] R. accessed 7 March 2013.Bibliography [1] Information technology: automatic identification and data capture techniques. R5n: Randomized recursive routing for restricted-route networks. 2005. and Robert Morris. page 305–318. Larson. Rowstron. In Proceedings of the 13th USENIX Security Symposium. James Robertson. page 70–82. Springer. Springer-Verlag. 02/2008 2008. [12] John R.cr. and Olivier Festor. [4] Burton H. USENIX Association. R. 2002. DNS Security Introduction and Requirements. In Peter Druschel. Bloom. November 2011. Rose. Enschede. 2011. [14] European Parliament. Nick Mathewson. Sybil- [10] Daniel J. http://bench. December 2011. IEEE. [8] Frank Dabek. Insight into redundancy schemes in dhts. Chris Lesniewski-laas. Arends. BSI Group. In NSDI’04 . https://git.org/wg/dane/charter/. London. [13] Peter Eckersley. [7] F. [9] George Danezis. 2009. Evaluation of sybil attacks protection schemes in kad. volume 5637 of Lecture Notes in Computer Science. Resolution on the EU-US Summit of 28 November 2011. 06/2009 2009. IETF RFC 4033. Isabelle Chrisment. IPTPS. [6] Thibault Cholez. pages 316–321. org/?p=sovereign-keys. USA. In 5th International Conference on Network and System Security. Spectral Graph Theory. Frans Kaashoek. M. D.ietf. P7-RC-2011-0577. [5] Guihai Chen. volume 2429 of Lecture Notes in Computer Science. Bernstein and Tanja Lange (editors). Barnes. Frans M. USENIX Association. and Fan Wu. Tongqing Qiu. T. Communications of the ACM.to/. San Francisco.Proceedings of the 3rd International Conference on Autonomous Infrastructure. and Ross Anderson. QR code 2005 bar code symbology specification.

of the European Symposium on Algorithms (ESA. Michael J. Rfc 1928: Socks protocol version 5. 2003. Rfc 3490: Internationalizing domain names in applications (idna). http://www. USENIX Association. http://heise. Berlin. de/-1447571. Leech. and Georg Carle. Nils Kammenhuber. Technical report. [33] Y. [34] Chris Lesniewski-Laas and M. Nelson. 11th Annual Internet Measurement Conference (IMC’11). Goodrich. [18] R. [22] Stefan Götz. Technical report. Whanau: a sybil-proof distributed hash table. 2012. page 384–393.kernel. Berlin / Heidelberg. Hoffman. 2005. [32] Ben Laurie and Adam Langley. pages 98–107. [20] Evgeniy Gabrilovich and Alex Gontmakher. NSDI’10. October 2006. pages 803–814. Bitcoin: A bit too far? Journal of Internet Banking and Commerce. Rfc 4648: The base16. ACM. [29] Frans M. [30] Maxim Krasnyansky. and A. February 2002. USA. [26] Iso 3166: Country codes. In Proc. Springer. Germany.txt. volume 2735/2003 of Lecture Notes in Computer Science. June 1995. wiretapping. Communications of the ACM. Springer. Springer. and Klaus Wehrle. 2010.system databases and name service switch. CA. [28] S. [25] Ralph Holz. [27] Edwin Jacobs.Bibliography [16] P. Technical report. The SSL landscape – a thorough analysis of the X. The gnu c library . [last retrieved in April 2012]. 2005. Lee. volume 3485 of Lecture Notes in Computer Science. 2006. 16(2). and the internet. and base64 data encodings. 45(2). Simon Rieche. ACM. Bitcoin: An innovative alternative digital currency. Universal tun/tap device driver. Sun. Nov 2011. December 2011. Costello. Hastings Science & Technology Law Journal. In Proc. base32. http://www. NY. Network Working Group. 98 . Certificate transparency. [19] Free Software Foundation. ACM. Technical report.509 PKI using active and passive measurements. Technical report. Network Working Group. [24] Martin Holland. Berkeley. March 1996. 2005. Kaashoek and David Karger. March 2012. Selected DHT Algorithms. Koorde: A Simple degree-optimal distributed hash table. chapter 8. Sheridan. Daenischer Polizist sperrt versehentlich 8000 Websites. Network Working Group. IEEE Security & Privacy.org/software/libc/manual/html_node/ Name-Service-Switch. pages 95–117.org/doc/ Documentation/networking/tuntap. Jared Saia. P. Frans Kaashoek. and Maxwell Young. [21] Michael T.org/. In SODA ’06: Proceedings of the seventeenth annual ACM-SIAM symposium on Discrete algorithm. pages 111–126. certificate-transparency. The homograph attack. [17] Amos Fiat. http://www. Josefsson. International Organization for Standardization.gnu. Faltstrom. M. Koblas. Lothar Braun. 4:159–208. In Proceedings of the 7th USENIX conference on Networked systems design and implementation. August 2011. Rfc 1808: Relative uniform resource locators. Springer. The rainbow skip graph: a faulttolerant constant-degree distributed data structure. Fielding. [23] Reuben Grinberg. March 2003. Making chord robust to byzantine attacks. [31] Susan Landau. New York. Security. USA. and D. Network Working Group. pages 26–33.html. and Jonathan Z.

Why software should not have owners.txt. Network Working Group. In ICDCN’10 . [43] Satoshi Nakamoto. Network Working Group. http://blog.thoughtcrime.mozilla. DigiNotar removal follow up. Soghoian and S. git/blob/HEAD:/proposals/194-mnemonic-urls.csail. X-vine: Secure and pseudonymous routing using social networks. [39] P.Proceedings of the 4th International Workshop in Peer-to-Peer Systems. Rfc 1591: Domain name system structure and delegation. 15th. 2008. Sdsi – a simple distributed security infrastructure. Stefan Schmid. page 195–206. IEEE. In IPTPS’05 . [52] Daniel Stutzbach and Reza Rejaie. January 2010. February 2005. 2012.thoughtcrime. Squaring the triangle: Secure. and Nikita Borisov. In INFOCOM. Technical report. [45] Venugopalan Ramasubramanian and Emin Gun Sirer. Rivest and Butler Lampson. March 1994. [47] Rodrigo Rodrigues and Barbara Liskov. http://www. Portland. and Roger Wattenhofer. November 1987.org/torspec. Postel. Oregon. High availability in dhts: Erasure coding vs. In Proceedings of SIGCOMM.com/ security/2011/09/02/diginotar-removal-follow-up/ [online. [41] Paul Mockapetris.com/ marcs/petnames/IntroPetNames.html. Poisoning the kad network.aaronsw. Stamm.pdf.mit.concepts and facilities. [44] J. The design and implementation of a next generation name service for the internet. 1996.implementation and specification. Domain Names . An introduction to petname systems. Certified lies: Detecting and defeating government interception attacks against SSL. Springer-Verlag. Ssl and the future of authenticity.Proceedings of the 11th International Conference on Distributed Computing and Networking.0971. Arpil 2011. [36] M.gnu. Technical report. Mockapetris.skyhunter.pdf. November 1987. Null prefix attacks against http://www. IETF RFC 1035. [48] Alex Fink Sai. January 2011. [38] Prateek Mittal. decentralized.html.onion urls. Rfc 1034: Domain names . India. 2009. https://gitweb.org/ [51] Marc Stiegler. [49] C. Marlinspike.org/ ssl-and-the-future-of-authenticity. 2006. Springer-Verlag. http://bitcoin. In Proc. New York. Technical report. [40] Paul Mockapetris. http: //www. 99 . Kolkata.Bibliography [35] Thomas Locher. 2011. abs/1109. [42] Mozilla Security Blog. David Mysicka. Springer. replication. ICDCN’10. Matthew Caesar. Rfc 1035: Domain names . human-readable names. Improving lookup performance over a widely-deployed dht. https://blog. Bitcoin: A peer-to-peer electronic cash system. http://www. 1987. philosophy/why-free. [53] Aaron Swartz. Mnemonic . Network Working Group. Financial Cryptography and Data Security. [50] Richard Stallman. August 2004. Mar 2011. Int. Springer. 2011.com/weblog/squarezooko.torproject. last retrieved in September 2011]. 02/2005 2005. Conf. Ithaca. [37] Moxie Marlinspike.org/ bitcoin. CoRR. Nov. http://groups. volume 3640 of Lecture Notes in Computer Science.Implementation and Specification. IEEE.org/papers/null-prefix-attacks. ssl/tls certificates. February 2012.html.edu/cis/sdsi. [46] Ronald L.

org/TR/cors/. Springer Verlag. Huitema. Shortest-path routing in randomized dht-based peer-to-peer systems. Investigating the OpenPGP Web of Trust. D. Souissi. V. 52(18):3307–3317. W3c Working Draft 3. 2005. LNCS. Rfc 3596: Dns extensions to support ip version 6. Names: Decentralized.. Stefan Götz. Springer. Cross-origin resource sharing. [59] Klaus Wehrle. In 16th European Symposium on Research in Computer Security (ESORICS 2011). and K-W Chin. Jan 2006. and M. human-meaningful: Choose two. Distributed Hash Tables. Ralph Holz.w3. April 2012. [55] Alexander Ulrich. [57] T. June 2008. and Simon Rieche. Netw. van Leijenhorst. [60] Zooko Wilcox-O’Hearn. Lowe. [58] Chih-Chiang Wang and Khaled Harfoush. Ksinant. Network Working Group. In The 5th International Conference on Information Technology and Applications. C. 100 . Technical report. [56] Anne van Kersteren. chapter 7. Technical report. October 2003.html. secure.com/distnames. Comput. and Georg Carle. http://zooko. Peter Hauck. http://www.Bibliography [54] S. volume 3485 of Lecture Notes in Computer Science. September 2011. Thomson. 2008. On the viability and performance of dns tunneling.

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master Your Semester with a Special Offer from Scribd & The New York Times

Cancel anytime.