DOCSLIB.ORG

A Longitudinal, End-To-End View of the DNSSEC Ecosystem

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Longitudinal, End-To-End View of the DNSSEC Ecosystem A Longitudinal, End-to-End View of the DNSSEC Ecosystem Taejoong Chung, Northeastern University; Roland van Rijswijk-Deij, University of Twente and SURFnet bv; Balakrishnan Chandrasekaran, TU Berlin; David Choffnes, Northeastern University; Dave Levin, University of Maryland; Bruce M. Maggs, Duke University and Akamai Technologies; Alan Mislove and Christo Wilson, Northeastern University https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/chung This paper is included in the Proceedings of the 26th USENIX Security Symposium August 16–18, 2017 • Vancouver, BC, Canada ISBN 978-1-931971-40-9 Open access to the Proceedings of the 26th USENIX Security Symposium is sponsored by USENIX A Longitudinal, End-to-End View of the DNSSEC Ecosystem Taejoong Chung Roland van Rijswijk-Deij Northeastern University University of Twente and SURFnet Balakrishnan Chandrasekaran David Choffnes Dave Levin TU Berlin Northeastern University University of Maryland Bruce M. Maggs Alan Mislove Duke University and Akamai Technologies Northeastern University Christo Wilson Northeastern University Abstract To address these problems, DNS Security Extensions (DNSSEC) [20] were introduced nearly two decades ago. The Domain Name System’s Security Extensions At its core, DNSSEC is a hierarchical public key infras- (DNSSEC) allow clients and resolvers to verify that tructure (PKI) that largely mirrors the DNS hierarchy and DNS responses have not been forged or modified in- is rooted at the root DNS zone. To enable DNSSEC, the flight. DNSSEC uses a public key infrastructure (PKI) owner of a domain signs its DNS records and publishes to achieve this integrity, without which users can be sub- the signatures along with its public key; this public key is ject to a wide range of attacks. However, DNSSEC can then signed by its parent domain, and so on up to the root operate only if each of the principals in its PKI prop- DNS zone. A resolver validates a signed DNS record erly performs its management tasks: authoritative name by recursively checking the associated signatures until it servers must generate and publish their keys and signa- reaches the well-known root zone trusted key. tures correctly, child zones that support DNSSEC must Largely in response to powerful attacks such as the be correctly signed with their parent’s keys, and resolvers Kaminsky Attack [28], DNSSEC adoption has increased must actually validate the chain of signatures. recently. As of early 2017, more than 90% of top- This paper performs the first large-scale, longitudi- level domains (TLDs) and 47% of country-code TLDs nal measurement study into how well DNSSEC’s PKI is (ccTLDs) are DNSSEC-enabled [26, 47]. Widely-used managed. We use data from all DNSSEC-enabled sub- DNS resolvers now attempt DNSSEC validation by de- domains under the .com, .org, and .net TLDs over a fault, e.g., as of January 2012 Comcast (one of the period of 21 months to analyze DNSSEC deployment largest ISPs in the US) requests and validates DNSSEC and management by domains; we supplement this with records for all queries [32], and Google (which operates active measurements of more than 59K DNS resolvers the largest public DNS resolver) did the same in March worldwide to evaluate resolver-side validation. 2013 [22].1 Our investigation reveals pervasive mismanagement of But like any PKI, DNSSEC can only function cor- the DNSSEC infrastructure. For example, we found that rectly when all principals—every signatory from root 31% of domains that support DNSSEC fail to publish to leaf, and the resolver validating the signatures— all relevant records required for validation; 39% of the fulfill their respective responsibilities. Unfortunately, domains use insufficiently strong key-signing keys; and DNSSEC is complex, creating many opportunities for although 82% of resolvers in our study request DNSSEC mismanagement. On the server side, a single error such records, only 12% of them actually attempt to validate as a weak key, an expired signature, or a broken signature them. These results highlight systemic problems, which chain can weaken or totally compromise the integrity of motivate improved automation and auditing of DNSSEC a large number of domains. On the client side, misman- management. aged or buggy DNS resolvers can obviate all server-side efforts by simply failing to catch invalid or missing sig- 1 Introduction natures. Surprisingly little is known about how well the The Domain Name System (DNS) [36] provides a DNSSEC PKI ecosystem is managed. While there have scalable, flexible name resolution service. Unfortu- 1It is important to note that these resolvers still accept responses nately, DNS has long been fraught with security issues without DNSSEC records, as the vast majority of domain administra- such as DNS spoofing and cache poisoning [3, 28, 46] tors have yet to deploy DNSSEC. USENIX Association 26th USENIX Security Symposium 1307 been many studies of DNSSEC, we find that no prior ef- solvers request DNSSEC records during their queries, forts had the data to allow them to study the DNSSEC only 12% of them actually validate the records (de- PKI at scale—across many domains and resolvers— feating the purpose of DNSSEC). This finding moti- and longitudinally—by monitoring their behavior over vates the need to reexamine approaches using query time. For example, server-side studies have shown in- logs from authoritative name servers as a lens to mea- stances of mismanagement, but only for samples of do- sure DNSSEC adoption by resolvers [21, 23]. main names [12–14]. Likewise, prior studies of DNS resolvers have used ad campaigns, which do not per- In summary, our results paint a distressing picture mit repeated, controlled measurements of resolvers over of widespread mismanagement of keys and DNSSEC time [7, 33, 47]. What has made large-scale, longitu- records that violate best practices in some cases, and dinal studies of DNSSEC so challenging is a dearth of completely defeat the security guarantees of DNSSEC DNSSEC record datasets and a lack of vantage points in others. On a more positive note, our findings demon- from which to repeatedly measure resolver behavior. strate several areas of improvement where management In this paper, we present a comprehensive study of the of the DNSSEC PKI can be automated and audited. To entire DNSSEC ecosystem—encompassing signers, au- this end, we publicly release all of our analysis code and 2 thoritative name servers, and validating DNS resolvers— data (where possible ) to the research community at to understand how DNSSEC is (mis)managed today. To https://securepki.org study server-side behavior, our work relies on 21 months of daily snapshots, and three months of hourly snap- thereby allowing other researchers and administrators to shots, of DNSSEC records for all signed .com, .net, reproduce and extend our work. and .org second-level domains. To study client-side behavior, we leverage the Luminati HTTP/S proxy ser- 2 Background vice [35], which allows us to perform repeated, con- trolled tests from 403,355 end hosts—thereby studying We begin by presenting an overview of both DNS and 59,513 distinct DNS resolvers—around the world. DNSSEC. Our analysis reveals troubling, persistent mismanage- ment in the DNSSEC PKI: DNS and DNSSEC DNS uses records to map domain names to values (e.g., an A record maps a domain name • First, we find that nearly one-third of DNSSEC- to an IPv4 address; an NS record maps a domain name enabled domains produce records that cannot be val- to the authoritative name server for a domain). DNS is idated due to missing or incorrect records. 1.7% designed to encourage caching, and every DNS record of signed domains fail to provide RRSIGs for SOA contains a time-to-live (TTL), specifying how long the records, while 30% of signed domains do not have DS records can be cached for. The original DNS proto- records. The vast majority of these missing records col did not include security, allowing an adversary to are due to large hosting providers that fail to publish forge DNS responses to carry out attacks. DNS Security the correct records for domains they manage. Addi- Extensions (commonly referred to as DNSSEC) are de- tionally, we find that 0.6% of signed domains provide signed to address this vulnerability [4–6, 19]. DNSSEC incorrect RRSIGs for both SOA and DNSKEY records. provides integrity for DNS records using three primary • Second, we identify four large providers that use the record types3: same keys to sign all of their managed domains. This unnecessary key reuse makes all of the domains vul- DNSKEY records, which are public keys used in nerable to the compromise of a single shared key. For DNSSEC. Typically, each zone uses two DNSKEY example, we find that a single key is shared by over records to sign DNS records, as discussed below. 132K domains. RRSIG (Resource Record Signature) records, which are • Third, we observe widespread use of 1024-bit RSA cryptographic signatures of other records. Each keys, which are now considered “weak” (smaller RRSIG is a signature over all records of a given than the NIST-recommended minimum size of 2048 type for a certain name; this set is called an RRSet. bits [1]). 39% of domains use weak Key Signing Keys (KSKs), and over 90% of domains use weak Zone 2Our .com, .org, and .net zone files are collected under agree- ment with the zone operators; while we are not permitted to release Signing Keys (ZSKs). DNSSEC is designed to be re- this data, we provide links where other researchers can obtain access silient against weak and stolen keys via frequent key themselves. rotation, but we find that 70% of domains never ro- 3There are other record types for expressing the non-existence of tated their KSK during our 21-month study.
Load more

