Droms R. The DHCP handbook

Подождите немного. Документ загружается.

In this example, the configuration file includes the

not authoritative

statement,

which sets the default to be that the server does not send

DHCPNAK messages. The ISP

subnet declaration identifies the ISP subnet to ensure that the server does not send

DHCPNAK message

s to DHCP messages received from the ISP’s subnet. The subnet decla-

ration for the local office network then states that the server is authoritative for the

local office network, meaning that it sends

DHCPNAK message

s in response to DHCP

messages received from the local office subnet. In addition, the subnet declaration

for the local office network also needs some configuration parameters and some IP

addresses to assign.

Running the DHCP Client and Server on the Same Interface

If you are using Topology B, it’s rather difficult to guarantee that the DHCP server

and client don’t interfere with each other because they are both using the same

interface. The DHCP client normally initializes the interface on startup into a state

where it has no IP addresses, which means it discards any addresses from the small

office network that were previously configured for that interface. If the DHCP client

on the operating system you are using uses the BSD socket API, you cannot prevent

this from happening; the BSD socket API doesn’t provide a mechanism for working

around it.

You can tell which API the client is using by starting it up with

dhclient -

At the end of the client’s output are two lines that start with Listening on and

Sending on, similar to the output shown in Example 22.5. After that is the name of

the API being used; in this case it is

Socket

, meaning the BSD socket API.

Example 22.5

Listening on Socket/ep0

Sending on Socket/ep0

Avoiding the PREINIT Problem

The

PREINIT phase of the client script normally starts the network interface. If the

DHCP client is not using the BSD socket API, you can prevent it from initializing the

network interface by installing the

/etc/dhclient-enter-hooks

script shown in

Example 22.6.

Example 22.6

if [ x$reason = xMEDIUM ] || [ x$reason = xPREINIT ]; then

exit 0

CHAPTER 22 Setting Up DHCP in a Small Office386

026 3273 CH22 10/3/02 5:05 PM Page 386

The script in the example disables the

PREINIT

phase. This means the network must

already be started before the client runs. To complete this workaround, you must

arrange to configure the interface with the IP address on your office network before

you start the DHCP client.

Configuring an Alias in the DHCP Client

When the DHCP client acquires a new IP address for a given interface, it normally

gets rid of the old network configuration for that interface and installs the new one.

To have the DHCP client reinstall the IP alias as it configures the network interface,

you must write an

alias

declaration in the

/etc/dhclient.conf

file. The alias declara-

tion tells the DHCP client that a second IP address needs to be configured on the

interface, in addition to the one it got from the DHCP server. Example 22.7 shows

alias declaration for the DHCP client whose startup output is shown in

Example 22.6.

Example 22.7

alias {

interface “ep0”;

fixed-address 10.0.0.1;

option subnet-mask 255.255.255.0;

}

This example assumes that the local network has a network number of 10.0.0.0 and

a subnet mask of 255.255.255.0 and that the NAT router’s IP address on that subnet

is 10.0.0.1. You need the interface declaration within the

alias declaration to tell

the client that the IP alias should be configured on interface

ep0

, along with what-

ever address is received from the ISP’s DHCP server.

Limiting the DHCP Server’s Authority

As mentioned previously, if you’re using Topology B, your local DHCP service and

other DHCP services can be connected to the ISP to interfere with each other. In

particular, your DHCP server might receive DHCP messages from clients on other

networks, and it might interpret those messages as coming from a client that has an

invalid IP address. Therefore, it is very important that you configure your DHCP

server so that it does not send

DHCPNAK

messages in response to packets it receives

from other networks. If you skip this step, you risk causing your ISP a great deal of

trouble.

Fortunately, it is easy to configure the ISC server so that it does not send

DHCPNAK

messages. You simply include not authoritative

;

at the top of the

/etc/dhcpd.conf

file.

Running a DHCP Server and Client on the Same Computer 387

026 3273 CH22 10/3/02 5:05 PM Page 387

Running the DHCP Server on Your Firewall

A firewall is a computer that sits between one network and another, forwarding some

packets while not forwarding others. You generally place a firewall between your

“trusted” internal network—in this case, your office network—and the Internet,

which you probably don’t trust. The firewall is configured to prevent packets from

being sent from the Internet that might compromise the security of machines on

your internal network. This book does not describe the detailed workings of firewalls.

If you don’t know how they work and are curious, you might want to read Firewalls

& Internet Security: Repelling the Wily Hacker by Steven M. Bellovin and William R.

Cheswick.

Ideally, no network services should run on your firewall. Your firewall should just be

filtering packets between your network and the outside world and preventing bad

packets from getting in. If you install a DHCP server on a firewall, you risk the possi-

bility that a bug in the DHCP server might enable an attacker outside your firewall

to subvert the firewall and penetrate your network.

However, people who are setting up small office environments with only a few

