Jessica M. Crane, CPSC 550

Case Study:

Name Services

Jessica M. Crane

CPSC 550

Table of Contents

History …………………………………… 2

Goals …………………………………… 3

Definitions …………………………………… 4

Features …………………………………… 5

Structure …………………………………… 5

How to Use …………………………………… 10

Applications …………………………………… 11

Significance of Points …………………………………… 12

Summary …………………………………… 12

References …………………………………… 13

13

Jessica M. Crane, CPSC 550

HISTORY

In the late 1960’s, the Department of Defense’s Advanced Research Projects Agency (ARPA) funded an experimental computer network. This network was called ARPAnet and allowed users to share computing resources. Each connected computer had to have a file called hosts.txt, which contained all the information about every host on the network, including name-to-address mapping. All that was needed to update the file upon changes was to email the file to everyone on the network. This system provided a name service in a single management domain and only needed to bind names to addresses. In its under developed state, hosts.txt was a sufficient means of connectivity, but would later become a huge problem. There would be an increased scale of distributed systems and the interconnection of networks, creating major name-mapping issues.

In the early 1980’s, Transmission Control Protocol and the Internet Protocol (TCP/IP) were developed, and they standardized connectivity to ARPAnet for all computers. TCP/IP greatly increased the number of computers connected and at that point, the network became known as the Internet. The problems that the limitations of hosts.txt now presented were severe. Traffic and load problems with distributing hosts.txt caused much network traffic and processor load. More users resulted in more names being created and name collisions came about because no two hosts can have the same name. The Network Information Center (NIC) ensured that the addresses were unique, but it had no control over host names. There also arose a problem with consistency of the file. The constantly expanding network meant that there was always a new hosts.txt file being sent out and all hosts did not have consistent data. It was abundantly clear that a new system was essential.

As a result of the complications with the hosts.txt file and the steadily increasing number of users, the NIC called for the design of a distributed database to replace the current system. The old system was centralized and possessed a single-host bottleneck. A new system was needed that should use hierarchical namespace to name hosts, thus ensuring the uniqueness of names. Hierarchic name spaces would allow the system to grow indefinitely. More goals included creating a system that solved problems in a cohesive host table system. The new system should also allow local administration of data and make that data available globally.

In 1984, Paul Mockapetris created of the Domain Name System (DNS). After that, the ARPAnet switched to a new system which has been the standard method for publishing and retrieving hostname information on the Internet ever since (Albitz, 2001). DNS is a name service design whose main naming database is used across the Internet. It is a distributed database, which is better than a static text-file listing of everyone on the Internet. It allows local control of the segments of the overall database, yet the data in each segment is available across the entire network through a client-server scheme. Under DNS, every connected computer does so through an Internet domain where each domain has a nameserver that maintains a database of its hosts and handles the requests for hostnames. An example domain name is defender.pcs.cnu.edu, which is a computer.

The Domain Name Service is the first example of a name service, but there are others. They include Jini discovery service, Global Name Service (GNS), and the X500 directory service. If a host is connected to the Internet, there is no alternate option other than setting up and managing name servers. Even though DNS is the primary means of name resolution, the /etc/hosts file is still found on most machines because it can help speed up the IP address lookup of frequently requested addresses.

People and computers do not process information in the same way. Referencing hosts by their Internet Protocol (IP) addresses is convenient for computers given their binary structure, but humans have an easier time using names. Names are easy to create and easy to recall for people, but difficult to resolve with TCP/IP protocols. However, humans need names. Thus, it is apparent that there is a need for some sort of translation table to convert the IP addresses to hostnames. With millions of machines on the Internet, the difficulties of maintaining the Internet decreases in an orderly fashion make clear the need for modification to the service, and consequences name services can adhere.

GOALS

The objective of a name service is to gather or look up attributes of an object by providing an object’s name. Attributes are clearly more powerful than names as designators of objects. It is easier to make a program that selects objects according to the attributes instead of trying to select names that may not even be known. Attributes do not expose the structure of organizations to the outside world, as an organized and partitioned name would. The main goals of name services are to handle very large name spaces, have a long life cycle, and have a high availability. Fault tolerance is also an essential goal because when local failures occur, the entire service must not collapse. An additional area of concern is the structure of the name space, is that the syntax and resolution rules are always changing. Navigation of the distribution across servers is also a design issue along with replication and caching.

The original goals of the Domain Name System were to scale large numbers of computers, allow local organizations to administer their own naming systems, and provide an all-purpose naming system, not just one that is only used for looking up computer addresses. The goals of the Global Name Service, in contrast, are more ambitious than those of DNS. They include handling a discretionary number of names and serving a discretionary number of administrative organizations, such as a system that can handle the electronic mail addresses of all of the computer users in the world. More GNS goals, that are the same as any generic name service, include a long life, have high availability, and fault isolation. Lastly, tolerance of mistrust is an additional goal of GNS because an open system cannot have components that are trusted by all of the clients in a large system.

DEFINITIONS

Names, in a distributed system, refer to resources such as computers, services, remote objects and files, as well as users. Names are needed to refer to entities such as users with proper names, login names, user identifiers, and electronic mail addresses. More examples include computers with host names such as defender and services such as file service, and printer service. Textual names are used to identify people, as in email addresses, and individual services like Uniform Resource Identifiers (URI). Textual names also identify groups of objects such as hosts.

