DOCSLIB.ORG

Internet Domain Name System

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

INTERNET DOMAIN NAME SYSTEM CS2520/TELCOM2321 Wide Area Network Spring Term, 2019 Prof. Taieb Znati Department Computer Science Telecommunication Program IP Addresses IP addresses are numerical address appreciated by Internet routers Fixed length, binary number Hierarchical, related to host location A name could map to multiple IP addresses www.cnn.com maps to multiple replicas of the Web site Replicas enable load-balancing, reduce latency by selecting nearby servers, and allow tailoring content to requesters location, identity, … Multiple names can map to the same address The names www.cnn.com and cnn.com are aliases and map to the same address Name To IP Address Mapping Originally, names to IP addresses mapping was achieved using per-host file – /etc/hosts Network administrators downloaded regularly a copy of the master file maintained by SRI Flat namespace Internet growth exposed the single server lack of scalability Traffic implosion – lookups and updates Single point of failure Solution Distributed, Hierarchical Name Servers Internet Domains Main types of domain names Top-Level Domains, Second-Level Domains, Third-level Domains, and Country Domains cs.pitt.edu ቐ Top Level Domain ቐ Second Level Domain ቐ Third Level Domain Domain Name System (DNS) DNS is a hierarchical name space divided into zones Zones distributed over collection of DNS servers Hierarchy of DNS servers Root Servers Top-level domain (TLD) servers Authoritative DNS servers Address resolution – name to address mapping Local DNS servers Resolver software DNS Root Zone A DNS root zone is the top-level DNS zone in a Domain Name System (DNS) hierarchy. The zone's content is managed and processed by the Internet Assigned Numbers Authority (IANA) Functions Operator The zone file itself is physically maintained by a third party under contract – Root Zone Maintainer. The current IANA Functions Operator is the Internet Corporation for Assigned Names and Numbers (ICANN) The current Root Zone Maintainer is Verisign, Inc. Distributed Hierarchical Database Unnamed Root Generic Domains Country Domains com edu org ac us zw arpa Top-Level Domains (TLDs) in- univ it addr eng cs co her my std my.cs.univ.edu std.co.it.us DNS Root Located in Virginia, USA How do we make the root scale? Verisign, Dulles, VA DNS Root Servers 13 root servers (http://www.root-servers.org/) Labeled A through M A Verisign, Dulles, VA C Cogent, Herndon, VA D U Maryland College Park, MD G US DoD Vienna, VA K RIPE London H ARL Aberdeen, MD J Verisign I Autonomica, Stockholm E NASA Mt View, CA F Internet Software Consortium M WIDE Tokyo Palo Alto, CA B USC-ISI Marina del Rey, CA L ICANN Los Angeles, CA DNS Root Servers Replication via any-casting Localized routing for addresses A Verisign, Dulles, VA C Cogent, Herndon, VA (also Los Angeles, NY, Chicago) D U Maryland College Park, MD G US DoD Vienna, VA K RIPE London (plus 16 other locations) H ARL Aberdeen, MD J Verisign (21 locations) I Autonomica, Stockholm (plus 29 other locations) E NASA Mt View, CA F Internet Software Consortium, M WIDE Tokyo Palo Alto, CA plus Seoul, Paris, (and 37 other locations) San Francisco B USC-ISI Marina del Rey, CA L ICANN Los Angeles, CA Top-Level Domain Servers A Top-Level Domain (TLD) is at the highest level in the hierarchical Domain Name System of the Internet. TLD servers Generic domains (e.g., com, org, edu) Country domains (e.g., uk, fr, cn, jp) Special domains (e.g., arpa) Typically managed professionally Network Solutions maintains servers for “com” Educause maintains servers for “edu” Root servers hold the lists of names and addresses for the authoritative servers for all of the top-level domains. Authoritative DNS Servers An Authoritative Name Server (ANS) is a name server that gives answers in response to questions asked about names in one or more zones. An Authoritative Name Server only returns answers to queries about domain names that have been specifically configured by the administrator. Name servers can also be configured to give authoritative answers to queries in some zones, while acting as a caching name server for all other zones. Domain Registry and ANS When a domain is registered with a domain name registrar, the zone administrator provides a list of authoritative name servers for the zone that contains the domain Typically, at least two, for redundancy The registrar provides the names of these servers to the domain registry for the TLD containing the zone. The domain registry in turn configures the authoritative name servers for that top level domain with delegations for each server for the zone. DNS Initialization and Use Root servers hold the lists of names and addresses for the authoritative servers for all of the top-level domains. Every name lookup must either start with a query to a root server or use information that was once obtained from a root server. The root servers have the official names A.root-servers.net, B.root-servers.net, … to M.root- servers.net To look up the IP address of a root server from these names, a DNS resolver must first be able to look up a root server to find the address of an authoritative server for the .net DNS zone. Clearly this creates a circular dependency, so the address of at least one root server must be known by a host in order to bootstrap access to the DNS. DNS Use – Breaking the Dependency Breaking the circular dependency is usually done by shipping the addresses of all known DNS root servers as a file with the computer operating system The IP addresses of some root servers will change over the years, but only one correct address is needed for the resolver to obtain the current list of name servers. This file is called named.cache in BIND and a current version is officially distributed by ICANN's InterNIC. Once the address of a single functioning root server is known, all other DNS information can be discovered recursively, and the address of any domain name may be found. Name to Address Resolution Local DNS server (“default name server”) Usually near the endhosts that use it Local hosts configured with local server (e.g., /etc/resolv.conf) or learn server via DHCP Client application Extract server name (e.g., from the URL) Do gethostbyname() to trigger resolver code Server application Extract client IP address from socket Optional gethostbyaddr() to translate into name DNS Name Resolution Iterative Query Root DNS server Host at cs.pitt.edu seeks to obtain IP address for host.cs.univ.edu 2 3 4 Local DNS Server TLD DNS server dns.cs.pitt.edu 5 7 6 1 8 Authoritative DNS Server dns.cs.univ.edu Requesting Host u at cs.pitt.edu host.cs.univ.edu No Caching DNS Name Resolution root DNS server Recursive Query 2 3 The burden of name resolution is on the 7 6 contacted name server TLD DNS server Heavy load? Stateful Servers? Local DNS server dns.cs.pitt.edu 5 4 1 8 Authoritative DNS Server dns.cs.univ.edu requesting host Host.cs.univ.edu host.cs.univ.edu DNS Caching and updating records Once (any) name server learns mapping, it caches mapping Cache entries are associated with timers Timers are reset when entries are refreshed Cache entries are expelled from the cache when their associated timers expire TLD servers typically cached in local name servers Thus root name servers not often visited Reverse Mapping (Address Host) How do we go the other direction, from an IP address to the corresponding hostname? Addresses already have natural “quad” hierarchy: 12.34.56.78 But: quad notation has most-significant hierarchy element on left, while www.cnn.com has it on the right Idea: reverse the quads = 78.56.34.12 … … and look that up in the DNS Under what TLD? Convention: in-addr.arpa So lookup is for 78.56.34.12.in-addr.arpa 21 Distributed Hierarchical Database Unnamed Root Generic Domains Country Domains com edu org ac us zw arpa in- univ Top-Level Domains (TLDs) it addr 12 eng cs co 34 her my std 56 my.cs.univ.edu std.co.it.us 12.34.56.0/24 DNS Caching Name to Address resolution is time consuming Must be performed before actual communication takes place e.g., 1-second latency before starting Web download Caching can greatly reduce overhead The top-level servers very rarely change Popular sites (e.g., www.cnn.com) visited often Local DNS server often has the information cached How DNS caching works DNS servers cache responses to queries Responses include a “time to live” (TTL) field Server deletes cached entry after TTL expires Negative Caching Remember things that don’t work Misspellings like www.cnn.comm and www.cnnn.com These can take a long time to fail the first time Good to remember that they don’t work … so the failure takes less time the next time around But: negative caching is optional And not widely implemented DNS Resource Records DNS: distributed DB storing resource records (RR) RR format: (name, value, type, ttl) • Type=A • Type=CNAME – name is hostname – Name is alias name for some – value is IP address “canonical” name e.g., elements.cs.pitt.edu is really Type=NS name is domain (e.g. foo.com) oxygen.cs.pitt.edu value is hostname of authoritative name – value is canonical name server for this domain Type=PTR • Type=MX name is reversed IP quads e.g. 78.56.34.12.in-addr.arpa – value is name of mailserver value is corresponding associated with name hostname – Also includes a weight/preference DNS Protocol DNS protocol: query and reply messages, both with same message format Message header: 16 bits 16 bits Identification Flags • Identification: 16 bit # for # Questions # Answer RRs query, reply to query uses same # # Authority RRs # Additional
Recommended publications
  • DNS Zones Overview

    DNS Zones Overview

    DNS Zones Overview A DNS zone is the contiguous portion of the DNS domain name space over which a DNS server has authority. A zone is a portion of a namespace. It is not a domain. A domain is a branch of the DNS namespace. A DNS zone can contain one or more contiguous domains. A DNS server can be authoritative for multiple DNS zones. A non-contiguous namespace cannot be a DNS zone. A zone contains the resource records for all of the names within the particular zone. Zone files are used if DNS data is not integrated with Active Directory. The zone files contain the DNS database resource records that define the zone. If DNS and Active Directory are integrated, then DNS data is stored in Active Directory. The different types of zones used in Windows Server 2003 DNS are listed below: Primary zone Secondary zone Active Directory-integrated zone Reverse lookup zone Stub zone A primary zone is the only zone type that can be edited or updated because the data in the zone is the original source of the data for all domains in the zone. Updates made to the primary zone are made by the DNS server that is authoritative for the specific primary zone. Users can also back up data from a primary zone to a secondary zone. A secondary zone is a read-only copy of the zone that was copied from the master server during zone transfer. In fact, a secondary zone can only be updated through zone transfer. An Active Directory-integrated zone is a zone that stores its data in Active Directory.
  • Configuring DNS

    Configuring DNS

    Configuring DNS The Domain Name System (DNS) is a distributed database in which you can map hostnames to IP addresses through the DNS protocol from a DNS server. Each unique IP address can have an associated hostname. The Cisco IOS software maintains a cache of hostname-to-address mappings for use by the connect, telnet, and ping EXEC commands, and related Telnet support operations. This cache speeds the process of converting names to addresses. Note You can specify IPv4 and IPv6 addresses while performing various tasks in this feature. The resource record type AAAA is used to map a domain name to an IPv6 address. The IP6.ARPA domain is defined to look up a record given an IPv6 address. • Finding Feature Information, page 1 • Prerequisites for Configuring DNS, page 2 • Information About DNS, page 2 • How to Configure DNS, page 4 • Configuration Examples for DNS, page 13 • Additional References, page 14 • Feature Information for DNS, page 15 Finding Feature Information Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
  • 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).
  • Reverse DNS What Is 'Reverse DNS'?

    Reverse DNS What Is 'Reverse DNS'?

    Reverse DNS Overview • Principles • Creating reverse zones • Setting up nameservers • Reverse delegation procedures What is ‘Reverse DNS’? • ‘Forward DNS’ maps names to numbers – svc00.apnic.net -> 202.12.28.131 • ‘Reverse DNS’ maps numbers to names – 202.12.28.131 -> svc00.apnic.net 1 Reverse DNS - why bother? • Service denial • That only allow access when fully reverse delegated eg. anonymous ftp • Diagnostics • Assisting in trace routes etc • SPAM identifications • Registration • Responsibility as a member and Local IR In-addr.arpa • Hierarchy of IP addresses – Uses ‘in-addr.arpa’ domain • INverse ADDRess • IP addresses: – Less specific to More specific • 210.56.14.1 • Domain names: – More specific to Less specific • delhi.vsnl.net.in – Reversed in in-addr.arpa hierarchy • 14.56.210.in-addr.arpa Principles • Delegate maintenance of the reverse DNS to the custodian of the address block • Address allocation is hierarchical – LIRs/ISPs -> Customers -> End users 2 Principles – DNS tree - Mapping numbers to names - ‘reverse DNS’ Root DNS net edu com arpa au apnic in-addr whoiswhois RIR 202202 203 210 211.. ISP 6464 22 .64.202 .in-addr.arpa Customer 2222 Creating reverse zones • Same as creating a forward zone file – SOA and initial NS records are the same as normal zone – Main difference • need to create additional PTR records • Can use BIND or other DNS software to create and manage reverse zones – Details can be different Creating reverse zones - contd • Files involved – Zone files • Forward zone file – e.g. db.domain.net • Reverse zone file – e.g. db.192.168.254 – Config files • <named.conf> – Other • Hints files etc.
  • Service (SRV) Records

    Service (SRV) Records

    Service (SRV) Records You deploy multiple DNS SRV records in different locations on your enterprise DNS structure. Understand which records you should provision on which name servers. Review examples of SRV records to ensure a successful deployment. • Deploy SRV Records, page 1 • SRV Records, page 4 Deploy SRV Records The client queries name servers for records in the services domain. The services domain is determined as described in How the Client Discovers Available Services. You must deploy SRV records in each DNS zone for those service domains if your organization has multiple subsets of users who use different service domains. Deploy SRV Records in a Separate Domain Structure In a separate name design there are two domains, an internal domain and an external domain. The client queries for SRV records in the services domain. The internal name server must serve records for the services domain. However in a separate name design, a zone for the services domain might not exist on the internal name server. If the services domain is not currently served by the internal name server, you can: • Deploy records within an internal zone for the services domain. • Deploy records within a pinpoint subdomain zone on the internal name server. Use an Internal Zone for a Services Domain If you do not already have a zone for the services domain on the internal name server, you can create one. This method makes the internal name server authoritative for the services domain. Because it is authoritative, the internal name server does not forward queries to any other name server.
  • 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.
  • DNS) Administration Guide

    DNS) Administration Guide

    Edgecast Route (DNS) Administration Guide Disclaimer Care was taken in the creation of this guide. However, Edgecast cannot accept any responsibility for errors or omissions. There are no warranties, expressed or implied, including the warranty of merchantability or fitness for a particular purpose, accompanying this product. Trademark Information EDGECAST is a registered trademark of Verizon Digital Media Services Inc. About This Guide Route (DNS) Administration Guide Version 2.40 8/28/2021 ©2021 Verizon Media. All rights reserved. Table of Contents Route ............................................................................................................................................................. 1 Introduction .............................................................................................................................................. 1 Scope ......................................................................................................................................................... 1 Module Comparison ................................................................................................................................. 2 Managed (Primary) or Secondary DNS Module .................................................................................... 2 DNS Health Checks Module .................................................................................................................. 3 Billing Activation ......................................................................................................................................
  • Guidelines for the Secure Deployment of Ipv6

    Guidelines for the Secure Deployment of Ipv6

    Special Publication 800-119 Guidelines for the Secure Deployment of IPv6 Recommendations of the National Institute of Standards and Technology Sheila Frankel Richard Graveman John Pearce Mark Rooks NIST Special Publication 800-119 Guidelines for the Secure Deployment of IPv6 Recommendations of the National Institute of Standards and Technology Sheila Frankel Richard Graveman John Pearce Mark Rooks C O M P U T E R S E C U R I T Y Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930 December 2010 U.S. Department of Commerce Gary Locke, Secretary National Institute of Standards and Technology Dr. Patrick D. Gallagher, Director GUIDELINES FOR THE SECURE DEPLOYMENT OF IPV6 Reports on Computer Systems Technology The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technology. ITL’s responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800-series reports on ITL’s research, guidance, and outreach efforts in computer security and its collaborative activities with industry, government, and academic organizations. National Institute of Standards and Technology Special Publication 800-119 Natl. Inst. Stand. Technol. Spec. Publ. 800-119, 188 pages (Dec. 2010) Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately.
  • 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.
  • DNS) Deployment Guide

    DNS) Deployment Guide

    Archived NIST Technical Series Publication The attached publication has been archived (withdrawn), and is provided solely for historical purposes. It may have been superseded by another publication (indicated below). Archived Publication Series/Number: NIST Special Publication 800-81 Revision 1 Title: Secure Domain Name System (DNS) Deployment Guide Publication Date(s): April 2010 Withdrawal Date: September 2013 Withdrawal Note: SP 800-81 Revision 1 is superseded in its entirety by the publication of SP 800-81-2 (September 2013). Superseding Publication(s) The attached publication has been superseded by the following publication(s): Series/Number: NIST Special Publication 800-81-2 Title: Secure Domain Name System (DNS) Deployment Guide Author(s): Ramaswamy Chandramouli, Scott Rose Publication Date(s): September 2013 URL/DOI: http://dx.doi.org/10.6028/NIST.SP.800-81-2 Additional Information (if applicable) Contact: Computer Security Division (Information Technology Lab) Latest revision of the SP 800-81-2 (as of August 7, 2015) attached publication: Related information: http://csrc.nist.gov/ Withdrawal N/A announcement (link): Date updated: ƵŐƵƐƚϳ, 2015 Special Publication 800-81r1 Sponsored by the Department of Homeland Security Secure Domain Name System (DNS) Deployment Guide Recommendations of the National Institute of Standards and Technology Ramaswamy Chandramouli Scott Rose i NIST Special Publication 800-81r1 Secure Domain Name System (DNS) Deployment Guide Sponsored by the Department of Homeland Security Recommendations of the National Institute of Standards and Technology Ramaswamy Chandramouli Scott Rose C O M P U T E R S E C U R I T Y Computer Security Division/Advanced Network Technologies Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899 April 2010 U.S.
  • DNS Performance – a Study of Free, Public and Popular DNS Servers in 2019

    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.