Droms R. The DHCP handbook

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

recent active lease, so Server B attempts to add an A record and a DHCID record for the

client’s domain name.

Server B generates a

DHCID record, either from the client’s client-identifier or from its

link-layer address. Server B sends to the DNS server a DNS update message. The

message includes the prerequisite that the client’s FQDN does not exist. The update

message adds an

A record and a DHCID record. The data in the A record is the new IP

address, and the data in the

DHCID record is the client identifier, as described in the

section “DHCP Client Name Collision,” earlier in this chapter.

This update fails because the FQDN is already present, reflecting the existing lease

from Server A. When Server B is notified of this failure, it then forms another update

message. This message includes a prerequisite that the

DHCID record for the client’s

domain name match the

DHCID that Server B generates. The message deletes any

existing

A records and then adds a new A record for the IP address that Server B

assigned to the client. The update in the message does not try to modify the

DHCID

record. The DHCID prerequisite should match in this example, so the update should

succeed. After the update has been completed, the client’s name should have just

one

A record, pointing to the client’s IP address in Building B.

Server A sees none of this activity. As far as it is concerned, the client has a valid

lease on an IP address in Building A. The client’s lease on its IP address in Building A

may expire while the client is in Building B. When that lease expires, Server A will

try to delete the

A record that it added when the client was in Building A. The dele-

tion will fail because Server B already deleted the

A record that Server A added.

Following the rules specified in the section “Lease Expiration,” earlier in this chapter,

maintains the consistency of the name database.

There is one problem here, though. In order to avoid constantly sending DNS

updates for names that already exist in the DNS database, the network administrator

may configure the DHCP server not to update DNS if it has a record that says it

already updated DNS. So what happens if the client goes from Building B back to

Building A before the original lease in Building A expires? In this case, the client will

renew its lease, but the DHCP server may not update DNS because it thinks it has

already done so. So the client’s

A record will remain in DNS, pointing to the IP

address assigned by Server B, but the client will actually be using the IP address

assigned by Server A. A DHCP server that implements this optimization must there-

fore detect that the client has changed networks and not do the update optimization

in that case.

Client Name Change

If a client changes its name while it has a valid lease, when it renews its lease, the

DHCP server detects that the client’s name has changed and tries to remove the

and DHCID records from the old name, just as it would if the client’s lease expired.

CHAPTER 11 DHCP–DNS Interaction186

014 3273 CH11 10/3/02 4:56 PM Page 186

It then adds the name to DNS again, using the same rules described in the section

“DHCP Client Name Collision.”

DNS Dynamic Update Security Issues

Dynamic updates to the information in DNS represent a significant potential for

security problems. Without some restrictions on the acceptance of dynamic updates,

anyone can send a dynamic update request to a server to change the IP address asso-

ciated with a domain name. So, if an adversary wanted to intercept all the traffic

aimed at

www.genericstartup.com, he or she could simply send a dynamic update to

dns.genericstartup.com that changes the IP address for www.genericstartup.com to

his or her computer’s IP address.

The least secure form of update identification is to restrict the set of IP addresses

from which DNS updates can be received. Many DNS servers provide this capability.

The problem with this technique is that DNS is a UDP-based protocol, and it’s very

easy to send a forged datagram with an IP source address that the attacker knows is

permitted to do updates. There is one case in which address-based authentication

might provide sufficient security: when the DHCP server and the DNS server are

running on the same computer. There is still some risk of a spoofed update; the

network administrator should be sure that the host on which the DHCP and DNS

servers are running will reject forged datagrams with a source and destination

address of 127.0.0.1 if they arrive on a network interface other than the loopback

interface.

DNS provides a standard mechanism, called TSIG, that can be used to authenticate

DNS updates. TSIG signatures are generated by using a secret that the updater and

the DNS server share. By checking the signature in the update packet, using this

shared secret, the DNS server can be sure that the update came from an updater that

possesses the key. Therefore, as long as the key is kept secret, TSIG updates can be

trusted.

TSIG works very nicely for DHCP servers because the DHCP server is under the

control of the network administrator, so the server can be trusted to follow the rules

