7.2.3. What About...
7.2.3.1. ...older clients that use the bootp protocol?
The DHCP server, dhcpd , can also manage clients that use the Bootstrap Protocol (BOOTP). However, BOOTP does not use leases, so once an IP address is assigned, it stays assigned even if the computer using that address is removed from the network . IP assignments from an address pool are therefore called automatic assignments instead of dynamic assignments.
To enable dhcpd to assign BOOTP addresses, add the dynamic-bootp option to the range statement in /etc/dhcpd.conf :
range dynamic-bootp 192.168.1.128 192.168.1.191
7.2.4. Where Can I Learn More?
The manpages for dhcpd , dhcpd.conf , dhclient , and dhclient.conf
The standard that defines DHCP: RFC 2131, http://www.ietf.org/rfc/rfc2131.txt
7.3. Configuring a Domain Name Server
Domain name service (DNS) is like a telephone-directory service for TCP/IP networks. When a program such as a browser or mail server needs to contact a machine for which it has a hostname, it uses DNS to convert that name to a numeric network address. DNS can also do the reverse: convert a numeric address to a hostname.
It is necessary to have DNS set up before you can serve data to the Internet. Although you can contract for DNS service from an external provider, Fedora Core provides a nameserver that you can easily set up to provide your own DNS capability.
7.3.1. How Do I Do That?
Fedora provides the named domain name server, which is the Berkeley Internet Name Domain (BIND). named serves two roles:
authoritative nameserver
Serves name information about one or more domains to other servers.
caching nameserver
Provides name lookups for client programs such as web browsers by contacting other nameservers. This information is cached in local storage in case it is requested again in the near future.
The Fedora package called bind contains the named service.
The named service is not run by default. Once you configure it to run (see Lab 4.6, "Managing and Configuring Services "), it will act as a caching nameserver:
If you just want to use named as a caching nameserver, you can skip to the section entitled "Using your nameservers locally."
To configure named as an authoritative nameserver for your domain, you just have to give it the information about your domain that you want it to serve to other systems. Usually at least two authoritative nameservers are set up for each domain; one is configured as the master , and the others are slaves . Changes to the DNS data are made on the master, and the slaves update themselves periodically.
You can configure an authoritative nameserver graphically or by editing configuration files and datafiles.
7.3.1.1. Configuring named graphically
Select the menu option System→Administration→Server Settings→Domain Name Server. After you enter the root password, the window shown in Figure 7-6 will appear.
Figure 7-6. BIND configuration GUI
The user interface of this tool is unique! It does not behave in the same way as other graphical configuration tools, so take your time when using it.
To add a zone which can be a complete domain or a subdomainclick on the DNS Server entry to highlight it, click the New button, and then select "zone" from the menu that appears. Figure 7-7 shows the small dialog box that appears.
Figure 7-7. New Zone dialog box
Click OK under Class, and then click OK under Origin Type. The dialog's controls will change to let you type in the Forward Zone Origin, as shown in Figure 7-8 . Enter the name of the domain with a period at the endfor example, fedorabook.com .
Figure 7-8. Zone Origin entry
Click OK to create the zone. The window in Figure 7-9 will appear. Don't be alarmed by the number of controls!
Figure 7-9. Zone Authority configuration window
This window sets several overall values for the zone. Many of these are time values:
Cache Time to Live (TTL)
The maximum length of time that information should be cached by a client or remote nameserver. A higher value will result in a lower volume of DNS requests for your server to process and fewer delays for your users, but when you change a DNS entry, it will take longer to be "noticed" by other systems. A minimum value of three days is recommended once your configuration is stable ( RFC 1912); the default value of one hour is appropriate during initial setup and during periods of frequent changes.
Refresh Interval, Refresh Retry Interval, and Expiration Interval
These values configure communication between a master and a slave system. The Refresh Interval specifies how often the slave should get an update from the master, the Refresh Retry Interval specifies how long the slave should wait before retrying a refresh if it is unsuccessful, and the Expiration Interval specifies how long a slave can go without an update before it should stop responding to requests.
Default Minimum Cache TTL
The name of this field is somewhat misleading because the usage has changed. It is now used to indicate how long a negative response should be cached by a remote machine; in other words, this is the minimum length of time that a remote machine should wait before asking again if a domain exists. In this graphical configuration tool, this value also sets the default TTL for the rest of the records within this zone.
Leave these values at their defaults to start. If you are setting up DNS for a heavily used domain, you should go back and change the Cache Time to Live to the three-day recommended minimum (or longer) once you've confirmed that your configuration works correctly; you'll also need to change the TTL on each resource record in this zone (which I will come to in a minute).
Beside the time fields, there are only four pieces of information to fill in:
Authoritative Name Server
The hostname of the nameserver computer. If the host is in this zone, you can enter the hostname without the domain name portion (e.g., just bluesky for bluesky.fedorabook.com ); otherwise, enter the fully qualified domain name followed by a period (the hostname and domain name together, such as ns.global.proximity.on.ca. ).