43.25.23.143.in-addr.arpa IN PTR bigcat 72.25.23.143.in-addr.arpa IN PTR pepper There must be a separate named.rev file for each zone or subdomain on the network. These files can have different names or be placed in different directories. If you have only a single zone, one named.rev file is all that's needed. The named.local file contains an entry for the loopback driver (which always has the IP address 127.0.0.1). This file must contain information about the IN-ADDR-ARPA mapping of the loopback driver, as well as a domain again (because the named.rev file doesn't cover the 127 subnet). A named.local file looks like this: ; named.local files ; Start Of Authority RR 0.0.127.in-addr.arpa IN SOA merlin.tpci.com root.merlin.tpci.com ( 2 ; Serial number 7200 ; Refresh (2 hrs) 3600 ; Retry (1 hr) 151200 ; Expire (1 week) 86400 ); min TTL ; ; Name Service RR 0.0.127.in-addr.arpa IN NS merlin.tpci.com ; ; Address RR 1.0.0.127.in-addr.arpa IN PTR localhost This file then provides the mapping from the machine named localhost to the IP address 127.0.0.1. The named.ca file is used to specify name servers that the system can resort to. The Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com machines specified in the named.ca file should be stable and not subject to rapid change. A sample named.ca file looks like this: ; named.ca ; servers for the root domain ; . 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 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. 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: ; named.boot directory /usr/lib/named primary tpci.com named.hosts primary 25.143.in-addr.arpa named.rev Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com primary 0.0.127.in-addr.arpa named.local cache . named.ca 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. 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. Starting the DNS Daemons 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: # 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 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. Configuring a Client Configuring a UNIX machine to use a primary DNS server for resolution is a quick Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 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: domain tpci.com nameserver 143.25.0.1 nameserver 143.25.0.2 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. BOOTP Protocol 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, "TCP/IP and the Internet," you saw how Reverse Address Resolution Protocol (RARP) can be used to determine an IP address, but an alternative is in common use: the bootstrap protocol or BOOTP. BOOTP uses UDP to enable a diskless machine to determine its IP address without using RARP. 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.) 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. 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 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 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. 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. 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. 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. BOOTP uses the terms client and server 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. 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. BOOTP Messages Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 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.) Figure 11.9. The BOOTP message format. 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.) 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. 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. 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 magic cookie 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. Table 11.5. BOOTP vendor-specific types. Type Code Length Description Padding 0 Used only for padding messages Subnet Mask 1 4 Subnet mask for local network Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Time of Day 2 4 Time of Day Gateways 3 Number of entries IP addresses of gateways Time Servers 4 Number of entries IP addresses of time servers IEN116 Server 5 Number of entries IP addresses of IEN116 servers DomainName Server 6 Number of entries IP addresses of Domain Name Servers Log Server 7 Number of entries IP addresses of log servers Quote Server 8 Number of entries IP addresses of quote servers LPR Servers 9 Number of entries IP addresses of lpr servers Impress 10 Number of entries IP addresses of impress servers RLP Server 11 Number of entries IP addresses of RLP servers Hostname 12 Number of bytes Client host name in host name Boot size 13 2 Integer size of boot file Unused 128–254 Not used End 255 End of list 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. 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. 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. 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 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com to the BOOTP client message might not be the machine that downloads the memory image. Network Time Protocol (NTP) 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. 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 master clocking source) and sets its own times to the standard. 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. 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. Figure 11.10. The NTP message format. 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. Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 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. Summary 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. 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. Q&A What are the top-level domain names and what are their purposes? The top level domains are .arpa (Internet-specific), .com (commercial), .edu (educational institutions), .gov (governmental), .mil (military), and .org (non-commercial organizations). What does a DNS name server do? The DNS name server manages a zone of machines and provides name resolution for all machines within that zone. If a name server cannot resolve a name using its own tables, what happens? Queries can be sent from the machine receiving the query to other name servers to search for a resolution. If another machine does have the answer, it is not returned to the inquiring machine, however. Only the address of the name resolver with the answer is returned. The inquiring machine must then send a specific query to the resolver with the answer. Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com What is the advantage of the IN-ADDR-ARPA format? IN-ADDR-ARPA enables a mapping from the IP address to the symbolic host name. Sometimes this is a fast way to obtain the symbolic name of a destination machine. Why does BOOTP use UDP? Simply because it is smaller to code. To embed TCP code in a PROM would take much more room than the simple code needed for UDP. Quiz 1. What protocol is used by DNS name servers? Why is that a good choice? 2. What is a DNS resource record? 3. Show a sample entry in an IN-ADDR-ARPA file and explain what the fields mean. 4. BOOTP helps a diskless workstation boot. How does it get a message to the network looking for its IP address and the location of its operating system boot files? 5. What is the Network Time Protocol? Why is it used? Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com [...]... Locking s Remote Execution Service (REX) s rusers and spray Configuring NFS s Configuring UNIX as an NFS Server s Setting Up a UNIX NFS Client s Setting Up Windows-Based NFS s Sharing a Windows Directory Network Information Service (NIS) Configuring NIS s Setting Up the NIS Domain s NIS Daemons s Setting Up an NIS Master s Setting Up NIS Slaves s Setting Up NIS Clients RPC and NFS Administration s rpcinfo... Each machine on the domain (whether one or many domains are established) must be entered into a configuration file to enable the client machine to use NIS To set up the NIS domain, you need to log into each client machine on the network and set up the domain name with the following command: domainname domain domain is the domain name the machine uses You need to be logged in as root or an administrative... requirements In this section I continue with ChameleonNFS as the example NFS software, because it is relatively easy to install, configure, and use I use Windows 3.11 as the operating system example ChameleonNFS relies on a software daemon called Portmapper, which maintains a list of all currently registered network services (including NFS) Portmapper is loaded automatically when the Windows machine boots in. .. called a domain (not to be confused with the Internet domain) Each domain has master and slave machines NIS keeps the access information in a set of maps, each map corresponding to a particular area or domain of a network This allows for several groups to use the same NIS master but have different access permissions The NIS maps do not have to correspond to DNS domains, enabling more versatility in configuration... looking at what has to be changed on any client machines that want to use NIS Setting Up the NIS Domain NIS domains are usually assigned to group machines together with an NIS master and one or more NIS slaves as backup An NIS domain doesn't have to be the same as an Internet domain, although for most networks they are identical (in other words, the entire network is the NIS domain) The NIS domain has... meaning NFS was designed to be a stateless protocol, meaning that the machines using NFS would not have to maintain state tables to use the protocol Also, it was designed to be robust, meaning that after failures (of a connection or a machine) the system could recover quickly and easily The NFS protocol is difficult to describe without introducing some programming, because the system is described in. .. UNIX file is uniquely defined by its device major and minor numbers and its inode number The filename itself is not used A data object is used for the file type (called ftype), which defines all the kinds of files known by NFS These mimic the UNIX file types, including a regular file (any kind of data), a directory (which is a file entry in UNIX), links (which are several pointers under different names... your Internet domain name Alternatively, you can set up subsidiary domains for small logical groups in a large corporation, such as domains for accounting, research and development, and marketing To set up an NIS domain, you need to decide on the domain name and know the IP address of the NIS master and any NIS slaves If you have more than one NIS domain established, you need to know which machines... packages for Windows 3.x, Windows 95, and Windows NT provide NFS support One of the widest used is NetManage's ChameleonNFS, which can be used under any of the Windows operating system versions ChameleonNFS enables a Windows machine to act as both client and server for NFS file access In other words, another machine can access files on the ChameleonNFS machine, and the ChameleonNFS machine can access... format uses sequential bits written into a buffer, then formatted into a message and sent to the lower protocol layers XDR relies on an 8- bit byte, with the lower bytes being the most significant The RFC defines that all integer data types are converted to 4-byte integers, with an extended 64-bit hyperinteger format available IEEE 32-bit formats are used for floating-point numbers, where the mantissa is . 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 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 1 98. 41.0.4 In. Locking ■ Remote Execution Service (REX) ■ rusers and spray ■ Configuring NFS ■ Configuring UNIX as an NFS Server ■ Setting Up a UNIX NFS Client ■ Setting Up Windows-Based NFS ■ Sharing a Windows