<BR></P>

<UL>

<LH><B>Table 8.1. Top-level domains.</B>

<BR></LH></UL>

<TABLE BORDER>

<TR>

<TD>

<PRE><I>Domain</I>

<BR></PRE>

<TD>

<PRE><I>Meaning</I>

<BR></PRE>

<TR>

<TD>

<P>EDU</P>

<TD>

<P>Educational. Colleges and Universities.</P>

<TR>

<TD>

<P>ORG</P>

<TD>

<P>Organizations. Nonprofit and not-for profit.</P>

<TR>

<TD>

<P>NET</P>

<TD>

<P>Networks. Networking services providers (some under COM).</P>

<TR>

<TD>

<P>COM</P>

<TD>

<P>Commercial. Businesses.</P>

<TR>

<TD>

<P>GOV</P>

<TD>

<P>Government. United States government offices.</P>

<TR>

<TD>

<P>MIL</P>

<TD>

<P>Military. The U.S. Armed Forces.</P>

<TR>

<TD>

<P><I>cc</I></P>

<TD>

<P>Countries. cc is an ISO country code.</P>

<TR>

<TD>

<P>US</P>

<TD>

<P>An example of a country code. The United States.</P></TABLE>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="note.gif" WIDTH = 35 HEIGHT = 35><B>NOTE:</B> Due in part to the history of the ARPAnet, most hosts in the United States (and some international organizations and businesses) are under EDU, ORG, NET, COM, GOV, or MIL. Many hosts in other 
countries are under a top-level domain that is the two-character ISO country code for the country. To further confuse things, the United States has a U.S. zone that includes local organizations, primary and secondary schools, and local governments.

<BR></NOTE>

<HR ALIGN=CENTER>

<P>Look at the hostnames conch.newcastle.org and conch.austin.tx.us. The org means that the name belongs to an organization. The newcastle means that Newcastle Associates is the owner. Finally, conch is a particular host in Newcastle's network. In the 
second name, us means the United States, tx means Texas, austin means the city Austin, and conch is a particular hostname. Note that the two machines are completely different machines with different owners. They happen to share one component of their name, 

but that is not a problem because of the hierarchical namespace presented by DNS. 

<BR></P>

<P>In fact, there are many repetitions of names. There are many machines on the Internet that have ftp as the first part of their domain names, and many that have www as the first part of their names. The advantage of using the DNS is that these 
repetitions are not in conflict. It has been said about names that &quot;all the good ones are taken,&quot; but the DNS allows you to reuse some of the good ones in a different context. Try using Figure 8.1 to figure out these hostnames:

<BR></P>

<PRE>ftp.x.org

ftp.uu.net

ftp.newcastle.org

rs.internic.net

utc.univ-coop.austin.tx.us</PRE>

<P>Notice that utc.univ-coop.austin.tx.us has a different number of components than some of the other names you looked at. The DNS can grow by creating a deeper tree. The owner of a domain may add new domains to make it easier to add more hosts.

<BR></P>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="note.gif" WIDTH = 35 HEIGHT = 35><B>NOTE:</B> In addition to having an official name, some hosts have aliases as well. The alias is simply another name for the host. For example, ftp.x.org is actually an alias for the current machine being used 
for ftp by x.org.

<BR></NOTE>

<HR ALIGN=CENTER>

<H5 ALIGN="CENTER">

<CENTER><A ID="I10" NAME="I10">

<FONT SIZE=3><B>Using Shorter Names</B>

<BR></FONT></A></CENTER></H5>

<P>Usually, the DNS is configured to use a search path for hostnames that don't end in a dot. This lets you use shorter names for hosts in your search path. Typically, your DNS will be configured to search your domain and then search progressively up to 
the root domain. Check your system documentation to see if you can change the DNS search path. If you were on cnidaria.newcastle.org and used the name newcstle.net, it would try the following names, matching the first one that exists:

<BR></P>

<UL>

<LI>newcstle.net.newcastle.org

<BR>

<BR></LI>

<LI>newcstle.net.org

<BR>

<BR></LI>

<LI>newcstle.net

<BR>

<BR></LI></UL>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="imp.gif" WIDTH = 68 HEIGHT = 35><B>TIP: </B>Because of the search algorithm, you may see faster network access if you use full names ending in a dot for machines outside your local domain.

<BR></NOTE>

<HR ALIGN=CENTER>

<H5 ALIGN="CENTER">

<CENTER><A ID="I11" NAME="I11">

<FONT SIZE=3><B>Decoding Addresses and Ports</B>

<BR></FONT></A></CENTER></H5>

