Linux can run several protocols that can provide important background functionality on networks. These protocols seldom make themselves obvious to users—except if the servers that manage them malfunction. Although most of them are major protocols in the sense that they provide many features and have even spawned entire books, they aren't tricky enough to configure to deserve entire chapters in this book. Therefore, I cover all of them in this chapter. These protocols are the Dynamic Host Configuration Protocol, which delivers IP addresses and other basic network configuration information to clients; the Domain Name System, which converts hostnames to IP addresses and vice versa; and the Network Time Protocol, which helps keep clocks synchronized on multiple computers.

Although all these protocols can be handled by Windows, doing so with Linux gives you all of Linux's advantages. The servers that handle these protocols are all small enough and require little enough in the way of CPU time, memory, and other resources that they can be run on a very modest Linux system—perhaps an old 80486 or Pentium system that's been retired. You can move one or more of these services onto such a Linux system, obviating the need to upgrade your software and hardware to enable the latest version of Windows to do the job.

Delivering IP Addresses with DHCP

Networks of all sizes use DHCP to simplify configuration of most computers on the network. A computer configured to use DHCP for basic network configuration tries to locate a DHCP server at startup and, if one is found, sets its basic network options to those specified by the DHCP server. This task may sound impossible because basic network configuration information is delivered via the network before the DHCP client is configured, but it is possible, and understanding the basics of how it's possible is the first order of business. Next up is an overview of DHCP configuration files. You can use DHCP to assign addresses either so that the same computer is or isn't guaranteed the same address on each boot, and understanding how to do both is important. Finally, knowing how to tell clients to use DHCP is critically important to this protocol's successful deployment.

The Role of DHCP

DHCP is an unusual protocol because it uses very low-level network protocols to help a computer "bootstrap" a more sophisticated configuration. When a DHCP client boots or starts its TCP/IP network stack, the client has no IP address, but it does have working hardware, and it can send data over the network wire. The DHCP client therefore sends a network broadcast with a query directed at any DHCP server that might be listening. Although the DHCP client has no IP address, it does have a working low-level hardware address, and the DHCP server is able to direct its reply to this address. The DHCP server's reply includes information on basic network settings—most importantly, the client's IP address and network mask, as well as the IP addresses of the subnet's router and the DNS servers the client should use. Additional information can be delivered, as well, such as the IP addresses of NBNS computers, but this information isn't delivered by all DHCP servers or used by all clients.

DHCP works by issuing leases on IP addresses. The idea is that, should the client crash or otherwise become inaccessible, the IP address will revert back to the pool of available addresses after a limited time. In this way, a DHCP server can continue delivering addresses from a fixed set of addresses. Clients can also give up their leases voluntarily—say, when they're shut down. Not all clients do this, though. Leases have fixed terms, and when a lease expires, a client must renew that lease. (Typically, clients attempt to renew their leases halfway through their terms. If the initial renewal attempt fails, subsequent attempts are made.)

Considered on the network as a whole, DHCP simplifies configuration. Instead of entering several IP addresses on each client (for the client itself, including its netmask, the router, DNS servers, and perhaps more), DHCP enables you to set a single option to use DHCP on each client. The details of IP address assignment can then be handled by the server, either automatically or by assigning one address to each computer. This centralized control has a certain appeal by itself, but it's also helpful because it reduces the risk of a typo causing problems, and it makes it easier to change your network's configuration. For instance, if you need to change your network's DNS server address for some reason, you can do so by implementing a change in the DHCP server configuration.

Tip

Because DHCP works by providing leases of fixed length, changes to network features such as DNS and router IP addresses won't immediately propagate to all DHCP clients. Most clients should update their settings by half the DHCP lease time, though. You can adjust the lease time from the DHCP server.

Because DHCP can assign IP addresses arbitrarily to any computer that asks for one, it can be particularly handy on networks on which computers are frequently added and removed. For instance, if your office hosts a number of notebook computers that are frequently removed and taken on business trips, these computers might not have permanent IP address assignments. A DHCP server can assign addresses to them as they're used. Furthermore, if a notebook computer is used on two networks, and if both networks use DHCP, the notebook computer can adjust itself automatically to the settings needed by both networks.

Warning

Although enabling DHCP to deliver IP addresses to any new computer it sees, and using notebook computers with any network's DHCP server are both useful procedures, they're also both potentially risky. If a new computer on your network is infected with a worm or virus, it might be able to spread locally, bypassing any firewall controls you have on your router. Likewise, a notebook computer can come under attack from worms or viruses if connected to a foreign network. To reduce risk in a security-conscious environment, you might configure DHCP to deliver IP addresses only to known computers. You can do so by referencing specific hardware addresses, as described in the Section 15.1.4.2.

In the Linux world, the Internet Software Consortium's (ISC; http://www.isc.org) DHCP server is the standard one. Most Linux distributions ship with this server under the package name dhcpd or dhcp-server. ISC also produces a DHCP client, which is frequently installed as dhcpcd. Other DHCP clients, such as pump and dhcp-client, are also available.

Kernel and Routing Requirements for DHCP

Because the DHCP server must communicate with clients that are not yet fully configured for TCP/IP, the server needs support for packet sockets. This is a way for programs to communicate over the network without using an intervening network protocol, such as TCP/IP. It's usually enabled by default, but if you've rebuilt your kernel yourself, you might want to check for it. In 2.6.x kernels, check Networking Support → Networking Options → Packet Socket. If this option isn't enabled, enable it and recompile your kernel. This option is also needed by some DHCP clients.

DHCP servers send their responses to clients using a broadcast address. This can be either a global broadcast (255.255.255.255) or a broadcast that reaches all the computers on a particular subnet (such as 172.24.255.255 to reach all the computers on the 172.24.0.0/16 subnet). Unfortunately, some DHCP clients (such as some versions of Windows) expect DHCP servers to deliver global broadcasts, but some Linux configurations convert global broadcasts into local broadcasts. The usual symptom of this problem is that some Windows clients (particularly Windows 9x/Me systems) can't obtain IP addresses via DHCP, but others (such as Linux clients) can. If this happens, try typing this command on the Linux DHCP server:

# route add -host 255.255.255.255 dev eth0

If the DHCP server is delivering addresses on a device other than eth0, change that part of the command appropriately. After making this change, try restarting an affected Windows system; it should now work. If so, add this line to a local Linux startup script or to the SysV startup script for your DHCP server.

Tip

This route command adds an explicit route for traffic destined to 255.255.255.255; without it, Linux changes the IP address to conform to existing routes. You can check your existing routing table by typing route-n. After adding the route as just described, it should appear as the first entry in the routing table.

DHCP Configuration Files

