Development of the Domain Name System*

Total Page:16

File Type:pdf, Size:1020Kb

Development of the Domain Name System* Development of the Domain Name System* Paul V. Mockapetris USC Information Sciences Institute, Marina del Rey, California Kevin J. Dunlap Digital Equipment Corp., DECwest Engineering, Washington (Originally published in the Proceedings of SIGCOMM ‘88, Computer Communication Review Vol. 18, No. 4, August 1988, pp. 123–133.) Abstract Simple growth was one cause of these problems; an- The Domain Name System (DNS) provides name other was the evolution of the community using service for the DARPA Internet. It is one of the largest HOSTS.TXT from the NCP-based original ARPANET name services in operation today, serves a highly to the IP/TCP-based Internet. The research diverse community of hosts, users, and networks, and ARPANET’s role had changed from being a single uses a unique combination of hierarchies, caching, and network connecting large timesharing systems to being datagram access. one of the several long-haul backbone networks linking local networks which were in turn populated with This paper examines the ideas behind the initial design workstations. The number of hosts changed from the of the DNS in 1983, discusses the evolution of these number of timesharing systems (roughly organizations) ideas into the current implementations and usages, to the number of workstations (roughly users). This notes conspicuous surprises, successes and increase was directly reflected in the size of shortcomings, and attempts to predict its future evo- HOSTS.TXT, the rate of change in HOSTS.TXT, and lution. the number of transfers of the file, leading to a much larger than linear increase in total resource use for 1. Introduction distributing the file. Since organizations were being forced into management of local network addresses, The genesis of the DNS was the observation, circa gateways, etc., by the technology anyway, it was quite 1982, that the HOSTS.TXT system for publishing the logical to want to partition the database and allow local mapping between host names and addresses was control of local name and address spaces. A distributed encountering or headed for problems. HOSTS.TXT is naming system seemed in order. the name of a simple text file, which is centrally maintained on a host at the SRI Network Information Existing distributed naming systems included the Center (SRI-NIC) and distributed to all hosts in the DARPA Internet’s IEN116 [IEN 116] and the XEROX Internet via direct and indirect file transfers. Grapevine [Birrell 82] and Clearinghouse systems [Oppen 83]. The IEN116 services seemed excessively The problems were that the file, and hence the costs of limited and host specific, and IEN116 did not provide its distribution, were becoming too large, and that the much benefit to justify the costs of renovation. The centralized control of updating did not fit the trend XEROX system was then, and may still be, the most toward more distributed management of the Internet. sophisticated name service in existence, but it was not *This research was supported by the Defense Advanced Research Projects Agency under contract MDA903-87-C-0719. Views and conclusions contained in this report are the authors’ and should not be interpreted as representing the official opinion or policy of DARPA, the U.S. government, or any person or agency connected with them. Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. ACM SIGCOMM -1- Computer Communication Review clear that its heavy use of replication, light use of architecture, or organizational style onto its caching, and fixed number of hierarchy levels were users. This idea applied all the way from appropriate for the heterogeneous and often chaotic concerns about case sensitivity to the idea that style of the DARPA Internet. Importing the XEROX the system should be useful for both large design would also have meant importing supporting timeshared hosts and isolated PCs. In general, elements of its protocol architecture. For these reasons, we wanted to avoid any constraints on the system a new design was begun. due to outside influences and permit as many different implementation structures as possible. The initial design of the DNS was specified in [RFC 882, RFC 883]. The outward appearance is a The HOSTS.TXT emulation requirement was not hierarchical name space with typed data at the nodes. particularly severe, but it did cause an early Control of the database is also delegated in a examination of schemes for storing data other than hierarchical fashion. The intent was that the data types name-to-address mappings. A hierarchical name space be extensible, with the addition of new data types seemed the obvious and minimal solution for the continuing indefinitely as new applications were distribution and size requirements. The interoperability added. Although the system has been modified and and performance constraints implied that the system refined in several areas [RFC 973, RFC 974], the would have to allow database information to be current specifications [RFC 1034, RFC 1035] and buffered between the client and the source of the data, usage are quite similar to the original definitions. since access to the source might not be possible or timely. Drawing an exact line between experimental use and production status is difficult, but 1985 saw some hosts The initial DNS design assumed the necessity of use the DNS as their sole means of accessing naming striking a balance between a very lean service and a information. While the DNS has not replaced the completely general distributed database. A lean service HOSTS.TXT mechanism in many older hosts, it is the was desirable because it would result in more standard mechanism for hosts, particularly those based implementation efforts and early availability. A general on Berkeley UNIX, that track progress in network and design would amortize the cost of introduction across operating system design. more applications, provide greater functionality, and increase the number of environments in which the DNS would eventually be used. The “leanness” 2. DNS Design criterion led to a conscious decision to omit many of The base design assumptions for the DNS were that it the functions one might expect in a state-of-the-art must: database. In particular, dynamic update of the database P with the related atomicity, voting, and backup provide at least all of the same information as considerations was omitted. The intent was to add HOSTS.TXT. these eventually, but it was believed that a system that P Allow the database to be maintained in a included these features would be viewed as too distributed manner. complex to be accepted by the community. P Have no obvious size limits for names, name components, data associated with a name, etc. 2.1 The architecture P Interoperate across the DARPA Internet and in The active components of the DNS are of two major as many other environments as possible. types: name servers and resolvers. Name servers are P Provide tolerable performance. repositories of information, and answer queries using whatever information they possess. Resolvers interface Derivative constraints included the following: to client programs, and embody the algorithms P The cost of implementing the system could only necessary to find a name server that has the be justified if it provided extensible services. In information sought by the client. particular, the system should be independent of network topology, and capable of encapsulating These functions may be combined or separated to suit other name spaces. the needs of the environment. In many cases, it is useful to centralize the resolver function in one or more P In order to be universally acceptable, the system special name servers for an organization. This should avoid trying to force a single OS, structure shares the use of cached information, and also ACM SIGCOMM -2- Computer Communication Review allows less capable hosts, such as PCs, to rely on the the domain space), but the default assumption is that resolving services of special servers without needing a the only way to tell definitely what a name represents resolver in the PC. is to look at the data associated with the name. The recommended name space structure for hosts, 2.2 The name space users, and other typical applications is one that mirrors the structure of the organization controlling the local The DNS internal name space is a variable-depth tree domain. This is convenient since the DNS features for where each node in the tree has an associated label. distributing control of the database is most efficient The domain name of a node is the concatenation of all when it parallels the tree structure. An administrative labels on the path from the node to the root of the tree. decision [RFC 920] was made to make the top levels Labels are variable-length strings of octets, and each correspond to country codes or broad organization octet in a label can be any 8-bit value. The zero length types (for example EDU for educational, MIL for label is reserved for the root. Name space searching military, UK for Great Britain). operations (for operations defined at present) are done in a case-insensitive manner (assuming ASCII). Thus the labels “Paul”, “paul”, and “PAUL”, would match 2.3 Data attached to names each other. This matching rule effectively prohibits the Since the DNS should not constrain the data that creation of brother nodes with labels having equivalent applications can attach to a name, it can’t fix the data’s spelling but different case.
Recommended publications
  • Privacy Policy V1.1
    CENTRALNIC LTD REGISTRY PRIVACY POLICY Version 1.1 September 2018 CentralNic Ltd 35-39 Moorgate London EC2R 6AR Table of Contents TABLE OF CONTENTS ......................................................................................................................... 2 AMENDMENT ISSUE SHEET ................................................................................................................. 3 INTRODUCTION ................................................................................................................................ 4 DATA PROTECTION RIGHTS ................................................................................................................. 5 RELATIONSHIP WITH REGISTRARS ......................................................................................................... 6 WHAT INFORMATION CENTRALNIC COLLECTS .......................................................................................... 6 INFORMATION CENTRALNIC DOES NOT COLLECT ....................................................................................... 8 HOW INFORMATION IS STORED ............................................................................................................ 8 HOW WE USE INFORMATION ............................................................................................................... 8 HOW INFORMATION IS PROTECTED ..................................................................................................... 13 HOW INFORMATION IS DELETED ........................................................................................................
    [Show full text]
  • 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.
    [Show full text]
  • Adopting Encrypted DNS in Enterprise Environments
    National Security Agency | Cybersecurity Information Adopting Encrypted DNS in Enterprise Environments Executive summary Use of the Internet relies on translating domain names (like “nsa.gov”) to Internet Protocol addresses. This is the job of the Domain Name System (DNS). In the past, DNS lookups were generally unencrypted, since they have to be handled by the network to direct traffic to the right locations. DNS over Hypertext Transfer Protocol over Transport Layer Security (HTTPS), often referred to as DNS over HTTPS (DoH), encrypts DNS requests by using HTTPS to provide privacy, integrity, and “last mile” source authentication with a client’s DNS resolver. It is useful to prevent eavesdropping and manipulation of DNS traffic. While DoH can help protect the privacy of DNS requests and the integrity of responses, enterprises that use DoH will lose some of the control needed to govern DNS usage within their networks unless they allow only their chosen DoH resolver to be used. Enterprise DNS controls can prevent numerous threat techniques used by cyber threat actors for initial access, command and control, and exfiltration. Using DoH with external resolvers can be good for home or mobile users and networks that do not use DNS security controls. For enterprise networks, however, NSA recommends using only designated enterprise DNS resolvers in order to properly leverage essential enterprise cybersecurity defenses, facilitate access to local network resources, and protect internal network information. The enterprise DNS resolver may be either an enterprise-operated DNS server or an externally hosted service. Either way, the enterprise resolver should support encrypted DNS requests, such as DoH, for local privacy and integrity protections, but all other encrypted DNS resolvers should be disabled and blocked.
    [Show full text]
  • Chapter 2. Application Layer Table of Contents 1. Context
    Chapter 2. Application Layer Table of Contents 1. Context ........................................................................................................................................... 1 2. Introduction .................................................................................................................................... 2 3. Objectives ....................................................................................................................................... 2 4. Network application software ....................................................................................................... 2 5. Process communication ................................................................................................................. 3 6. Transport Layer services provided by the Internet ....................................................................... 3 7. Application Layer Protocols ........................................................................................................... 4 8. The web and HTTP .......................................................................................................................... 4 8.1. Web Terminology ................................................................................................................... 5 8.2. Overview of HTTP protocol .................................................................................................... 6 8.3. HTTP message format ...........................................................................................................
    [Show full text]
  • Analysis of Malware and Domain Name System Traffic
    Analysis of Malware and Domain Name System Traffic Hamad Mohammed Binsalleeh A Thesis in The Department of Computer Science and Software Engineering Presented in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy at Concordia University Montréal, Québec, Canada July 2014 c Hamad Mohammed Binsalleeh, 2014 CONCORDIA UNIVERSITY Division of Graduate Studies This is to certify that the thesis prepared By: Hamad Mohammed Binsalleeh Entitled: Analysis of Malware and Domain Name System Traffic and submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy complies with the regulations of this University and meets the accepted standards with respect to originality and quality. Signed by the final examining committee: Chair Dr. Christian Moreau External Examiner Dr. Nadia Tawbi Examiner to Program Dr. Lingyu Wang Examiner Dr. Peter Grogono Examiner Dr. Olga Ormandjieva Thesis Co-Supervisor Dr. Mourad Debbabi Thesis Co-Supervisor Dr. Amr Youssef Approved by Chair of the CSE Department 2014 Dean of Engineering ABSTRACT Analysis of Malware and Domain Name System Traffic Hamad Mohammed Binsalleeh Concordia University, 2014 Malicious domains host Command and Control servers that are used to instruct in- fected machines to perpetuate malicious activities such as sending spam, stealing creden- tials, and launching denial of service attacks. Both static and dynamic analysis of malware as well as monitoring Domain Name System (DNS) traffic provide valuable insight into such malicious activities and help security experts detect and protect against many cyber attacks. Advanced crimeware toolkits were responsible for many recent cyber attacks. In order to understand the inner workings of such toolkits, we present a detailed reverse en- gineering analysis of the Zeus crimeware toolkit to unveil its underlying architecture and enable its mitigation.
    [Show full text]
  • Internet Domain Name System
    IINNTTEERRNNEETT DDOOMMAAIINN NNAAMMEE SSYYSSTTEEMM http://www.tutorialspoint.com/internet_technologies/internet_domain_name_system.htm Copyright © tutorialspoint.com Overview When DNS was not into existence, one had to download a Host file containing host names and their corresponding IP address. But with increase in number of hosts of internet, the size of host file also increased. This resulted in increased traffic on downloading this file. To solve this problem the DNS system was introduced. Domain Name System helps to resolve the host name to an address. It uses a hierarchical naming scheme and distributed database of IP addresses and associated names IP Address IP address is a unique logical address assigned to a machine over the network. An IP address exhibits the following properties: IP address is the unique address assigned to each host present on Internet. IP address is 32 bits 4bytes long. IP address consists of two components: network component and host component. Each of the 4 bytes is represented by a number from 0 to 255, separated with dots. For example 137.170.4.124 IP address is 32-bit number while on the other hand domain names are easy to remember names. For example, when we enter an email address we always enter a symbolic string such as [email protected]. Uniform Resource Locator URL Uniform Resource Locator URL refers to a web address which uniquely identifies a document over the internet. This document can be a web page, image, audio, video or anything else present on the web. For example, www.tutorialspoint.com/internet_technology/index.html is an URL to the index.html which is stored on tutorialspoint web server under internet_technology directory.
    [Show full text]
  • Web Portal User Manual For
    Web Portal User Manual for ©Copyright 2009 Afilias Limited Afilias Managed DNS – Web Portal User Manual Contents 1. Introduction ................................................................................................................ 1 1.1 About Afilias Managed DNS Service ........................................................................ 1 1.2 Afilias Managed DNS Service Website Help ............................................................. 1 1.3 Support .................................................................................................................. 2 2. DNS Portal Login Screen ............................................................................................... 4 3. MyAccount Screen ....................................................................................................... 5 3.1 Users & Groups ...................................................................................................... 5 3.1.1 User Details Tab ...................................................................................................... 6 3.1.2 User Password Tab .................................................................................................. 7 3.1.3 Users Tab ................................................................................................................. 8 3.1.4 Groups Tab .............................................................................................................. 9 3.2 Add User ...............................................................................................................
    [Show full text]
  • Secure Shell- Its Significance in Networking (Ssh)
    International Journal of Application or Innovation in Engineering & Management (IJAIEM) Web Site: www.ijaiem.org Email: [email protected] Volume 4, Issue 3, March 2015 ISSN 2319 - 4847 SECURE SHELL- ITS SIGNIFICANCE IN NETWORKING (SSH) ANOOSHA GARIMELLA , D.RAKESH KUMAR 1. B. TECH, COMPUTER SCIENCE AND ENGINEERING Student, 3rd year-2nd Semester GITAM UNIVERSITY Visakhapatnam, Andhra Pradesh India 2.Assistant Professor Computer Science and Engineering GITAM UNIVERSITY Visakhapatnam, Andhra Pradesh India ABSTRACT This paper is focused on the evolution of SSH, the need for SSH, working of SSH, its major components and features of SSH. As the number of users over the Internet is increasing, there is a greater threat of your data being vulnerable. Secure Shell (SSH) Protocol provides a secure method for remote login and other secure network services over an insecure network. The SSH protocol has been designed to support many features along with proper security. This architecture with the help of its inbuilt layers which are independent of each other provides user authentication, integrity, and confidentiality, connection- oriented end to end delivery, multiplexes encrypted tunnel into several logical channels, provides datagram delivery across multiple networks and may optionally provide compression. Here, we have also described in detail what every layer of the architecture does along with the connection establishment. Some of the threats which Ssh can encounter, applications, advantages and disadvantages have also been mentioned in this document. Keywords: SSH, Cryptography, Port Forwarding, Secure SSH Tunnel, Key Exchange, IP spoofing, Connection- Hijacking. 1. INTRODUCTION SSH Secure Shell was first created in 1995 by Tatu Ylonen with the release of version 1.0 of SSH Secure Shell and the Internet Draft “The SSH Secure Shell Remote Login Protocol”.
    [Show full text]
  • ICANN Registry Request Service
    ICANN Registry Request Service Ticket ID: X8T8C-0S4B2 Registry Name: Public Interest Registry gTLD: .org Status: ICANN Review Status Date: 2013-06-04 22:05:48 Print Date: 2013-06-04 22:06:10 Proposed Service Name of Proposed Service: Technical description of Proposed Service: Technical Description of Proposed Service: Background: BTAPPA will be beneficial in situations where one ICANN-accredited registrar purchases (the "Gaining Registrar"), by means of a stock or asset purchase, merger or similar transaction, a portion, but not all, of another ICANN accredited registrar's domain name portfolio ("Losing Registrar") in the .ORG top-level domains ("TLDs") or where a Gaining Registrar receives a request from a registrant to transfer a significant number of its domain names from a Losing Registrar to such Gaining Registrar. Unless an entire portfolio of domain names is being transferred, Gaining Registrars must request that each domain name be transferred individually. Gaining Registrars must meet the following requirements: oGaining Registrar must be ICANN accredited for the .ORG TLD. oGaining Registrar must be in good standing and be under a Registry-Registrar Agreement with PIR. oGaining Registrar must provide PIR with evidence (i.e., affidavit, sale documents) that sets forth the transfer date or, if an acquisition, the target closing date. oIf domain names are to be transferred from multiple Losing Registrars, then they must be Registrar Affiliates. A Registrar Affiliate is a registrar entity that controls, is controlled by or is under common control with, another the Losing Registrar. oTransfers of domain names to multiple Gaining Registrars will not be permitted, regardless of familiar relationship.
    [Show full text]
  • A Diversified Set of Security Features for XMPP Communication Systems
    International Journal on Advances in Security, vol 6 no 3 & 4, year 2013, http://www.iariajournals.org/security/ 99 A Diversified Set of Security Features for XMPP Communication Systems Useful in Cloud Computing Federation Antonio Celesti, Massimo Villari, and Antonio Puliafito DICIEAMA, University of Messina Contrada di Dio, S. Agata, 98166 Messina, Italy. e-mail: facelesti, mvillari, apuliafi[email protected] Abstract—Nowadays, in the panorama of Cloud Computing, Presence Protocol (XMPP), i.e., an open-standard commu- finding a right compromise between interactivity and security nications protocol for message-oriented middleware based is not trivial at all. Currently, most of Cloud providers base on the XML (Extensible Markup Language). On one hand, their communication systems on the web service technology. The problem is that both Cloud architectures and services the XMPP is able to overcome the disadvantages of web have started as simple but they are becoming increasingly services in terms of performance, but on the other hand complex. Consequently, web services are often inappropriate. it lacks of native security features for addressing the new Recently, many operators in both academia and industry are emerging Cloud computing scenarios. evaluating the eXtensible Messaging and Presence Protocol for In this paper, we discuss how the XMPP can be adopted the implementation of Cloud communication systems. In fact, the XMPP offers many advantages in term of real-time capa- for the development of secure Cloud communication sys- bilities, efficient data distribution, service discovery, and inter- tems. In particular, we combine and generalize the assump- domain communication compared to web service technologies. tions made in our previous works respectively regarding how Nevertheless, the protocol lacks of native security features.
    [Show full text]
  • Afilias Limited Request 28 January 2020
    Registry Services Evaluation Policy (RSEP) Request January 17, 2020 Registry Operator Afilias Limited Request Details Case Number: 00941695 This Registry Services Evaluation Policy (RSEP) request form should be submitted for review by ICANN org when a registry operator is adding, modifying, or removing a Registry Service for a TLD or group of TLDs. The RSEP Process webpage provides additional information about the process and lists RSEP requests that have been reviewed and/or approved by ICANN org. If you are proposing a service that was previously approved, we encourage you to respond similarly to the most recently approved request(s) to facilitate ICANN org’s review. Certain known Registry Services are identified in the Naming Services portal (NSp) case type list under “RSEP Fast Track” (example: “RSEP Fast Track – BTAPPA”). If you would like to submit a request for one of these services, please exit this case and select the specific Fast Track case type. Unless the service is identified under RSEP Fast Track, all other RSEP requests should be submitted through this form. Helpful Tips • Click the “Save” button to save your work. This will allow you to return to the request at a later time and will not submit the request. • You may print or save your request as a PDF by clicking the printer icon in the upper right corner. You must click “Save” at least once in order to print the request. • Click the “Submit” button to submit your completed request to ICANN org. • Complete the information requested below. All fields marked with an asterisk (*) are required.
    [Show full text]
  • Domain Name System System Work?
    What is the DNS? - how it works Isaac Maposa | Dev Anand Teelucksingh | Beran Gillen Community Onboarding Program | 11 March 2017 Agenda 1 2 3 What is the Domain Structure of the How does the Name System? Domain Name Domain Name System System Work? 4 5 6 Who makes the Stakeholders in the Engage with ICANN Domain Name Domain Name ??? System Work? System. | 2 What is the Domain Name System (DNS)? The Internet, what is it..? ● The Internet is a network of networks that interconnects devices to exchange information. ● In order to “talk” to each other, all of these devices must have a unique numerical address called an Internet Protocol address or IP Address. An example of an IP address is 94.127.53.132 ● When you visit a website from your browser, you are requesting the website from your device’s IP address to the web server’s IP address. ● However, you don’t type in the ip address of the web server, rather the domain name of for example www.google.com ● In so doing, you have queried the DNS. ● So what is this DNS???? | 4 What is the Domain Name System? ● The Domain Name System or DNS overcomes this problem of remembering IP addresses by mapping domain names to IP addresses. ● While this sounds like a phone book, it is not a centralised database. ● The DNS is a distributed database across a hierarchy of networks of servers and provide ways for devices and software (like browsers and email) to query the DNS to get an IP address. ● Domain names must be unique.
    [Show full text]