<P>Although DNS names are a reasonably convenient way for humans to refer to hosts, the Internet Protocol needs to use a 32-bit Internet address to find a host on the network. For example, as of this writing the host ftp.uu.net has the Internet Address 
192.48.96.9. Internet address are usually written using dot names, with four numbers between 0 and 255, separated by dots. Note that each of the four numbers is 8 bits, so you end up with a 32-bit Internet address.

<BR></P>

<P>It is not enough just to connect to the correct machine. You also need to connect to the correct program. TCP/IP and UDP/IP use ports to specify where a connection will go. In order to make a connection to a remote computer, there has to be some program 

listening on the correct port. If you think of IP addresses as being like phone numbers, a port number is like an extension. Once your IP message reaches the correct machine, the port number enables it to be delivered to the correct program.

<BR></P>

<P>When a new protocol is adopted as a standard, it is assigned a port number that will always be used for that protocol. For example, the login protocol used to implement rlogin is assigned port 513, and telnet is assigned port 23. You can examine the 
assignments of ports to protocols by looking at the file /etc/services on your machine. If you are running NIS (the Network Information System, formerly called the Yellow Pages), you can run the command ypcat services to look at the map.

<BR></P>

<P>Look at what happens when you run the command rlogin <I>remotehost</I>. If <I>remotehost</I> is willing to accept rlogin requests, there is a program waiting for connections on port 513 on <I>remotehost</I>; this program (called inetd) will handle all 
of the work on <I>remotehost</I> that needs to be performed to allow you to use rlogin (inetd does this by handing the incoming connection to a program called rlogind, which implements the protocol). The rlogin program on your host attempts to open a 
connection to port 513 on the <I>remotehost</I>. The program monitoring port 513 on <I>remotehost</I> will accept the connection and let your rlogin program perform the setup necessary to perform a login.

<BR></P>

<H5 ALIGN="CENTER">

<CENTER><A ID="I12" NAME="I12">

<FONT SIZE=3><B>Converting Names to Addresses</B>

<BR></FONT></A></CENTER></H5>

<P>You have seen what hostnames look like and what the low-level Internet address and port numbers are, but you still need to learn how names get converted to addresses.

<BR></P>

<P>Hostname conversion is usually handled by the domain naming system, which, in addition to specifying what hostnames look like, specifies a protocol for translating hostnames to addresses. First look at a hostname conversion of the name ftp.x.org. When 
your local host tries to convert the name ftp.x.org to an IP address, it contacts a nameserver, a machine that has DNS mappings loaded and is prepared to answer questions about them. Your nameserver is also configured with information about how to contact 

other nameservers so it can look up names that it doesn't already know.

<BR></P>

<H5 ALIGN="CENTER">

<CENTER><A ID="I13" NAME="I13">

<FONT SIZE=3><B>A Brief Introduction to NIS</B>

<BR></FONT></A></CENTER></H5>

<P>When implementing a network, one of the common problems that arises is management of passwd and group files. Some organizations wish to have a common user and group list for all or most hosts in a network. The Network Information Service, introduced by 

Sun, is one way to solve this problem. NIS allows sharing of passwd, group, and other information between hosts that share administrative control. Other (commercial and freely available) solutions to this problem exist, but none have yet become as 
widespread as NIS.

<BR></P>

<P>If you are running NIS, you should use the command ypcat passwd to examine the passwd information on your system. The actual /etc/passwd file will not list all of the users who can log in to a machine running NIS. If you are using NIS to manage passwd 
files, your password will be the same on any machine in your network that runs NIS. NIS may also be used to create an environment where you can share files transparently between systems. This is done using the network file system, NFS, which enables you to 

mount a file  system from a mount computer and access it as if it were local. Some computing environments configure NIS so that your HOME is always the same directory, no matter what machine you use. This means that your files will be accessible no matter 

what machine in the network you are using. Check with your system administrators to find out if NIS is running and if it is being used to handle automounting of home (and other) directories.

<BR></P>

<H3 ALIGN="CENTER">

<CENTER><A ID="I14" NAME="I14">

<FONT SIZE=4><B>I'm on the Wire&#151;</B><B>rlogin</B><B>, </B><B>telnet</B><B>, </B><B>cu</B>

<BR></FONT></A></CENTER></H3>

<P>With the three services rlogin, telnet, and cu, you can connect to a remote computer over the network. rlogin uses the login service to connect using the TCP/IP protocol over the network, telnet uses the telnet service to connect using the TCP/IP 
protocol over the network, and cu connects over a phone line.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I15" NAME="I15">

<FONT SIZE=3><B>Before Using </B><B>rlogin</B><B>, </B><B>rsh</B><B>, and </B><B>rcp</B>

<BR></FONT></A></CENTER></H4>