machines generally can’t afford a separate machine to use as a firewall. They also

tend not to be as concerned about active attacks from the Internet as they might be

if they were involved in E-commerce or had a serious Web presence. If you are

involved in either of these applications, you’re probably already paying more every

month for your Internet connectivity than a dedicated firewall machine costs.

You are likely to run into two problems when running the DHCP server on your fire-

wall: filtering rules that prevent DHCP from working and the use of a server identi-

fier that all clients might not be able to reach.

Filtering Rules

DHCP requires that clients be able to send packets from a source address of 0.0.0.0 to

a destination address of 255.255.255.255.

A firewall is normally configured to allow only packets from or to your local subnet,

and it might reject packets from 0.0.0.0 or to 255.255.255.255. Some firewall imple-

mentations examine packets when they receive them, rather than when the routing

decision is made. If you have such a firewall, you must configure it to accept packets

from 0.0.0.0 or to 255.255.255.255. It must also be able to send replies from its own

IP address to 255.255.255.255. If you omit the first rule, the DHCP server never sees

any DHCP packets. If you omit the second rule, it sees them and tries to respond,

but the client never sees its response.

CHAPTER 22 Setting Up DHCP in a Small Office388

026 3273 CH22 10/3/02 5:05 PM Page 388

Server Identifiers

The DHCP protocol requires clients that are in the

RENEWING

state to send unicast

messages of their renewal requests (

DHCPREQUEST

packets) to the IP address that the

DHCP server provides in the

dhcp-server-identifier

option. The ISC DHCP server

normally sends the primary IP address of the interface on which it receives the

client’s request in the

dhcp-server-identifier

option.

Firewall rules might prevent clients on the local network from sending packets to

that address. This is most likely to occur with Topology B, in which the firewall

has one interface configured with two IP addresses: one on your office subnet and

one on the ISP’s subnet. In that case, the DHCP server might choose to use the

IP address on the ISP’s subnet for the server identifier. If your router is not config-

ured to pass DHCP packets, your DHCP clients might not be able to send unicast

renewals to that IP address. To solve this problem, you simply write a

server-

identifier

statement that uses the server’s IP address on the office subnet.

Problems with DSL Routers

Some DSL routers are known to have problems. The routers in question are marketed

as complete solutions; they have built-in firewall support, built-in IP address transla-

tion support, and built-in DHCP service. Although you should use the firewall

support and IP address translation support in these routers, the DHCP support can be

a problem if you aren’t aware of its existence.

For instance, consider this scenario. A DSL router comes preconfigured with DHCP

service enabled, but the DHCP server setup is completely incorrect. The router is

connected to the same subnet on which a legitimate DHCP server is operating.

Whenever a DHCP client tries to get an IP address, it sends a

DHCPDISCOVER message

gets a

DHCPOFFER message

, sends a

DHCPREQUEST message

, and gets a

DHCPACK message

from the legitimate server. Unfortunately, before the

DHCPACK message

from the legiti-

mate server arrives, a

DHCPNAK message

from the DSL router arrives, causing the client

to report that it is not permitted to obtain an IP address.

The solution to this problem is to reconfigure the router to disable DHCP service.

After this is done, the DHCP clients on the network can be configured with no

trouble at all.

Configuring an Integrated Router/Server

One popular way to connect a small network to an ISP is with a dedicated device

that acts as a router, performs NAT, and provides DHCP service. Such a device would

take the place of the router/server in Topology C of Figure 22.1. Typically, the device

would have two Ethernet ports, one of which connects to the DSL or cable modem

and one that is used for the small network. Some of these devices also include built-

in hubs and can provide four or eight ports for the local network.

Configuring an Integrated Router/Server 389

026 3273 CH22 10/3/02 5:05 PM Page 389

The dedicated router/server requires much the same configuration as the Linux- or

NetBSD-based system described earlier in this chapter. Because such devices are

designed to provide router, NAT, and DHCP service, they usually come with Web-

based user interfaces that are tailored to the specific services provided by the device.

These devices come with initial configurations that are appropriate for many small

networks, so that you may be able to simply plug the device into your network and

use it immediately.

Configuring a WAN Port

Integrated router/server devices usually have separate WAN ports that must be

configured to connect with the ISP service through a device such as a DSL modem or

a cable modem. You need to configure this port according to the requirements of

your ISP. If your ISP provides you a static IP address, subnet mask, default router, and

DNS server, you should configure the router/server with those values. If your ISP

uses DHCP, you need to configure the router/server to obtain its configuration from

the DHCP service provided by your ISP.

The examples in this section are based on the Etherfast Cable/DSL Router manufac-

tured by Linksys. This device includes a WAN port and either one or four LAN ports,

depending on the model. The device is configured through a Web-based user inter-

face, which is shown in the figures.