with respect to updating the zone. TSIG works less well for DHCP clients than it does

for DHCP servers. The problem is that in order to make sure that clients update only

their own records, every client has to have its own secret key. Setting up a special

secret key for each individual DHCP client that needs to update a zone is a lot more

work than setting up one key for each DHCP server. Sites with only a few clients

may find this worthwhile. Sites with more clients may have more difficulty.

Dynamic Updates and DHCP 187

014 3273 CH11 10/3/02 4:56 PM Page 187

How the DHCP Server Updates the DNS

It is important to know something about how the DHCP server actually figures out

how to update the DNS. Without that knowledge, it can be difficult to debug prob-

lems. First, you must understand that the DNS namespace is broken up into zones

on the basis of authority records (usually referred to as SOA records). SOA records

define which DNS server is responsible for the information in a given namespace.

The definitive version of the information in a namespace has to reside on a single

server, known as the primary server. There are two other kinds of name servers—

secondary and caching servers. Secondary servers mirror data that is on primaries,

and some secondary servers can accept DNS updates, but only the primary server for

a zone can make changes to it. Name servers that act as primary or secondary servers

for certain zones are said to be authoritative name servers for those zones. Caching

servers remember names that they have looked up in the past and keep information

about those names in their cache. When the same name is looked up repeatedly, the

caching name server answers each subsequent query itself rather than consulting an

authoritative name server.

In order for the DHCP server to update the DNS, it has to identify the zone it needs

to update, and then it has to send the update to the primary server for that zone. A

zone is a portion of the DNS hierarchy. DNS starts with a root zone, which is at the

top of the tree. Within the root zone are all the top-level domains, which are all

separate zones—for example,

.com. is a top-level domain. Underneath the top-level

domains are organizational domains, such as

fugue.com., which is my home

domain. Organizational domains are run by the organizations that own them, or by

DNS service providers. It is a safe bet that the top three levels of the domain hierar-

chy are all separate zones. However, it is not required that each label be in its own

zone. It is possible for

manhattan.fugue.com. and bisbee.fugue.com. to both be part

of the

fugue.com. zone. It is also possible for them to be separate zones.

The DHCP server figures out the primary server for a given name by asking DNS,

using the DNS resolver, which is an operating system service for looking up records

in the DNS. For example, if the server needs to update

samten.bisbee.fugue.com., it

first checks to see if

samten.bisbee.fugue.com. is a zone, by asking DNS for an SOA

record for the domain. If there is an SOA record for

samten.bisbee.fugue.com., then

the DHCP server sends the update to the DNS server named in that SOA record. If

there is not, the DHCP server tries to find an SOA record for

bisbee.fugue.com., and

then

fugue.com., and then com., and then .. Of course, it won’t have to traverse all

the way up to

., but in an organization with a deep hierarchy, it might have to try a

few times before it gets the SOA record it needs.

One consequence of this is that it is difficult to short-circuit the process for testing

purposes. Because the structure of the DNS is contained within the DNS, if you want

to set up a test server but don’t want to publish it, you have to somehow tell the

DHCP server to send updates to the test server and not to the IP address that it

CHAPTER 11 DHCP–DNS Interaction188

014 3273 CH11 10/3/02 4:56 PM Page 188

would find if it queried the DNS. Because the DHCP server searches up the hierarchy

rather than starting from the top and moving down, this is possible; if you configure

the DNS resolver on the DHCP server machine to use the test DNS server for name

resolution, then when the DHCP server asks which server is authoritative for the

zone it wants to update, the test server claims that it is authoritative, even though it

really isn’t.

There is an additional complication. TSIG keys are generally defined on a per-zone

basis or for some set of zones. Therefore, the TSIG key

mykey.fugue.com. might work

for updating

manhattan.fugue.com but not for bisbee.fugue.com. The DHCP server

or client has to provide a way for the administrator to tell it which key to use with

which zone. Some DHCP servers may be able to accomplish two goals at once with

this configuration process. If the DHCP server can be configured with the IP address

of the IP address of the primary server for the zone as well as the TSIG key to use

when updating the zone, the DHCP server doesn’t have to search for the zone to

