3.5 Naming and Look-Up Service
3.5.1 Host addresses and Port numbers
A client requiring a service needs to locate a server that will provide the desired service. In JavaRMI discussed in §3.3, rmiregistry provided a limited form of name service. First of all, we need a unique network address bound to each host (machine).
• IP addresses: Used in the Internet and are universally accepted. 32 bits long (com-pact). Dotted decimal notation: each of the four parts in an IP address is the decimal representation of a one-byte bit pattern. Theoretically, 232
(≈ 4∗109
) addresses are possible under this address scheme, but only a small fraction is usable. 2
So, giving unique transport addresses to all servers is not difficult: use a two-part struc-ture, e.g., (host address,port#), where port#indicates the port on which the server is lis-tening. On any machine attached to the Internet, host addressis its IP address.1
See Unix
gethostbyname(3N). The port numbers 1∼1023 are reserved for system-provided services,
which are the same regardless of the host. Listed below are some well-known addresses
(see /etc/services in a Unix machine.):
A user can pick an arbitrary 16-bit port numbers (≥1024) to name a new server (accessed by RPC). In Unix, you can then register the service by calling theportmapperwhich listens on the well-kown port 111. (Its role is similar to that ofrmiregistry, which listens on port 1099 by default.) Clients can ask the portmapper for the port number of a particular server by presenting its program number. The addresses of system-provided services on a remote host (that is known to the local host) can be obtained by consulting the two databases,
/etc/hostsfor the (host name, IP address) pairs and /etc/services for the port numbers
of different available services. 1
E.g., the machinefraserhas IP address 142.58.110.2. You can login tofraserfrom anywhere in the world bytelnet142.58.110.2.
Name Port # Description
rjd 5 Remote job entry
echo 7 Echo
users 11 List active users
daytme 13 Day and time
ftp-data 20 File transfer (data)
ftp 21 File transfer (control)
telnet 23 Virtual terminal
smtp 25 Simple Mail Transfer
time 37 Time service
name 42 Host name server
whois 43 Find nickname
domain 53 DNS server
bootps 67 Bootstrap protocol server
bootpc 68 Bootstrap protocol client
tftp 69 Trivial (or simplified) ftp
finger 79 Information service about users
http 80 HTTP server
hostnames 101 NIC host name server
ISO-tsap 102 ISO TSAP
X400 103 X400 name server
X400SND 104 X400.SND
pop2 109 Post office protocol 2
pop3 110 Post office protocol 3
portmapper 111 Sun RPC portmapper
netbios-ns 137 NETBIOS name service
netbios-dg 138 NETBIOS datagram service
netbios-ss 139 NETBIOS session service
login 513 Unix login service
shell 514 Unix shell
talk 517 Unix talk service Common Interner Port Numbers
3.5.2 Name service
Requiring users to use numeric addresses of the servers creates some problems. Besides being difficult to remember, if the host IP address of a server machine is bound into the client program at compile time, replacing the server (e.g., due to repair work) by another machine necessitates the recompilation of every client program that calls it.
A name serverwas introduced to solve this problem. Likermiregistry, a name server accepts registration of dynamically created service names and their addresses and helps clients in looking up servers which provide the desired service. The RMI registry requires at least one registry server in each server machine, which may not be practical. In ARPANET, the predecessor to the Internet, flat (i.e., non-hierarchical) naming was used, and a file
fetch it every night. For a network of a few hundred hosts, this was satisfactory (up to 1983), but clearly, this didn’t scale well.2
Definitions
• Name: Human-friendly denotation, e.g., file and service names.
• Address: where an object can be found, e.g., IP address. Many names (e.g., aliases) can have the same address, and the same name can have multiple addresses.3
• Name resolution: Name →address mapping, e.g., telnet → “port 23”, fraser → “142.58.110.2”.
• Address resolution: Address → route mapping.
3.5.3 DNS - The Internet Domain Name System
In this subsection, we consider the Internet DNS, which, unlike RMI Registry, can work in large-scale distributed systems. It has the following features:
1. User friendly structured textual names (instead of numbers).
2. Distributed database (of name-mapping) under local control. Hierarchical names pre-vents name collision.
3. Changes to the database require little overhead.
4. Scalable, robust (replicated service) and adequate performance (caching)
• Internet domain names(e.g., orion.csil.sfu.ca). Hierarchical and user-friendly. Similar to postal addresses or Unix paths. Each node in the hierarchy represents a
domain, consisting of the subtree rooted at the node.4
Component names ≤63 char-acters, the total length ≤ 255 characters. The top-level domains: several hundred domains, includingcom, edu, gov, org, mil, net,int (certain international orga-nizations), as well as abbreviated country names, e.g., ca, hk, jp, us. Since .com
became very crowded, recently, new top-level domains, biz, name, info, museum, etc. have been added. To obtain a domain under one of the top-level domains, an application must be made to the NIC. However, creating subdomains under such a granted domain requires no additional permission. This is similar to IP address as-signment to an organization by NIC. Within the assigned network address space, the organization is free to create subnetworks or assign IP addresses to hosts. However, subnets and subdomains are not related: Creating one does not imply creating the other.
2
In 1986, the number of hosts attached to the Internet was 3,100, and in 1995, it was about 4 million. 3
A router, for example, has an IP address in each network it belongs to. 4
English
au ca
cs
sfu ubc ec uoft
library wormhole css fornax . . . edu com . . . . . . Figure 7: DNS hierarchy.
Currently (as of 2000) there are 13 root servers, i.e., name servers for the root zone.5
NAME Location Organization
A.ROOT-SERVERS.NET internic.net InterNIC
B.ROOT-SERVERS.NET isi.edu Information Science Institute (USC)
C.ROOT-SERVERS.NET psi.net PSINet
D.ROOT-SERVERS.NET umd.edu University of Maryland
E.ROOT-SERVERS.NET nasa.gov NASA
F.ROOT-SERVERS.NET isc.org Internet Software Consortium
G.ROOT-SERVERS.NET nic.mil NIC, Dept. of Defence
H.ROOT-SERVERS.NET arl.mil Army Research Laboratory
I.ROOT-SERVERS.NET sunet.se Swedish University Network
J.ROOT-SERVERS.NET nsi InterNIC(tmp)
K.ROOT-SERVERS.NET lynx.net RIPE NCC (LYNX INTERNET & MARKETING)
L.ROOT-SERVERS.NET ep.net ISI (IANA)
M.ROOT-SERVERS.NET wide.ad.jp WIDE
To traverse the domain hierarchy, it is convenient to keep information about its child domains at each node. If a child is a domain consisting of a single host, then this information would be (host name, IP address) pair for the host. If the child is a subdomain, then this information would be (name server, IP address) pair for the subdomain.
One major advantage of hierarchical naming is that the management (e.g., cre-5
A “zone” will be defined later. As seen from Figure 8, a NS may provide mapping for more than one domain. For example, the root server is shown to provide name service not only for the root of the hierarchy, but also for all top-level domains in US, e.g., edu and com, as well. The root servers on average receive
= fornax = whistler IP = d English ca_ns au ca cs
sfu ubc ec uoft
library wormhole css fornax . . . edu com . . . . . . sfu_ns cmpt_ns root_ns
Figure 8: Name servers for “zones”.
ation/deletion of subdomains) can be delegated to local authorities, thus avoiding bottle-necks.
Distributed NS
The main problem is how to provide name service (mapping between hierarchical host names and IP addresses) to remote hosts, which is robust and without performance bot-tlenecks and scaling problem. We will talk about the database required and the searching procedure. It is based on client-server paradigm, where the client is a local procedure called the resolver or a name server (NS)and the server is another NS.
• Database
It is reasonable to assume that the NS for any domain corresponding to a LAN maintains a list of local hosts and their IP addresses, and that each host knows about the NS for the local domain. If, for reliability reasons, there is more than one NS in a local domain, then all their addresses must be known to each host, so that they can be contacted one by one, in case some of them have failed. A more common solution in local area networks, however, is for a machine to broadcast a query message asking for the identity of the current name server(s), on start-up and whenever it cannot communicate with the name server it knows about. The first one to respond can be used, since it is probably the least loaded.
In general, a NS for a node needs to maintain a database containing:
1. All local names (of hosts and NSs for subdomains) and their IP addresses. 2. Info on looking up some remote names.
A zone is a contiguous subset of a domain, consisting of a set of subdomains adjacent in the domain tree. Each zone has one primary NS and one or more secondary NSs (for reliability and load-sharing) which copy the entire database periodically (e.g., once a day) from the primary server. Theresource records(see below) for the zone maintained by both the primary and secondary NSs areauthoritative. The domain administrator enters data into
The same NS may look after name service for more than one zone. For simplicity, we assume that a zone consists of exactly one domain, and each domain has its own NS.
Resource records
DNS maintains a database of resource records (RRs) of the form
Domain name | Time to live | Class | Type | Value
• wormhole.cs.sfu.ca 2419200 IN A 199.60.3.48
Time to live is specified in seconds (e.g., 86400 = 1 day), and indicates how long the
cached information may be valid.6
There are about 20 different types of RRs, including: Type Value
A 32-bit host IP address
MX Preference (integer), host willing to accept email for the domain
NS Name of a NS for this domain
HINFO Host info: CPU and OS in ASCII
CNAME Official name for alias Domain name (Canonical name)
SOA Start of data for the zone (Start of Authority)
TXT Uninterpreted ASCII text
An SOA-type record marks the start of data for a zone, and contains the name of the source of information about this zone, the email address of the zone administrator, and parameters specifying, e.g., how often secondary NSs should refresh their copies from the primary NS.
• wormhole.cs.sfu.ca 86400 IN MX fornax.cs.sfu.ca
• www.cs.sfu.ca 2419200 IN CNAME adhara.cs.sfu.ca
• . 3600000 IN NS A.ROOT-SERVERS.NET. (Note the root domain “.”)
• A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
www.cs.sfu.ca, for example, is analias, which can be used without designating a specific
machine; if the current WWW server fails, another can be assigned by updating the database, without invalidating the address people use to access it. The nslookup command can be used to access information in this database.
wormhole% nslookup /* Command that I type.
Default Server: fornax.cs.sfu.ca /* These two lines are response.
Address: 199.60.1.1
> set type=any /* To indicate that I am interested in all available info at the NS.
6
If this field is empty, it defaults to the value specified in another part of the database. If it is 0, the RR should not be cached.
> wormhole /* I want to get info on wormhole
Server: fornax.cs.sfu.ca
Address: 199.60.1.1
wormhole.cs.sfu.ca internet address = 199.60.3.48
wormhole.cs.sfu.ca preference = 10, mail exchanger = cs.sfu.ca cs.sfu.ca nameserver = fornax.cs.sfu.ca
cs.sfu.ca nameserver = whistler.sfu.ca cs.sfu.ca nameserver = seymour.sfu.ca cs.sfu.ca internet address = 142.58.111.1 fornax.cs.sfu.ca internet address = 199.60.1.1 whistler.sfu.ca internet address = 142.58.103.1 seymour.sfu.ca internet address = 142.58.103.2
> server whistler.sfu.ca /* I want to talk to whistler.
Server: whistler.sfu.ca
Address: 142.58.103.1
> whistler.sfu.ca /* Tell me about yourself.
Server: whistler.sfu.ca
Address: 142.58.103.1
whistler.sfu.ca preference = 10, mail exchanger = rm-rstar.sfu.ca whistler.sfu.ca preference = 20, mail exchanger = wedge.sfu.ca whistler.sfu.ca internet address = 142.58.103.1
sfu.ca nameserver = whistler.sfu.ca sfu.ca nameserver = seymour.sfu.ca sfu.ca nameserver = cheddar.ucs.ubc.ca
rm-rstar.sfu.ca internet address = 142.58.120.21 wedge.sfu.ca internet address = 134.87.112.1 whistler.sfu.ca internet address = 142.58.103.1 seymour.sfu.ca internet address = 142.58.103.2 cheddar.ucs.ubc.ca internet address = 137.82.28.3
> root /* I want to talk to a root
Default Server: a.root-servers.net
Address: 198.41.0.4
> ca. /* What do you know about the domain ca.?
Server: a.root-servers.net
Address: 198.41.0.4
ca nameserver = CLOUSO.RISQ.QC.ca
ca nameserver = NS2.UUNET.ca
ca nameserver = RS0.INTERNIC.NET
ca nameserver = DNS2.UTCC.UTORONTO.ca
ca nameserver = RELAY.CDNNET.ca
Authoritative answers can be found from:
ca nameserver = CLOUSO.RISQ.QC.ca
ca nameserver = NS2.UUNET.ca
ca nameserver = RS0.INTERNIC.NET
ca nameserver = DNS2.UTCC.UTORONTO.ca
ca nameserver = RELAY.CDNNET.ca
CLOUSO.RISQ.QC.ca internet address = 192.26.210.1
NS2.UUNET.ca internet address = 142.77.1.5
RS0.INTERNIC.NET internet address = 198.41.0.5
DNS2.UTCC.UTORONTO.ca internet address = 128.100.102.201
RELAY.CDNNET.ca internet address = 192.73.5.1 >exit
Notes:
1. Each host has the IP addresses of the local NSs of the domain it belongs to in a system config file (/etc/resolv.conf), and
2. Each NS has the addresses of the root servers(for the top-level US domains), whose IP addresses are in a system config file, and are loaded into the DNS cache when it is started and is never purged (its Time to Live is ignored).
3. A domain name (e.g., WWW.sfu.ca) may be mapped to more than one computer for load sharing. In this case, there is one RR of type A for each such computer. To assign load equally among the servers, the NS normally returns those addresses to successive queries on a round-robin basis. This effort is somewhat spoiled if server addresses are
cached. 2
• Domain name resolution
The resolver is a library of software procedure, that is linked into a program which
requires name service. It sends a name-resolution query by the client to a local NS.
Iterative: If a NS cannot satisfy the query, it returns the IP address of another NS which may be able to resolve the name to the requesting NS.
Recursive: Each NS forwards the query and passes the reply back. The local NS is off-loaded. Not all NSs can handle queries recursively. In particular, the root servers do not provide this service.
Client's name resolver Root name server Name server nl node Name server vu node Name server cs node 1. <nl,vu,cs,ftp> 2. #<nl>, <vu,cs,ftp> 3. <vu,cs,ftp> 4. #<vu>, <cs,ftp> 5. <cs,ftp> 6. #<cs>, <ftp> ftp cs vu nl Nodes are managed by the same server 7. <ftp>
8. #<ftp>
#<nl,vu,cs,ftp> <nl,vu,cs,ftp>
Figure 9: Iterative name resolution. Fig. 9 shows an example of iterative name resolution.
The resolver and NSs may cache the addresses of remote NSs that they have dealt with recently.
1. Email address resolution foruser@host.domain: The source host invokes the name re-solver, which asks the NS fordomainto send all MX records for the destination machine
host. The source host tries to send the mail to the mail exchangers, one at a time, in the preference order, until it succeeds. This mechanism allows the administrator of the .com domain to add the following MX record to its database:
tikoDomain.com 86400 IN MX 1 mailserver.cs.sfu.ca
in order to have all mail to tikoDomain.com delivered tomailserver.cs.sfu.ca. 2. Non-email access (e.g., telnet, ping): The source host invokes the name resolver,
which asks the address record (type A) ofhost, which in this case must be a machine. 3. An important consequence of multiple types: It is entirely possible that the NS stores an A-record forhost in its database but no MX record forhost. In this case, you can
doping host, but if you try to send email touser@host.domain, you may be informed
that the destination is unkown. Failing to obtain an MX-record, some resolvers send email to the IP address of host. Or conversely, there may be an MX-record but no A-record forhost, in which case you can send email to it but ping host will fail. The Berkeley Internet Name Domain (BIND) is the most widely used implementa-tion of DNS (on Unix machines). The source code is available through anonymous FTP