Recommended publications
  • Internet Governance Project
    International internet Policy Priorities United States Department of Commerce, National Telecommunications and Information Administration (NTIA) [Docket No. 180124068–8068–01] RIN 0660–XC041 The Internet Governance Project (IGP) is a group of professors, postdoctoral researchers and students hosted at the Georgia Institute of Technology’s School of Public Policy. We conduct scholarly research, produce policy analyses and commentary on events in Internet governance, and bring our ideas and proposals directly into Internet governance processes. We also educate professionals and young people about Internet governance in various world regions. IGP welcomes NTIA’s broadly focused NOI on “International Internet Policy Priorities.” We believe that agency is asking many of the right questions and appreciate its desire to look for guidance from the public. Our response will follow the template of the NOI. I. THE FREE FLOW OF INFORMATION AND JURISDICTION A. What are the challenges to the free flow of information online? ​ There are two distinct challenges to the free flow of information. The biggest and most fundamental is alignment,1 which is related to the issue of jurisdiction. Alignment refers to the ​ ​ ​ attempt by national governments to assert sovereignty over cyberspace, by imposing exclusive territorial jurisdiction and national controls in a globally interoperable cyberspace. Data localization is one obvious example of a policy that seeks to achieve alignment, but the process is evident in multiple domains of Internet governance: in cybersecurity policy, trade policy, intellectual property protection and content regulation. In each case states erect barriers that 1 The concept of alignment was described in the book Will the Internet Fragment? (Polity Press, 2017).
    [Show full text]
  • Ethereum Based Domain Name System Using Smart Contracts
    ETHEREUM BASED DOMAIN NAME SYSTEM USING SMART CONTRACTS (BC-DNS) A Project Presented to the faculty of the Department of Computer Science California State University, Sacramento Submitted in partial satisfaction of the requirements for the degree of MASTER OF SCIENCE in Computer Science by Rodney Pinto SPRING 2019 © 2019 Rodney Pinto ALL RIGHTS RESERVED ii ETHEREUM BASED DOMAIN NAME SYSTEM USING SMART CONTRACTS (BC-DNS) A Project by Rodney Pinto Approved by: __________________________________, Committee Chair Dr. Jun Dai. __________________________________, Second Reader Dr. Xuyu Wang. ____________________________ Date iii Student: Rodney Pinto I certify that this student has met the requirements for format contained in the university format manual, and that this project is suitable for shelving in the library and credit is to be awarded for the project. __________________________, Graduate Coordinator ____________________ Dr. Jinsong Ouyang, Ph.D. Date Department of Computer Science iv Abstract of ETHEREUM BASED DOMAIN NAME SYSTEM USING SMART CONTRACTS (BC-DNS) by Rodney Pinto One of the most critical resources that ensure the current working of the internet is the domain name system (DNS). It is a decentralized, hierarchical naming system that is responsible for translating the human-readable domain name to its associated IP address. The use of DNS thus eliminates the need for humans to remember the IP address of all their favorite websites (such as 172.217.6.68 an IPV4 address for google.com). Despite its widespread use, DNS is vulnerable to various security issues. This project focuses on replicating the basic functionality of the existing DNS on the blockchain and deploying it on a peer to peer network making it completely decentralized and, in the process, make it a bit more secure and reliable by addressing few of the security vulnerabilities of the existing system.
    [Show full text]
  • L-Root and Internet in LAC Mauricio Vergara Ereche | Qos Internet CEPAL | Oct 2015 Agenda
    L-Root and Internet in LAC Mauricio Vergara Ereche | QoS Internet CEPAL | Oct 2015 Agenda 1 2 3 What is L-Root LAC ICANN? Connectivity 4 5 Our model for Recommend deployment ations | 2 What is ICANN? What is a resilient and secure Internet? Quick Look at ICANN Overview ICANN is a global multi-stakeholder, private sector organization that manages Internet resources for the public benefit. It is best known for its role as technical coordinator of the Internet’s Domain Name System Mission To coordinate, at the overall level, the global Internet’s system of unique identifiers, and in particular to ensure the stable and secure operation of the Internet’s unique identifier system | 4 Supporting A Healthy, Resilient Internet | 5 SSR: Security, Stability and Resiliency Secure 1 Capacity to protect and prevent misuse of Internet Unique identifiers Stable Capacity to ensure that the system operates as expected, 2 and that users of the unique identifiers have confidence that the system operates as expected Resilient Capacity of the unique identifier system to effectively 3 withstand/tolerate/survive malicious attacks and other disruptive events without disruption or cessation of service | 6 L-Root DNS and Anycasting How DNS Works? Root Server 2 www.icann.org ? 1 3 4 8 .ORG Server 5 DNS Resolver (ISP) 6 9 7 www.icann.org ICANN.ORG Server | 8 What is L-Root? “L” is one of 13 independently operated root servers serving the DNS root zone ICANN DNS Engineering team operates L under the Autonomous System Number (ASN) AS20144 using the following
    [Show full text]
  • Domain Name System 1 Domain Name System
    Domain Name System 1 Domain Name System The Domain Name System (DNS) is a hierarchical distributed naming system for computers, services, or any resource connected to the Internet or a private network. It associates various information with domain names assigned to each of the participating entities. A Domain Name Service translates queries for domain names (which are easier to understand and utilize when accessing the internet) into IP addresses for the purpose of locating computer services and devices worldwide. An often-used analogy to explain the Domain Name System is that it serves as the phone book for the Internet by translating human-friendly computer hostnames into IP addresses. For example, the domain name www.example.com translates to the addresses 192.0.43.10 (IPv4) and 2620:0:2d0:200::10 (IPv6). The Domain Name System makes it possible to assign domain names to groups of Internet resources and users in a meaningful way, independent of each entity's physical location. Because of this, World Wide Web (WWW) hyperlinks and Internet contact information can remain consistent and constant even if the current Internet routing arrangements change or the participant uses a mobile device. Internet domain names are easier to remember than IP addresses such as 208.77.188.166 (IPv4) or 2001:db8:1f70::999:de8:7648:6e8 (IPv6). Users take advantage of this when they recite meaningful Uniform Resource Locators (URLs) and e-mail addresses without having to know how the computer actually locates them. The Domain Name System distributes the responsibility of assigning domain names and mapping those names to IP addresses by designating authoritative name servers for each domain.
    [Show full text]
  • Identifier System Attack Mitigation Methodology DATE: 13 February 2017 Identifier System Attack Mitigation Methodology
    Identifier System Attack Mitigation Methodology DATE: 13 February 2017 Identifier System Attack Mitigation Methodology Introduction This document is part of ICANN’s effort to contribute to enhancing the Stability, Security, and Resiliency (SSR) of the Internet’s system of unique identifiers (“Internet Identifiers”) by working with the Community to identify and increase awareness of related attacks and to promote broader adoption of attack mitigation practices. This effort also addresses Recommendation #12 of the Security, Stability & Resiliency (SSR) Review Team (SSR-RT) by creating an Identifier System Attack Mitigation Methodology. Specifically, this document identifies and prioritizes types of attacks against the Identifier System, providing a stepping-off point for ICANN to coordinate with the Community to develop a series of short technical documents (“Tech Notes”) on actual high-impact attacks and emerging high-risk vulnerabilities. This document will be periodically updated to reflect evolution of both the Identifier System and the cybercrime landscape, supporting on-going efforts within both ICANN and the Community to mitigate attacks that pose the greatest risk to Identifier System SSR. Authors: Lisa Phifer and David Piscitello Page 1 Identifier System Attack Mitigation Methodology DATE: 13 February 2017 Attack Mitigation Methodology ICANN is proposing a new Identifier System Attack Mitigation Methodology to: • Identify, prioritize, and periodically refresh a list of top Identifier System attacks; • Develop guidance on actual high-impact attacks and emerging high-risk vulnerabilities; • Describe corresponding attack mitigation practices that are commonly considered useful; and • Encourage broader adoption of those practices via contracts, agreements, incentives, etc. This document represents the first component of this methodology.
    [Show full text]
  • Thesis That TW-OR Forwards All DNS Queries to a Resolver in China
    The Impact of DNSSEC on the Internet Landscape Von der Fakult¨atf¨urIngenieurwissenschaften, Abteilung Informatik und Angewandte Kognitionswissenschaft der Universit¨atDuisburg-Essen zur Erlangung des akademischen Grades Doktor der Ingenieurwissenschaften genehmigte Dissertation von Matth¨ausWander aus Lubin (L¨uben) Gutachter: Prof. Dr.-Ing. Torben Weis Prof. Dr.-Ing. Felix Freiling Tag der m¨undlichen Pr¨ufung:19. Juni 2015 Abstract In this dissertation we investigate the security deficiencies of the Domain Name System (DNS) and assess the impact of the DNSSEC security extensions. DNS spoofing attacks divert an application to the wrong server, but are also used routinely for blocking access to websites. We provide evidence for systematic DNS spoofing in China and Iran with measurement-based analyses, which allow us to examine the DNS spoofing filters from van- tage points outside of the affected networks. Third-parties in other countries can be affected inadvertently by spoofing-based domain filtering, which could be averted with DNSSEC. The security goals of DNSSEC are data integrity and authenticity. A point solution called NSEC3 adds a privacy assertion to DNSSEC, which is supposed to prevent disclosure of the domain namespace as a whole. We present GPU-based attacks on the NSEC3 privacy assertion, which allow efficient recovery of the namespace contents. We demonstrate with active measurements that DNSSEC has found wide adoption after initial hesitation. At server-side, there are more than five million domains signed with DNSSEC. A portion of them is insecure due to insufficient cryptographic key lengths or broken due to maintenance failures. At client-side, we have observed a worldwide increase of DNSSEC validation over the last three years, though not necessarily on the last mile.
    [Show full text]
  • CS4700/CS5700 Fundamentals of Computer Networks
    CS4700/CS5700 Fundamentals of Computer Networks Lecture 17: Domain Name System Slides used with permissions from Edward W. Knightly, T. S. Eugene Ng, Ion Stoica, Hui Zhang Alan Mislove amislove at ccs.neu.edu Northeastern1 University Human Involvement • Just like your friend needs to tell you his phone number for you to call him • Somehow, an application needs to know the IP address of the communication peer • There is no magic, some out-of-band mechanism is needed – Word of mouth – Read it in the advertisement in the paper – Etc. • But IP addresses are bad for humans to remember and tell each other • So need names that makes some sense to humans Alan Mislove amislove at ccs.neu.edu Northeastern2 University Internet Names & Addresses • Names: e.g. www.rice.edu – human-usable labels for machines – conforms to “organizational” structure • Addresses: e.g. 128.42.247.150 – router-usable labels for machines – conforms to “network” structure • How do you map from one to another? – Domain Name System (DNS) Alan Mislove amislove at ccs.neu.edu Northeastern3 University DNS: History • Initially all host-addess mappings were in a file called hosts.txt (in /etc/hosts) – Changes were submitted to SRI by email – New versions of hosts.txt ftp’d periodically from SRI – An administrator could pick names at their discretion – Any name is allowed: eugenesdesktopatrice • As the Internet grew this system broke down because: – SRI couldn’t handled the load – Hard to enforce uniqueness of names – Many hosts had inaccurate copies of hosts.txt • Domain Name System (DNS) was born Alan Mislove amislove at ccs.neu.edu Northeastern4 University Basic DNS Features • Hierarchical namespace – as opposed to original flat namespace • Distributed storage architecture – as opposed to centralized storage (plus replication) • Client--server interaction on UDP Port 53 – but can use TCP if desired Alan Mislove amislove at ccs.neu.edu Northeastern5 University Naming Hierarchy root edu com gov mil org net uk fr etc.
    [Show full text]
  • DNS Performance – a Study of Free, Public and Popular DNS Servers in 2019
    Linköping University | Department of Computer and Information Science Bachelor’s thesis, 16 ECTS | Informationsteknologi 2019 | LIU-IDA/LITH-EX-G--19/037--SE DNS Performance – A study of free, public and popular DNS servers in 2019 DNS prestanda – En studie av gratis, publika och populära DNS servrar år 2019 Filip Ström Felix Zedén Yverås Supervisor : Niklas Carlsson Examiner : Marcus Bendtsen Linköpings universitet SE–581 83 Linköping +46 13 28 10 00 , www.liu.se Upphovsrätt Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publicer- ingsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka ko- pior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervis- ning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säker- heten och tillgängligheten finns lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dok- umentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för up- phovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/. Copyright The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances.
    [Show full text]
  • DNS: Domain Name System a Scalable Naming System for the Internet
    Introduction Queries and Caching Protocol History and Growth DNS: Domain Name System A Scalable Naming System for the Internet Daniel Zappala Brigham Young University Computer Science Department 1/26 Introduction Introduction Queries and Caching Protocol History and Growth Domain Name System • people like to use names for computers (www.byu.edu), but computers need to use numbers (128.187.22.132) • the Domain Name System (DNS) is a distributed database providing this service • a program send a query a local name server • the local name server contacts other servers as needed • many DNS services • host name to IP address translation • host aliasing (canonical name versus alias names) • lookup mail server for a host • load distribution - can provide a set of IP addresses for one canonical name Demonstration: dig 3/26 Introduction Queries and Caching Protocol History and Growth Names • domain name: top-level domain (TLD) + one or more subdomains • example: cs.byu.edu • host name: a domain name with one or more IP addresses associated with it • TLDs • ccTLD: country codes (.us, .uk, .tv) • gTLD: generic (.com, .edu, .org, .net, .gov, .mil) { see full list at Wikipedia • iTLD: infrastructure (.arpa) • may be 127 levels deep, 63 characters per label, 255 characters per name 4/26 Introduction Queries and Caching Protocol History and Growth DNS Hierarchy • root, top-level domain (TLD), and local name servers • each level represents a zone • what zone is BYU in charge of? 5/26 Introduction Queries and Caching Protocol History and Growth Root Name
    [Show full text]
  • Blockchain, Iot and DNS
    Domain Name Registrar Blockchain, IoT and DNS ICANN64 Tech Day Kobe, Japan Tom Barrett EnCirca President About EnCirca Domain Name Registrar • Formed in 2001 in Boston, USA • ICANN Accredited Registrar • Specialty: Partnering with TLD Registries • Restricted and regulated TLDs • White-labelled Storefronts for DotBrand and regulated registries • Validation Provider for .BANK and six other TLDs • Blockchain integration with .LUXE, XYZ Why Do We Care? Domain Name Registrar The blockchain and the Internet of Things (IoT) are two of the most transformative technologies in the world today. “Blockchain technology is probably the best invention since the internet itself” IoT Investments Domain Name Registrar Blockchain Investments Domain Name Registrar Blockchain and IoT Domain Name Registrar • Both need DNS to work. • Both need features not present in today’s DNS • Alternative frameworks and protocols are emerging to address the limitations of the DNS • Will DNS advance to meet this challenge? • What role will ICANN play in this space? A World Exploding with Devices Domain Name Registrar IoT Defined Domain Name Registrar Connect physical things to communication networks with a special focus on: • Existing infrastructure (buildings, roads, vehicles, factory equipment, etc.) and • Constrained devices with extremely limited computing resources (switches, valves, sensors, actuators, thermostats, etc.) Blockchain Defined Domain Name Registrar • An open, distributed ledger that can record transactions between two parties efficiently and in a verifiable and permanent way • A growing list of records, called blocks, are linked using cryptography • Typically managed by a peer-to-peer network • Data in any block cannot be altered retroactively without alteration of all subsequent blocks Blockchain Benefits Domain Name Registrar • You have complete control of the value you own; there is no third party that holds your value or can limit your access to it.
    [Show full text]
  • Wow, That's a Lot of Packets
    Wow, That’s a Lot of Packets Duane Wessels, Marina Fomenkov Abstract—Organizations operating Root DNS servers re- an authoritative answer. If the application does not know port loads exceeding 100 million queries per day. Given the where to send a query it asks the servers in the parent design goals of the DNS, and what we know about today’s In- zone. In the example above, not knowing anything about ternet, this number is about two orders of magnitude more ucsd.edu, the application should send a query to the au- than we would expect. thoritative server for the edu zone. If the application does With the assistance of one root server operator, we took a edu 24-hour trace of queries arriving at one of the thirteen root not know about the zone, it queries the “root zone.” servers. In this paper we analyze these data and use a simple This process is called recursive iteration. model of the DNS to classify each query into one of nine cat- The DNS root zone is served by 13 name servers (not to egories. We find that, by far, most of the queries are repeats be confused with the 13 generic top-level domain servers) and that only a small percentage are legitimate. distributed across the globe. Thirteen is the maximum We also characterize a few of the “root server abusers,” number of root servers possible in the current DNS archi- that is, clients sending a particularly large number of tecture because that is the most that can fit inside a 512- queries to the root server.
    [Show full text]
  • Retrait Effectif Ou Pluralisation Contrôlée?
    UNIVERSITÉ DU QUÉBEC À MONTRÉAL RETRAlT EFFECTIF OU PLURALISATION CONTRÔLÉE? ANALYSE CRITIQUE DE LA STRATÉGIE DE LÉGITIMATION DE L'AUTORITÉ DU GOUVERNEMENT AMÉRICAIN DANS LA GOUVERNANCE POLITIQUE DU SYSTÈME DE NOMS DE DOMAINES D'INTERNET (DNS) MÉMOIRE PRÉSENTÉ COMME EXIGENCE PARTIELLE DE LA MAÎTRISE EN SCIENCE POLITIQUE PAR OLIVIER DAGENAIS JUILLET 2016 UNIVERSITÉ DU QUÉBEC À MONTRÉAL Service des bibliothèques Avertissement La diffusion de ce mémoire se fait dans le respect des droits de son auteur, qui a signé le formulaire Autorisation de reproduire et de diffuser un travail de recherche de cycles supérieurs (SDU-522 - Rév.1 0-2015). Cette autorisation stipule que «conformément à l'article 11 du Règlement no 8 des études de cycles supérieurs, [l 'auteur] concède à l'Université du Québec à Montréal une licence non exclusive d'utilisation et de publication de la totalité ou d'une partie importante de [son] travail de recherche pour des fins pédagogiques et non commerciales. Plus précisément, [l'auteur] autorise l'Université du Québec à Montréal à reproduire , diffuser, prêter, distribuer ou vendre des copies de [son] travail de recherche à des fins non commerciales sur quelque support que ce soit, y compris l'Internet. Cette licence et cette autorisation n'entraînent pas une renonciation de [la] part [de l'auteur] à [ses] droits moraux ni à [ses] droits de propriété intellectuelle. Sauf entente contraire, [l'auteur] conserve la liberté de diffuser et de commercialiser ou non ce travail dont [il] possède un exemplaire. » REMERCIEMENTS Quelqu'un m'a dit il n'y a pas si longremps que terminer un mémoire était un peu comme un accouchement, à la d ifférence près qu'une fo is te rminé, on n'avai t jam ais le goût de revoir le nouveau-né de notre vie.
    [Show full text]