Name Services EEE465 2001 Reference: CDK00 9'12

1
Name ServicesEEE465 2001Reference CDK00
9.1-2

• Major Greg Phillips
• Royal Military College of Canada
• Electrical and Computer Engineering
• greg.phillips_at_rmc.ca
• 1-613-541-6000 ext. 6190

2
Context

• We have now completed our look at distributed
  system architectures and technologies
• Next we will look at name services. They are
  interesting for two main reasons
• they are critical enabling technologies for other
  distributed systems (e.g., the WWW)
• they are themselves implemented as distributed
  systems

3
Names, Entities, Attributes, Addresses

• Names are designators for a network resource
• often human readable e.g., Internet hostnames
• sometimes identifiers, chosen for efficient
  manipulation and storage e.g., RMI object
  identifiers
• Names are associated with interesting entities in
  a distributed system by a binding
• some examples users (real names, login names,
  email addresses), computers (host names),
  services (file service, print service)
• Normally, the binding will be between a name and
  one or more attributes of an entity, most
  frequently an address
• e.g., DNS associates phillips.rmc.ca with
  137.94.177.60, which is an address of a computer

4
Name Services

• a name service stores a database of bindings
  between names and attributes
• name services resolve names to attributes
  (addresses)
• addresses may themselves be names
• e.g., an IP address must typically be resolved to
  an Ethernet address at the data-link layer
• resolution is typically done with regard to a
  context
• e.g., phillips is resolved in the rmc.ca
  context

5
General Requirements

• From the design rationale for the Global Name
  Service (DEC SRC, 1986)
• arbitrarily large number of names, arbitrary
  number of administrative organizations
• handle all email addresses of all computer users,
  worldwide
• long lifetime
• allow for arbitrary changes in the namespace
  organization
• high availability
• since its the critical service
• fault isolation
• local failures must leave the system intact
• tolerance of mistrust
• must not require any one component to be trusted
  by all users
• DNS meets some of these goals which?

6
Name Spaces

• a name space is the collection of all valid names
  a service will attempt to look up
• some (most) valid names will be unbound
• name spaces may be hierarchical or flat
• DNS names hierarchical, IP addresses flat
• hierarchic name spaces potentially infinite
• flat name spaces finite if names finite (often
  true)
• DNS names
• labels separated by dots (.)
• not case sensitive
• all names referred to global root (no relative
  names)
• client software often assumes local domain

7
DNS Name Hierarchy
root
generic
ISO-3166
net
ch
au
at
mil
com
edu
gov
org
us
su
int
ca
plus new generic top level domains (e.g, biz,
info, etc)
rmc
An administrative (vice physical) hierarchy. The
name itself tells you nothing about IP addresses,
routing, or physical location of the named
entity.
phillips
8
Aliases

• an alias is (usually) a simpler or more
  recognizable name substituting for a less
  recognizable actual name
• e.g., www.rmc.ca is an alias for ext1.rmc.ca
• allows service to be moved to a new machine
  simply by updating DNS database

9
DNS Servers

• name resolution data is
• partitioned (each DNS zone is responsible for
  supplying its own name servers)
• replicated (more than one server per zone)
• primary or master reads data directly from local
  file
• secondary periodically download from primary
  server (typically once or twice per day)
• cached
• any server can cache data from other name servers
• marked non-authoritative and tagged with time
  to live
• initial time to live set by authoritative server
  (typically days)
• root servers hold entries for
• generic top level domains (.com, .edu)
• servers for second-level subdomains
• name servers for country domains
• typically about a dozen root servers
• serve about 1000 requests/second
• for efficiency, multiple requests may be bundled
  together

10
DNS Lookup

• DNS requests are typically directed to a local
  name server by a client resolver
• name server resolves names within the local
  domain, plus any cached names
• maintains references to other domains at various
  levels, including the root
• when a non-resolvable query comes in, it is
  forwarded to the lowest level appropriate server
  known by the forwarding server
• lookup can be either iterative or recursive
• reverse resolves IP addresses to host names
  using the special in-addr.arpa domain
• also looks up mail services resolves mail
  service name to host name
• e.g., mail directed to rmc.ca domain handled by
  bastion.rmc.ca

11
Navigation Models
Non-recursive server controlled
Iterative
NS2
NS2
2
2
1
NS1
1
NS1
Client
Client
4
NS3
NS3
3
3
Recursive server controlled

• Issues
• transaction state on server
• server thread utilization
• caching effectiveness

NS2
2
1
NS1
4
Client
3
5
NS3
12
Discussion

• DNS extremely effective considering size of
  network
• largely because of effective replication, caching
• since mappings change relatively rarely, caching
  very effective strategy
• caches typically on order of days
• downside allows naming data to become
  inconsistent
• limited scope as service, enough to act as
  underpinning for wide range of other services
• rigidity causes some problems
• technical issue non-European characters in names
• political issue new top level domains

13
Next ClassDirectory and Discovery Services