Библиотека сайта rus-linux.net
Linux System Administrator's Survival Guide lsg30.htm
Chapter 30
Configuring TCP/IP
Despite what you may have heard, configuring TCP/IP is an easy process requiring usually only a little preparation work and a couple of commands to install the network IP addresses and names. This chapter looks at the process, setting up the support files, TCP/IP route files, and a PLIP interface. It also looks at how to set up your system to act as a gateway between networks, or use another machine as a gateway. Most of the steps you have to go through in this chapter are required only when you initially set up the system or when you make a network configuration change.
The last section of this chapter deals with name service, which you may need to install and configure if your machine is connected to a lot of other networks and machines. The name service and name resolver that goes with it are optional and are not necessary for your configuration unless you feel they will add to the usefulness of the network. You'll find a short discussion about name service in the preamble to the configuration steps.
Getting Ready to Configure TCP/IP
You must conduct a few housekeeping steps before you can configure your system's TCP/IP files. These are easy to accomplish and need only be done once. Some of the steps may have been done for you automatically when the system was installed, and others have been taken care of in earlier chapters of this book.
Some versions of Linux networking reply on the /proc filesystem (any Linux kernel that uses the Net-2 or later releases usually has this dependency). Most Linux kernels that support networking automatically create the /proc filesystem when the system is installed, so you shouldn't have to do anything more than make sure it is properly mounted by the kernel. The /proc filesystem is essentially a quick interface point for the kernel to obtain network information easily, as well as maintain important tables (which are usually kept in the subdirectory /proc/net, created by the network installation routine).
You should make sure the /proc filesystem is mounted automatically on your Linux system by examining the startup code for the kernel. To force the /proc filesystem to be mounted automatically, modify the /etc/fstab file and add the mount command there. (The /etc/fstab file was covered in more detail in Chapter 18, "Filesystems and Disks.") Check the entries in /etc/fstab for a line like this:
none /proc proc defaults
If no such line exists, you should add it to the contents of the /etc/fstab file using an ASCII editor.
If the /proc filesystem is not created by your Linux kernel you will have to rebuild the kernel and select the /proc option. Change to the source directory (such as /usr/src/Linux) and run the configuration routine with the following command:
make config
When you are asked whether you want the procfs (the /proc filesystem) support, answer y. If you do not get asked about the /proc filesystem support, and the /proc directory is not created on your filesystem, then you need to upgrade your kernel in order to support networking.
Another step you must take before configuring TCP/IP is to set the hostname. We examined this process in Chapter 17, "System Names and Access Permissions." To set the hostname, use the command
hostname name
where name is the system name you want for your local machine. If you have a full domain name assigned to your network and your machine, you can use that name for your system. For example, if your Linux machine is attached to the domain star.com and your machine's name is dark, you can set the full domain name using the command:
hostname dark.star.com
If you don't have a fully qualified domain name (one approach by the Internet Network Information Center), you can make up your own domain name as long as you are not connected to the Internet in any way. Such a domain name will not have any meaning outside your local area network. Alternatively, you do not have to assign a domain at all for your machine, but simply enter the short name:
hostname dark
When you set the local machine's name with the hostname command, an entry is usually made in the /etc/hosts file. You should verify that your machine name appears in that file.
You should also know the IP address assigned to your machine. We looked at IP addresses early in this section in Chapter 28, "TCP/IP and Networks." You should have a unique IP address ready for your local machine.
One file that may be handy for you if you plan to direct information across many networks is the /etc/networks file. This file contains a list of network names and their IP addresses. Applications on your machine can use this file to determine target networks based on their name. The file consists of two columns, one for the symbolic name of the remote network and the second for the IP address of the network (minus any host identifiers).
Most /etc/networks files have at least one entry for the loopback driver. The extract from an /etc/networks file looks like this:
loopback 127.0.0.0
merlin-net 147.154.12.0
BNR 47.0.0.0
This file has two networks entered in it with their network IP addresses. The entries are used primarily when the network boots, but can be used for other purposes including establishing routing.
Setting Up the Basics
The first step in setting up TCP/IP on your Linux machine is to make the network interface accessible. This is done with the ifconfig command. When run, ifconfig essentially makes the network layer of the kernel work with the network interface by giving it an IP address, and then issuing the command to make the interface active. When the interface is active, the kernel can send and receive data through the interface.
You need to set up several interfaces for your machine, including the loopback driver and the Ethernet interface (or whatever other network interface you are using). The ifconfig command is used for each interface in turn. The general format of the ifconfig command is
ifconfig interface_type IP_Address
where interface_type is the interface's device driver name, such as lo for loopback, ppp for PPP, and eth for Ethernet. (See Chapter 29, "Configuring Hardware and the Kernel," for interface names.) The IP_Address is the IP address used by that interface.
Once the ifconfig command has been run and the interface is active, you must use the route command to add or remove routes in the kernel's routing table. This is needed to allow the local machine to find other machines. The general format of the route command is:
route add|del IP_Address
where either add or del is specified to add or remove the route from the kernel's routing table, and IP_Address is the remote route being affected.
You can display the current contents of the kernel's routing table at any time by entering the command route all by itself on the command line. For example, if your system is set up only with the loopback driver, you will see an output like this:
$ route
Kernel Routing Table
Destination Gateway Genmask Flags MSS Window Use Iface
loopback * 255.0.0.0 U 1936 0 16 lo
The important columns are the destination name, which shows the name of the configured target (in this case only loopback), the mask to be used (Genmask), and the interface (Iface, in this case /dev/lo). You can force route to display the IP addresses instead of symbolic names by using the -n option:
$ route -n
Kernel Routing Table
Destination Gateway Genmask Flags MSS Window Use Iface
127.0.0.1 * 255.0.0.0 U 1936 0 16 lo
A typical Linux network configuration will include a couple of interfaces. The loopback interface should exist on every machine. The network interface, whether Ethernet or other device, is also present (unless you only want a loopback driver). This chapter assumes you want to set up your system for a loopback and an Ethernet card, both of which need to be done separately.
Setting Up the Loopback Interface
The loopback interface should exist on every networked machine (as well as machines that are stand-alone, for that matter). The loopback interface always has the IP address 127.0.0.1, so the /etc/hosts file should have an entry for this interface. The loopback driver may have been created by the kernel during software installation, so check the /etc/hosts file for a line similar to this:
127.0.0.1 localhost
If the line exists, the loopback driver is in place. Make sure the line doesn't have a pound sign ahead of it to comment it out. If the line doesn't exist in the /etc/hosts file, add it using an ASCII editor.
If the loopback interface was not in the /etc/hosts file, you will need to create the interface as well using the ifconfig command. Issue the following command to complete the addition of the loopback driver:
ifconfig lo 127.0.0.1
If you are not sure about the configuration, you can use the ifconfig command to display all the information it knows about the loopback driver. Use the following command:
ifconfig lo
You should see several lines of information like the following:
merlin:~# ifconfig lo
lo Link encap:Local Loopback
inet addr:127.0.0.1 Bcast:127.255.255.255 Mask:255.0.0.0
UP BROADCAST LOOPBACK RUNNING MTU:2000 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0
TX packets:12 errors:0 dropped:0 overruns:0
If you get an error message such as unknown interface, the loopback driver does not exist and must be added.
Once the ifconfig routine has been checked, add the loopback driver to the kernel routing tables with one of these two commands:
route add 127.0.0.1
route add localhost
It doesn't matter which command you use because they both refer to the same thing. The command essentially tells the kernel that it can use the route for address 127.0.0.1 or the name localhost.
As a quick check that all is correct with the loopback driver, you can use the ping command to check the routing (see Chapter 32, "Network Utilities," for more information on ping). For example, if you issue either of these two commands
ping localhost
ping 127.0.0.1
you should see output like this:
PING localhost: 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0. ttl=255 time=1 ms
64 bytes from 127.0.0.1: icmp_seq=1. ttl=255 time=1 ms
64 bytes from 127.0.0.1: icmp_seq=2. ttl=255 time=1 ms
64 bytes from 127.0.0.1: icmp_seq=3. ttl=255 time=1 ms
64 bytes from 127.0.0.1: icmp_seq=4. ttl=255 time=1 ms
64 bytes from 127.0.0.1: icmp_seq=5. ttl=255 time=1 ms
64 bytes from 127.0.0.1: icmp_seq=6. ttl=255 time=1 ms
64 bytes from 127.0.0.1: icmp_seq=7. ttl=255 time=1 ms
^C
--- localhost PING Statistics ---
7 packets transmitted, 7 packets received, 0% packet loss
round-trip (ms) min/avg/max = 1/1/1
The ping command's progress was interrupted by the user issuing a Ctrl-C after seven transmissions. You can let as many transmissions as you want go by. If you get a "no replies" from the ping command, then the address 127.0.0.1 or the name localhost wasn't recognized and you should check the configuration files and route entry again.
If the configuration files look correct and the route command was accepted properly, but the ping command still doesn't produce the proper results, then you have a serious problem. In some cases, the network kernel is not properly configured and the entire process must be conducted again. Sometimes a mismatch in versions of kernel drivers and network utilities can cause hang-ups with the ping routine, as well.
Setting Up an Ethernet Interface
Now that the loopback driver is installed and operational, you can do the same configuration process with the Ethernet driver (or whatever driver you are using). The process is exactly the same: use ifconfig to tell the kernel about the interface, and then add the routes to the remote machines on the network. If the network is attached, you can then test the connections with ping.
To begin, set up the Ethernet interface using ifconfig. To make the interface active, use the ifconfig command with the Ethernet device name and your local IP address. For example, use the command
ifconfig eth0 147.123.20.1
to set up the local machine with the IP Address 147.123.20.1. The interface is to the Ethernet device /dev/eth0. You don't have to specify the network mask with the ifconfig command, because it will deduce the proper value from the IP address entered. If you want to explicitly provide the network mask value, append it to the command line with the keyword netmask:
ifconfig eth0 147.123.20.1 netmask 255.255.255.0
This command explicitly sets the network mask to 255.255.255.0. You can then check the interface with the ifconfig command using the interface name:
$ ifconfig eth0
eth0 Link encap 10Mps: Ethernet Hwaddr
inet addr 147.123.20.1 Bcast 147.123.1.255 Mask 255.255.255.0
UP BROADCAST RUNNING MTU 1500 Metric 1
RX packets:0 errors:0 dropped:0 overruns:0
TX packets:0 errors:0 dropped:0 overruns:0
You may have noticed in the output from the command that the broadcast address was set based on the local machine's IP address. This is used by TCP/IP to access all machines on the local area network at once. The Message Transfer Unit (MTU) size is usually set to the maximum value of 1500 (for Ethernet networks).
Next, you need to add an entry to the kernel routing tables that let the kernel know about the local machine's network address. That lets it send data to other machines on the same network. The IP address that is used with the route command to do this is not your local machine's IP address, but that of the network as a whole without the local identifier. To set the entire local area network at once, the -net option of the route command is used. In the case of the IP addresses shown previously, the command would be:
route add -net 147.123.20.0
This command adds all the machines on the network identified by the network address 147.123.20 to the kernel's list of accessible machines. If you didn't do it this way, you would have to manually enter the IP address of each machine on the network. An alternative method is to use the /etc/networks file which can contain a list of network names and their IP addresses. If you have an entry in the /etc/networks file for a network called foobar_net, you could add the entire network to the routing table with the command:
route add foobar_net
Once the route has been added to the kernel routing tables, you can try the Ethernet interface out. This step assumes, of course, that you are connected to other machines and that you know the IP address of one of them. If your network isn't installed yet or you are not connected to another machine that is running TCP/IP, you can't try this step now. To ping another machine, you need either its IP address or its local name. Suppose you know the IP address and want to ping the machine 142.12.130.12. The command and output looks like the following:
tpci_sco1-45> ping 142.12.130.12
PING 142.12.130.12: 64 data bytes
64 bytes from 142.12.130.12: icmp_seq=0. time=20. ms
64 bytes from 142.12.130.12: icmp_seq=1. time=10. ms
64 bytes from 142.12.130.12: icmp_seq=2. time=10. ms
64 bytes from 142.12.130.12: icmp_seq=3. time=20. ms
64 bytes from 142.12.130.12: icmp_seq=4. time=10. ms
64 bytes from 142.12.130.12: icmp_seq=5. time=10. ms
64 bytes from 142.12.130.12: icmp_seq=6. time=10. ms
^C
--- 142.12.130.12 PING Statistics ---
7 packets transmitted, 7 packets received, 0% packet loss
round-trip (ms) min/avg/max = 10/12/20
Again, the ping routine was interrupted after seven attempts. You can see the diagnostic messages and summaries as ping sends a request to the remote machine and waits for a reply.
If you don't get anything back from the remote machine, verify that the remote is connected and you are using the proper IP address. If all is well there, check the configuration and route commands. If that checks out, try pinging another machine. If that fails, you can resort to the netstat utility, discussed in more detail in Chapter 32, "Network Utilities."
Configuring PLIP
The PLIP (parallel port IP) interface is used to connect only two machines through their parallel ports. (Chapter 29 looked briefly at PLIP.) Configuring PLIP is different from configuring TCP/IP, especially since the interface is not a standard TCP/IP interface and only two machines are involved.
Suppose that there is a simple PLIP interface between your local Linux machine called darkstar and a sibling's machine called x-wing. The two are connected by a null-parallel cable (see the previous chapter for wiring specifications). Both machines have only one parallel port used for PLIP. When PLIP is configured as shown in Chapter 29, "Configuring Hardware and the Kernel for Networking," the devices are set up as /dev/plip1 on both machines.
To configure the PLIP interface between the two machines, use the ifconfig command again, although this uses a special keyword called "pointopoint" (a condensed and confusing form of point-to-point, which describes the network type). The ifconfig command needed for the connection is:
ifconfig plip1 x-wing pointopoint darkstar
Note that the device is /dev/plip1, the remote machine is x-wing, and your local machine is darkstar. The order of arguments must be exact for the command to work properly.
Once the ifconfig command has been issued, you can follow it with an update of the kernel routing table with the route command. The command is:
route add x-wing gw darkstar
The gw keyword indicates that darkstar is a gateway to the x-wing machine. The next section covers gateways in more detail.
The same sort of entries must be made on the other machine to enable two-way communications. In this case, the remote machine would have entries like this:
ifconfig plip1 darkstar pointopoint x-wing
route add darkstar gw x-wing
Once both configurations are completed, you should be able to use the PLIP interface to send data between the two machines.
Gateways
Local area networks are connected by a gateway. The gateway is one machine that acts as the connection between the two networks, routing data between the two based on the IP address of the destination machine. The simplest use of a gateway is to connect to the rest of the world through the Internet. A machine that connects into the Internet can then connect to any other network on the Internet.
You have to make some changes to the network configuration files whenever your local machine is going to use a gateway, as well as if your machine is going to act as a gateway. To use the services of another machine as a gateway, you have to tell the routing tables about the gateway and the networks it connects to by using the route command
route add default gw net_gate
where net_gate is the name of the machine on your local area network that acts as the gateway out. The gateway machine follows the keyword gw in the route command. The use of the word default in the command indicates that the kernel's routing table should assume all networks can be reached through that gateway. (Physically, the default network setting translates to an IP address of 0.0.0.0.)
If you want to configure a gateway to another network, the name of that network should be in the /etc/networks file (see earlier in this chapter for details of the /etc/networks file). For example, if you have a gateway machine called gate_serv that leads from your own local area network to a neighboring network called big_corp (and an entry exists in the /etc/networks file for big_corp with their network IP address), you could configure the routing tables on your local machine to use gate_serv to access big_corp machines with this command:
route add big_corp gw gate_serv
An entry should be made on the remote network's routing table to reflect your network's address, otherwise you would only be able to send data and not receive it.
If you want to set up your local machine to act as a gateway itself, you need to configure the two network connections that your machine is joining. This usually requires two network boards, PPP connections, or SLIP connections in some combination. Assume your machine is going to act as a simple gateway between two networks called small_net and big_net, and you have two Ethernet cards installed in your machine. You configure both Ethernet interfaces separately with their respective network IP addresses, as you saw in Chapter 29, "Configuring Hardware and the Kernel." (For example, your machine many have an IP address on big_net of 163.12.34.36 and have the IP address 147.123.12.1 on small_net.)
Add the two IP addresses to your /etc/hosts file to simplify resolution. For the networks and IP addresses mentioned previously, you will have the following two entries in the /etc/hosts file:
163.12.34.36 merlin.big_net.com merlin-iface1
147.123.12.1 merlin.small_net.com merlin-iface
In this case, the fully qualified domain names have been added to the /etc/hosts file (this example assumes the machine has the name merlin on both networks, which is perfectly legal). You can also add shorter forms of the name, as well (such as merlin, merlin.big_net, and so on). Finally, the interface names have been included for convenience (so merlin-iface1 is the first interface on merlin, while merlin-iface2 is the second).
You then use the ifconfig commands to set up the connections between the interface and the names used in the /etc/hosts file:
ifconfig eth0 merlin-iface1
ifconfig eth1 merlin-iface2
These commands assume that the Ethernet device /dev/eth0 is for the interface to big_net, and /dev/eth1 is for small_net. Of course, you could have used the IP addresses of the networks instead of the interface name, as you saw earlier in this chapter.
Finally, the kernel routing table must be updated to reflect the two network names. The commands for this example are:
route add big_net
route add small_net
When these steps are completed, you must make sure that IP Forwarding has been enabled in the kernel. You can enable IP Forwarding by rebuilding the kernel. Once the kernel supports IP Forwarding, you can use your machine as a gateway between the two networks. Other machines on either network can also use your machine as a gateway between the two networks.
Although the examples shown here are for Ethernet connections to two networks, you could have any kind of interface. You could, for example, use an Ethernet card for your local area network, and then use a SLIP or PPP connection to another network (including the Internet).
Name Service and Name Resolver
TCP/IP uses the /etc/hosts file to resolve symbolic names into IP addresses. For example, when you specify the name darkstar for a target machine, TCP/IP will examine the /etc/hosts file for a machine of that name, and then read off the IP address. If the name isn't in the file, you can't send data to it. Suppose you connect to a lot of different machines, though. Your local area network may have dozens of machines on it, and your friend's network may have more. Adding all those entries to the /etc/hosts file can be tiresome and difficult, and maintaining the file as changes occur in the networks can be even more bothersome. To solve this problem, a couple of services were developed.
BIND (Berkeley Internet Name Domain service) was developed to help resolve the IP addresses of remote machines. BIND was later developed into DNS (Domain Name Service). Most Linux network systems implement the BIND version, although a few DNS-specific versions of software are appearing. Both BIND and DNS are complex subjects and involve many details that simply are not of interest to most Linux users. In this section, we will look at the necessary basics to get your Linux machine using BIND or DNS, and then leave it at that.
Configuring BIND or DNS can be a bothersome process and should only be done if your /etc/hosts file can't handle your requirements. For example, if you only connect to about a dozen machines, maintaining the /etc/hosts file is much easier than configuring BIND. For larger systems, or if you want to run the full Internet services available to your Linux machine, you need to configure BIND properly. Luckily, BIND usually has to be configured only once, and then it can be ignored. (If you do go through the process of configuring BIND, make sure you have backups!)
You will need the BIND software, which is usually included in the distribution software of most Linux recent releases. The BIND package includes all the files and executables, as well as a copy of the BOG (BIND Operator's Guide). Without the BIND software you can't configure your Linux system to use BIND or DNS.
The named Daemon and Name Servers
BIND and DNS are implemented through a daemon called named. The named daemon always runs on a machine called a name server, which is the machine on your network that handles the resolution of symbolic names to IP addresses. There can be several name servers on your network, or your machine can be the name server if you are running stand-alone.
Part of the name server system is a library of functions that are used by applications to set up queries for the name server, and to obtain answers from the name server. These functions are called the resolver or name resolver. The library of functions does not really have to be on the same machine as the name server.
The named daemon is usually started as part of the normal networking startup of Linux, although if you installed networking after your Linux system was installed, you may have to manually add the startup command to the rc files. The named daemon uses a file called /etc/named.boot that lists the master files used by other name servers. The /etc/named.boot file is covered later in this section.
Grossly simplified, BIND and DNS can be thought of as working like a set of telephone operators. If you are living in New York and want the number of a friend in London, England, you call your long distance operator to get the country code for England. That operator may connect to the English operator to give you the area code for London. Finally, that operator may connect to the London area operator to get your directory assistance number. BIND and DNS work in much the same way. When a name server can't figure out a name, it communicates with another name server that appears to be on the route to the target and waits for a reply to a directory query. That name server may contact others down the network, until some machine resolves the name and passes the message back to you.
Each name server manages a distinct area of a network (or an entire domain, if the network is small). The set of machines managed by the name server is called a zone. One name server may manage several zones. Within each zone, there is almost always a designated secondary or backup name server, with the two (primary and secondary) name servers holding duplicate information. The name servers within a zone communicate using a zone transfer protocol.
DNS operates by having a set of nested zones. Each name server communicates with the one above it (and the one below it, if one exists). Each zone has at least one name server responsible for knowing the address information for each machine within that zone. Each name server also knows the address of at least one other name server.
When an application needs to resolve a symbolic name into a network address, the application sends a query to the resolver process, which then communicates the query to the name server. The name server checks its own tables and returns the network address corresponding to the symbolic name. If the name server doesn't have the information it requires, it can send a request to another name server. Both the name servers and the resolvers use database tables and caches to maintain information about the machines in the local zone, as well as recently requested information from outside the zone.
When a name server receives a query from a resolver, the name server can perform several types of operations. Name resolver operations fall into two categories called non-recursive and recursive. A recursive operation is one in which the name server must access another name server for information. Non-recursive operations performed by the name server include a full answer to the resolver's request, a referral to another name server (which the resolver must address a query to itself), or an error message. When a recursive operation is necessary, the name server contacts another name server with the resolver's request. The remote name server will reply to the request with either a network address or a negative message indicating failure. Rules prohibit a remote name server from sending a referral on to yet another name server.
The resolver is intended to replace existing name resolution systems such as the /etc/hosts file. The replacement of these common mechanisms is transparent to users, although the administrator must know whether the native name resolution system or BIND/DNS is to be used on each machine so the correct tables can be maintained.
When the resolver acquires information from a name server, it stores the entries in its own cache to reduce the need for more network traffic if the same symbolic name is used again (as is often the case with applications that work across networks).
Under Linux, several different implementations of the name resolver are in use. The original resolver supplied with the BSD-based versions of Linux is somewhat limited, offering neither a cache nor iterative query capabilities. To solve these limitations, the Berkeley Internet Name Domain (BIND) server was added. BIND provides both caching and iterative query capabilities in three different modes: primary server, secondary server, or caching-only server (which doesn't have a database of its own, only a cache). The use of BIND on BSD systems allowed another process to take over the workload of name resolution, a process that may be on another machine entirely.
The hosts.conf File and Resolver Variables
The file /etc/hosts.conf is used as the central reference for the resolver. The /etc/hosts.conf file is used to tell the resolver which services it can use to resolve a name, and in what order they should be used. A sample /etc/hosts.conf file looks like this:
# /etc/host.conf
order bind hosts # named running
multi on # allow multiple addresses
nospoof on # protect from spoofing
trim merlin.com # local domain trim
Several options are possible in a /etc/hosts.conf file, each of which must be on a separate line of its own. The following are valid options:
| alert | If this option is active, any spoof attempt (see nospoof) logs a message in the syslog facility. This option is active if argument is on. |
| multi | This option determines whether a host in /etc/hosts is allowed to have several IP addresses. Valid values for this option are on and off. |
| nospoof | This option checks IP addresses to make sure the request is a valid one and not an attempt to break into the network. This check is not very secure, but it is a good first measure. If this option is specified with the argument on, nospoof is active. |
| order | This option specifies the order in which resolving services should be tried. Valid options are bind (query the name server), hosts (use the /etc/hosts file), and nis (use NIS lookups). |
| trim | This option takes a domain name as argument. It removes that domain name from hostnames before a lookup. You can use it to allow /etc/hosts to take precedence over name resolver for local networks, for example. |
The settings in the /etc/hosts.conf file can be overridden by some special resolver environment variables. Valid environment variables (which may be set for the session or by an application) are the following:
- RESOLV_ADD_TRIM_DOMAINS specifies a list of trim domains to add to those given in /etc/hosts.conf.
- Whenfollowed by a filename, RESOLV_HOST_CONF specifies the file to use instead of /etc/hosts.conf.
- RESOLV_MULTI overrides multi argument in /etc/hosts.conf. Valid values are on and off.
- RESOLV_OVERRIDE_TRIM_DOMAINS specifies a list of trim domains to override those given in /etc/hosts.conf.
- RESOLV_SERV_ORDER overrides the order option in the /etc/hosts.conf file.
- RESOLV_SPOOF_CHECK turns spoof checks on or off. Also allowed is the warn argument, which checks for spoofing and logs results, and warn off, which checks but doesn't log results. This variable also allows an asterisk argument, which turns on spoof checks but leaves logging as set in /etc/hosts.conf.
Name Server Lookups: The resolv.conf File
The file /etc/resolv.conf is used to tell the resolver which name servers to use. At least one name server must be specified for the resolver to be able to communicate with the server. If the /etc/resolv.conf file doesn't exist or is empty, the resolver will assume that your local machine is the name servers and try to send resolution requests to it.
A sample /etc/resolv.conf file shows the general format and the entries most systems will need. For a machine that uses a name server elsewhere on the network, this format is usually sufficient:
# /etc/resolv.conf
domain merlin.com # the local domain
nameserver 147.23.1.23 # the name server
The important keyword is the second one in the file, called nameserver. As you can guess, this keyword gives the IP address of the name server your local machine should use to resolve addresses.
You can specify more than one name server by using extra lines with the keyword (do not put the IP addresses on a single line). For example, the entries:
nameserver 147.23.1.23 # primary name server
nameserver 147.23.1.46 # secondary name server
nameserver 147.23.2.1 # extra name sever
use the name servers in the order they are encountered in the file. The most reliable name server should always be listed first. Most Linux versions allow only three name servers to be specified.
The domain and search keywords are used to allow shortcuts to identify addresses. The domain keyword is used to append a full address to a name instead of forcing you to specify it. For example, if you are on a local area network and want to FTP files from another system, you can use the name wizard instead of specifying the full domain names (such as wizard@foobar.com), as long as the domain line in the /etc/resolv.conf file contains the line:
domain foobar.com
This feature makes addressing machines on the local area network much easier.
The search option does much the same thing as the domain keyword, except it can apply to other networks instead of just your own. Both search and domain keywords can only appear once in the /etc/resolv.conf file.
The /etc/named.boot File
The /etc/named.boot file is used to specify the master files that contain zone information and name servers. The /etc/named.boot file is often set up by the software installation routine, but you should know the format of the file. One important difference between the named.boot file and most other files is the use of semi-colons for comments instead of the pound sign. A sample /etc/named.boot file looks like this:
; /etc/named.boot
; this is a comment line
directory /var/named
; now the domains and files they use
cache named.ca
primary merlin named.hosts
The directory keyword shows the directory in which the zone files are found. For most Linux installations this should be /var/named. The cache line indicates that the cache for BIND is to be enabled and load some basic information from the file named.ca. The primary keyword indicates the primary server is merlin and the zone information file is named.hosts.
The options (and their arguments) of the most commonly used values allowed in the named.boot file are:
| cache | Indicates the domain name and filename of the "root server hints" file and the cache |
| directory | Lists the directory in which zone files are found |
| forwarders | Indicates the IP addresses of a list of name severs that the named daemon can query |
| primary | Indicates the domain name and filename of the primary name server |
| secondary | Indicates the domain name and filename of the secondary name server |
| slave | Sets the name server as a slave |
Resource Records
The name server maintains the information required to resolve symbolic names to their IP addresses in a set of resource records, which are entries in a database. Resource records (often abbreviated to RR) contain information in ASCII format. Because ASCII is used, it is easy to update the records. Each RR has a specific format:
domain_name, type, class, TTL, Routing_Data
The domain name field is the machine the record refers to. If no name is specified, the name in the previous RR is used. The Type field identifies the type of resource record. The different types of resource records have different purposes, such as mapping names to addresses and defining zones. A mnemonic code or a number identifies the type of resource record. These codes and their meanings are listed in Table 30.1.
| Number | Code | Description |
| 1 | A | Network address |
| 2 | NS | Authoritative name server |
| 3 | MD | Mail destination. Now replaced by MX. |
| 4 | MF | Mail forwarder. Now replaced by MX. |
| 5 | CNAME | Canonical alias name |
| 6 | SOA | Start of zone authority |
| 7 | MB | Mailbox domain name |
| 8 | MG | Mailbox member |
| 9 | MR | Mail rename domain |
| 10 | NULL | Null resource record |
| 11 | WKS | Well-known service |
| 12 | PTR | Pointer to a domain name |
| 13 | HINFO | Host information |
| 14 | MINFO | Mailbox information |
| 15 | MX | Mail exchange |
| 16 | TXT | Text strings |
| 17 | RP | Responsible person |
| 18 | AFSDB | AFS-type services |
| 19 | X.25 | X.25 address |
| 20 | ISDN | ISDN address |
| 21 | RT | Route through |
Some of the resource record types are now obsolete (numbers 3 and 4), and others are considered experimental at this time (numbers 13 and 17 through 21). In most resource records, you find only types A, NS, SOA, and PTR.
The Class field in the resource record format contains a value for the class of record. If no value is specified, the class of the previous RR is substituted. Internet name servers usually have the code IN in this field.
The Time-to-Live (TTL) field specifies the amount of time in seconds that the resource record is valid in the cache. If a value of zero is used, the record should not be added to the cache. If the Time-to-Live field is omitted, a default value is used. Usually this field tells the name server how long the entry is valid before it has to ask for an update.
The data section of the resource record contains two parts: the length of the current record and the data itself. The Data Length field specifies the length of the data section. The data is a variable length field (hence the need for a length value) that describes the entry. The use of this field differs with the different types of resource records.
Some resource record types have a single piece of information in the data area, such as an address, or at most three pieces of information. The only exception is the Start of Authority (SOA) resource record. The contents of the resource record data areas (except SOA's) are:
The Start of Authority (SOA) resource record format is used to identify the machines that are within a zone. There is only one SOA record in each zone. The fields in the SOA resource record are mostly used for administration and maintenance of the name server. The order of fields in the SOA RR is:
MNAME, RNAME, Serial, Refresh, Retry, Expiry, Minimim
The MNAME field is the domain name of the source of data for the zone. The RNAME field is the domain name of the mailbox of the administrator of the zone (the responsible person name). The Serial field contains a version number for the zone. It is incremented when the zone is changed, otherwise maintained as the same value for all such messages.
The Refresh Time is the number of seconds between data refreshes for the zone. The Retry Time is the number of seconds to wait between unsuccessful refresh requests. The Expiry Time is the number of seconds after which the zone information is no longer valid. Finally, the Minimum Time is the number of seconds to be used in the Time-to-Live field of resource records within the zone.
Some sample resource records will show the formats used. Address resource records consist of the machine name, the type of resource record indicator ("A" for address RRs, for example), and the network address. A sample address resource record would look like this:
merlin _4 IN A 143.23.25.7
The IN tags the resource record as an Internet class. This format makes it easy to locate a name and derive its address. (The reverse, going from address to name, is not as easy and requires a special format called IN-ADDR-ARPA.)
For Well-Known Service resource records (WKS or Type 11), the data field of the record contains three fields used to describe the services supported at the address the record refers to. A sample WKS resource record might look like this:
wizard.merlin.com. IN WKS 143.23.1.34.
FTP TCP SMTP TELNET
If you want to specify the full domain name in the resource record, you must provide a trailing period. If you don't, the domain name will be added again, resulting in wizard.merlin.com.merlin.com in the preceding example. Alternatively, you can let the domain name get appended and just leave the machine name wizard in the resource record. The full domain name and Internet address are shown in the preceding example, as is the IN to show the Internet class of resource records. The type of record is indicated with the WKS. The protocols supported by the machine at that address are listed after the address. In reality, these protocols are a bitmap that corresponds to ports. When the port bit is set to a value of one, the service is supported. The list of ports and services are defined by an Internet RFC.
Resource Record Files
The main file that resource records reside in is usually called /var/named/named.ca on Linux systems. This file consists of hints to the resolver, which help it decide where to find information about name servers. A sample extract from the /var/named/named.ca file looks like this (comments are shown preceded by semi-colons):
; /var/named/named.ca - the cache file name
; this points to the primary name server
. 99999999 IN NS big_boy.big_net.com
big_boy.big_net.com 99999999 IN A 156.23.14.2
The /var/named/named.hosts file lists the local hosts and maps the hostname to an IP address. The file includes alias names, as well. A sample /var/named/named.hosts file looks like this:
; /var/named/named.hosts
@ IN SOA merlin.tpci.com merlin. (
16 ; serial
86400 ; refresh
3600 ; retry
36000 ; exxpiry
604800 ; expiry
)
IN NS merlin.tpci.com
; the local machine
localhost. IN A 127.0.0.1
merlin IN A 176.23.1.34
merlin.if1 IN CNAME merlin
The file /var/named/named.local helps with reverse mapping of locally-accessible addresses using the IN-ADDR-ARPA format(discussed in a section later in this chapter). A sample named.local file looks like this:
; /var/named/named.local
@ IN SOA merlin.tpci.com merlin (
16 ; serial
86400 ; refresh
3600 ; retry
36000 ; exxpiry
604800 ; expiry
)
IN NS merlin.tpci.com.
1 IN PTR localhost.
Finally, the file /var/named/named.rev is used for reverse mapping of other machines using IN-ADDR-ARPA. A sample named.rev file looks like this:
; /var/named/named.rev
@ IN SOA merlin.tpci.com merlin (
16 ; serial
86400 ; refresh
3600 ; retry
36000 ; exxpiry
604800 ; expiry
)
IN NS merlin.tpci.com.
1.1 IN PTR wizard.tpci.com.
2.1 IN PTR chatton.tpci.com.
3.1 IN PTR walter.tpci.com
All these files are created for you with default information when you install BIND. The process to update them to contain your information isn't as bad as you may think. Follow this two-step process to update your files:
First, edit the /var/named/named.hosts file. For each machine to be added to the file, you need the machine's symbolic name, its IP address, any host information you want to include, and any aliases that should be recognized. For example, to add the machine artemis (which is also called the_ark) to the named.hosts file, add these lines:
ARTEMIS IN A 146.12.23.1
IN HINFO PC UNIX
THE_ARK IN CNAME ARTEMIS
Next, edit the /var/named/hosts.rev file to provide reverse IN-ADDR-ARPA mapping for each newly added machine. For the machine used in the preceding example, this line would be added:
1.23 IN PTR ARTEMIS.TPCI.COM.
Note that the address portion of the IP address is reversed, as it should be (i.e. 1.23 instead of 23.1). Also the trailing period needs to be put in place.
IN-ADDR-ARPA
The address fields, such as in the Address resource record type, use a special format called "IN-ADDR-ARPA." This allows reverse mapping from the address to the host name as well as from the host to the address mapping. To understand IN-ADDR-ARPA, it is useful to begin with a standard-format resource record. One of the simplest types of resource record is for the address (type A). The following is an extract from an address file:
TPCI_HPWS1 IN A 143.12.2.50
TPCI_HPWS2 IN A 143.12.2.51
TPCI_HPWS3 IN A 143.12.2.52
TPCI_GATEWAY IN A 143.12.2.100
IN A 144.23.56.2
MERLIN IN A 145.23.24.1
SMALLWOOD IN A 134.2.12.75
Each line of the file represents one resource record. In this case, they are all simple entries that have the machine's symbolic name, the class of machine (IN for Internet), A to show it is an address resource record, and the Internet address. The entry for the machine TPCI_GATEWAY has two corresponding addresses because it is a gateway between two networks. The gateway has a different address on each of the networks, which results in two resource records in the same file.
This type of file makes name-to-address mapping easy. The name server simply searches for a line that has the symbolic name requested by the application and returns the Internet address at the end of that line. The databases are indexed on the name, so these searches proceed very quickly.
Searching from the address to the name is not quite as easy. If the resource record files were small, time delays for a manual search would not be appreciable, but with large zones there can be thousands or tens of thousands of entries. The index is on the name, so searching for an address would be a slow process. To solve this "reverse mapping" problem, IN-ADDR-ARPA was developed. IN-ADDR-ARPA uses the host address as an index to the host's resource record information. When the proper resource record is located, the symbolic name can be extracted.
IN-ADDR-ARPA uses the PTR resource record type (see Table 30.1) to point from the address to the name. There may be one of these pointer indexes maintained on each name server. An example of a "number-to-name" file is shown below:
23.1.45.143.IN-ADDR-ARPA. PTR TPCI_HPWS_4.TPCI.COM
1.23.64.147.IN-ADDR-ARPA. PTR TPCI_SERVER.MERLIN.COM
3.12.6.123.IN-ADDR-ARPA. PTR BEAST.BEAST.COM
143.23.IN-ADDR-ARPA PTR MERLINGATEWAY.MERLIN.COM
The Internet addresses are reversed in the IN-ADDR-ARPA file for ease of use. As shown in the sample file above, it is not necessary to specify the complete address for a gateway, because the domain name will provide enough routing information.
Summary
Once you've followed the steps in this chapter, your TCP/IP connection is properly configured (except for PPP and SLIP, which are discussed in Chapter 31, "Configuring SLIP and PPP.") The process for configuring TCP/IP is simple: run ifconfig, and then route. As long as the arguments are in the proper order, and the support files (such as /etc/hosts and /etc/networks) are correct, TCP/IP will not be fully accessible by your applications.
