Droms R. The DHCP handbook
Подождите немного. Документ загружается.
grant dechen.keys.example.com. name \
dechen.sci.example.com.;
};
};
In Example 23.14, we have eliminated the allow-updates statement that is shown in
Example 23.6. The DHCP server is still allowed to update the zone by using the
mykey.example.com key because of the first grant statement in the update policy.
The second
grant statement gives the client permission to update its own name.
Updating the Client’s A Record from a Script
If your DHCP client does not directly support DNS updates but does support scripts,
or if you want to use SIG(0) with the ISC DHCP client, you must use a shell script.
The shell script can use the
nsupdate command, which comes with BIND version 9.
The ISC DHCP client normally assumes that if you configure it to tell the server it
will be doing the update, it should do the update. You can prevent it from doing this
by adding the statement in Example 23.15 to your
dhclient.conf file:
Example 23.15
do-forward-updates off;
The ISC DHCP client can be made to invoke a shell script whenever it acquires or
renews a lease. This script is called
dhclient-enter-hooks, and it is stored in the
/etc directory. The script file must be executable. Example 23.16 shows a dhclient-
enter-hooks script that installs an A record for the client:
Example 23.16
TTL=120
SERVER=10.0.100.17
ZONE=sci.example.org
HOSTNAME=dechen
KF=/etc/dnskeys/Kdechen.keys.example.com.+157+62188.private
if [ x$reason = xBOUND ] || [ x$reason = xREBIND ]
then
nsupdate -v -k $KF > /dev/null << EOF
server $SERVER
zone $ZONE
update delete $HOSTNAME A
update add $HOSTNAME $TTL A $new_ip_address
send
CHAPTER 23 Updating DNS with DHCP406
Example 23.14 Continued
027 3273 CH23 10/3/02 5:00 PM Page 406
EOF
elif [ x$reason = xEXPIRE ] || [ x$reason = xRELEASE ]
then
nsupdate -v -k $KF > /dev/null << EOF
server $SERVER
zone $ZONE
update delete $HOSTNAME A
send
EOF
fi
This script works with both SIG(0) and TSIG update keys, and it operates in almost
exactly the same way as the configuration shown in Examples 23.12 and 23.13. The
one difference is that instead of using a
key statement in the dhclient.conf file, the
nsupdate command uses the private key file generated by dnssec-keygen, which, in
the example, is placed in the
/etc/dnskeys directory.
This script does not run, unchanged, with some other DHCP client. In order to make
it work with a different DHCP client, you must figure out how the DHCP client
signals to the script that a new address has been acquired or that the client is releas-
ing its old address. Also, the ISC DHCP client places the newly acquired IP address in
the
new_ip_address shell variable. Other DHCP clients may pass the IP address in
some other way. When you understand how the client does these things, modify the
script accordingly and configure the client to invoke the script when it acquires a
lease, when it releases a lease, and when a lease expires.
DNS Record Removal
One important problem to consider with DNS updates is what happens when the
client’s lease expires and the client’s IP address is reassigned to a new client. If
the client’s
A record is being used by any network services to locate and contact the
client, then when the client goes away, if its name remains, those services continue
to attempt to contact it at its old IP address.
Not all DHCP servers and clients follow the same policies for DNS record removal.
Some DHCP servers simply leave the
A record in place. The ISC DHCP server auto-
matically deletes the
A record from the DNS server when the lease expires or when
the client releases the lease.
If the client is updating its own
A record, the situation is more difficult because
DHCP clients frequently do not know in advance that they are being disconnected
from the network. If the user of the client instructs the client to send a
DHCPRELEASE
message, the client may delete the name before sending the DHCPRELEASE message
DNS Record Removal 407
Example 23.16 Continued
027 3273 CH23 10/3/02 5:00 PM Page 407
(the ISC client does this). However, if the client computer is unplugged from the
network, the DHCP client doesn’t know to remove its
A record until the connection
is gone, and then it’s too late.
There is no real solution to this problem, so mobile DHCP clients must not arrange
for network services that use protocols that are not cryptographically secure to
connect to them.
The Threat Model for Dangling A Records
The threat model for dangling A records is not an entirely academic subject. A
sophisticated user might set up network services on a DHCP client machine. A mali-
cious person might set up a computer that watches for the DHCP client machine to
be disconnected from the network. When the client is disconnected, the attack
computer could take over its IP address and start listening for service connections.
For example, suppose you set up an SMTP listener on your DHCP client. After you
disconnect from the network, the attacker could accept incoming SMTP connections
on your IP address and intercept your e-mail until your client updates its
A record or
the lease expires on the server and the server deletes the
A record.
There could be another, more subtle, attack: Suppose that the DHCP client is adver-
tising a Web server or and FTP server on its
A record. In that case, a malicious person
could set up a fake Web server or FTP server with content similar to the DHCP
client’s content, but with perverted files intended to compromise the security of any
machine that uses them. Because it would be listening on the IP address that the
client’s
A record advertises, people who have come to trust that name would connect,
assuming they were talking to the server they trust, and would not be as careful in
checking the files they downloaded.
So a mobile DHCP client that advertises network services must be careful to use only
network services that provide a mechanism whereby the server can prove its identity
to clients that connect and where no nonsecured path is available that would appear
the same to a naive client. For example, secure HTTP provides a mechanism by
which the client can verify the server’s identity, but if the user types
http instead of
https, the Web browser never checks the identity of the server. SMTP provides an
authorization mechanism, but doesn’t require that SMTP clients use authentication,
so it is unlikely that a bogus SMTP server would be detected.
Time to Live on Client A Records
The Time to Live (TTL) of a DNS record tells a DNS cache how long it can continue
to use a DNS record it has retrieved before it has to check to see whether it has
changed. The TTL is used to prevent a DNS cache from holding on to stale data that
may have changed. The TTL isn’t an expiration date on the record—DNS records do
CHAPTER 23 Updating DNS with DHCP408
027 3273 CH23 10/3/02 5:00 PM Page 408
not expire. Rather, it is a guess as to the longest time interval during which it is not
likely that the record will change.
The TTL on a DNS record should be chosen considering three things: minimizing
redundant lookups, minimizing out-of-date answers, and minimizing lookup failures
due to unreachable name servers.
DNS caching reduces the load on authoritative name servers. A DNS record with a
TTL of zero can’t be cached, so it must be looked up on an authoritative name server
every time it is used. Imagine how many hits the name servers for the
.com domain
would take if the SOA record for
.com had a TTL of zero. Every time anybody or any
server anywhere on the internet looked up a name in the
.com domain (for example,
example.com), the request would have to go to a name server for the .com domain.
This would amount to millions of queries per second.
On the other hand, a DHCP client is not going to be that popular. It is more likely to
receive a query every couple minutes. One other aspect of caching is that it only
works if a lot of queries for the same name go through the same cache. So if a DNS
client at
example.org and another DNS client at dhcp-handbook.com both try to look
up
dechen.sci.example.com, they each have to consult an authoritative name server
because they do not use the same DNS cache.
However, as the user of a particular DHCP client surfs the Internet, the client
machine is likely to fetch quite a few Web pages from the same server before moving
on to the next server. So it is likely that there is some benefit to caching—just not for
very long.
On the other hand, as mentioned earlier in the chapter, having the
A record
dangling is not a very good idea. If the client cleanly releases its lease before discon-
necting, the client or the DHCP server removes the client’s
A record from the DNS
server. The latest time that a record for that client could still be cached is the time
the
A record is deleted plus the TTL on the record. Therefore, you would like to keep
the TTL fairly short.
It is not possible to say exactly what the right TTL is; it depends on your site and the
kind of users that are using it. Clients that are not likely to move, such as cable
modem and DSL customer computers, can safely use quite long TTLs. Clients that
move around a lot, such as laptop computers, need short TTLs.
DHCP doesn’t provide the DHCP client with a way to give the DHCP server hints
about how long a TTL to use, so you have to guess based on your site’s particular
usage patterns. At a minimum, a TTL of between 10 seconds and 2 minutes should
work pretty well for a mobile client, and if your DNS server is not seeing an excessive
load, you might want to just assume this TTL value for every client. At a cable
modem or DSL ISP, you might need to use a longer TTL to reduce load on your DNS
server, and it is probably safe to do so.
DNS Record Removal 409
027 3273 CH23 10/3/02 5:00 PM Page 409
To set the TTL to use on DNS updates in the ISC DHCP server, you use the ddns-ttl
parameter, as shown in Example 23.17.
Example 23.17
ddns-ttl 120;
The ISC DHCP client currently does not provide a way to set the TTL, although if
you use a script to update DNS, you can specify the TTL to the script.
Debugging Problems with DNS Updates
This section lists a series of error messages that the DHCP server or client may print
and explains what is the likely cause of each message.
If you look at the domain name in the error message in Example 23.18, you can see
that the
sci.example.com domain name is repeated twice.
Example 23.18
Jan 23 16:20:39 server dhcpd: Unable to add forward map from
dechen.sci.example.com.sci.example.com to 10.0.0.1: timed out
What has happened in Example 23.18 is that the DHCP client was configured to
send its FQDN, but the domain name that you specified was not fully qualified—it
did not have a trailing period. To fix this problem, add the trailing period in the
DHCP client’s configuration, as shown in Example 23.19.
Example 23.19
send fqdn.fqdn “dechen.sci.example.com.”;
You might get a timeout message like the one shown in Example 23.18, but the
domain name being updated looks correct. In this case, the update message was
dropped by the DNS server. The DNS server usually ignores updates because the
update isn’t signed or because the signature isn’t valid (that is, the secret on the DNS
server is different than the secret on the DHCP server or client). So make sure that
you’ve written a correct zone declaration with a correct key reference and that the
secret in the key on the DHCP server or client matches the secret in the key on the
DNS server. Also make sure that the key name is the same in both places; the key
name is what the DNS server uses to figure out which key to use to check the
signature.
The message in Example 23.20 indicates that the DNS server was able to confirm
that you have the key you intended to use but that key does not authorize you to
CHAPTER 23 Updating DNS with DHCP410
027 3273 CH23 10/3/02 5:00 PM Page 410
update the DNS server. This means that you’ve set up the update-policy or allow-
updates statement on the DNS server incorrectly, so that the key you think should
allow to make the update isn’t actually configured to allow you to make the update.
Example 23.20
Jan 23 16:20:39 server dhcpd: Unable to add forward
map from dechen.sci.example.com.sci.example.com to
10.0.0.1: invalid TSIG key.
The message in Example 23.21 indicates that the system clock on the DNS server and
the system clock on the DHCP server or client are more than five minutes apart. You
must synchronize these clocks in order for DNS updates to succeed. You can do this
by using NTP or a similar protocol or by simply synchronizing the servers by hand
when they get out of sync.
Example 23.21
Jan 23 16:20:39 server dhcpd: Unable to add forward
map from dechen.sci.example.com.sci.example.com to
10.0.0.1: clock skew too great.
The message in Example 23.22 indicates that you have written a zone declaration
that does not refer to a zone. If you want to update
dechen.sci.example.com and
there is an SOA record for
example.com but no SOA record for sci.example.com, you
must write a zone statement for
example.com, not sci.example.com.
Example 23.22
Jan 23 16:20:39 server dhcpd: Unable to add forward
map from dechen.sci.example.com.sci.example.com to
10.0.0.1: not a zone
Summary
DHCP clients can benefit from having forward and reverse mappings in DNS. Either
the DHCP client or the DHCP server can update the client’s forward mapping; only
the DHCP server can update the reverse mapping. You must have a site policy to
determine whether your DHCP server will cooperate with clients that want to update
their own forward mapping.
When the DHCP server is updating the forward mapping, it can generate a domain
to update, using a hostname or FQDN provided by the DHCP client, and it can also
be configured to use a name that is configured by the server administrator. The
Summary 411
027 3273 CH23 10/3/02 5:00 PM Page 411
DHCP–DNS update protocol resolves naming conflicts in favor of the client that has
an active lease with a certain name when another client with the same name tries to
get a lease.
Updates can be secured with TSIG, SIG(0), or GSS-TSIG, and TKEY and SIG(0) can be
used together to establish TSIG keys in a relatively manageable fashion. You must
generate a key and install it on the DNS server and the DHCP server or client.
CHAPTER 23 Updating DNS with DHCP412
027 3273 CH23 10/3/02 5:00 PM Page 412
IN THIS CHAPTER
• The Debugging Process
• Connectivity Problems
• When the Server Does Not
Respond
• Server DHCPNAK Message
Behavior
•Incorrect Option Values
• The Uniqueness of Client
Identifiers
• Dual-Boot Client Systems
• Duplicate IP Addresses
• When a Client Fails to Get a
Reserved IP Address
24
Debugging Problems
with DHCP
Previous chapters discuss how DHCP works and how to
configure DHCP servers and clients. This chapter discusses
problems that can occur when DHCP servers and clients
are configured incorrectly. It also provides an overview of
the process of debugging DHCP clients and servers when
they aren’t working correctly and describes some specific
problems that occur rather frequently. This chapter is
strictly about debugging DHCP itself; debugging of the
DHCP failover protocol and DHCP–DNS interactions are
covered in Chapters 18, “Failover Configuration,” and 23,
“Configuring DHCP–DDNS Interactions,” respectively.
The Debugging Process
The debugging process includes three basic parts:
•Discovering that you have a problem
• Determining what the problem is
• Solving the problem
These parts might seem obvious, but each of these parts
can be fairly subtle. Therefore, the following sections
describe them in detail.
Discovering That You Have a Problem
A computer that uses DHCP is likely to encounter two
fundamental problems:
• The DHCP client may fail to acquire or renew a lease.
• If the DHCP client acquires a lease, the information
the server provides may be incorrect.
028 3273 CH24 10/3/02 4:57 PM Page 413
Depending on which version of the DHCP client you are using and on the nature of
the problem, it may be difficult to tell which of these two problems has occurred.
Failure to Acquire or Renew a Lease
Some older DHCP clients, such as the one included in Windows 95, notify the user if
they fail to acquire or renew a lease. Unfortunately, most modern DHCP clients
assume that if they are unable to get an IP address from a DHCP server, they should
use an Automated Private IP Addressing (APIPA) as described in Chapter 21 in the
section titled, “When a Client Fails to Get an Address.” The clients included in
Windows 98, 2000, Me, and XP, and the clients included in Mac OS 9 and later
versions all do APIPA autoconfiguration if they can’t contact a DHCP server or
acquire an IP address.
These clients do not display a dialog box if they fail to acquire an IP address. Instead,
they choose an IP address on the 169.254.0.0/16 subnet. The only way to tell that
the client chose an autoconfiguration address is to find out what IP address the
client has, if any. If the client has an IP address that starts with 169.254, the DHCP
client was not able to acquire an IP address from the DHCP server.
To check the IP address that a client acquired on Windows 98, you use the
winipcfg
command. When you do, a dialog box appears, allowing you to see what IP address
is assigned to each network interface. In Windows NT, 2000, and XP you use the
ipconfig command to display a list of interfaces and their IP addresses. In Windows
Me you can use either of these commands. On Unix and Linux systems, you can
type
netstat -in to get a list of the IP addresses associated with each interface. On
Mac OS 9, the TCP/IP Control Panel sometimes shows the IP address that is config-
ured to a particular network interface, if you select that interface and click on the
Info
button, but it does not always display this information. On Mac OS X, you can
use the Network Preferences dialog box to show the IP address of an interface, and
you can also use the
netstat command.
NOTE
DHCP clients on multiuser systems, such as Unix, Linux, NetBSD, and Windows NT, do not
necessarily display dialog boxes indicating that a problem exists in acquiring an IP address.
Instead, the DHCP client reports the problems through the system error log. To determine
that these systems failed to acquire an IP address, you can either look in the error log or check
the IP address assigned to each network interface that the DHCP client is instructed to config-
ure. If the network interface doesn’t have an IP address, the DHCP client failed to acquire one.
On Unix-like systems, the syslog daemon, which is configured through the
/etc/syslog.conf
file, writes the system error log. If you don’t know where DHCP
client errors are logged, consulting this file and the documentation for the DHCP
CHAPTER 24 Debugging Problems with DHCP414
028 3273 CH24 10/3/02 4:57 PM Page 414
client should help. On Windows NT, you can run the Event Log program to examine
the event log for errors.
Incorrect Information from the DHCP Server
If the DHCP server is providing a lease but is providing incorrect information about
network services with that lease, the DHCP client generally cannot tell that this is
the case, and it does not display a dialog box or log a message indicating that an
error occurred. The only evidence that something is wrong is that the client cannot
access some or all network services.
For example, if the DHCP server supplies an incorrect value for the Domain Name
System (DNS) server or the default route, the DHCP client cannot resolve DNS names
and contact other computers on the network, even though it has a valid IP address.
A DHCP client for a diskless workstation (for example, a network computer) that is
provided either with incorrect information about the name of its bootfile or with an
incorrect IP address for the server that provides that file may display an error
message such as “File not found” on startup.
If you suspect that something of this nature is occurring, you should examine the
client’s configuration in detail to discover the problem. The Windows 95/98
winipcfg
command displays the IP address of the domain name servers that it receives, as well
as the default route, so it is possible to verify that these configuration parameters are
correct. To get
winipcfg to display more information, you can click the More button
in the
winipcfg dialog box. DHCP clients for Unix systems generally write the IP
addresses of the DNS servers into the
/etc/resolv.conf
file, and you can use the
netstat -r command to display the routing table, including the default route
provided by the DHCP server. On Windows systems that support the
ipconfig
command, you can use ipconfig/al
l
to display all the parameters received from the
DHCP server that Windows knows how to use. On Mac OS X, the Network
Preferences dialog box displays the client’s IP address, subnet mask, and default
route, but it does not display the domain name server address or the domain name.
The file
/var/etc/resolv.conf may contain the domain name server address and
the domain name.
Determining What the Problem Is
After you discover that you have a problem, you must figure out why you have the
problem. The client may fail to acquire or renew a lease for four general reasons:
• The client might be unable to get DHCP packets to the server.
• The server might be receiving DHCP packets but unable to get its responses to
the client.
The Debugging Process 415
028 3273 CH24 10/3/02 4:57 PM Page 415