Figure 22.2 shows the main configuration page for the Etherfast Cable/DSL Router.

This page is used to set up the WAN port and some other functions. In this example,

the selection Obtain an IP Address Automatically configures the device to use DHCP

from the ISP. If Specify an IP Address is selected, you enter the IP address provided by

the ISP in the field next to the selection, and you enter the remainder of the infor-

mation provided by the ISP in the fields labeled Subnet Mask, Default Gateway

Address, and DNS (Required).

This example allows the possibility of using Point-to-Point Protocol over Ethernet

(PPPoE). Some ISPs, especially those providing DSL service, use PPPoE to connect the

customer’s modem device to the ISP network. If your ISP gives you configuration

information for PPPoE, you should enter it in the appropriate fields.

Configuring a LAN Port and Small Network Services

There are a couple choices to make when you’re configuring a LAN port and the

services delivered on the local network. The first of these is whether the local

network can use globally routable IP addresses or private addresses. If you have

arranged for a globally routable network address, you need to assign one of those

addresses to the LAN interface of your router/server. Otherwise, you use a

network address from the nonroutable or private address space and assign one of

CHAPTER 22 Setting Up DHCP in a Small Office390

026 3273 CH22 10/3/02 5:05 PM Page 390

the addresses to the LAN interface. The Etherfast Cable/DSL Router uses the private

network address 192.168.1.0 by default and assigns the IP address 192.168.1.1 to the

LAN interface, as shown in Figure 22.2.

Configuring a LAN Port and Small Network Services 391

FIGURE 22.2 The setup page for the Linksys cable/DSL router.

Next, you choose whether to provide DHCP service on your local network with the

router/server. The Linksys device comes configured to provide DHCP service; you

should disable the service if you have another DHCP server on your local network.

You also need to select the range of IP addresses to be assigned by the router/server.

Be sure to choose addresses that are appropriate for the network address assigned to

your local network, and don’t include the address assigned to the router/server LAN

interface as one of the available addresses. The Linksys device assigns addresses in

the range 192.168.1.100 to 192.168.1.149 by default, as shown in Figure 22.3.

Finally, you configure the DHCP server with other parameters for the DHCP clients

on your local network. Typically, the DHCP server provides a subnet mask, a default

route, and a list of DNS servers. Often, the DHCP server automatically determines

the subnet mask from the subnet mask of the local network interface, and it uses the

router/server’s IP address as the default route. If the router/server obtained its WAN

interface IP address through DHCP from your ISP, the router/server DHCP server

might automatically forward the list of DNS servers from the ISP to your local DHCP

clients. Otherwise, you have to manually configure the DHCP server with a list of

DNS servers. The Etherfast Cable/DSL Router automatically provides the subnet

mask, default route, and DNS servers, so those parameters need not be manually

configured for the DHCP server.

026 3273 CH22 10/3/02 5:05 PM Page 391

FIGURE 22.3 The DHCP service configuration page for the Etherfast Cable/DSL Router.

Summary

DHCP service can be useful in a small office environment. Although for the most

part setting up DHCP service in such an environment is the same as setting it up in

any other environment, you might encounter some special difficulties. For instance,

you should be aware of the possible interference that a firewall can cause to a DHCP

server running on it. You should also know about the problems that DHCP clients

and servers can encounter when running on the same computer and the problems

that a poorly configured DHCP server can cause when connected to a network

segment that is bridged to an ISP’s network. You can solve these problems in a

number of ways, as described in this chapter.

Dedicated devices or appliances can provide DHCP service, NAT to allow multiple

computers to share a single global IP address, and act as a firewall. These devices are

simple to install and configure. They come with default configurations that are

appropriate for many local network configurations and offer plug-and-play connec-

tion of a local network with multiple computers through a analog, modem, or DSL

modem to an ISP.

CHAPTER 22 Setting Up DHCP in a Small Office392

026 3273 CH22 10/3/02 5:05 PM Page 392

IN THIS CHAPTER

• Overview of Updating DNS

with DHCP

• The Motivation for Doing

DNS Updates from DHCP

• The Domain Name Update

Policy

• Name Clashes

• DNS Update Security

• Configuring the Servers

• DNS Record Removal

• Debugging Problems with

DNS Updates

Updating DNS with

DHCP

This chapter explains how to operate a DHCP service that

performs DNS updates. It discusses both client- and server-

originated updates, site update policies, security policies,

and the mechanics of configuring DHCP clients and

servers to update DNS.

You can make use of most of the information in this

chapter without reading and understanding Chapter 11,

“DHCP–DNS Interaction,” but reading Chapter 11 will

help you understand the subtleties, and more importantly,

to be able to understand what’s going on when the proto-

col doesn’t work.

In order to illustrate the process of configuring the DHCP

and DNS servers as described in this chapter, we use the

ISC DHCP server and ISC BIND version 9 in our examples.

