Naming Services

In a distributed system, names are used to

refer to a wide variety of resources such as
computers, services, remote objects and
files, as well as to users. Naming is an
issue that is easily overlooked but is
nonetheless fundamental in distributed
system design. Names facilitate
communication and resource sharing. A
name is needed to request a computer
system to act upon a specific resource
chosen out of many; for example, a name
in the form of a URL is needed to access a
specific web page.
Naming Services

Names are not the only useful means of

identification: descriptive attributes are
another. Sometimes clients do not know the
name of the particular entity that they seek, but
they do have some information that describes
it. Or they may require a service and know
some of its characteristics but not what entity
implements it.
Naming Services
A name service stores information about a
collection of textual names, in the form of
bindings between the names and the attributes
of the entities they denote, such as users,
computers, services and objects. The collection
is often subdivided into one or more naming
contexts: individual subsets of the bindings
that are managed as a unit. The major
operation that a name service supports is to
resolve a name – that is, to look up attributes
from a given name.
Naming Services
A name service stores information about a
collection of textual names, in the form of
bindings between the names and the attributes
of the entities they denote, such as users,
computers, services and objects. The collection
is often subdivided into one or more naming
contexts: individual subsets of the bindings
that are managed as a unit. The major
operation that a name service supports is to
resolve a name – that is, to look up attributes
from a given name.
Naming Services
Name management is separated from other services largely
because of the openness of distributed systems, which brings
the following motivations:

Unification: It is often convenient for resources

managed by different services to use the same
naming scheme. URIs are a good example of this.

Integration: It is not always possible to predict the

scope of sharing in a distributed system. It may
become necessary to share and therefore name
resources that were created in different
administrative domains.
General name service requirements

Name services were originally quite simple,

since they were designed only to meet the need
to bind names to addresses in a single
management domain, corresponding to a single
LAN or WAN. The interconnection of networks
and the increased scale of distributed systems
have produced a much larger name-mapping
problem.
General name service requirements

The Global Name Service, developed at the

Digital Equipment Corporation Systems
Research Center [Lampson 1986], is a
descendant of Grapevine with ambitious goals,
including: To handle an essentially arbitrary
number of names and to serve an arbitrary
number of administrative organizations: For
example, the system should be capable of
handling the names of all the documents in the
world.
Naming Spaces
A name space is the collection of all valid names recognized
by a particular service. The service will attempt to look up a
valid name, even though that name may prove not to
correspond to any object – i.e., to be unbound. Name spaces
require a syntactic definition to separate valid names from
invalid names. For example, ‘...’ is not acceptable as the DNS
name of a computer, whereas www.cdk99.net is valid (even
though it is unbound).

Names may have an internal structure that represents their

position in a hierarchic name space such as pathnames in a
file system, or in an organizational hierarchy such as
Internet domain names; or they may be chosen from a flat
set of numeric or symbolic identifiers.
Name resolution

For the common case of hierarchic name spaces, name

resolution is an iterative or recursive process whereby a
name is repeatedly presented to naming contexts in
order to look up the attributes to which it refers. A
naming context either maps a given name onto a set of
primitive attributes (such as those of a user) directly, or
maps it onto a further naming context and a derived
name to be presented to that context. To resolve a
name, it is first presented to some initial naming context;
resolution iterates as long as further contexts and
derived names are output.
Figure 13.2 Interative navigation

A client iteratively contacts name servers NS1-NS3

in order to resolve a name
Figure 13.2 Non-recursive and recursive server-controlled navigation

A name server NS1 communicate with other name

servers on behalf of a client
The Domain Name System

The Domain Name System is a name service design

whose main naming database is used across the
Internet. It was devised principally by Mockapetris and
specified in RFC 1034 [Mockapetris 1987] and RFC 1035.
DNS replaced the original Internet naming scheme, in
which all host names and addresses were held in a single
central master file and downloaded by FTP to all
computers that required them [Harrenstien et al. 1985].
This original scheme was soon seen to suffer from three
major shortcomings:
The Domain Name System

It did not scale to large numbers of computers.

Local organizations wished to administer their

own naming systems.

A general name service was needed - not one that

serves only for looking up computer addresses.
Domain Names

The DNS is designed for use in multiple

implementations, each of which may have its own name
space. In practice, however, only one is in widespread
use, and that is the one used for naming across the
Internet. The Internet DNS name space is partitioned
both organizationally and according to geography. The
names are written with the highest-level domain on the
right.
The original top-level organizational domains in use New top-level domains such as biz and mobi have
across the Internet were: been added since the early 2000s.

com Commercial organizations us United States

edu Universities and other educational uk United Kingdom
institutions
fr France
gov US governmental agencies
mil US military organizations
A full list of current generic domain names is
net Major network support centres available from the Internet Assigned Numbers
org Organizations not mentioned above Authority [www.iana.org I]. In addition, every
int International organizations country has its own domains:
Figure 13.4 DNS name servers
Navigation and query processing

