The Dynamic Host Configuration Protocol is one of the unsung heros of the network administrator. Without the help of DHCP and DHCP Servers, we would be thrust into a life of constant battle against entropy of our IP addressing scheme. We would live the listless life of an inventory specialist, continuously having to record and record IP addresses for the machines on our network.
The Dynamic Host Configuration Protocol is one of the
unsung hero's of the network administrator. Without the help of DHCP and DHCP
Servers, we would be thrust into a life of constant battle against entropy of
our IP addressing scheme. We would live the listless life of an inventory
specialist, continuously having to record and record IP addresses for the
machines on our network.
However, the DHCP Server now does all the work for us. All
we have to do is install the Windows 2000 DHCP Server, configure scopes and DHCP
Options, and away we go. No muss, no fuss, and almost all the time,
things work very nicely. The only chink is the armor is the broadcast nature of
DHCP Client/Server communications. And although this provides one of its
greatest strengths, it also creates one of its greatest weaknesses.
The Mysterious Network Glitch
As an experienced network administrator, you probably have
had the experience of having someone "try out" a new DHCP Server on
your production network. You probably also had to spend many long hours trying
to figure out what the problem was after the "surprise" DHCP Server
was brought online.
The core of the problem is that DHCP messages are
broadcast messages, and any DHCP Server that hears the broadcast can respond to
the DHCPDISCOVER message from a DHCP Client. Since any and all DHCP Servers
within broadcast range of the DHCP client can respond to DHCP requests, if an
unauthorized DCHP Server answers the request, there's a good chance that the
information the DCHP Client receives from it will not be valid.
We call such an unauthorized DHCP Server a Rogue DHCP
Server. Rogue DHCP servers will likely assign inaccurate IP addressing
information to DHCP clients, and in the process disrupt network communications
for these hapless DHCP clients.
Windows 2000 networks running only Windows 2000
DHCP servers can recognize and shut down rogue DHCP servers by keeping a list of
authorized DHCP servers in the Active Directory. Authorized Windows 2000
DCHP Servers in the same broadcast domain will shut down any Windows 2000 DCHP
Server that is not authorized in the Active Directory.
Rogue DHCP Server detection is very cool. However, it is
severely limited in its efficacy because only Windows 2000 DHCP servers can
detect rogue DHCP servers, and the rogue DHCP server must also be a
Windows 2000 DHCP Server. If someone were to introduce a Windows NT 4.0 or SCO
DCHP Server onto the network, the authorized Windows 2000 DCHP Servers on the
network would not shut down that DHCP Server.
How Rogue DHCP Server Detection Works
When a Windows 2000 DHCP server boots up, it broadcasts a
DHCPINFORM message to the local segment. The DHCPINFORM message contains Windows
2000 vendor-specific option codes that are interpreted by Windows 2000 DHCP
Servers. These vendor option types allow the Windows 2000 DHCP server to obtain
information about the network from other Windows 2000 DHCP servers on the
segment. Most specifically, they are able to obtain information about servers
that are authorized in the Active Directory.
The DCHPINFORM message includes a query asking about the
name and location of an Active Directory domain controller. All Windows 2000
DHCP Servers will reply with this information via a DHCPACK message. If DHCP
Servers from multiple domain are included on the same segment, then the
requesting machine will obtain information about domain controllers in each of
After the DHCP Server obtains the information about the
location of a domain controller, it will query the Active Directory for the list
of authorized DHCP servers. If the querying DHCP Server's IP address is on the
list, it will successfully initialize its DHCP Server service. If not, DHCP
server service will not initialize and will not be able to function as a DHCP
So Exactly When
Will a DHCP Server Start?
The new DHCP server will start DHCP server services if:
- There are other DHCP servers on the segment that are
authorized DHCP servers and the new DHCP server is listed in the Active
Directory's list of authorized DHCP servers, or
- The new DHCP server is the only DHCP server on
the segment. Since the new DHCP will not receive a response to the
DHCPINFORM message query, the new DHCP server will not receive any
information about the Active Directory, or
- The new DHCP server is on a segment with other
Windows 2000 DHCP Servers that are workgroup members or all other DHCP
servers on the segments are downlevel systems (such as Windows NT 4.0 or
UNIX DHCP servers).
In the second and third examples the new DHCP server is
unable to contact another DHCP server that has information regarding an Active
Directory domain. The "lone" DHCP server will continue to send a
DHCPINFORM message every five minutes hoping to find a DHCP Server with
information about an Active Directory domain. If the new DHCP server later
receives a DHCPACK from a Windows 2000 DHCP server that contains information
about an Active Directory domain, the new DHCP server will check to see if it is
authorized in the Active Directory and if not, will disable its DHCP server
Get to Know the Windows 2000 DHCP Server's New Features
The Windows 2000 DHCP Server has many new features that
are worth looking at in more detail. Another important feature of the Windows
2000 DHCP Server is its ability to integrate with the Windows 2000 Dynamic DNS
Server. But we'll save that discussion for another time.
For More Information
For more information about the Windows 2000 DHCP Server
and what can go wrong with it at times, check out Troubleshooting
Windows 2000 TCP/IP.
For a thorough grounding on how the DHCP Server is
supposed to work, check out our Windows
2000 Network Infrastructure Study Guide.
You can read about DHCP Concepts in the online help file
This article was originally published on Monday Oct 9th 2000