These examples should carry over to other DHCP and DNS

servers as well.

Overview of Updating DNS with DHCP

In order for a host to be properly identified in DNS, it

must have an

A record, or a forward mapping. This is a

mapping from a fully qualified domain name (FQDN) to

an IP address. For example, if a host is called

dechen and is

in the domain

example.com and has an IP address of

10.0.0.1, it needs an

A record that maps the name

dechen.example.com to the IP address 10.0.0.1.

It is also useful to be able to determine a host’s FQDN from

its IP address. This is called a reverse mapping, and it is

accomplished with a

PTR record. The PTR record has a

domain name that is constructed in a special way based on

the IP address, and its value is the host’s domain name.

027 3273 CH23 10/3/02 5:00 PM Page 393

In the example in the preceding paragraph, the PTR record’s name would be

1.0.0.10.in-addr.arpa, and its value would be dechen.example.com.

NOTE

We say “updating DNS” instead of “updating a DNS server” because DNS as a whole is a

database, and DNS servers serve portions of that database. The PTR record and the A record

for a client are in completely different parts of the database, and although it is likely in some

cases that the same DNS server will serve both of these parts, this is not a requirement. In

some of the configurations that this chapter describes, it is very unlikely that the A and PTR

records for a client will be on the same DNS server.

The Motivation for Doing DNS Updates from DHCP

A DHCP client can act as a network client without ever having an A record or a PTR

record in DNS. However, there are two problems with this. First, many network

servers require that the client’s IP address,

PTR record, and A record all match.

Second, sometimes two DHCP clients need to exchange information, and the easiest

way for their users to rendezvous is by exchanging domain names.

One additional reason for updating DNS is that it makes logging easier, particularly if

client IP addresses change a lot. It’s much easier to find a client’s hostname in a log

than it is to figure out the client’s IP address and look that up.

Many network services on the Internet check that the client’s IP address,

A record,

and

PTR record all match. They do this by first constructing a domain name from the

IP address and using that domain name to look up the

PTR record. They then use the

domain name specified in the

PTR record to look up the A record. If the client’s IP

address appears in the

A record, the client is allowed to access the network service;

otherwise, it is not.

Although this provides no authentication, it provides a small amount of accountabil-

ity; if the name server for the

PTR record and the name server for the A record agree

about the identity of the client, there’s a good chance that if the client causes a

problem, you can find the culprit by contacting the administrator of one or both of

the name servers.

The second reason for publishing the client’s name is that users of computers gener-

ally understand domain names but are less likely to understand IP addresses. Also,

with DHCP, the client’s IP address is not guaranteed to be stable. If the DHCP server

and client cooperate, however, the client’s name should be stable.

For clients that roam to different administrative domains, this stability requires that

the client be able to update its own

A record and that the DHCP server in the admin-

istrative domain to which the client has connected use the domain name supplied

by the client to update the client’s

PTR record.

CHAPTER 23 Updating DNS with DHCP394

027 3273 CH23 10/3/02 5:00 PM Page 394

The Domain Name Update Policy

When setting up a DHCP server to do DNS updates, one issue that you must

consider is who should update the

A record. Both the DHCP server and the DHCP

client can, in theory, update the

A record. Even if you do not allow clients at your

site to update the name server at your site, your DHCP server may encounter DHCP

clients from other sites that want to update their own

A records at their sites.

In order for a client to update its own A record, it must know its FQDN and it must

have permission to update the

A record for its FQDN. Most clients are not configured

with their FQDN, or they do not have permission to update their own

A record. So

even at a site that allows clients to update their own

A records, you usually need to

configure your DHCP server to update the

A records of clients that cannot perform

their own updates.

The DHCP server can advise a client not to update its own

A record, but it can’t force

the client not to update its A record.

Because clients can specify arbitrary FQDNs, there is no way to configure the DHCP

server to update DNS with the FQDN that the client provides; if the DHCP server is

going to update an

A record, the A record has to be in a domain that is served by a

DNS server that your DHCP server has permission to update.

So when deciding how to configure your site, you need to decide the following:

•What to do when the client wants to update its own

A record.

•What to do when the client provides a hostname that it wants you to use in

the update.

•What to do when the client doesn’t provide a hostname.

• Into what domain you want to place client

A records when no domain is

specified.

The Threat Model for PTR Record Updates

In general, if a client wants to update its own A record, your DHCP server has to

store the FQDN the client provides in the client’s

PTR record. This means that the

DHCP server must store a client-supplied string in DNS. Therefore, it is worth under-

standing whether this is a problem.

The first question to ask is whether there is any sort of risk to your site security in

storing a client-supplied domain name on your DNS server? It’s also worth consider-

ing the positive aspects of honoring the client’s request.

The Domain Name Update Policy 395

027 3273 CH23 10/3/02 5:00 PM Page 395