DOCSLIB.ORG

DNS Performance – a Study of Free, Public and Popular DNS Servers in 2019

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

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. The online availability of the document implies permanent permission for anyone to read, to down- load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/. Filip Ström © Felix Zedén Yverås Students in the 5 year Information Technology program complete a semester-long soft- ware development project during their sixth semester (third year). The project is completed in mid-sized groups, and the students implement a mobile application intended to be used in a multi-actor setting, currently a search and rescue scenario. In parallel they study several topics relevant to the technical and ethical considerations in the project. The project culmin- ates by demonstrating a working product and a written report documenting the results of the practical development process including requirements elicitation. During the final stage of the semester, students create small groups and specialise in one topic, resulting in a bach- elor thesis. The current report represents the results obtained during this specialisation work. Hence, the thesis should be viewed as part of a larger body of work required to pass the semester, including the conditions and requirements for a bachelor thesis. Abstract The Domain Name System (DNS) is an integral part of making the internet a more human-friendly place. However, it comes with the cost of an added abstraction layer that introduces extra latency in many aspects of the modern computing experience - a great selling point for many DNS services. In this thesis we look at the performance of DNS services and servers through the scope of 51 unique free, public and popular DNS servers. We use a specifically designed tool, DNSHoarder, to collect 714,000 datapoints of 250 differ- ent hostnames of varying popularity over seven days. From this data we find most DNS servers to exhibit a similar relative distribution of response times and performance differ- ences between IPv4 and IPv6 to be minor or nonexistent. We also find network distance and quality to have a big effect on the performance of DNS as well as network latency to be a major limiting factor in further DNS performance improvements. Acknowledgments First, a big thank you to our supervisor Niklas Carlsson for his support and feedback during the writing of this thesis. We would also like to thank Xiangfeng Yang of the Department of Mathematics for taking the time to help out two random students suddenly appearing at his door. Additionally, we would like to extend our gratitude to Philippe Biondi and the Scapy community for enabling this work with their excellent Scapy tool. Finally we would like to thank two members of the Scapy community in particular, Gabriel (@gpotter2) and Guillaume Valadon (@guedou), for their personal assistance. Without your help, the results presented herein would have suffered greatly. v Contents Abstract iv Acknowledgments v Contents vi List of Figures viii List of Tables ix List of Code x 1 Introduction 1 1.1 Motivation . 2 1.2 Aim............................................ 2 1.3 Research Questions . 2 1.4 Delimitations . 2 2 Background 3 2.1 The Domain Name System (DNS) . 3 2.2 Related Work . 5 3 Method 8 3.1 Tool Development . 8 3.2 Automated Data Collection . 10 4 Results 12 4.1 Overview of Failed DNS Queries . 12 4.2 IPv4 vs IPv6 Performance . 17 4.3 Performance Variation Between DNS Servers . 23 4.4 Performance Based on Hostname Popularity . 26 5 Discussion 27 5.1 Results . 27 5.2 Method . 28 5.3 The Work in a Wider Context . 30 6 Conclusion 31 6.1 Going Further . 31 Bibliography 33 A Structure of DNSHoarder Output Data 36 vi B Additional Graphs 41 C DNSHoarder CLI Arguments 49 D .gitlab-ci.yml 50 E DNS Servers 52 F Hostnames 54 vii List of Figures 3.1 How input files are combined into DNSHoarder jobs . 9 4.1 DNS servers failing 100% of queries . 13 4.2 Excerpt of traceroute for DNS servers failing 100% of queries . 13 4.3 Excerpt of DNS servers failing some queries, but not all . 14 4.4 Excerpt of traceroute for DNS servers failing some queries, but not all . 14 4.5 Excerpt of DNS servers intermittently failing 100% of queries . 15 4.6 Excerpt of traceroute for DNS servers intermittently failing 100% of queries . 15 4.7 Excerpt of DNS servers completing almost 100% of queries . 16 4.8 Excerpt of traceroute for DNS servers completing almost 100% of queries . 17 4.9 Average performance over time, per DNS server (IPv4 / A record) . 18 4.10 Average performance over time, per DNS server (IPv6 / AAAA record) . 19 4.11 Performance per DNS server (IPv4 / A record) . 20 4.12 Performance per DNS server (IPv6 / AAAA record) . 21 4.13 Performance per day of week . 22 4.14 Excerpt of response sizes per DNS server . 23 4.15 IPv4 performance comparison based on median and average performance values of primary and secondary DNS servers. Blue favors the primary DNS server. 24 4.16 IPv6 performance comparison based on median and average performance values of primary and secondary DNS servers. Blue favors the primary DNS server. 24 4.17 Performance per day of week . 25 4.18 Median performance per hostname . 26 5.1 Disparity in response size where the 209.88.198.133 and 208.76.50.50 DNS server yielded significantly smaller responses than other DNS servers. 27 5.2 Comparison of the heatmap of failed requests before and after considering empty DNS responses invalid. 28 A.1 Hierarchical structure of DNSHoarder’s output data . 37 B.1 Failed DNS queries over time, per DNS server (IPv4 / A record) . 42 B.2 Failed DNS queries over time, per DNS server (IPv6 / AAAA record) . 43 B.3 Average distance and ping performance of the routes to each DNS server as meas- ured by traceroute . 44 B.4 Average failed DNS queries per DNS server, over time . 45 B.5 Average failed DNS queries per DNS server, over time (excluding DNS servers that fail 100% of the requests) . 45 B.6 Response size per DNS server (IPv4 / A record) . 46 B.7 Response size per DNS server (IPv6 / AAAA record) . 47 B.8 Performance per day of week . 48 viii List of Tables 3.1 DNS services providing a primary and secondary DNS server . 11 A.1 Attributes for the <RECORD TYPE> entry . 36 A.2 Attributes for the IP entry . 38 A.3 Attributes for the UDP entry . 38 A.4 Attributes for the DNS entry . 39 A.5 Attributes for each qd entry . 39 A.6 Attributes for each an entry . 39 A.7 Attributes for each ns entry . 40 A.8 Attributes for each ar entry . 40 E.1 DNS servers used for data collection . 53 F.1 Hostnames used for data collection . 61 ix List of Code C.1 Available arguments and associated descriptions for DNSHoarder . 49 D.1 Gitlab CI configuration file (.gitlab-ci.yml) used to automate data collection . 50 x 1 Introduction The Domain Name System (DNS) is an integral part of making the internet a more human- friendly place, allowing for the use of more memorable hostnames over series of numbers - and with the introduction of IPv6 even letters - for addressing of individual, interconnected devices. The caveat is an additional layer of abstraction that introduces extra latency in many aspects of the modern computing experience. To combat the overhead introduced by DNS, multiple free and public DNS services have appeared, claiming to offer ever better perform- ing services.
Recommended publications
  • Internet Governance Project

    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).
  • 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

    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
  • Domain Name System 1 Domain Name System

    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.
  • Thesis That TW-OR Forwards All DNS Queries to a Resolver in China

    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.
  • Wow, That's a Lot of Packets

    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.
  • Design of a Reactive DNS Measurement System

    Design of a Reactive DNS Measurement System

    Design of a Reactive DNS Measurement System Jochem Braakhuis 13-07-2021, University of Twente [email protected] Abstract—For speed, robustness and safety of the Internet, it is will then delegate the query to the appropriate top-level domain important that information on name servers in every level of the name server dependent on the entered domain (.com, .org, .nl). hierarchical DNS structure is accurate and consistent. OpenIN- Then, the top-level domain name server will in turn delegate TEL, designed in 2016, measures about half of the global names- the query to the authoritative name server for the entered pace every day, but lacks flexibility in reactive measurement. To domain, which finally returns the IP address of the domain’s provide an easily scalable framework for performing research server to the user, or delegate it to authoritative name servers in DNS inconsistencies, we designed and tested a reactive DNS measurement system compatible with OpenINTEL, supported by for further sub-domains. Section II further elaborates on this Apache Kafka message broker functionality. The software can process. query multiple levels in the DNS hierarchy and supports 10 query In addition to storing the IP addresses of name servers types. Initial high-volume testing of the resolver authoritative level shows the software is able to handle large volumes of and domains, name servers also contain other records about queries, but only gives a lower bound on the performance of the domains in their zone. For example, MX records contain the software. Testing of more authoritative levels, testing on purpose- domain names of the servers that handle email traffic for the built hardware and implementation of extended decoder logic and domain, and their priority.
  • How Linux Containers Have Evolved Daniel Walsh 11 Containers Have Come a Long Way in the Past Few Years

    How Linux Containers Have Evolved Daniel Walsh 11 Containers Have Come a Long Way in the Past Few Years

    . ........ .... ... .. .. .. ... .. OPENSOURCE.COM Opensource.com publishes stories about creating, adopting, and sharing open source solutions. Visit Opensource.com to learn more about how the open source way is improving technologies, education, business, government, health, law, entertainment, humanitarian efforts, and more. Submit a story idea: https://opensource.com/story Email us: [email protected] Chat with us in Freenode IRC: #opensource.com . OPEN SOURCE YEARBOOK 2017 . OPENSOURCE.COM 3 ............................. AUTOGRAPHS . .... ... .. .. .. ........ ... .. ............................. AUTOGRAPHS . .... ... .. .. .. ........ ... .. OPENSOURCE.COM............................. ........ WRITE FOR US ................... 7 big reasons to contribute to Opensource.com: Career benefits: “I probably would not have gotten my most recent job if it had not been for my articles on 1 Opensource.com.” Raise awareness: “The platform and publicity that is available through Opensource.com is extremely 2 valuable.” Grow your network: “I met a lot of interesting people after that, boosted my blog stats immediately, and 3 even got some business offers!” Contribute back to open source communities: “Writing for Opensource.com has allowed me to give 4 back to a community of users and developers from whom I have truly benefited for many years.” Receive free, professional editing services: “The team helps me, through feedback, on improving my 5 writing skills.” We’re loveable: “I love the Opensource.com team. I have known some of them for years and they are 6 good people.” 7 Writing for us is easy: “I couldn't have been more pleased with my writing experience.” Email us to learn more or to share your feedback about writing for us: https://opensource.com/story Visit our Participate page to more about joining in the Opensource.com community: https://opensource.com/participate Find our editorial team, moderators, authors, and readers on Freenode IRC at #opensource.com: https://opensource.com/irc .
  • The ISP Column Scoring the DNS Root Server System

    The ISP Column Scoring the DNS Root Server System

    The ISP Column A monthly column on things Internet Geoff Huston November 2016 Scoring the DNS Root Server System The process of rolling the DNS Root’s Key Signing Key of the DNS has now started. During this process there will be a period where the root zone servers’ response to a DNS query for the DNSKEY resource record of the root zone will grow from the current value of 864 octets to 1,425 octets. Does this present a problem? Let’s look at the DNS Root Server system and score it on how well it can cope with large responses. It seems that awarding stars is the current Internet way, so let’s see how many stars we’ll give to the Root Server System for their handling of large responses. Packets and Networks What is it about large responses that are an issue here? There are a number of persistent themes in packet networking that appear to be unresolved despite many decades of experience. One of these is the handling of packet sizes. Packet-switched networks dispensed with the constant time base used in time-switched networks. Instead, they allow individual packets to be sized according to the needs of the application as well as the needs of the network. Smaller packets have a higher packet header to payload ratio, and are consequently less efficient in data carriage. On the other hand, within a packet switching system the smaller packet can be dispatched faster, reducing the level of head-of-line blocking in the internal queues within a packet switch and potentially reducing network-imposed jitter as a result.
  • CS 43: Computer Networks

    CS 43: Computer Networks

    CS 43: Computer Networks 10: Naming and DNS September 24, 2018 Last class • Distributed systems architectures – Client-Server – Peer-to-Peer • Challenges in design – Partial failures – Event ordering Lecture 10 - Slide 2 Today • Identifiers and addressing • Domain Name System – History – Query sequences – Record types – Load balancing Lecture 10 - Slide 3 DNS: domain name system People: many identifiers: – SSN, name, passport # Internet hosts, routers: – IP address (32 bit) - used for addressing datagrams – “name”, e.g., www.google.com - used by humans How do we map between IP address and name, and vice versa ? Lecture 10 - Slide 4 DNS: domain name system • distributed database implemented in hierarchy of many name servers. • application-layer protocol: hosts, name servers communicate to resolve names à addresses – note: core Internet function, implemented as application-layer protocol – complexity at network’s “edge” Lecture 10 - Slide 5 Recall: TCP/IP Protocol Stack host host HTTP Application Layer HTTP TCP Transport Layer TCP router router IP IP Network Layer IP IP Ethernet Ethernet SONET SONET Ethernet Ethernet interface interface interface Link Layerinterface interface interface Lecture 10 - Slide 6 Recall: TCP/IP Protocol Stack host host HTTP Human-readable strings: www.example.com HTTP TCP (Not much addressing here, ports to ID socket) TCP router router IP IP addressesIP (32-bit IPv4, 128-bitIP IPv6) IP Ethernet Ethernet SONET SONET Ethernet Ethernet interface (Networkinterface dependent)interface Ethernet:interface 48-bit MACinterface address interface Lecture 10 - Slide 7 Why do we need to map names to IP addresses? Why not route on names at the network layer? A. Domain names are hierarchical, so we can route on domain names too.
  • DNS for Rocket Scientists Section 1 Overview

    DNS for Rocket Scientists Section 1 Overview

    DNS for Rocket Scientists This Open Source Guide is about DNS and (mostly) BIND 9.x on Linux (REDHAT Versions 6.x and 7.x) and the BSD's (FreeBSD, OpenBSD and NetBSD). It is meant for newbies, Rocket Scientist wannabees and anyone in between. This Guide was born out of our first attempts a number of years ago at trying to install a much needed DNS service on an early Redhat Linux system. We completed the DNS 'rite of passage' and found it a pretty unedifying and pointless experience. Health Warning: This is still a work-in-progress. If you have expertise in something - contribute some text. If you find errors don't grumble - tell us. Look at our to do list and if you want to contribute something please do so. And for all that hard work we promise only a warm sense of well-being and an acknowledgment of your work in the licence. Section 1 Overview What's new in Guide version 0.1.27 1. Boilerplate and Terminology 1.1 Objectives and Scope 1.2 How to read this Guide 1.3 Terminology and Conventions used 1.4 Acknowledgements 1.5 Copyright and License 2. DNS - Overview 2.1 A brief History of Name Servers 2.2 DNS Concepts & Implementation 2.2.1 DNS Overview 2.2.2 Domains and Delegation 2.2.3 DNS Organization and Structure 2.2.4 DNS System Components 2.2.5 Zones and Zone Files 2.2.6 DNS Queries 2.2.6.1 Recursive Queries 2.2.6.2 Iterative Queries 2.2.6.3 Inverse Queries 2.2.7 Zone Updates 2.2.7.1 Full Zone Transfer (AXFR) 2.2.7.2 Incremental Zone Transfer (IXFR) 2.2.7.3 Notify (NOTIFY) 2.2.7.4 Dynamic Zone Updates 2.2.7.5 Alternative Dynamic DNS Approaches 2.3 DNS Security Overview 2.3.1 Security Threats 2.3.2 Security Types 2.3.3 Local Security 2.3.4 Server-Server (TSIG Transactions) 2.3.5 Server-Client (DNSSEC) 3.
  • A Longitudinal, End-To-End View of the DNSSEC Ecosystem

    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.
  • SAC113 SSAC Advisory on Private-Use Tlds

    SAC113 SSAC Advisory on Private-Use Tlds

    SAC113 SSAC Advisory on Private-Use TLDs An Advisory from the ICANN Security and Stability Advisory Committee (SSAC) 18 September 2020 SSAC Advisory on Private Use TLDs Preface This is an advisory to the ICANN Board, the ICANN Organization staff, the ICANN community, and, more broadly, the Internet community from the ICANN Security and Stability Advisory Committee (SSAC) about private-use TLDs. The SSAC focuses on matters relating to the security and integrity of the Internet’s naming and address allocation systems. This includes operational matters (e.g., pertaining to the correct and reliable operation of the root zone publication system), administrative matters (e.g., pertaining to address allocation and Internet number assignment), and registration matters (e.g., pertaining to registry and registrar services). SSAC engages in ongoing threat assessment and risk analysis of the Internet naming and address allocation services to assess where the principal threats to stability and security lie, and advises the ICANN community accordingly. The SSAC has no authority to regulate, enforce, or adjudicate. Those functions belong to other parties, and the advice offered here should be evaluated on its merits. SAC113 1 SSAC Advisory on Private Use TLDs Table of Contents Preface 1 Table of Contents 2 Executive Summary 3 1 Introduction 3 1.1 Terminology and Scope of Work 5 2 Private-Use TLDs and Their Uses 5 2.1 Use-Cases for Private-Use TLDs 6 2.2 Current Usage of Private-Use TLDs 7 2.3 Issues with Private-Use TLDs 9 3 Private IP Address Space,