tyt11fi.htm

一个学习tcp/ip协议的教程

.  99999999  IN   NS  ns.nic.ddn.mil.

   99999999  IN   NS  ns.nasa.gov.

   99999999  IN   NS  ns.internic.net

; servers by address

;

ns.nic.ddn.mil   99999999   IN  A  192.112.36.4

ns.nasa.gov      99999999   IN  A  192.52.195.10

ns.internic.net  99999999   IN  A  198.41.0.4</FONT></PRE><P>In this file only three DNS servers have been specified. A normal named.ca file can have a dozen or so name servers, depending on their proximity to your system. You can get a full list of valid root domain name servers through anonymous FTP to nic.ddn.mil, in the file /netinfo/root-servers.txt. This file can be pasted into named.ca. The servers specified in the named.ca file are each identified by two entries. One gives the root domain (the period) followed by the name server name; the other has the name server IP address. The Time to Live field is set very large because these servers are expected to be always available.<BR><P>The named.boot file is used to trigger the loading of the DNS daemons and to specify the primary and secondary name servers on the network. A sample named.boot file looks like this:<BR><PRE>

<FONT COLOR=#000080>; named.boot

directory    /usr/lib/named

primary    tpci.com    named.hosts

primary    25.143.in-addr.arpa    named.rev

primary    0.0.127.in-addr.arpa    named.local

cache    .    named.ca</FONT></PRE><P>The first line of the named.boot file has the keyword directory followed by the directory of the DNS configuration files. Each following line with the keyword primary tells DNS the files that it should use to find configuration information. The first line, for example, sets named.hosts as the file for locating the primary server of tpci.com. The IN-ADDR-ARPA information is kept in the file named.rev for the 143.25 subnet. The localhost information is in named.local, and finally the server and name cache information are in named.ca.<BR><P>A secondary name server is configured only slightly differently than a primary server. The difference is in the named.boot file, which points back to the primary server.<BR><BR><A ID=E70E45 NAME=E70E45></A><H5 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>Starting the DNS Daemons</B></FONT></CENTER></H5><BR><P>The final step in the DNS configuration is to ensure that the DNS daemon called named is loaded when the UNIX system boots. This is usually done through the rc startup scripts. Most versions of UNIX have the routines for DNS startup already entered in the startup script, usually in the form of a check for the file named.boot. If named.boot exists, the DNS daemon named starts. The code usually looks like this:<BR><PRE>

<FONT COLOR=#000080># Run DNS server if named.boot exists

if [ -f /etc/inet/named.boot -a -x /usr/sbin/in.named ]

then

   /usr/sbin/in.named

fi</FONT></PRE><P>The exact directory paths and options might be different in your rc script, but the command should check for the named.boot file and start named if it exists.<BR><BR><A ID=E70E46 NAME=E70E46></A><H5 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>Configuring a Client</B></FONT></CENTER></H5><BR><P>Configuring a UNIX machine to use a primary DNS server for resolution is a quick process. First, the /etc/resolv.conf file is modified to include the primary server's address. For example, a resolv.conf file might look like this:<BR><PRE>

<FONT COLOR=#000080>domain tpci.com

nameserver   143.25.0.1

