[Chapter 8] 8.3 Configuring named The first time you run it, watch for error messages. named logs errors to the messages file. [11] Once named is running to your satisfaction, use nslookup to query the nameserver to make sure it is providing the correct information. [11] This file if found at /usr/adm/messages on both our Linux and Solaris sample systems but it might be located somewhere else on your system. Check your system's documentation. Previous: 8.2 Configuring the Resolver TCP/IP Network Administration Next: 8.4 Using nslookup 8.2 Configuring the Resolver Book Index 8.4 Using nslookup [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] file:///C|/mynapster/Downloads/warez/tcpip/ch08_03.htm (13 of 13) [2001-10-15 09:18:25] Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [Chapter 8] 8.4 Using nslookup Previous: 8.3 Configuring named Chapter 8 Configuring DNS Name Service Next: 8.5 Summary 8.4 Using nslookup nslookup is a debugging tool provided as part of the BIND software package. It allows anyone to directly query a nameserver and retrieve any of the information known to the DNS system. It is helpful for determining if the server is running correctly and is properly configured, or for querying for information provided by remote servers. The nslookup program is used to resolve queries either interactively or directly from the command line. Below is a command-line example of using nslookup to query for the IP address of a host: % nslookup almond.nuts.com Server: peanut.nuts.com Address: 172.16.12.2 Name: almond.nuts.com Address: 172.16.12.1 Here, a user asks nslookup to provide the address of almond.nuts.com. nslookup displays the name and address of the server used to resolve the query, and then it displays the answer to the query. This is useful, but nslookup is more often used interactively. The real power of nslookup is seen in interactive mode. To enter interactive mode, type nslookup on the command line without any arguments. Terminate an interactive session by entering CTRL-D (^D) or the exit command at the nslookup prompt. Redone in an interactive session, the previous query shown is: % nslookup Default Server: peanut.nuts.com Address: 172.16.12.2 > almond.nuts.com Server: peanut.nuts.com Address: 172.16.12.2 Name: almond.nuts.com Address: 172.16.12.1 > ^D file:///C|/mynapster/Downloads/warez/tcpip/ch08_04.htm (1 of 4) [2001-10-15 09:18:26] Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [Chapter 8] 8.4 Using nslookup By default, nslookup queries for A records, but you can use the set type command to change the query to another resource record type, or to the special query type "ANY." ANY is used to retrieve all available resource records for the specified host. The following example checks MX records for almond and peanut. Note that once the query type is set to MX, it stays MX. It doesn't revert to the default A-type query. Another set type command is required to reset the query type. % nslookup Default Server: peanut.nuts.com Address: 172.16.12.2 > set type=MX > almond.nuts.com Server: peanut.nuts.com Address: 172.16.12.2 almond.nuts.com preference = 5, mail exchanger = almond.nuts.com almond.nuts.com inet address = 172.16.12.1 > peanut.nuts.com Server: peanut.nuts.com Address: 172.16.12.2 peanut.nuts.com preference = 5, mail exchanger = peanut.nuts.com peanut.nuts.com inet address = 172.16.12.2 > exit You can use the server command to control the server used to resolve queries. This is particularly useful for going directly to an authoritative server to check some information. The following example does just that. In fact, this example contains several interesting commands: ● First we set type=NS and get the NS records for the zoo.edu domain. ● From the information returned by this query, we select a server and use the server command to direct nslookup to use that server. ● Next, using the set domain command, we set the default domain to zoo.edu. nslookup uses this default domain name to expand the hostnames in its queries, in the same way that the resolver uses the default domain name defined in resolv.conf. ● We reset the query type to ANY. If the query type is not reset, nslookup still queries for NS records. ● Finally, we query for information about the host tiger.zoo.edu. Because the default domain is set to zoo.edu, we simply enter tiger at the prompt. % nslookup Default Server: peanut.nuts.com Address: 172.16.12.2 > set type=NS file:///C|/mynapster/Downloads/warez/tcpip/ch08_04.htm (2 of 4) [2001-10-15 09:18:26] Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [Chapter 8] 8.4 Using nslookup > zoo.edu Server: peanut.nuts.com Address: 172.16.12.2 Non-authoritative answer: zoo.edu nameserver = NOC.ZOO.EDU zoo.edu nameserver = NI.ZOO.EDU zoo.edu nameserver = NAMESERVER.AGENCY.GOV Authoritative answers can be found from: NOC.ZOO.EDU inet address = 172.28.2.200 NI.ZOO.EDU inet address = 172.28.2.240 NAMESERVER.AGENCY.GOV inet address = 172.21.18.31 > server NOC.ZOO.EDU Default Server: NOC.ZOO.EDU Address: 172.28.2.200 > set domain=zoo.edu > set type=any > tiger Server: NOC.ZOO.EDU Address: 172.28.2.200 tiger.zoo.edu inet address = 172.28.172.8 tiger.zoo.edu preference = 10, mail exchanger = tiger.ZOO.EDU tiger.zoo.edu CPU=ALPHA OS=UNIX tiger.zoo.edu inet address = 172.28.172.8, protocol = 6 7 21 23 25 79 tiger.ZOO.EDU inet address = 172.28.172.8 > exit The final example shows how to download an entire domain from an authoritative server and examine it on your local system. The ls command requests a zone transfer and displays the contents of the zone it receives. [12] If the zone file is more than a few lines long, redirect the output to a file, and use the view command to examine the contents of the file. (view sorts a file and displays it using the UNIX more command.) The combination of ls and view are helpful when tracking down a remote hostname. In the example that follows, the ls command retrieves the big.com zone and stores the information in temp.file. Then view is used to examine temp.file. [12] For security reasons, many nameservers do not respond to the ls command. See the xfrnets command in Appendix C for information on how to limit access to zone transfers. peanut% nslookup Default Server: peanut.nuts.com Address: 172.16.12.2 > server minerals.big.com Default Server: minerals.big.com Address: 192.168.20.1 file:///C|/mynapster/Downloads/warez/tcpip/ch08_04.htm (3 of 4) [2001-10-15 09:18:26] Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [Chapter 8] 8.4 Using nslookup > ls big.com > temp.file [minerals.big.com] ######## Received 406 records. > view temp.file acmite 192.168.20.28 adamite 192.168.20.29 adelite 192.168.20.11 agate 192.168.20.30 alabaster 192.168.20.31 albite 192.168.20.32 allanite 192.168.20.20 altaite 192.168.20.33 alum 192.168.20.35 aluminum 192.168.20.8 amaranth 192.168.20.85 amethyst 192.168.20.36 andorite 192.168.20.37 apatite 192.168.20.38 beryl 192.168.20.23 --More-- q > exit These examples show that nslookup allows you to: ● Query for any specific type of standard resource record. ● Directly query the authoritative servers for a domain. ● Get the entire contents of a domain into a file so you can view it. Use nslookup's help command to see its other features. Turn on debugging (with set debug) and examine the additional information this provides. As you play with this tool, you'll find many helpful features. Previous: 8.3 Configuring named TCP/IP Network Administration Next: 8.5 Summary 8.3 Configuring named Book Index 8.5 Summary [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] file:///C|/mynapster/Downloads/warez/tcpip/ch08_04.htm (4 of 4) [2001-10-15 09:18:26] Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [Chapter 8] 8.5 Summary Previous: 8.4 Using nslookup Chapter 8 Configuring DNS Name Service Next: 9. Configuring Network Servers 8.5 Summary Domain Name Service (DNS) is an important user service that should be used on every system connected to the Internet. UNIX implementations of DNS are based on the Berkeley Internet Name Domain (BIND) software. BIND provides both a DNS client and a DNS server. The BIND client issues name queries and is implemented as library routines. It is called the resolver. The resolver is configured in the resolv.conf file. All systems run the resolver. The BIND server answers name queries and it runs as a daemon. It is called named. named is configured by the named.boot file, which defines where the server gets the domain database information and the type of server being configured. The server types are primary, secondary and caching servers. Because all servers are caching servers, a single configurtaion often encompasses more than one server type. The original domain database source files are found on the primary server. The domain database file is called a zone file. The zone file is constructed from standard resources records (RR) that are defined in RFCs. The RRs share a common structure and are used to define all DNS database information. The DNS server can be tested using nslookup. This test tool is included with the BIND release. In this chapter we have seen how to configure and test domain name service. In the next chapter we configure several other services. Previous: 8.4 Using nslookup TCP/IP Network Administration Next: 9. Configuring Network Servers 8.4 Using nslookup Book Index 9. Configuring Network Servers [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] file:///C|/mynapster/Downloads/warez/tcpip/ch08_05.htm [2001-10-15 09:18:27] Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. file:///C|/mynapster/Downloads/warez/tcpip/ch09_01.htm Previous: 8.5 Summary Chapter 9 Next: 9.2 Line Printer Daemon 9. Configuring Network Servers Contents: The Network File System Line Printer Daemon Network Information Service A BOOTP Server DHCP Managing Distributed Servers Mail Servers Summary Now our attention turns to configuring network servers. As with name service, these servers are not strictly required for the network to operate, but they provide services that are central to the network's purpose. There are many network services - many more than can be covered in this chapter. We concentrate on servers that provide "computer-to-computer" services. [1] The services covered in this chapter are: [1] Notably absent is sendmail. It requires so much discussion, it has its own chapter ( Chapter 10, sendmail )! ● The Network File System (NFS) ● The Line Printer Daemon (LPD) ● The Network Information Service (NIS) ● The Bootstrap Protocol (BOOTP) ● Dynamic Host Configuration Protocol (DHCP) ● The Post Office Protocol (POP) We begin with NFS, which is the server that provides file sharing on UNIX networks. 9.1 The Network File System The Network File System (NFS) allows directories and files to be shared across a network. It was originally developed by Sun Microsystems, but is now supported by virtually all UNIX implementations and many non- UNIX operating systems. Through NFS, users and programs can access files located on remote systems as if they were local files. In a perfect NFS environment, the user neither knows nor cares where files are actually stored. file:///C|/mynapster/Downloads/warez/tcpip/ch09_01.htm (1 of 13) [2001-10-15 09:18:29] Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. file:///C|/mynapster/Downloads/warez/tcpip/ch09_01.htm NFS has several benefits: ● It reduces local disk storage requirements because a network can store a single copy of a directory, while the directory continues to be fully accessible to everyone on the network. ● NFS simplifies central support tasks - files can be updated centrally, yet available throughout the network. ● NFS allows users to use familiar UNIX commands to manipulate remote files instead of learning new commands. There is no need to use ftp or rcp to copy a file between hosts on the network; cp works fine. There are two sides to NFS - a client side and a server side. The client is the system that uses the remote directories as if they were part of its local filesystem. The server is the system that makes the directories available for use. Attaching a remote directory to the local filesystem (a client function) is called mounting a directory. Offering a directory for remote access (a server function) is called sharing a directory. [2] Frequently, a system runs both the client and the server NFS software. In this section we'll look at how to configure a system to share and mount directories using NFS. [2] An older term for this function is exporting. Many systems still refer to file sharing as exporting. If you're responsible for an NFS server for a large site, you should take care in planning and implementing the NFS environment. The discussion in this chapter tells how NFS is configured to run on a client and a server, but you may want more details to design an optimal NFS environment. For a comprehensive treatment, see Managing NFS and NIS, by Hal Stern (O'Reilly & Associates). 9.1.1 NFS Daemons The Network File System is run by several daemons, some performing client functions and some performing server functions. Before we discuss the NFS configuration, let's look at the function of the daemons that run NFS: nfsd [nservers] The NFS daemon, nfsd, runs on NFS servers. This daemon services the client's NFS requests. The nservers option is available on Solaris systems. It specifies how many daemons should be started. mountd The NFS mount daemon, mountd, processes the clients' mount requests. NFS servers run the mount daemon. lockd The lock daemon, lockd, handles file lock requests. Both clients and servers run the lock daemon. Clients request file locks, and servers grant them. statd The network status monitor daemon, statd, is required by lockd to provide monitoring services. In particular, it allows locks to be reset properly after a crash. Both clients and servers run statd. The daemons necessary to run NFS are started from boot scripts. On a Solaris system, two scripts located in the /etc/init.d directory, nfs.client and nfs.server, handle this job. The nfs.client script starts the statd and lockd programs. [3] NFS server systems run those two daemons, plus the NFS server daemon, nfsd, and the mount file:///C|/mynapster/Downloads/warez/tcpip/ch09_01.htm (2 of 13) [2001-10-15 09:18:29] Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. file:///C|/mynapster/Downloads/warez/tcpip/ch09_01.htm server daemon, mountd. On Solaris systems, the nfs.server script starts mountd and 16 copies of nfsd. [3] On your system, the prefix "rpc." may be used on the daemon names. For example, the Slackware Linux system uses the filename rpc.nfsd for the NFS daemon. Check your system's documentation. Each system has its own technique for starting these daemons. If some of the daemons aren't starting, make sure your startup scripts are correct. 9.1.2 Sharing Filesystems The first step in configuring a server is deciding which filesystems will be shared, and what restrictions will be placed on them. Only filesystems that provide a benefit to the client should be shared. Before you share a filesystem, think about what purpose it will serve. Some common reasons for sharing filesystems are: ● To provide disk space to diskless clients ● To prevent unnecessary duplication of the same data on multiple systems ● To provide centrally supported programs and data ● To share data among users in a group Once you've selected the filesystems you'll share, you must configuring them for sharing using the appropriate commands for your system. In the following sections we emphasize the way this is done on Solaris systems. It is very different on Linux systems. Check your system's documentation to find out exactly how it implements NFS file sharing. 9.1.2.1 The share command On Solaris systems, directories are shared using the share command. A simplified syntax for the share command is: share -F nfs [-o options] pathname where pathname is the path of the directory the server is offering to share with its clients, and options are the access controls for that directory. The commonly used options are: rw The rw option grants read and write access to the shared filesystem. It can be specified in the form rw=host:host . to identify the individual hosts that are granted this access. When used in this way, only the hosts identified in the list are given access to the filesystem. If the colon-separated list of hostnames is not provided with the rw option, all hosts are given read/write access to the filesystem. In fact, if no options are specified at all, the share command defaults to giving all clients read/write access. This default is acceptable if your systems are on an isolated network, but if they are on a connected network, this could open up a security hole. It is the best practice to restrict access to those hosts that you really trust. ro This option limits access to read-only. It also can be specified with a colon-separated host list, e.g., file:///C|/mynapster/Downloads/warez/tcpip/ch09_01.htm (3 of 13) [2001-10-15 09:18:29] Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. file:///C|/mynapster/Downloads/warez/tcpip/ch09_01.htm ro=host:host When the host list is included, only the hosts on the list have access and that access is limited to read-only. root=host This option allows the root user on the specified host to have root access to the shared filesystem. Normally, the root user on a remote system is mapped to the userid nobody and given only normal user privileges. Granting root access is a big security risk. The rw and ro options can be combined to grant different levels of access to different clients. For example: share -F nfs -o rw=almond:pecan ro /usr/man share -F nfs -o rw=peanut:almond:pecan:walnut /export/home/research The first share command grants read and write access to almond and peanut and read-only access to all other clients. On the other hand, the second share command grants read/write access to peanut, almond, pecan, and walnut, and no access of any kind to any other client. The share command does not survive a boot. Put the share commands in the /etc/dfs/dfstab file to make sure that the filesystems continue to be offered to your clients even if the system reboots. Here is a sample dfstab file containing our two share commands: % cat /etc/dfs/dfstab # place share(1M) commands here for automatic execution # on entering init state 3. # # share [-F fstype] [ -o options] [-d "<text>"] <pathname> [resource] # .e.g, # share -F nfs -o rw=engineering -d "home dirs" /export/home2 share -F nfs -o rw=almond:pecan ro /usr/man share -F nfs -o rw=peanut:almond:pecan:walnut /export/home/research The share command, the dfstab file, and even the terminology "share" are Solaris-specific. Most UNIX systems say that they are exporting files, instead of sharing files, when they are offering files to NFS clients. Furthermore, they do not use the share command or the dfstab file; instead, they offer filesystems through the /etc/exports file. Linux is an example of such a system. 9.1.2.2 The /etc/exports file The /etc/exports file is the NFS server configuration file for Linux systems. It controls which files and directories are shared (exported), which hosts can access them, and what kinds of access are allowed. A sample /etc/exports file might contain these entries: /usr/man almond(rw) pecan(rw) (ro) /usr/local (ro) /home/research peanut(rw) almond(rw) pecan(rw) walnut(rw) This sample file says that: ● /usr/man can be mounted by any client, but it can be written to only by almond and pecan. Other clients file:///C|/mynapster/Downloads/warez/tcpip/ch09_01.htm (4 of 13) [2001-10-15 09:18:29] Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [...]... for lpsystem for more information All UNIX systems provide some technique for sharing printers The network administrator's task is to ensure that the printers are accessible via the network and that they are properly secured Previous: 9.1 The Network File System TCP/IP Network Administration Next: 9.3 Network Information Service Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark... Line Printer Daemon 9.1 The Network File System Book Index 9.3 Network Information Service [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark file:///C|/mynapster/Downloads/warez/tcpip/ch09_02.htm (6 of 6) [2001-10-15 09:18:30] [Chapter 9] 9.3 Network Information Service... Line Printer Daemon Chapter 9 Configuring Network Servers Next: 9.4 A BOOTP Server 9.3 Network Information Service The Network Information Service (NIS) [9] is an administrative database that provides central control and automatic dissemination of important administrative files NIS converts several standard UNIX files into databases that can be queried over the network The databases are called NIS maps... the Solaris System and Network Administration manual set NIS and NIS+ provide a wide range of system configuration information to their clients However, they cannot provide all of the information needed to configure a TCP/IP system In the next two sections, we look at configuration servers that can do the entire job Previous: 9.2 Line Printer Daemon 9.2 Line Printer Daemon TCP/IP Network Administration... to remove this watermark file:///C|/mynapster/Downloads/warez/tcpip/ch09_01.htm (13 of 13) [2001-10-15 09:18:29] [Chapter 9] 9.2 Line Printer Daemon Previous: 9.1 The Network File System Chapter 9 Configuring Network Servers Next: 9.3 Network Information Service 9.2 Line Printer Daemon The Line Printer Daemon (lpd) provides printer services for local and remote users lpd manages the printer spool area... dequeued cfA404acorn dequeued Along with the r commands, lpd and lpr were among the first commands created for UNIX to exploit the power of TCP/IP networking Managing printers is primarily a system administration task Only those aspects of LPD related to remote printing and network security are covered here 9.2.2 Solaris Line Printer Service The Solaris system uses the Line Printer (LP) print service that... related to network administration: [9] NIS was formerly called the "Yellow Pages," or yp Although the name has changed, the abbreviation yp is still used /etc/ethers Creates the NIS maps ethers.byaddr and ethers.byname The /etc/ethers file is used by RARP (see Chapter 2, Delivering the Data) /etc/hosts Produces the maps hosts.byname and hosts.byaddr (see Chapter 3, Network Services) /etc/networks Produces... [Chapter 9] 9.3 Network Information Service same map list on both our Solaris and Linux sample systems Your server may display a longer list Here is the list from my Solaris system: % ypcat -x Use "passwd" Use "group" Use "networks" Use "hosts" Use "protocols" Use "services" Use "aliases" Use "ethers" for for for for for for for for map map map map map map map map "passwd.byname" "group.byname" "networks.byaddr"... file:///C|/mynapster/Downloads/warez/tcpip/ch09_01.htm lpr and lpd if a printer is not properly configured Previous: 8.5 Summary 8.5 Summary TCP/IP Network Administration Book Index Next: 9.2 Line Printer Daemon 9.2 Line Printer Daemon [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] Please purchase PDF Split-Merge on www.verypdf.com to remove this... Server [ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ] Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark file:///C|/mynapster/Downloads/warez/tcpip/ch09_03.htm (5 of 5) [2001-10-15 09:18:31] [Chapter 9] 9.4 A BOOTP Server Previous: 9.3 Network Information Service Chapter 9 Configuring Network Servers Next: 9.5 DHCP 9.4 . 8.4 Using nslookup TCP/IP Network Administration Next: 9. Configuring Network Servers 8.4 Using nslookup Book Index 9. Configuring Network Servers [ Library. sharing on UNIX networks. 9.1 The Network File System The Network File System (NFS) allows directories and files to be shared across a network. It was