update.

One other consideration when using TSIG is that TSIG updates do not work if the

updater and the server do not have clocks that are synchronized to within five

minutes of each other. This is a result of the way TSIG prevents replay attacks. In a

replay attack, an attacker captures DNS update messages on the network and stores

them. Later, it replays one of these messages, to make the DNS server redo the

update. This puts invalid data into the DNS server. To prevent this, DNS agents that

generate the messages put timestamps on each message that is signed with TSIG. The

DNS server checks each timestamp, and if that timestamp differs from the current

time by more than five minutes, the server discards the message.

Summary

DNS provides a mapping between mnemonic names for networked devices and the

IP addresses assigned to those devices. The mapping information is stored as a data-

base whose contents are distributed among DNS servers throughout the Internet.

As DHCP servers assign IP addresses to clients, either the DHCP server or client must

add database entries to the DNS database or the DNS database must already contain

forward and reverse mappings for the client.

The dynamic DNS update mechanism described in RFC 2136 defines a mechanism

through which DNS messages can update—not just query—the DNS database. Three

protocol specifications describe how RFC 2136 can be used in combination with

DHCP services: “A DNS RR for Encoding DHCP Information (

DHCID RR),” “Resolution

of DNS Name Conflicts Among DHCP Clients,” and “The DHCP Client FQDN

Option.” These specifications define a set of techniques that can be used to reliably

keep the DNS database synchronized to the DHCP lease database.

Summary 189

014 3273 CH11 10/3/02 4:56 PM Page 189

014 3273 CH11 10/3/02 4:56 PM Page 190

PART III

DHCP Servers and

Clients

IN THIS PART

12 Theory of the Operation of a DHCP Server

13 The Microsoft DHCP Server

14 The ISC DHCP Server

15 Configuring a DHCP Server

16 Client Identification and Fixed-Address Allocation

17 Setting Up a Reliable DHCP Service

18 Configuring a Failover Server

19 Tuning a DHCP Service

20 Conditional Behavior

21 DHCP Clients

22 Setting Up DHCP in a Small Office

23 Updating DNS with DHCP

24 Debugging Problems with DHCP

25 DHCP for IPv6

015 3273 Part III 10/3/02 5:05 PM Page 191

015 3273 Part III 10/3/02 5:05 PM Page 192

IN THIS CHAPTER

• Address Allocation Strategy

•Allocation and Renewal in

Response to a DHCPREQUEST

Message

• DHCP Message Handling

• Abandoned Lease Address

Reclamation

Theory of the Operation

of a DHCP Server

This chapter describes the actual operation of a DHCP

server. It uses as an example the operation of version 3.0 of

the ISC DHCP server because the source code for this

server is readily available; interested readers can follow

along and see how it is implemented. In addition, one of

the authors is intimately familiar with version 3.0’s opera-

tion. Although the operation of some of the features of the

DHCP server is ISC-specific, this discussion should be

meaningful to users of other DHCP servers as well.

Address Allocation Strategy

A DHCP server allocates IP addresses to clients according

to the configuration set up for the server by the DHCP

administrator. IP addresses are allocated either dynamically

or statically. In dynamic allocation, a client can be allocated

any address out of an address pool. (An address pool is a list

of IP addresses that are available for allocation on a partic-

ular network segment.) When the server receives a request

for an address from a client, the server looks through its

configuration and identifies an address from an appropri-

ate address pool to be allocated to the client.

Each address pool is associated with the network segment

for the subnet declaration in which it is defined. If a

network segment is configured with more than one IP

subnet, then any address pool for that network segment

can contain IP addresses from any IP subnet on that

network segment. Any address pool can have an access

control list—that is, a list of tests to run on a client to see

whether the server can allocate an address out of the pool

for that client. There can be more than one pool per

network segment, so that different clients on that network

segment can get different IP addresses.

016 3273 CH12 10/3/02 4:59 PM Page 193

CHAPTER 12 Theory of the Operation of a DHCP Server194

In static allocation, you define an address for a specific host in the DHCP server

configuration. The ISC server uses a host declaration to identify a host. The host