nameserver   143.25.0.2</FONT></PRE><P>The first line establishes the domain name, which is followed by the IP addresses of available name servers. This file points to two name servers on the 143.25 subnet.<BR><BR><A ID=E68E103 NAME=E68E103></A><H3 ALIGN=CENTER><CENTER><FONT SIZE=5 COLOR=#FF0000><B>BOOTP Protocol</B></FONT></CENTER></H3><BR><P>TCP/IP needs to know an Internet address before it can communicate with other machines. This can cause a problem when a machine is initially loaded or has no dedicated disk drive of its own. On Day 2, &quot;TCP/IP and the Internet,&quot; you saw how Reverse Address Resolution Protocol (RARP) can be used to determine an IP address, but an alternative is in common use: the <I>bootstrap protocol</I> or BOOTP. BOOTP uses UDP to enable a diskless machine to determine its IP address without using RARP.<BR><P>Diskless machines usually contain start-up information in their PROMs. Because these must be kept small and consistent between many models of diskless workstations to reduce costs, it is impossible to pack a complete protocol such as TCP/IP into a chip. It is also impossible to embed an IP address, because the chip can be used in many different machines on the same network. This forces a newly booted diskless workstation to determine its own IP address from the other machines on the network. (In practice, the diskless machine also must determine the IP address of the network server it will use, as well as the address of the nearest IP gateway.)<BR><P>BOOTP overcomes a few of RARP's problems. RARP requires direct access to the network hardware, which can cause problems when dealing with servers. Also, RARP supplies only an IP address. When large packets must be sent, this wastes a lot of space that could be used for useful information. BOOTP was developed to use UDP and can be implemented within an application program. BOOTP also requires only a single packet of information to provide all the information a new diskless workstation requires to begin operation. Therefore, BOOTP is more efficient and easier to develop applications for, making it popular.<BR><P>To determine a diskless workstation's IP address, BOOTP uses the broadcast capabilities of IP. (You might recall that IP enables several special network addresses that are broadcast to all machines on the network.) This lets the workstation send a message even when it doesn't know the destination machine's address or even its own.<BR><BLOCKQUOTE><BLOCKQUOTE><HR ALIGN=CENTER><BR><NOTE><IMG SRC=note.gif WIDTH = 75 HEIGHT = 46>IP broadcast addresses such as 255.255.255.255 enable a message to be sent to all machines on a network despite having no source or destination network address.</NOTE><BR><HR ALIGN=CENTER></BLOCKQUOTE></BLOCKQUOTE><P>BOOTP puts all the communications tasks on the diskless workstation. It specifies that all UDP messages sent over the network use checksums and that the Do Not Fragment bit be set. This tends to reduce the number of lost, misinterpreted, or duplicated datagrams.<BR><P>To handle the loss of a message, BOOTP uses a simple set of timers. When a message has been sent, a timer starts. If no reply has been received when the timer runs out, the message is resent. The protocol stipulates that the timer is set to a random value, which increases each time the timer expires until it reaches a maximum value, after which it is randomized again. This prevents massive traffic after several machines fail at once and try to broadcast BOOTP messages at the same time.<BR><P>BOOTP uses the terms <I>client</I> and <I>server</I> to refer to machines. The client is the machine that initiates a query, and the server is the machine that replies to that query. From these definitions, it is easy to see that client and server have no physical relation to any workstation, because the role of each workstation can change with message traffic. Because most systems can handle multiple traffic threads at a time, it is possible for a machine to be both a client and a server simultaneously.<BR><BLOCKQUOTE><BLOCKQUOTE><HR ALIGN=CENTER><BR><NOTE><IMG SRC=note.gif WIDTH = 75 HEIGHT = 46>When considering client/server roles in BOOTP, remember that the machine that sends the first message is the client and the machine that replies is the server. There is no relationship to client/server architecture terms.</NOTE><BR><HR ALIGN=CENTER></BLOCKQUOTE></BLOCKQUOTE><BR><A ID=E69E151 NAME=E69E151></A><H4 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>BOOTP Messages</B></FONT></CENTER></H4><BR><P>BOOTP messages are kept in fixed formats for simplicity and to enable the BOOTP software to fit in a small space within a PROM. The format of BOOTP messages is shown in Figure 11.9. The OpCode field is used to signal either a request (set to a value of 1) or a reply (set to a value of 2). The HTYPE field indicates the network hardware type. The HLEN field indicates the length of a hardware address. (These last two fields are the same as in ARP.)<BR><P><B><A HREF=11tyt09.gif>Figure 11.9. The BOOTP message format.</A></B><BR><P>The HOPS field keeps track of the number of times the message is forwarded. When the client sends the request message, a value of 0 is put in the HOPS field. If the server decides to forward the message to another machine, it increments the HOPS count. (Forwarding is necessary when bootstrapping a machine across more than one gateway.)<BR><P>The Transaction Number field is an integer assigned by the client to the message and is unchanged from request to reply. This enables matching the replies to the correct request. The Seconds field is the number of seconds the client has been booted, assigned by the client when the message is sent.<BR><P>The Client IP Address field is filled in as much as possible by the client. This might result in a partial network address or no information at all, depending on the client's knowledge of the network it is in. Any information that is unknown is set to 0 (so the field might be 0.0.0.0 if nothing is known about the network address). If the client wants information from a particular server, it can put the address of the server in the Server IP Address field. Similarly, if the client knows the server's name, it puts it in the Server Host Name field. The same applies for the other address fields. If the fields are set to 0, any server can respond. If a specific server or gateway is given, only that machine responds to the message.<BR><P>The Vendor-Specific field is used, as the name suggests, for implementation information that is specific to each vendor. This field is optional. The first 32 bits define the format of the remaining information. These first bits are known as the <I>magic cookie</I> and have a standard value of 99.120.83.99. Following the magic cookie are sets of information in a three-field format: a type, a length, and a value. There are several types identified by the Internet RFC, as shown in Table 11.5. The Length field is not used for types 0 and 255, but it must be present for types 1 and 2. The length can vary depending on the number of entries in the other types of messages.<BR><BR><P ALIGN=CENTER><CENTER><FONT COLOR=#000080><B>Table 11.5. BOOTP vendor-specific types.</B></FONT></CENTER><BR><CENTER><TABLE BORDERCOLOR=#000040 BORDER=1 CELLSPACING=2 CELLPADDING=3><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P><B><I>Type</I></B></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P><B><I>Code</I></B></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P><B><I>Length</I></B></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P><B><I>Description</I></B></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Padding<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>0<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>--<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Used only for padding messages<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Subnet Mask<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>1<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>4<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Subnet mask for local network<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Time of Day<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>2<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>4<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Time of Day<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Gateways<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>3<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Number of entries<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>IP addresses of gateways<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Time Servers<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>4<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Number of entries<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>IP addresses of time servers<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>IEN116 Server<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>5<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Number of entries<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>IP addresses of IEN116 servers<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>DomainName Server<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>6<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Number of entries<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>IP addresses of Domain Name Servers<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Log Server<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>7<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Number of entries<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>IP addresses of log servers<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Quote Server<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>8<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Number of entries<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>IP addresses of quote servers<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>LPR Servers<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>9<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Number of entries<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>IP addresses of lpr servers<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Impress<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>10<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Number of entries<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>IP addresses of impress servers<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>RLP Server<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>11<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Number of entries<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>IP addresses of RLP servers<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Hostname<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>12<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Number of bytes<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Client host name in host name<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Boot size<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>13<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>2<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Integer size of boot file<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Unused<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>128&#150;254<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>--<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Not used<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>End<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>255<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>--<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>End of list</FONT></TABLE></CENTER><BR><P>You might remember that a machine can obtain the subnet mask from an ICMP message, but BOOTP is the recommended method of obtaining this value.<BR><P>The Boot Filename field can specify a filename from which to obtain a memory image that enables the diskless workstation to boot properly. This might be vendor-set or supplied by the server. This enables the memory image to be obtained from one machine while the actual addresses are obtained from another. If this field is set to 0, the server selects the memory image to send.<BR><P>The process of booting follows two steps. The first is to use BOOTP to obtain information about the network addresses of the client and at least one other machine (a gateway or server). The second step uses a different protocol to obtain a memory image for the client.<BR><BLOCKQUOTE><BLOCKQUOTE><HR ALIGN=CENTER><BR><NOTE><IMG SRC=note.gif WIDTH = 75 HEIGHT = 46>A two-step process using two different protocols is used to separate the configuration and operating system load of the machine. The use of two protocols enables optimization for each task. Two steps are also used because the machine that replies to the BOOTP client message might not be the machine that downloads the memory image.</NOTE><BR><HR ALIGN=CENTER></BLOCKQUOTE></BLOCKQUOTE><BR><A ID=E68E104 NAME=E68E104></A><H3 ALIGN=CENTER><CENTER><FONT SIZE=5 COLOR=#FF0000><B>Network Time Protocol (NTP)</B></FONT></CENTER></H3><BR><P>Timing is very important to networks, not only to ensure that internal timers are maintained properly, but also for synchronization of clocks for sending messages and timestamps within those messages. Some systems rely on time for routing. Ensuring that time clocks are consistent and accurate is a task often overlooked, but it remains important enough to have a formal procedure defined by an Internet RFC. The protocol that maintains time standards is called the Network Time Protocol, or NTP. NTP can use either TCP or UDP; port 37 is dedicated to it.<BR><P>The operation of NTP relies on obtaining an accurate time from a query to a primary time server, which itself gets its timing information from a standard time source (such as the National Institute of Standards and Technology in the U.S.). The time server queries the standard clock (also called a <I>master clocking source</I>) and sets its own times to the standard.<BR><P>Once the primary time server has an accurate time, it sends NTP messages to secondary time servers further out on the internetwork. Secondary time servers can communicate with more secondary time servers using NTP, although accuracy is lost with each communication due to latency in the networks. Eventually, these time messages can be sent to gateways and individual machines within a network, if the administrator so decides. Usually each network has at least one primary time server and one secondary server, although large networks might have several of each.<BR><P>The format of NTP messages is simple, as shown in Figure 11.10. Several control fields are used for synchronization and updating procedures, but the details of these fields are not important to this discussion. The Sync Distance to Primary field is an estimate of the round-trip delay incurred to the primary clock. The ID of the primary time server is the address of the primary.<BR><P><B><A HREF=11tyt10.gif>Figure 11.10. The NTP message format.</A></B><BR><P>There are several timestamps in the NTP message. The Time Local Clock Updated is the time the message originator's local clock was updated. The Originate timestamp is the time the message was sent. The Receive timestamp is the time it was received. The Transmit timestamp is the time the message was transmitted after reception.<BR><P>All timestamps are calculated from an offset of the number of seconds since January 1, 1900. The timestamp fields are 64 bits, the first 32 bits for a whole number and the last 32 for a fraction. The final Authentication field is optional and can be used to authenticate the message.<BR><BR><A ID=E68E105 NAME=E68E105></A><H3 ALIGN=CENTER><CENTER><FONT SIZE=5 COLOR=#FF0000><B>Summary</B></FONT></CENTER></H3><BR><P>You have now seen how the Domain Name Service works. DNS is an integral and important part of most TCP/IP installations, enabling symbolic names to be resolved properly across networks. The use of name servers was explained, as well as the manner in which records are stored within the servers. Associated with DNS is the ARP and IN-ADDR-ARPA name resolution process.<BR><P>Today I also looked at the BOOTP protocol, necessary to enable many diskless terminals and workstations to connect to the network and load their operating system. Without BOOTP, you would all need full-featured computers or workstations.<BR><BR><A ID=E68E106 NAME=E68E106></A><H3 ALIGN=CENTER><CENTER><FONT SIZE=5 COLOR=#FF0000><B>Q&amp;A</B></FONT></CENTER></H3><BR><P><B>What are the top-level domain names and what are their purposes?</B><BR><P>The top level domains are .arpa (Internet-specific), .com (commercial), .edu (educational institutions), .gov (governmental), .mil (military), and .org (non-commercial organizations).<BR><P><B>What does a DNS name server do?</B><BR><P>The DNS name server manages a zone of machines and provides name resolution for all machines within that zone.<BR><P><B>If a name server cannot resolve a n