76 lines
3.6 KiB
HTML
76 lines
3.6 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
|
|
<!--Converted with LaTeX2HTML 96.1-c (Feb 29, 1996) by Nikos Drakos (nikos@cbl.leeds.ac.uk), CBLU, University of Leeds -->
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>Hostname Resolution</TITLE>
|
|
</HEAD>
|
|
<BODY LANG="EN">
|
|
<A HREF="node1.html"><IMG WIDTH=65 HEIGHT=24 ALIGN=BOTTOM ALT="contents" SRC="contents_motif.gif"></A> <BR>
|
|
<B> Next:</B> <A HREF="node36.html">Enter DNS</A>
|
|
<B>Up:</B> <A HREF="node34.html">The Domain Name System</A>
|
|
<B> Previous:</B> <A HREF="node34.html">The Domain Name System</A>
|
|
<BR> <P>
|
|
<H2><A NAME="SECTION004610000">Hostname Resolution</A></H2>
|
|
<A NAME="tcpipdnsresolv"></A>
|
|
<A NAME="1240"></A>
|
|
<A NAME="1241"></A>
|
|
<A NAME="1242"></A>
|
|
As described above, addressing in TCP/IP networking revolves around
|
|
32-bit numbers. However, you will have a hard time remembering more than
|
|
a few of these. Therefore, hosts are generally known by ``ordinary''
|
|
names such as gauss or strange. It is then the
|
|
application's duty to find the IP-address corresponding to this name.
|
|
This process is called <em>host name resolution</em>.
|
|
<P>
|
|
An application that wants to find the IP-address of a given host name
|
|
does not have to provide its own routines for looking up a hosts and
|
|
IP-addresses. Instead, it relies on number of library functions that do
|
|
this transparently, called gethostbyname(3) and
|
|
gethostbyaddr(3). Traditionally, these and a number of related
|
|
procedures were grouped in a separate library called the resolver
|
|
library; on , these are part of the standard libc.
|
|
Colloquially, this collection of functions are therefore referred to as
|
|
``the resolver''.
|
|
<P>
|
|
Now, on a small network like an Ethernet, or even a cluster of them, it
|
|
is not very difficult to maintain tables mapping host names to
|
|
addresses. This information is usually kept in a file named
|
|
/etc/hosts. When adding or removing hosts, or reassigning
|
|
addresses, all you have to do is update the hosts on all hosts.
|
|
Quite obviously, this will become burdensome with networks than comprise
|
|
more than a handful of machines.
|
|
<P>
|
|
One solution to this problem is NIS, the <em>Network Information
|
|
System</em> developed by Sun Microsystems, colloquially called YP, or
|
|
<em>Yellow Pages</em>. NIS stores the hosts file (and other
|
|
information) in a database on a master host, from which clients may
|
|
retrieve it as needed. Still, this approach is only suitable for
|
|
medium-sized networks such as LANs, because it involves maintaining
|
|
the entire hosts database centrally, and distributing it to all
|
|
servers.
|
|
<P>
|
|
On the Internet, address information was initially stored in a single
|
|
HOSTS.TXT database, too. This file was maintained at the Network
|
|
Information Center, or NIC, and had to be downloaded and installed by
|
|
all participating sites. When the network grew, several problems with
|
|
this scheme arose. Beside the administrative overhead involved in
|
|
installing HOSTS.TXT regularly, the load on the servers that
|
|
distributed it became too high. Even more severe was the problem that
|
|
all names had to be registered with the NIC, which had to make sure that
|
|
no name was issued twice.
|
|
<P>
|
|
This is why, in 1984, a new name resolution scheme has been adopted,
|
|
the <em>Domain Name System</em>. DNS was designed by Paul Mockapetris,
|
|
and addresses both problems simultaneously.
|
|
<P>
|
|
<HR><A HREF="node1.html"><IMG WIDTH=65 HEIGHT=24 ALIGN=BOTTOM ALT="contents" SRC="contents_motif.gif"></A> <BR>
|
|
<B> Next:</B> <A HREF="node36.html">Enter DNS</A>
|
|
<B>Up:</B> <A HREF="node34.html">The Domain Name System</A>
|
|
<B> Previous:</B> <A HREF="node34.html">The Domain Name System</A>
|
|
<P><ADDRESS>
|
|
<I>Andrew Anderson <BR>
|
|
Thu Mar 7 23:22:06 EST 1996</I>
|
|
</ADDRESS>
|
|
</BODY>
|
|
</HTML>
|