A name service stores a collection of naming contexts, which are sets of bindings between textual names and attributes for objects such as the users, computer, services, and remote objects. The main function of a name service is to resolve a name, which make communication and resource sharing possible. Name services provide management in a distributed system, which is very open. Name services unify resources managed by different services by ensuring that they all use the same naming scheme, such as a URL. They also integrate different administrative domains, where name resources are created. Even though the administrative domains are different, they will share a common name service.

Replicating a directory constitutes copying it. This is done for performance and availability. Caching is storing previously looked up information. These two features allow for the robustness and adequate performance of a name service. The Domain Name Service relies heavily on replication and caching of naming data to provide sufficient service.

FEATURES & STRUCTURES

Name services look up attributes of an object by providing an object’s name. They are hierarchical in structure. The DNS maps domain names to IP addresses. It is mostly used for host names and email addresses. Web browsers use DNS to interpret the domain names in URLs while email clients use DNS to interpret the domain names in email addresses. The overhead involved in managing zones and their name servers can outweigh the benefits of using DNS. There are three elements of the Internet DNS that allow lookup to be made against it from around the world. They are the hierarchical partitioning of the name database, replication of the naming data, and caching.

Replication is a technique for increasing availability, fault tolerance, and sometimes performance. It is part of a domain-based network operating system in which more than one physical machine provides services such as logon authentication, access to resources, and other
"domain controller" duties. The major tradeoff is that it performs under less than perfect conditions, such as network failures and server shutdowns. The process of copying data from one computer to another, in such a way that both sets of data will be identical, and updates made to one set will be propagated to the others. Thus, files will be duplicated exactly and synchronized periodically to ensure that the contents remain identical.

A name server is a program that contains information about some parts of the database and makes it available to the clients. A resolver is a library routine that creates queries and sends them over a network to a name server. In name services, including DNS, client resolution software and servers maintain a cache of the results of previous name resolutions. When a client requests a name lookup, the name resolution software consults its cache. If the name exists in the cache from a previous lookup, the software returns it to the client. If the name does not exist there, the software relays from server to server until finding the name. Part of its success is owed to the rare changing of naming data, but it is possible to get an out-of-date attribute. Caching is essential to name services and their performance because it assists in maintaining the availability of services despite name server crashes. It can also be used to eliminate high-level name servers, like the root server, from the navigation path. Shortening the navigation path allows resolution to proceed despite some server failures.

UNIX File System

DNS Structure

The structure of DNS is similar to the structure of the UNIX file system. It is a hierarchical tree with the root set to null. Each node is the root of a new subtree and each subtree represents a partition of the overall database or a domain in the DNS. Each domain can be further divided into partitions, called subdomains in DNS. For example, Network Solutions runs the edu domain, but delegates cnu.edu subdomain to CNU. The goal of delegation is to decentralize administration. For the purpose of the Domain Name System, delegation refers to an organization being responsible for maintaining all data in their subdomains. A subdomain has permission to divide into more and/or change the data. A path is a domain name space and is read from the bottom node to the root. The highest level of the hierarchy is the last component, or label, of the CNU address. This method ensures that two subdirectories or files do not have the same name.

GNS Structure

The Global Name Service maps global names to their attributes. GNS provides resource information, authentication, and mailing addresses. Problems with DNS that were resolved in GNS are the rigid structure of the name space and lack of customization of name space to local needs. GNS is essential to a database that must be replicated at every node. Caching is essential to GNS because it is a naming database that is composed of a tree of directories holding names and values. However, it is hard to uphold complete consistency between all copies of a database entry because of the caching. Names in GNS include directory names and value names. A directory name example includes ab/cd/ef/qwm. A value name includes jessie.crane/password and refers to a value tree.

X500 Directory Tree

A directory service stores collections of bindings between names and attributes and also looks up entries that match attribute-based specifications. Directory services return attributes of any objects found to match some specified attributes. For example, a request with a phone number can return the person’s name, thus giving it the nickname ‘yellow pages service.’ The X500 directory service provides attribute-based name service by mapping a person’s name to his or her email address and phone number. X500 uses Directory Information Tree (DIT) that is a tree structure starting with a root. It also a client/server connection that uses caching and replication to make it robust.


Jini Discovery Service

A discovery service is a directory service that registers the services provided in a spontaneous networking environment. Spontaneous networks have devices that are liable to connect without warning. Discovery services must integrate sets of clients and services that are changing dynamically, without user involvement. To meet these needs, it includes an interface that allows the clients and services to register and de-register. The Jini discovery service looks up objects according to attributes. Jini provides users with access to services from laptops while away from the location of the service. The services tell the system of their existence and attributes. The look-up service registers and stores information about the service while the Jini services provide objects and attributes for the service. Jini clients request services that match requirements. Using an example of a service, such as a printer, the first step is a server and a client joining Jini dynamically. The look-up service registers the printer name and type. On entering, clients and servers send request to multicast address and the look-up service replies with the address of the printer. The client then contacts the printer directly.