Domain Name Service (DNS)
References
TCP/IP Network Administration, Craig Hunt, O'Reilly & Associates
TCP/IP Illustrated, Volume 1, W. Richard Stevens, Addison-Wesley
Sockets need an IP address to connect. Machines use the IP address,
not the English host name. People don't remember numbers well.
How do you map the name to the number?
Bad old days: text file
Keep the mapping in a text file, e.g. /etc/hosts. Appoint an administrator
of the central hosts file.
Problems: who maintains?, bottleneck to access, very dynamic
First improvement: name server
Make an application protocol to distribute names, run a name
server on the net. Clients use the net to find names, not a file.
YP (NIS) is a means of exchanging system admin info (host names, passwords,
printers, etc) developed by Sun Microsystems.
Problem: limited scaleability, ok for an organization, not for the
whole world. Still stuck with who maintains the centralized data.
Second approach: distribute the servers
Have each domain run a name server. This relieves the performance
bottleneck, and distributes the responsibility for names to each domain
(admin bottleneck).
Question: how does a client know the name of each name server?
Making a well known service isn't enough, since that just standardizes
the port on which the name servers listen. Standardizing the names isn't
enough (e.g. names.gvsu.edu), since you'd still need the IP address of
each name server before you could contact it.
Final solution: the DNS
Put name servers at each level of the hierarchy. Addresses
of root domain servers for .com, .edu, .org, etc, are well-known. They
are responsible for knowing the addresses of the lower level domain servers
(names.gvsu.edu).
Now you've made a fully distributed, hierarchical , scaleable system
of name servers.
Name space
Fully qualified domain names (hostnames) are case insensitive. The
separator between portions of the name is a "." but this has nothing to
do with the "." notation for IP addresses.
Hierarchy of name space currently administered by a company. It costs
$50 per year to maintain a domain name. Current controversy is extending
the name space and adding more root level domains. From the root we currently
have
net
gov
mil
org
com
edu
arpa
<country codes>
Root level servers know the names (IP addresses) of the servers for the
top level domains. There is more than one server for each top-level domain.
The arpa top level domain is for maintaining an IP-to-hostname mapping.
Each lower level domain (or zone) must run its own name server.
That name server is responsible for the mappings within its domain.
Sofware processes involved
-
resolver
-
The library routines (gethostbyname(), etc) that talk to the DNS servers.
-
A client for talking to the name servers manually is nslookup(1).
-
name server
-
The process that responds to queries and maintains a DNS database.
-
May be of type:
-
primary - authoritative for a domain
-
secondary - authoritative, but does a "zone transfer" periodically
from a primary
-
caching-only - non-authoritative, starts at nothing, but builds up
cache of mappings
Non-recursive query
A client process on a machine at GVSU wants to talk to a machine
at Uppsala University (www.docs.uu.se).
-
The client process uses the library routine gethostbyname() to map from
the FQDN to the IP address.
-
The resolver on the client machine contacts the local name server (148.61.1.10).
-
The local name server does not know this host (checks cache) or even the
domain server for this domain (uu.se).
-
The local name server contacts a root server for the edu domain.
-
The root server provides the NS record (name/address) of the uu.se domain
server (names.uu.se).
-
The local name server contacts names.uu.se to resolve the hostname www.docs.uu.se.
-
The uu.se server returns instead an NS record for the subdomain server
(names.docs.uu.se).
-
The local server contacts names.docs.uu.se and gets the A record for www.docs.uu.se.
-
The IP address for www.docs.uu.se is returned to the client process on
the client machine. The NS records for names.uu.se and names.docs.uu.se,
and the A record for www.docs.uu.se are cached in the local server.
-
The client machine makes a connection via the IP address of www.docs.uu.se
Recursive query
The server doesn't return an answer, but rather calls the name server
it is referring the client to itself.
Transport protocol
DNS is built on both UDP and TCP. The first attempt to resolve a name uses
UDP. If the returned data fits in a 512 bytes then the response comes back
in a UDP packet (512 is guaranteed to pass through an IP subnet). If the
response is too big then the resolver automatically reissues the request
with via TCP so that the larger amount of data can be returned.
Subdomains
Subdomains may be created by the local authority for a domain. For instance,
GVSU could create a subdomain named csis.gvsu.edu. That would require CSIS
to run their own name server and resolve all requests for hosts in the
csis subdomain.
Performance
Caching is used by the name servers to reduce the number of redundant queries
made to frequently contacted hosts.
When a local server makes a request for a client, it caches both the requested
mapping, as well as all of the name server records retrieved as a result of this
request.
Caching DNS data brings up interesting
questions, like how long should an entry exist in the cache?
The whole Internet hinges on the DNS system. Ponder what happens when
one of the root level server's tables is corrupted.