<P>Before you use rlogin, some user configuration may be needed. The same configuration is used for rsh and rcp. You should refer to these details when reading the next section as well. For reference, <I>loc-host</I> is used as the local machine name and 
<I>rem-host</I> is the name of the remote machine.

<BR></P>

<P>Two files on the remote machine affect your remote access ability: /etc/hosts.equiv and .rhosts in the remote user's home directory. The hosts.equiv file contains a list of hostnames. Each machine in this list is considered to be a trusted host. Any 
user who has an account on both <I>loc-host</I> and <I>rem-host</I> is allowed to access the remote machine from the local machine without question. The &quot;without question&quot; is important and means that the user does not have to supply a password 
for access.

<BR></P>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="imp.gif" WIDTH = 68 HEIGHT = 35><B>TIP: </B>System administrators should seriously consider disabling the rlogin and rexec protocols on machines that are directly connected to the Internet since the authentication used on these protocols is very 

weak. At the very least, be extremely careful about entries in /etc/hosts.equiv and any .rhosts files.

<BR></NOTE>

<HR ALIGN=CENTER>

<P>The .rhosts file in the remote user's home directory contains a list of trusted host and user pairs. This is similar to the trusted hosts of the hosts.equiv file, but gives a finer grain of control. Each entry grants trusted access to one particular 
user on a particular host rather than to all common users on a particular host. Lines in .rhosts that name only a machine will grant access to a user with the same login name. The user on <I>loc-host</I> can access <I>rem-host</I> without question (that 
is, without specifying a password). The user authentication is done by the protocol.

<BR></P>

<P>Usually only the system administrator can change the values in the /etc/hosts.equiv file. Since this file allows many users access, this is a system configuration file. But each user can set up his or her own .rhosts file. This file must live in the 
user's home directory and be owned by the user (or by root). The ownership restrictions are security measures preventing a user from gaining access to another user's account.

<BR></P>

<P>Listing 8.1 and Listing 8.2 show examples of the hosts.equiv and .rhosts files. These two files are located on the machine called flounder, and the .rhosts file is owned by user rob and is located in his home directory. The two hosts listed in the 
/etc/hosts.equiv file, manatee and dolphin, are trusted hosts to flounder. Any user with an account on manatee and flounder may remotely access flounder from manatee without specifying a password. Likewise, any user with an account on dolphin and flounder 

may remotely access flounder from dolphin without specifying a password.

<BR></P>

<UL>

<LH><B>Listing 8.1. /etc/hosts.equiv and $HOME/.rhosts files.</B></LH></UL>

<PRE>manatee

dolphin</PRE>

<UL>

<LH><B>Listing 8.2. </B><B>/users/rob/.rhosts</B><B> on machine </B><B>flounder</B><B>.</B></LH></UL>

<PRE>french-angel

rob yellowtail

rob dolphin

rob dolphin

root dolphin

diane stingray

rob stingray

root flying-gurnard

root</PRE>

<P>The .rhosts file of the user rob contains a list of users on a remote machine who may access flounder as user rob without specifying a password. That sentence packed several important points together that need expanding:

<BR></P>

<UL>

<LI><B>The </B><B>.rhosts</B><B> file of user </B><B>rob</B><B>.</B> This implies that the machine flounder has a user account, with rob as the user name. The home directory of user rob (the example implies it is /users/rob) has a file named .rhosts that 
is owned by rob.

<BR>

<BR></LI>

<LI><B>Users on a remote machine who may access </B><B>flounder</B><B>.</B> Each entry in the list is a pair of names&#151;the machine name and the associated user name. This pair of names describes one particular user who may access flounder. That user 
must be accessing flounder from the specified machine. It is not enough for the user to simply have an account on the machine; the remote access must be initiated from that machine (by that user).

<BR>

<BR></LI>

<LI><B>As user </B><B>rob</B><B>.</B> This is probably the most subtle of all the points, so be careful here. Any of the users who are in the list may access rob's account on flounder, as rob. They &quot;become&quot; rob on flounder even if they were a 
different user on the initiating machine. This is effectively the same as giving rob's password on machine flounder to this user. Because of this, be extremely selective about entries in your .rhosts files!

<BR>

<BR></LI>

<LI><B>Without specifying a password.</B> Some services (rlogin) allow for the possibility of a password prompt. If the user authentication was not successful via the equivalence files, the service is able to fall back on the prompt method of 
authentication. So the ability to access a remote host without specifying a password may not be needed. Other services (rsh and rcp) do not have a way to prompt for a password. In order to use these services, the access must be configured so that 
specifying a password is unnecessary.

<BR>

<BR></LI></UL>

<P>Using Listing 8.2, for each of the following scenarios, decide if the user would be able to access flounder&#151;as rob&#151;without a password. Assume that each user has an account on the local machine in the question, as well as on flounder.

<BR></P>