The DHCP server's configuration file is /etc/dhcpd.conf . Some package distributions include this file in this location, but some packages instead provide a sample file in another location. For instance, SuSE's dhcp-server package stores a sample file in /usr/share/doc/packages/dhcp-server/. The ISC DHCP server also creates a file to track its leases, often called /var/lib/dhcp/dhcpd.leases. You shouldn't need to adjust this file, although examining it can sometimes be a good way to check the server's operation.

Warning

Don't confuse the DHCP server's dhcpd.conf file with dhcpcd.conf, which some DHCP client packages use as a configuration file!

Aside from comments, which are denoted by hash marks (#), dhcpd.conf contains two broad types of statements:

Parameters

These are relatively simple statements that provide information for clients (such as a router's IP address) or that tell the server whether or how to do something (such as how long leases should be). Many parameters begin with the keyword option.

Declarations

These statements describe the network topology, assign IP addresses to clients, or create a grouping of related parameters. Declarations often span multiple lines, in which case the grouped lines are denoted by curly braces ({ }).

Most dhcpd.conf files begin with a set of parameters and then move on to declarations. A simple network may contain just one declaration, which in turn contains multiple parameters. A more complex network might contain multiple declarations.

Assigning Addresses

The bulk of DHCP server configuration is in assigning IP addresses. A full configuration file, though, sets assorted other parameters, and it's best to consider them together. I therefore describe two complete configurations as examples: assigning dynamic IP addresses and assigning fixed IP addresses.

Dynamic address assignment

In a dynamic IP address assignment configuration, the DHCP server hands out IP addresses to any computer that asks for them but doesn't go to any great lengths to track computers and match them with the same IP address every time they boot. Thus, a single computer might receive four different IP addresses over the course of a week, depending on factors such as the lease time, the number of addresses available, the number of computers on the network, and how often the computer reboots or is shut down for an extended period.

Tip

Even when a network uses dynamic IP addresses, a computer's IP address is unlikely to change unless the computer is shut down for an extended period of time, such that its lease expires and another computer grabs the address. Even when a computer reboots, it typically asks for its old address back, and will probably receive that address if the lease hasn't expired yet. When the computer stays up continuously, it renews its lease before the lease expires and so keeps the same IP address continuously.

Example 15-1 shows a typical dhcpd.conf file for assigning dynamic IP addresses. Although this example is simple, something like it should be adequate for many small networks or even simple large networks. Most lines in this file end in semicolons (;), and omitting that character is an easy way to create a nonfunctional configuration file, so be sure to check that detail. Multiline declarations, however, don't use a semicolon on lines that end in either an open or a close curly brace.

This example begins with several lines that set assorted parameters. Most of these have fairly descriptive names, such as default-lease-time or optionsubnet-mask. However, some options require some elaboration:

allow bootp

This option tells DHCP to respond to BootP requests, which are similar to DHCP requests but designed to be used by computers that boot off the network. Such configurations are often used with thin clients, as described in Chapter 12.

default-lease-time

You set the default lease time, in seconds, with this option. The lease time is actually determined by negotiation between the client and the server, so you may end up delivering longer leases than you specify with this file, depending on the client's options.

max-lease-time

This parameter sets the maximum lease time the server delivers. Even if the client requests a longer time, the server won't comply.

Tip

When testing a DHCP configuration, or sometime before making important changes such as altering a router or NTP server IP address, you may want to reduce the default-lease-time and max-lease-time values to something short—possibly as short as a few minutes (say, 300—five minutes). This action reduces the amount of time that clients have invalid information, which can speed up DHCP testing. Using lease times in the range of several minutes to a few hours can be good on networks that see lots of coming and going, such as a network to which users frequently attach laptops for a few minutes at a time. Note that using short lease times will increase network traffic and load on the DHCP server. Setting lease times in the range of many hours or days (such as the 86400, or one day, default lease time in Example 15-1), is a better policy for a stable and working DHCP server on a network that sees few changes to its clients.

option subnet-mask

As you might guess, this option sets the subnet mask (a.k.a. the network mask or netmask).

option domain-name-servers

Point to your network's DNS servers with this option. You can specify multiple servers by separating their values with commas. Most clients accept up to three DNS server addresses, but you can deliver fewer than this number if you like. Example 15-1 specifies DNS servers by IP address, but you can specify hostnames for the DHCP server to resolve when it starts up. (The DHCP server delivers IP addresses to clients in both cases.)

option domain-name

You can tell clients what domain name to use with this option. Not all clients use this information, but for those that do, it can be a handy feature.

option netbios-node-type

This option tells Windows clients how they should attempt to resolve names—whether to use a NBNS system, broadcast resolution, or both. A value of 8 tells the system to use an NBNS system if possible but to fall back on broadcast name resolution. Chapter 5 describes NBNS configuration in more detail.

option netbios-name-servers

This option is the NetBIOS equivalent of optiondomain-name-servers and works in a similar way. Linux clients ignore this information, though; it's useful only for Windows clients.

option ntp-servers

You can point clients at an NTP server with this option; however, many clients ignore this information. Section 15.3, describes NTP in more detail.

option x-display-manager

This option can point certain X terminal thin clients at an XDMCP server, as described in Chapter 12. Some thin clients ignore this information, however.

option tftp-server-name

A TFTP server delivers files to computers, such as some thin clients, that boot off of the network. This option points such clients to the TFTP server.

option routers

Although Example 15-1 shows this option within a declaration block, it can appear outside such a block. It points the clients at the network's router (a.k.a. the gateway).

DHCP supports many additional parameters, but most of them are quite obscure. Consult the dhcpd.conf manpage or a book on DHCP for more information.

The core of the DHCP configuration, and the part that sets the dynamic addresses it can deliver, is the subnet declaration in Example 15-1. This declaration begins with a specification of the numeric subnet it serves—192.168.1.0 netmask 255.255.255.0. The curly braces then set off several lines that define features unique to this declaration. In Example 15-1, the declaration contains just two parameter lines, but you can add more. These lines override parameters set outside the declaration body or set new options. The key to defining a dynamic DHCP definition is the range parameter:

range 192.168.1.50 192.168.1.254;

This line tells dhcpd what IP addresses it may deliver. In this case, the range includes 205 addresses, from 192.168.1.50 through 192.168.1.254. The server won't deliver addresses outside of this range, even within the 192.168.1.0/255 subnet. Thus, you can assign IP addresses for some systems without using DHCP. For instance, the DHCP server itself typically has a static IP address. You might also want to give a router or other important server a static IP address outside the DHCP server's control.

Once you make changes to the DHCP server's configuration, you must restart the server. Typically, you do this using the server's SysV startup script, as in /etc/init.d/dhcpdrestart. If the server isn't already running, you can start it the same way. Consult distribution-specific documentation if you need help with SysV startup scripts.

Fixed address assignment

The leap from dynamic IP address assignment to fixed address assignment is a matter of adding new declarations, one for each computer to which you want to assign a fixed address. These host declarations appear within the declaration for the dynamic subnet:

Each host declaration begins with a hostname (gingko in this case). This hostname may be passed to the client if you set the use-host-decl-names true parameter, but most clients ignore the name. The declaration then contains two lines. The first sets the client's media type (ethernet in this case, although token-ring is appropriate for Token Ring networks) and media access control (MAC) address, a.k.a. the hardware address. The DHCP server then knows to assign the specified fixed-address as the IP address whenever the computer with the specified MAC address requests an address.

Warning

The IP address you specify with fixed-address must be outside the range specified with range but within the range determined by the subnet IP address and netmask declaration.

Of course, on a large network, managing all the computers' MAC and IP addresses can be tedious. For this reason, assigning fixed IP addresses in this way is best reserved for small networks or for a limited number of computers (say, important servers) on large networks. This type of configuration is also often used when configuring thin clients, which may need to be told on a client-by-client basis what files to use as a boot OS. This topic is described in Chapter 12.

One critical detail about this configuration is locating the target computer's MAC address. Several approaches to doing so exist:

Examining board markings

Some network card manufacturers mark the MAC address on their boards, usually by affixing a sticker. This can be a good way to get a MAC address if you're installing a card, but it can be inconvenient if the computer's already assembled and has the network card in it. Also, not all manufacturers label their cards this way.

Client configuration tools

Most clients enable you to view the MAC address in one way or another. On Linux and most other Unix-like clients, you can find the address using ifconfig, as in ifconfigeth0. The MAC address is called the HWaddr in the output. Typing IPCONFIG/ALL at a DOS prompt on Windows NT/200x/XP systems also displays this information, on a line labelled Physical Address. Windows 9x/Me systems provide a GUI tool, WINIPCFG, which delivers this information.

Using arp

You can give the client an IP address, either by configuring it statically or by using DHCP without a static IP address defined for the system. You can then use the Linux arp command to find the MAC address. For instance, arp 192.168.1.78 finds the MAC address (and some other information) for 192.168.1.78. You may need to direct some other traffic at the computer first, though; using ping should do the job.

Examining DHCP logs

If you have the client obtain an IP address from the DHCP server's pool of dynamic addresses, you can then examine the /var/lib/dhcp/dhcpd.leases file to locate the MAC address. This appears in a block named after the IP address given to the client. Similarly, the /var/log/messages or other system logfile on the DHCP server usually records the MAC address of clients and the assigned IP address. These techniques are both simplest to use on a network with little DHCP activity, such as a small network. Locating the correct entry on a larger network can be trickier.

In all these cases, the exact form of the MAC address can vary. For inclusion in the dhcpd.conf file's host declaration, the address appears as a series of hexadecimal (base 16) numbers separated by colons (:). Some utilities may show the address in another form, such as separated by dashes. If necessary, make the change. For hexadecimal values between A and F, the DHCP server doesn't care about case. For instance, 5a is exactly equivalent to 5A.

Telling Clients to Use DHCP

Like any server, the ISC DHCP server is useful only if it has clients. These clients can be Windows, Linux, Mac OS, or just about any other system. The DHCP client sets its own basic TCP/IP features by consulting the DHCP server, so the DHCP client program must run before most other network-related programs on the client.

Tip

A DHCP client can be a server for other protocols. For instance, you might use DHCP to assign an IP address to an SMB/CIFS file or printer server. Some servers work best with fixed IP addresses simply because this makes it easier to enter a name-to-IP-address mapping in your DNS server. For them, you can assign a fixed IP address to the server via DHCP, as just described.

To tell a computer to use a DHCP server, you must typically run the computer's basic network configuration tools. For instance, you can do this job on a Windows XP system that's already configured with a static IP address:

Open the Windows Control Panel.

Double-click the Network Connections icon in the Control Panel. This action opens a Network Connections window.

In the Network Connections window, right-click the Local Area Connection icon and select Properties from the resulting context menu. This action opens a Local Area Connection Properties dialog box.

In the Local Area Connection Properties dialog box, select the Internet Protocol (TCP/IP) item and click Properties. This action yields a dialog box called Internet Protocol (TCP/IP) Properties, as shown in Figure 15-1.

Figure 15-1. The TCP/IP Properties dialog box lets you set basic network features

In the Internet Protocol (TCP/IP) Properties dialog box, click "Obtain an IP address automatically". If any are set, the values in the "Use the following IP address" fields should disappear.

If your DHCP server delivers DNS server addresses, click "Obtain DNS server address automatically". Any addresses you've set manually should disappear. (You can continue to set DNS server addresses manually, though, which can be handy if you want to use a nonstandard DNS server for some reason.)

Click OK. This should activate your changes. You then need to close the remaining open dialog boxes and network option windows.

In many cases, you'll configure the DHCP client when you first set up its networking features. For instance, you might double-click the Network Setup Wizard in Windows XP. This setup procedure will guide you through various network settings, but in all cases, you should be presented with a choice to use DHCP or to set the IP address manually, as in Figure 15-1. (Windows often doesn't use the term DHCP, though, instead referring to this option as "obtain IP address automatically," as in Figure 15-1, or something similar.)

Precise details vary from one operating system to another, as well. Most versions of Windows, Mac OS, and other GUI-oriented OSs provide a procedure similar to that just described for Windows XP, but many details differ. Consult the OS's documentation, or browse the system configuration options for ones relating to network configuration. Linux distributions with GUI system administration tools can usually be configured to use DHCP in much this way, as well. You can also do so using text-mode tools: install a DHCP client (usually in a package called dhcpcd, dhcp-client, or pump), and use chkconfig or other tools to enable this package in your default runlevel. Consult distribution-specific documentation if you need help with this task.

Delivering Names with DNS

A second key network management tool is DNS. DNS servers fill two roles: enabling your local clients to convert names to IP addresses for local and remote computers, and enabling remote systems to find local computers that you choose (such as web or mail servers). One important question is whether you should even run a local DNS server; for many purposes, relying on outside servers makes a lot of sense. Sometimes, though, running a DNS server locally is very helpful. If you decide you want to run your own DNS server, you must be able to configure it. The basic DNS server configuration varies with the server software you select. BIND is the most popular Linux DNS server, and so it's described in this chapter. Once the basic configuration is set, you must create files that describe the computers on your network—their hostnames, IP addresses, and related characteristics. Finally, you must be able to tell clients to use the DNS servers you've configured.

Principles of DNS

DNS is, essentially, a global database of computer names. The huge size of the DNS database presents many challenges, including maintenance of the database and providing storage space for it. Both challenges are overcome by the fact that DNS is a distributed database; no one computer holds all the data in the DNS database. Instead, the DNS namespace is arranged hierarchically. At the top of the hierarchy are the top-level domains (TLDs), which appear at the end of a DNS hostname. Common examples include .com, .edu, and .net. These three TLDs are all examples of generic TLDs (gTLDs), which are (theoretically) not tied to specific nations. Another type of TLD is the country code TLD (ccTLD), which uses a two-digit country code as the TLD, such as .us for the United States or .ru for Russia.

Below the TLDs are the domain names that are so common, such as oreilly.com for O'Reilly Media or upenn.edu for the University of Pennsylvania. These domains can be further subdivided, such as cis.upenn.edu for the Computer and Information Science department at the University of Pennsylvania. At some point, individual computers can be specified, as in www.oreilly.com for the O'Reilly web server.

The beauty of DNS's distributed nature is that it ties into this hierarchy. At each level of the hierarchy, a single DNS server can reasonably hold data on all the domains or subdomains at that level. At the very top of this hierarchy, a set of computers known as the root servers maintain information on the TLDs. Each root server can field queries concerning TLDs; most importantly, the root servers can tell a client where to find DNS servers for the .com, .ru, and other TLDs. The client can then contact a TLD's DNS server for information on a specific domain, such as oreilly.com; the result is the address of the oreilly.com DNS servers. With this information in hand, the client can ask about a specific computer, such as www.oreilly.com.

The distributed DNS system therefore enables lookups in a huge address space relatively quickly. Although multiple queries may be needed, each one finishes rather rapidly. DNS also includes certain time-saving features. For instance, rather than have users' workstations perform the full recursive lookup , in which a name is queried starting with the root servers, a network can host a DNS server that does this job and caches the results. Thus, if two users on a network look up www.oreilly.com in quick succession, the local DNS server needn't perform a full recursive lookup for the second query; it simply retrieves the result of the original lookup from its cache and delivers that result. This characteristic is also a key to understanding the two main roles that a DNS server can play on your network:

The DNS server can perform full recursive lookups for the benefit of your local computers, and also deliver information on local computers to other local computers. Running a DNS server this way doesn't require modifying your domain's registration with the outside world.

The DNS server can hold information on your local network and deliver that information when queried by remote systems. This capability is extremely important for delivering the IP address of your externally accessible servers, such as your mail server. Although this chapter can help get you started running your own DNS server, you must consult your domain registrar to link your server to the global DNS system.

This chapter focuses on the first type of DNS configuration—that which is most useful to local computers. The principles described here also form the foundation for making changes that are accessible to the outside world, though.

Tip

You can assign one DNS server to be used by local computers and another for use by outside systems. In fact, you don't need to run both servers yourself. For instance, you might run your own local DNS server to help your computers perform DNS lookups, but rely on a domain registrar or a domain hosting provider to run DNS servers that hold information on your domain for the outside world.

Running a DNS server for the benefit of your local computers is most useful if your ISP doesn't provide one or if you want to deliver information that's unique to your private network. For instance, you might have a subnet behind a firewall that holds file servers, print servers, and pull mail servers to be used by other computers behind the firewall. Entering information on these systems in a globally accessible DNS server is unnecessary and can even give potential attackers information about your network, so running a DNS server behind the firewall can be a good way to provide local name resolution. This server can also handle full recursive lookups for the benefit of other local computers.

Tip

An alternative to DNS for local name resolution is to configure an NBNS system. Windows clients often use an NBNS system automatically if the DHCP server is configured to deliver the NBNS address, as described earlier in Section 15.1.4.1. You can also configure Linux systems to use NBNS, as described in Chapter 6. NBNS has certain advantages, such as simpler adaptation to dynamic IP addresses, but it's also got limitations, such as a lack of support for DNS domain information.

Basic Name Server Configuration

Running a name server involves two basic configuration tasks: setting up the name server itself (that is, the options it uses to control where it stores additional configuration files, how it should respond, and so on) and setting up the domains it handles. This section describes the first of these tasks, using the BIND software as an example. (If you use another server, such as djbdns, you need to read its documentation.) The second task is described in the next section.

The Berkeley Internet Name Domain (BIND) is distributed by the ISC (http://www.isc.org), which also distributes the most common Linux DHCP server. As with ISC's DHCP server, BIND is available with all major distributions, except for some very desktop-oriented ones; thus, you shouldn't need to download it from the ISC web site unless you have a specific reason to avoid your distribution's BIND package. Typically, the package name is bind.

Although the official name for this server package is BIND, the executable filename is named , and BIND configuration files are named after this—namely, the main configuration file is /etc/named.conf . For a simple configuration, this file contains two broad classes of entries:

Global options appear in a section called options. These include features such as a directory in which domain definitions exist, on what network interfaces the server should listen, and so on.

Each domain or subdomain (that is, a zone) is briefly described in a zone section. This section sets only the broad outlines for a zone; the description of the zone's computers appears in zone configuration files, as described in the next section.

Example 15-2 shows a simple but usable /etc/named.conf file. This file defines the basic settings for a BIND server handling the example.com domain. It includes an options section and four zone sections, which are described in more detail shortly. A DNS server for a network with multiple subnets or domains is likely to have additional zone sections.

The general format of the /etc/named.conf file is similar to that of the ISC DHCP server. Most lines set individual options and end in semicolons (;). Other lines, though, begin or end blocks of options. The line that begins such a block ends in an open curly brace ({), and the line ending such a block ends in a close curly brace and a semicolon (};).

The options section in Example 15-2 sets several important global features of the server:

directory

This may be the most important line in the options section; it sets the name of the directory in which BIND looks for zone definition files—that is, the files that define the mappings of hostnames to IP addresses and related domain features.

listen-on

This optional subsection specifies one or more IP addresses on which BIND listens for queries. This feature can be handy if you run the server on a computer with multiple network interfaces but want to make the server available on only some of them.

forwarders

This subsection is optional. If you use it, you can specify the IP addresses of one or more DNS servers that you want to handle DNS queries other than those for which your own server is the ultimate authority. Typically, you use this feature if your ISP offers DNS servers of its own. You can point BIND to your ISP's servers using this directive and, rather than perform a full recursive lookup itself, your server queries your ISP's servers and lets them perform the full recursive lookup. This can result in faster responses if your ISP's servers are working correctly, because they probably have better Internet connections than your own server. This option has no effect on lookups within your own domains (such as example.com in this example).

forward

The forward option tells BIND when to use the DNS servers specified with the forwarders directive. The forward option takes either of two values: only or first. The forwardonly directive tells BIND to use the servers listed in the forwarders section and its own zone files exclusively; BIND doesn't perform its own recursive lookup. The forwardfirst directive, by contrast, tells BIND to attempt to use the servers specified by forwarders but to perform a full recursive lookup if those servers are unavailable. This option can improve reliability, but it can also slow the return of a failure code.

Many other directives can be placed within the options section, but the ones described here should be enough for many small configurations. Consult the documentation that came with BIND, or a book on the server, such as O'Reilly's DNS and BIND, for more information on these options.

If you want BIND to deliver information on your local network, the zone definitions are just as important as the options section. Each zone definition begins with the zone keyword followed by the name of the zone. Chances are your named.conf file will have three broad classes of zone definitions:

The root zone

The zone "." entry in Example 15-2 defines the root zone, which ultimately points BIND to the root DNS servers. This definition uses a type hint line, which is unique to the root zone definition.

Forward lookup zones

The only forward lookup zone in Example 15-2 is for the example.com domain. This type of entry specifies the domain or subdomain name as the zone name, and enables clients to pass a hostname to get an IP address. On the domain's primary DNS server, this zone will have a type master line in the zone definition. (Slave DNS servers can copy zone files from another DNS server and use a type slave definition; however, slave DNS server configuration is beyond the scope of this book.)

Reverse lookup zones

Frequently, DNS servers include zone definitions for reverse lookups, in which a client enters an IP address and receives back a hostname. Reverse lookups work much like forward lookups, but they require an unusual notation for the zone type. Specifically, reverse lookups use hostnames of the form backwards-IP-address.in-addr.arpa, where backwards-IP-address is an IP address fragment in reverse. For instance, Example 15-2 has two reverse lookup zones, named 1.168.192.in-addr.arpa and 0.0.127.in-addr.arpa. These correspond to the 192.168.1.0/24 and 127.0.0.0/24 network blocks, respectively—note that the order of the four bytes of the IP addresses are reversed. In both cases, the first byte of the reversed address (the final byte of the original) is omitted, which denotes the fact that these zones apply to networks with 255.255.255.0 netmasks. The reverse ordering of these names is confusing at first, but the reason is that the most- and least-significant portions of IP addresses and hostnames are reversed. A reverse lookup converts an IP address to a hostname in the special in-addr.arpa domain. However, to define the individual hosts in this domain, the machine identifier portion (that is, the final byte of the address in a /24 netblock) must be the first part of the name in the in-addr.arpa domain, so the order of the IP address elements must be reversed. Example 15-2 defines two reverse lookup zones, one for the loopback address (127.0.0.0/24) and the other for the local network address (192.168.1.0/24).

Tip

It's possible to omit a reverse lookup zone. In fact, if your DNS server will be serving names for IP addresses on the Internet as a whole and you don't control the entire netblock, you should omit the reverse lookup zone. You're responsible for handling forward lookups on your domain, but whoever controls the netblock (usually an ISP for small networks) is responsible for the reverse lookup. If you're configuring a DNS server for a small private network, though, you might want to include both forward and reverse lookups.

Once you've configured the basics in /etc/named.conf, you might be tempted to restart the named server. You can do so in the usual way, such as by using a SysV startup script, however, you should probably wait until you've created appropriate domain configuration files, as described next.

Setting Up a Domain

Configuring the basics of the server's options is just the start of the process. In day-to-day operation, you're more likely to need to modify your zone definitions, which are stored in files in the directory specified with the directory keyword in the options section of the /etc/named.conf file. Each zone has its own configuration file, which defines features of the zone as a whole and creates mappings of hostnames to IP addresses for each member of the zone.

Each type of zone definition in named.conf has its own variant style of zone definition file. The most fundamental of these is the root zone definition. Chances are your BIND configuration includes a default configuration that will work. Typically, the filename is named.ca or db.cache. If this file isn't present, or if it's very old, you should try to obtain a more up-to-date version. You can find the latest copy from ftp://ftp.rs.internic.net/domain/db.cache. Copy this file to the directory specified in your named.conf file, and name it as specified by the file option in that file's root zone definition (zone "."). Additional zone files are the forward and reverse zone files.

Configuring forward zone files

The second type of zone definition is for forward lookups—those that use an ordinary domain name in the zone line of named.conf. Use whatever filename you specify in named.conf for the file. Typically, this name is related to your domain's name, such as named.example.com for the example.com domain. Example 15-3 shows a sample forward lookup zone configuration file.

The zone file begins with two lines that set some global parameters. The $ORIGIN. line should be present in your zone files unchanged. The $TTL 604800 line sets a default time-to-live(TTL) value, which tells other servers how long, in seconds, they may cache entries obtained from your server. You may increase or decrease this value as you see fit.

The lines beginning with example.com and ending with a single close parenthesis ")" define the start of authority(SOA) record for this zone. This entry sets several important overall features for the zone:

Zone name

The zone name (example.com in this example) begins the SOA line. You should change it to match your own domain or subdomain name.

Entry class

The IN code defines the class of the entry. IN stands for Internet, and it's the most common SOA entry class and the only one described in this chapter.

Record type

The SOA code identifies this entry as creating an SOA record.

Master name server

The maize.example.com. entry in the SOA record identifies the zone's primary name server. Note that this hostname ends in a dot (.). Technically, all DNS hostnames end in a dot. Most user programs enable you to omit this dot, but you must include it when specifying a full hostname in the DNS configuration files.

Administrative email account

The linnaeus.example.com. entry, although it doesn't look like one, represents an email address for the person responsible for administering the domain. Replace the first dot with an at sign (@; to create linnaeus@example.com.) to generate an email address. As with other addresses, this one must end in a dot.

Timing information

The remaining information, beginning with the open parenthesis on the main SOA line and ending with the close parenthesis line, represents timing information for the data retrieved from this zone. This information is used mainly by other DNS servers. Values are a serial number (often set to the date followed by a code for the change number on the day), the interval for slaves to use between checks for updated information, the interval at which slaves should attempt transfers if the first one failed, the time after which a slave should expire and discard an entire zone if it's not been updated, and a minimum TTL value for remote DNS servers to cache information. The values shown in Example 15-3 are reasonable starting points. Note that most of these values are important only if you run multiple DNS servers, with one configured as a master and the rest as slaves.

Following the SOA record is a line that explicitly sets the $ORIGIN to your domain, including its trailing dot—example.com. in this case. Subsequent lines are similar in form to the SOA line, but they're simpler; most take the following form:

hostname IN code address

The hostname is the hostname in question, without a domain component. Some entries enable you to specify an at sign (@) as the hostname. This symbol stands in for the domain name and is used by certain code types, as described shortly. The IN component is invariant in these entries, at least as far as described in this chapter. The code is a code that stands for the entry type and is described in more detail shortly. Finally, the address is the address to associate with the hostname. In many cases, this is an IP address; but for some code types, it can be a hostname—either a hostname without a domain, which is interpreted as a hostname in the current domain or a hostname with domain component and trailing dot. The MXcode is unique in that it includes a number before the address, as described shortly.

In defining a domain, you're likely to include several different types of code:

A

An A record defines an individual host in the domain. Use this to associate an IP address with a hostname.

CNAME

A CNAME record sets up an alias—a linkage of one name with another. CNAME records are often used when a single computer goes by multiple names, such as a single system that functions as both a web server and an FTP server, and that you want to be accessible by the names www and ftp for this reason. Alternatively, you can create multiple A records, but doing so requires you to change all the A records if you ever change the server's IP address; using CNAMEs for most records makes subsequent changes easier and less prone to error.

NS

A name serverrecord identifies a DNS server for the domain. Normally, one NS record points to the computer you're configuring. Others may point to other DNS servers, such as slaves of a master server. The hostname on this line is either the domain name alone or an @ sign, and the address is the name of an A record—with or without the domain component.

MX

A mail exchanger record points to a domain's mail server. This record requires a priority number for each server listed; sending mail servers attempt to contact your mail servers in sequence, starting with the one with the lowest number and moving up from there. As with NS records, the hostname is either the domain name alone or an @ sign, and the address is the name of an A record.

PTR

Example 15-3 shows no pointer (PTR) records because they're unique to reverse lookup zone files. They use a pseudo-hostname based on an IP address as a hostname, and they list a regular hostname as the address. PTRs are described in more detail shortly.

Configuring reverse zone files

In some cases, you need to configure only forward lookups. For instance, your ISP might own your network block and so handle the reverse lookups, or you might simply not care about reverse lookups. (Some programs, though, perform reverse lookups and compare them to the forward lookups. If the two don't match, the programs terminate the connection or otherwise cause headaches. Thus, working reverse lookups can be more than just a convenience.) If you're in control of your network block, including if you're running in a private reserved address space, you can configure a reverse lookup zone. To do so, you must first specify a reverse lookup zone in the /etc/named.conf file, as described earlier, in Section 15.2.2. You can then create a reverse lookup file in your zone file directory. This file is likely to be named after the zone, e.g., named.192.168.1. Example 15-4 shows an example of such a file.

The reverse lookup file is very similar to the forward lookup file. Like the forward lookup file, it includes a $TTL directive. (Example 15-4 shows an alternative way of specifying the time, though, by including a one-letter abbreviation for the time unit—1W meaning one week.) This file also contains an SOA record, which takes the same form as the equivalent record in the forward zone definition file; the main difference is in the name of the domain. (You can use different specifics, such as refresh times or network administrator email address if you like, though.)

The bulk of the post-SOA entries in a reverse lookup file are PTR records, which tie an IP address (in the form of its reversed in-addr.arpa pseudo-hostname) to conventional hostnames. As with forward lookup files, you can abbreviate hostnames by omitting the domain portion of the name. In the case of reverse lookup files, though, the domain portion of the name is the reversed network portion of the address and in-addr.arpa. Thus, the reverse lookup for the 192.168.1.1 address in Example 15-4 is 1, referring to the final byte of the IP address. Example 15-4 doesn't use this convention for the remaining addresses. The looked-up names (maize.example.com., gingko.example.com., and so on in Example 15-4) may not be abbreviated by omitting their domain portions. You must also include the trailing dot after each of these names.

In addition to SOA and PTR records, reverse lookup zone files typically include one or more NS records, which point to the DNS servers that handle the network block. These might or might not be the same servers that handle forward lookups for the computers in that network block. Other record types, such as A, CNAME, and MX, are uncommon in reverse lookup files.

Running the server

Once you've set up your domain, you can start the server. Typically, this is done via a SysV startup script; typing /etc/init.d/namedstart or something similar usually does the job. To run the server permanently, you can use chkconfig or a similar tool to add the server to your default runlevel, or do the job manually by creating appropriate symbolic links yourself. Consult distribution-specific documentation if you need help with this job. Once the server has started, you may want to check the last few lines of your log files to see if the server has reported any problems. Typing tail/var/log/messages can do this.

Warning

If you restart the server, you may get an error message in your logs about the journalforwardfailed, and you might not be able to resolve names in a domain. This often happens if you change your BIND configuration while the server is running; it doesn't like that. The solution is to shut down named, delete the file whose name starts with the name of the zone configuration file but ends in .jnl in the directory that holds your zone configuration files, and restart named. A better practice is to make changes to your zone files only when named isn't running.

You can test your server's operation using the host command on the server or any other computer that has this tool. Type hostnameserver to look up name using the specified server. If the computer pauses for several seconds and responds connectiontimedout, chances are the server has crashed on startup or you've specified the wrong server. (You may need to specify server as an IP address if the computer isn't configured to use that system for name resolution by default.) Other error messages typically denote problems with your DNS configuration; check your logfiles for clues. Be sure to test both forward and reverse DNS lookups.

Pointing Clients at the Name Server

Client configuration is, of course, critically important to DNS operation. If you want local workstations and servers to use your DNS server for name resolution, you must tell them to do so. If you use DHCP to assign IP addresses to these computers, the simplest way to configure them to use your DNS server is to adjust your DHCP configuration using the optiondomain-name-servers line in your DHCP configuration file, as described earlier, in the section Section 15.1.4.1. Once configured in this way, a DHCP server can deliver DNS server information to Windows, Linux, Mac OS, and other clients that use DHCP.

If you want to configure some or all of your computers using static IP addresses without using DHCP, you must configure these computers to use your DNS servers manually. Precisely how you do so varies from one OS to another, but most provide GUI tools that enable you to enter the DNS server addresses manually. Earlier, the Section 15.1.5 described how to configure Windows XP to use DHCP. Part of this process provided an opportunity to tell Windows to use the DNS servers provided by the DHCP server or to use servers you specify. In particular, Figure 15-1 shows the relevant dialog box. Click "Use the following DNS server addresses," and enter up to two DNS server addresses to have Windows use them instead of those provided via DHCP or if you don't use DHCP at all. Similar tools exist in other versions of Windows and in other OSs.

Although you can enter DNS server addresses using GUI tools in most Linux distributions, Linux supports another method: the /etc/resolv.conf file specifies DNS servers and the domains that Linux should attempt to search. This file is likely to be quite short:

This line tells the computer the domain to which it belongs. The main practical upshot is that names are searched for in this domain before they're searched in other domains or without the domain name.

search

This line enables you to tell the system to search domains instead of the one specified by domain. You can list up to six domains, separated by commas or spaces.

nameserver

You list DNS servers, one per line, using nameserver keywords. Linux supports up to three DNS servers; it tries each one in sequence until a lookup returns a definitive success code (a certain success or failure, as opposed to a failure of the server).

Whether the DNS client runs Linux, Windows, or some other OS, a DNS lookup normally uses a domain search list, even if the user specified a hostname with a domain. For instance, if you do a lookup on mandragora.example.com from within the example.com domain, the computer first tries a lookup on mandragora.example.com.example.com. If additional domains are in the search paths, similar lookups are performed on them, as in mandragora.example.com.pangaea.edu. When these lookups fail, the name resolver tries the lookup without appending any item from the search path. The assumption is that the user has entered a relative hostname without a domain component. You can block this initial, and probably erroneous, lookup by appending a dot, e.g., typing mandragora.example.com. rather than mandragora.example.com when entering the hostname. This trick works with most programs and protocols, but it might confuse some. In most cases, it's unnecessary; the extra lookup that fails is unlikely to take very long at all, so it does no real harm.

Keeping Clocks Synchronized with NTP

One of the frustrations of using a computer network is that the individual computer clocks can report different times. This fact can be a minor annoyance when, say, you seem to have jumped back in time by two minutes when switching computers. It can become more serious when programs that rely on time stamps see inconsistent times on files. A make utility, for instance, might fail to compile a file if it believes that file changed before the last compilation, when in fact it changed after the last compilation but the time stamps are off. Even more serious temporal problems result with tools such as Kerberos, which embed timestamps in some of their packets as a security measure. Depending on your Kerberos settings, logins can fail completely if two computers' clocks are inconsistent.

These problems can all be overcome using a protocol designed to keep computers' clocks synchronized. The most popular protocol to do this job is known as the Network Time Protocol, which is headquartered at http://www.ntp.org. Before proceeding with the details of NTP configuration, you should understand its basic operating principles; this will help you decide how to implement NTP. As with most protocols, you must then configure both servers and clients. The Linux NTP server, though, does double duty as both a server and a client. On the Windows side, you can use either a full NTP implementation or a built-in Windows command.

Principles of NTP

NTP can do more than simply keep your clocks synchronized on your local network: it's designed to help you keep all your computers' clocks set to an accurate time source. It does so by creating a hierarchy of NTP servers, most of which also function as clients to NTP servers that are closer to the ultimate time source—usually an atomic clock or a device that reads its time from one, such as a radio that receives signals from an atomic clock. This arrangement is illustrated in Figure 15-2.

The atomic clock or other time source is referred to as a stratum 0 time source. The servers that communicate with this device are known as stratum 1 servers; those that communicate with the stratum 1 servers are stratum 2 servers, and so on. This arrangement provides a powerful exponential effect on the number of computers a single time source can serve. For instance, if each server has just 100 clients, a single stratum 1 server can have 10,000 stratum 3 and 1,000,000 stratum 4 clients. As the stratum level increases, the accuracy of the clocks decreases, but not by much; times are typically accurate to well under a second up to several stratums. (The exact values depend on factors such as the variability of transit times and how evenly divided the transit times are on each leg of the journey.)

At each step of the way, NTP works by measuring the time it takes for packets to traverse the network. For instance, if you send a packet to a computer, and it replies, you can measure the round-trip transit time. (You can use ping to do this in a crude way.) If the return packet includes a time stamp, you can use the time stamp and round-trip transit time to set your own clock to that of the remote server; you use the time stamp in the packet and half the transit time. NTP uses this principle at its core, although it's more sophisticated. For instance, a full NTP implementation runs as a daemon and checks its upstream time source on a periodic basis. It can use the data gleaned from these checks to adjust the rate at which its own clock "ticks," thus maintaining a more accurate time even between time checks. NTP can also refer to multiple upstream time sources, thus providing redundancy and enabling it to select the best time source.

In practice, you'll set up one computer as a master NTP server for your network. (You might set up more than one if your network is very large or is geographically diverse.) Your master NTP server refers to an upstream server to set its own clock; the rest of your computers set their clocks based on their own master NTP server. This configuration minimizes network traffic; you can set potentially thousands of computers' clocks using the external bandwidth required to set just one system's clock.

What computer should you use as your master NTP server? In practice, requirements are fairly minor. Compared to most other network protocols, NTP generates little network traffic and requires practically no disk space, aside from that needed for the OS itself. Therefore, it's common to piggyback NTP duties onto another server. On the other hand, you don't want to add master NTP duties to a server that's already overloaded, because delays in handling the NTP packets will be quite detrimental to the NTP server functions. In any event, the server should have ready network access to the Internet and to all the computers on your local network. Of course, like all servers, NTP is a potential security risk, although it's a minor one compared to servers that provide login or file access.

NTP Server Configuration

In Linux, an NTP server acts as both a client and a server. In fact, to maintain the most accurate time in Linux, you may want to install a full NTP server, even if it has no clients of its own; your NTP server will act only as a client.

All major Linux distributions ship with NTP servers, typically in packages called ntp, xntp, or a variant with a major version number appended, such as ntp4. The major NTP configuration file is /etc/ntp.conf. Most distributions ship ntp.conf files that should require few changes; you may only need to set an appropriate server. A few other options may need attention as well, though:

server

This line sets the hostname or IP address of an NTP server, as in server tick.pangaea.edu to tell NTP to refer to the NTP server on tick.pangaea.edu. You can also add various options to support authentication and other features, but, in most cases, these aren't needed. Picking a server is described in more detail shortly. One special case that deserves attention is setting server127.127.1.0. This line tells NTP to use the local system clock. It may be included as a fallback position in case all other servers become unavailable.

fudge

Ordinarily, NTP automatically detects the stratum of the servers to which it communicates; it can then set its own stratum automatically. The fudge line enables you to force NTP to treat a server as belonging to another stratum. It's most often used in conjunction with the 127.127.1.0 address to force NTP to give the local NTP server a very high stratum number so that it's not used in preference to more accurate sources. For instance, fudge 127.127.1.0 stratum10 tells NTP to treat the local clock as a stratum 10 server.

driftfile

You can specify a file in which NTP stores information on the hardware clock's drift. This information can help when you first start the server after it's been down for a while or in case your network access goes out. Using the drift file, NTP should be able to maintain your clock's accuracy much better than is possible using the computer's unmodified clock. You shouldn't need to adjust this entry unless you rearrange your directory structure in some unusual way.

broadcast

If your network hosts many systems that also run the full version of NTP, you can minimize local NTP-related network traffic by telling your main NTP server to periodically broadcast its time information, which then reaches all the clients, obviating the need for them to contact the server individually. To use this feature, specify the broadcast keyword followed by the computer's own IP address; it then broadcasts to the local network.

broadcastclient

The flip side of the broadcast feature is the configuration of the NTP broadcast clients. On these systems, you set broadcastclientyes to have NTP listen for broadcasts from other NTP servers, or broadcastclientno to have the server ignore such broadcasts.

One of the trickiest aspects of NTP configuration is in selecting an upstream NTP server. NTP server lists are maintained at http://www.eecis.udel.edu/~mills/ntp/servers.html; this list has links to both stratum 1 and stratum 2 servers, and it describes rules of etiquette for using the servers. You may be able to find other sources, as well. For instance, your ISP might operate an NTP server that you can use, or if you're setting up NTP for a single department in a much larger organization, your organization might run an NTP server. In most cases, you should contact the server's operator before connecting your own server, although some server operators provide blanket permission for certain people to use their NTP servers. (Lists of NTP servers often contain information on what types of permission should be obtained before using any given server.) You should try to pick a server that's close to you in network topology. For rough estimates of this measure, use ping to determine the round-trip transit time to potential servers, and use traceroute to measure the number of intervening systems. The lower the transit time and the fewer the intervening systems the better.

The higher you go in the NTP stratum hierarchy, the more accurate the times; however, NTP servers with low stratum numbers are few in number and shouldn't be used except by clients that themselves serve many clients. As a general rule of thumb, you shouldn't use a stratum 1 server unless your own server is itself delivering time to at least 100 clients. For smaller networks, use a stratum 2 or lower server; the accuracy of your time won't suffer much, and the variability within your network won't suffer at all, but you'll be helping to distribute the load on the NTP network as a whole.

You can specify multiple upstream NTP servers, but you can get by with just one. Using multiple servers provides redundancy and enables the NTP software to pick the best server from the lot automatically. On the other hand, using few servers reduces network load. Generally speaking, small networks can get by just fine with just one server, although you might want to try several at first to determine which works best. Large networks, or networks on which precision timekeeping is particularly important, may do well to use multiple upstream servers—typically, at least three to make it easier to pick the bad time keeper, if there is one.

Once you've entered one or more server lines in ntp.conf and made any other changes you like, you should start NTP. On most distributions, this can be done using a SysV startup script, e.g., by typing /etc/init.d/ntpdstart. (The exact name of the SysV startup script varies; some omit the d from the end of the script name or add x to the start.) To run NTP regularly, use tools such as chkconfig to add the NTP startup script to your default runlevel. Consult distribution-specific documentation for help on this topic.

Once the NTP server is running, you can use the ntpq tool to monitor its operation. Type ntpq to run the program, and it replies with a ntpq> prompt. Type peers to obtain a list of upstream NTP servers and assorted statistics on them. In particular, note the value of the st column, which shows the upstream server's stratum. Initially, NTP polls the upstream servers frequently to determine which one is the most accurate. After a few minutes, it settles on one as its primary source and marks it with an asterisk (*) to the left of the server's hostname. Other servers that generate reasonable results receive a plus (+) mark in this position. Be wary of a server that's marked with an x to the left of its name; this is a false ticker, which is providing times that are inaccurate compared to the other servers.

To configure Linux NTP clients (which may run other servers, such as Samba), configure them just as you do your primary NTP server, but instead of pointing them at one or more external NTP servers, point them to your primary NTP server alone. Because these servers are all on the same network, the time for NTP packets to make their round trip will be tiny, and the NTP clients you configure will have times that are virtually identical to the time on your primary NTP server.

Configuring Windows Clients

In principle, Windows computers are no different from Linux computers when it comes to NTP. In practice, though, it may be easier to use a standard Windows command, NET, to set their clocks than to install a full NTP package. You can take the full approach if you prefer, though. This is most likely to be helpful on important servers or if you want the Windows system to function as an NTP server to other clients.

Using NET SET

The Windows NET command lets you set the Windows computer's clock. In Windows NT/200x/XP, you can use this command to set the clock using NTP with the /SETSNTP:server option, where server is the NTP server's name. For instance, to set the Windows system's clock to the time maintained by the harrison.example.com server, use this command:

C:\> NET TIME /SETSNTP:harrison.example.com

This command actually uses a simplified variant of the full NTP protocol, known as SNTP. This procedure should be good enough for most purposes. If the computer restarts on a regular basis, you can include a command like this in a batch file that runs when the computer starts. Placing it in the Windows StartUp folder can be a good choice, particularly on desktop computers; this ensures that the script is run on a regular basis. Another option is to place this call in a domain's network logon script.

Unfortunately, Windows 9x/Me doesn't accept the /SETSNTP option, so you can't set a Windows 9x/Me computer's clock using an NTP server in this way. You can, though, use a similar command to set the clock using part of the SMB/CIFS protocol suite:

C:\> NET TIME \\HARRISON /SET /YES

This command sets the computer's time to that maintained on HARRISON. If your main NTP server also runs Samba, this can be a good way to deliver the time to Windows 9x/Me clients. If your primary NTP server doesn't run Samba, but you do run Samba on another computer, you can use this procedure to set the clock from the Samba server, which can use NTP to synchronize its clock to your main NTP server's clock. As with the /SETSNTP variant, you can include this command in a batch file you run from a StartUp folder or network logon script. Windows NT/200x/XP responds to this command as well, so if you want to simplify your configuration task, you can use this SMB/CIFS variant on all your Windows computers.

Windows NTP clients

Sometimes, only the "real thing" will do. Perhaps you want a Windows computer to function as an NTP server, or you want it to maintain highly accurate time without having to run NET TIME on a periodic basis. In such cases, running a full NTP package on Windows is an option. Even if you don't need a full NTP client/server package, you might want to track down an NTP client for Windows 9x/Me—say, if you don't use SMB/CIFS at all on your network but do want to set Windows 9x/Me systems' clocks.

The official NTP software package is available only for Unix and Unix-like systems. However, the NTP protocol has been implemented on many other OSs, either by porting the official package or by writing a new implementation. Microsoft's NET TIME /SETSNTP command is one implementation. Here are some others:

Automachron

This is an SNTP client only, but it runs on all versions of Windows, making it a good choice for Windows 9x/Me clients. This program is free in the sense of no-cost, but it's not open source. Check its home page at http://www.oneguycoding.com/automachron/ for more details.

NetTime

This program, headquartered at http://sourceforge.net/projects/nettime/, is an open source SNTP client and server for all versions of Windows. This program can run as a service on Windows NT/200x/XP, meaning that it runs at all times, much like the NTP daemon in Linux. Development has officially been abandoned because of Microsoft's inclusion of SNTP support in recent versions of Windows, but NetTime can still be useful if you're running old versions of Windows.

NTP for Windows

The Unix NTP code has been ported to Windows NT/200x/XP and is available, in both source and binary forms, from http://www.eecis.udel.edu/~ntp/ntp_spool/html/hints/winnt.html. If nothing but a full NTP implementation for Windows will do, this package is well worth investigating. However, it doesn't run on Windows 9x/Me.

Summary

Linux can fill many unglamorous server roles on a network—roles that go largely unnoticed by users but that are vital to a network's normal functioning. A Linux DHCP server can help you automatically configure basic networking features of other computers; a Linux DNS server can convert between hostnames and IP addresses; and a Linux NTP server can help you keep your computers' clocks synchronized. Employing Linux in these roles can simplify your overall network administrative workload or improve your network's functionality.