declaration can contain a fixed address, specifying one or more IP addresses for static

allocation. These addresses are allocated only to the client that matches the host

declaration.

NOTE

The ISC DHCP server does not check for conflicts between IP addresses declared in fixed-

address

statements and IP addresses declared in address pools. This means that if you declare

an address range that includes an IP address that is also in a fixed-address declaration, the

DHCP server might assign the same IP address to two different clients. This check is not done

because a DHCP server with a large configuration file that contains many host declarations

would take too long to start.

NOTE

The reason that it is possible to provide more than one statically allocated IP address to a

single client is that the client might have network interfaces on more than one network or it

might need to be able to receive statically allocated IP addresses as it roams among different

network segments.

Allocation in Response to DHCPDISCOVER or BOOTREQUEST Messages

When a server receives a DHCPDISCOVER or BOOTREQUEST message, it attempts to allo-

cate an IP address for the client that is sending the message. It first looks for host

declarations that match the client and that contain fixed-address declarations. It

checks each IP address in these declarations to see if it is valid on the network

segment to which the client is connected. If it finds an IP address that is valid, that

IP address is always assigned to the client. Otherwise, it looks to see whether the

client has an existing lease on the network segment to which it is connected that is

either still valid or hasn’t been reused since it expired. If it finds such a lease, it

checks to see whether the client is permitted to use the address. If the client is

permitted to use the address, the DHCP server assigns the client that address.

(Reasons the client might not be permitted to use the address are described in a later

section called “Address Use Denied.”)

If a client has specified an address by using the

requested-address option and that

address is on the network segment to which the client is connected, the server

checks to see whether that address is available and whether the client is allowed to

use it. If the address is available and the client is allowed to use it, the server allo-

cates that address for the client.

016 3273 CH12 10/3/02 4:59 PM Page 194

If the client still doesn’t have an IP address, the server goes through the list of pools

for the network segment to which the client is connected and tries to find one that

is free and that the client is permitted to have. If it finds one, it allocates it to the

client. If there are no free addresses that the client is allowed to have, the server logs

no free leases message and doesn’t respond to the client.

In searching each pool, the server first looks for an address that has never been asso-

ciated with a client, and then, if it doesn’t find one, it looks for a previously assigned

address that is now available. The server continues to search through all the address

pools for the network segment to which the client is attached, looking for an address

that has never been associated with a client, until it finds one or runs out of pools.

Address Assignment

After the server identifies an address that can be allocated to the client, it sends an

ICMP echo request to that address, to see whether the address is already in use. It

waits for about one second for a response, and if it doesn’t receive one, it sends a

message to the client with the address that was allocated.

If the client is a DHCP client, the DHCP server sends a

DHCPOFFER message to the

client that contains the address that the DHCP server has allocated, as well as all the

parameters the server intends to send to the client. The lease is not yet final, so the

DHCP server does not write the lease to disk, but it does reserve the lease in its in-

memory database for two minutes, to give the DHCP client time to confirm the lease

with a

DHCPREQUEST message.

If the client is a BOOTP client, the server sends a BOOTREPLY message to the client

with the client’s new address. This is the end of the transaction for a BOOTP client.

If the client’s address is a statically assigned address, the server writes no information

into the lease database. If the client’s address is dynamically allocated, before the

server sends the

BOOTREPLY message, it writes the address to the lease database so that

when it is restarted, it will remember that it has dynamically allocated the address to

the BOOTP client. Because BOOTP has no concept of a “lease”, and a BOOTP client

considers its address to be permanently allocated, the DHCP server records the

dynamically allocated address for a BOOTP client as a permanent assignment with

an infinite lease.

If the server receives an ICMP echo reply message in response to its ICMP echo

request, it marks the address as abandoned and logs a message indicating that this

has occurred so that an administrator can take action. A permanent lease is assigned

to that IP address, and it is marked as abandoned. The abandoned lease is immedi-

ately written to the lease database so that the server does not attempt to allocate

the address again later. The server does not send any response to the client in this

case.

Address Allocation Strategy 195

016 3273 CH12 10/3/02 4:59 PM Page 195