A DNS client is called a resolver. It is normally

implemented as library software. It accepts queries,
formats them into messages in the form expected under
the DNS protocol and communicates with one or more
name servers in order to satisfy the queries. A simple
request-reply protocol is used, typically using UDP
packets on the Internet (DNS servers use a well-known
port number). The resolver times out and resends its
query if necessary. The resolver can be configured to
contact a list of initial name servers in order of
preference in case one or more are unavailable.
DNS Resource Records
Record type Meaning Main contents
A A computer address (IPv4) IPv4 number
AAAA A computer address (IPv6) IPv6 number
NS An outhoritative name server Domain name for server
CNAME The canonical name for an alias Domai name for alias
SOA Marks the start of data for zone Parameters governing the zone
PTR Domain name pointer (reserve Domain name
lookups)
HINFO Host information Machine architecture amd operating system
MX Mail exchange List of <preference, host> pairs
TXT Text string Arbitary text
 DNS zone data records

domain name Time to live Class Type value

dcs.qmul.ac.uk ID IN NS Dns0
dcs.qmul.ac.uk ID IN NS Dns1
dcs.qmul.ac.uk ID IN MX 1 mail1.qmul.ac.uk
dcs.qmul.ac.uk ID IN MX 2 mail2.qmul.ac.uk
The majority of the remainder of the records in a lower-level zone like
dcs.qmul.ac.uk will be of type A and map the domain name of a computer onto
its IP address. They may contain some aliases for the well-known services, for
example:

If the domain has any subdomains, there will be further records of type NS
specifying their name servers, which will also have individual A entries. For
example, at one point the database for qmul.ac.uk contained the following
records for the name servers in its subdomain dcs.qmul.ac.uk:
The BIND implementation of the DNS
The Berkeley Internet Name Domain (BIND) is an
implementation of the DNS for computers running
UNIX. Client programs link in library software as the
resolver. DNS name server computers run the named
daemon.
BIND allows for three categories of name server:
primary servers, secondary servers and caching-only
servers. The named program implements just one of
these types, according to the contents of a
configuration file. The first two categories are as
described above. Caching-only servers read in from a
configuration file sufficient names and addresses of
authoritative servers to resolve any name. Thereafter,
they only store this data and data that they learn by
resolving names for clients.
Directory services

A service that stores collections of bindings between

names and attributes and that looks up entries that
match attribute-based specifications is called a directory
service. Examples are Microsoft’s Active Directory
Services, X.500 and its cousin LDAP (described in Section
13.5), Univers [Bowman et al. 1990] and Profile
[Peterson 1988]. Directory services are sometimes called
yellow pages services, and conventional name services
are correspondingly called white pages services, in an
analogy with the traditional types of telephone
directory. Directory services are also sometimes known
as attribute-based name services.
Case study: The Global Name Service

A Global Name Service (GNS) was designed and

implemented by Lampson and colleagues at the DEC
Systems Research Center [Lampson 1986] to provide
facilities for resource location, mail addressing and
authentication.
The potentially large naming database and the scale of
the distributed environment in which the GNS is
intended to operate make the use of caching essential
and render it extremely difficult to maintain complete
consistency between all copies of a database entry. The
cache consistency strategy adopted relies on the
assumption that updates to the database will be
infrequent and that slow dissemination of updates is
acceptable, since clients can detect and recover from the
use of out-of-date naming data.
Case study: The X.500 Directory
Service

X.500 is a directory service in the sense defined in

Section 13.3. It can be used in the same way as a
conventional name service, but it is primarily used to
satisfy descriptive queries and is designed to discover
the names and attributes of other users or system
resources. Users may have a variety of requirements for
searching and browsing in a directory of network users,
organizations and system resources to obtain
information about the entities that the directory
contains.
Case study: The X.500 Directory
Service

The ITU and ISO standards organizations defined

the X.500 Directory Service [ITU/ISO 1997] as a
network service intended to meet these
requirements. The standard refers to it as a
service for access to information about ‘real-
world entities’, but it is also likely to be used for
access to information about hardware and
software services and devices.
Case study: The X.500 Directory
Service
X.500 is specified as an application-level service in
the Open Systems Interconnection (OSI) set of
standards, but its design does not depend to any
significant extent on the other OSI standards, and
it can be viewed as a design for a general-purpose
directory service. We outline the design of the
X.500 directory service and its implementation
here. Readers interested in a more detailed
description of X.500 and methods for its
implementation are advised to study Rose’s book
on the subject [Rose 1992]. X.500 is also the basis
for LDAP (discussed below), and it is used in the
DCE directory service [OSF 1997].
Figure 13.10 X.500 Directory Service architecture
Figure 13.11 Part of the X.500 Directory Information Tree
Figure 13.12 An X.500 DIB Entry