Top 16 DHCP Best Practices: The Ultimate Guide

This is the ultimate guide to Windows DHCP best practices and tips.

If you have any best practices or tips please post them in the comments below.

In this guide, I’ll share the following DHCP best practices and tips.

Table of contents:

  1. Don’t put DHCP on Your Domain Controller
  2. Use DHCP Failover
  3. Central vs Distributed DHCP Server
  4. Avoid static IP assignments and use DHCP reservations
  5. Exclude IPs from the DHCP scope
  6. Learn PowerShell DHCP Commands
  7. Subnetting and benefits of network segmentation
  8. DHCP Lease Duration Tips
  9. Use IP conflict detection only when it is needed
  10. Run DHCP Best Practice Analyzer
  11. Document IP addresses or us an IPAM
  12. Set DHCP Server Options
  13. Use DHCP Relay Agents
  14. Prevent Rogue DHCP Servers
  15. Backup DHCP Server
  16. DHCP MAC Address Filtering

Don’t Put DHCP on Your Domain Controller

The general recommendation is to not run any additional roles on your domain controller other than DNS. Your domain controller should be a domain controller/DNS and that is it. It is common for small organizations to install additional roles and 3rd party software on their domain controllers. It is recommended to avoid this if you can.

What is the issue?

Installing additional services on your DC increases the attack surface, makes it difficult to manage and can lead to performance issues.

Issue #1. Manage DC with multiple roles

Domain Controllers with multiple roles installed are difficult to manage. This can often lead to instability and disruption of services.

For example, say you are having issues with DHCP or installed a security patch that requires a reboot. Rebooting a server with Active Directory Domain Services role on it could cause major disruption to your organization. This can affect authentication, replication, group policy, and DNS. Your users will not be able to access anything if DNS is down.

If you have multiple domain controllers and it’s properly configured then these issues can be avoided but why risk it?

If DHCP was installed on its own server you could reboot the DCHP server with no worries of affecting the services on the Domain Controller.

Issue #2. Security

  1. The more software/services you install the bigger your attack surface. If DHCP is installed on the DC and a new vulnerability was discovered in the DHCP service your DC server is now at risk.
  2. Do you have guest wifi? How do you feel about these unmanaged devices being connected to your DHCP/DC server? I’m not a fan of using an internal DHCP server to provide IP addresses for the public. Then to add that these public devices are also connecting to the domain controller…. yikes my security alarms are going off.
  3. When DHCP is installed on a domain controller the DHCP service inherits the security permissions of the DC computer account. This violates the principle of least privilege. Now your DHCP server is running with privileges it doesn’t need to perform a task which it was designed for. Yes, this can be corrected but why add this risk.

Installing DHCP on its own member server will reduce the attack surface of your DC.

Issue #3. Performance

Generally, I’ve seen DHCP servers run very efficiently and not require a lot of system resources such as CPU or memory.

But…

Say you just learned about a new DHCP option such as conflict detection and you turn it on for all scopes.

Uh oh… Now the CPU usage skyrockets and the domain services are slow, users can’t log in and DNS requests are painfully slow.

Maybe you install an IPAM to keep tracking of available IP addresses and it takes up CPU and memory… again taking away resources from the domain services.

I could go on and on… point being the more software/services you install on your domain controller the more it can affect performance and lead to disruption in services.

Summary
Your domain controller is one of the most critical services in a Windows domain environment, it’s your baby and deserves its on server. A Domain Controller is a Domain Controller is a Domain Controller is a Domain Controller. Nothing else.

Use DHCP Failover

DHCP failover is a feature for ensuring the high availability of a DHCP server. With DHCP failover two DHCP servers share DHCP information so that if one goes down the other server can still provide DHCP leases to clients.

The DHCP failover option is built into the Windows server operating system. The picture below shows the setup of two DHCP servers configured with load balance failure mode. If one server fails the other server is still active and takes over all DCHP requests.

There are two failover design options:

Hot standby design

When using hot standby mode one server is the active server and the other is a standby. The active server is the primary server and handles all DHCP requests. If the active server goes down the standby server takes over the DHCP requests.

This option is commonly used with the standby unit being at a physically different location than the active.

Load balance design

In load balance mode both servers work in an active-active mode to handle DHCP requests. The requests are load balanced and shared among the two DHCP servers. If one of the servers loses contact with its failover partner it will begin granting leases to all DHCP clients.

Summary
You will need to determine which failover design is best for your environment. It’s a free built in option so take advantage of it and make your DHCP servers are fault tolerate.

Sources:

Central vs Distributed DHCP Server

Do you have a large network with branch offices at multiple locations?

The question is do you install a DHCP server at these branch offices or have them tunnel back to a centralized DHCP server?

Centralized DHCP Server

A centralized DHCP server is placed at a centralized location that the remote offices connect to for DHCP. This is typically located at one of the main data centers.  In this design there are no local DHCP servers, all requests go back to the centralized server.

Distributed DHCP Server

In a distributed DHCP model there are DHCP servers at the local branch office. In this model the clients get IP addresses from the local DHCP server.

So which option is best? 

This can be answered by one simple question?

Can the branch office work entirely by itself with no connection back to the data center? If yes then it makes sense for there to be a local DHCP and DNS server.

If the branch office tunnels back to the data center for the internet, Active Directory, DNS, and so on then there is no point in putting DHCP locally.

I work for a company that has offices throughout the state and I use a centralized DHCP model. We have reliable fast connections so it makes sense for us to use a centralized DHCP server.

One thing to consider is how many employees are at the branch office. If you have a very large branch office with thousands of employees then having local resources like Active Directory, DNS and DHCP can be helpful. That will be a lot of traffic going across the WAN link and if the link goes down it would take all those employees offline.

Summary
Choosing between centralized or distributed DHCP can often be answered with the following question “Can the branch office work with no connection back to the data center. Size of the remote office and connection speed back to the datacenter can also be a factor.

Sources:

Avoid static IP assignments and use DHCP reservations

Assigning static IP addresses to computers, printers, phones, or any other end user device is a pain.

Here is what happens when you statistically assign an IP address.

  1. Helpdesk replaces the device not aware of the static IP
  2. Now the device lost connection completely or partially
  3. Helpdesk sends tickets to network team to fix the issue
  4. The network team sends ticket back to helpdesk with the static IP
  5. Helpdesk now has to go to the device and assign the IP

I’ve been in the above situation plenty of times and like I said it’s a pain. To avoid all of this just use DHCP reservations instead of static IP assignments.

For anything that needs a fixed IP address, I use DHCP reservations. The one exception is infrastructure devices like routers and switches, those that get static IPs.

Screenshot of DHCP reservations for printers.

WIth DHCP reservations all you need to do is update the MAC address when devices are replaced and the IP is auto assigned back to the device. It also provides a quick view of everything that has been assigned an IP, instead of manually tracking everything in a spreadsheet.

Exclude IPs from the DHCP scope

When creating a DHCP scope I recommend excluding a small range for static IP assignments. Yes, I know in the previous tip I said don’t use static assignments but you will need it for infrastructure equipment.

Your networks will have a default route that will be a router so you definitely want that excluded from the DHCP pool. You may also run into other equipment that requires a static IP so it’s good to have a small range of IPs excluded from the DHCP pool for these devices. For example, I’ve seen various alarms and security devices that need a static IP so I just provide an IP from the exclusion range.

Here is a screenshot of a data VLAN used for workstations and laptops with the exclusion of 10.2.10.1 to 10.2.10.10.

Learn PowerShell DHCP Commands

There is nothing wrong with using the DHCP console (dhcpmgmt.ms) but PowerShell is awesome and simplifies many tasks. If you have a large network with hundreds of DHCP scopes then using PowerShell is a huge time saver.

Here are a few commands to get you started.

Install DHCP Role

Install-WindowsFeature -IncludeManagementTools DHCP

Backup DHCP Server

 Backup-DhcpServer -ComputerName "dhcp1.ad.activedirectorypro.com" -Path "C:\Windows\system32\dhcp\backup"

View DHCP leases

Get-DhcpServerv4Scope | Get-DhcpServerv4Lease

Find DHCP Lease from MAC Address

Get-DhcpServerv4Scope |Get-DhcpServerv4Lease |where {$_.ClientId -like “b4-b6-86-b4-**-**” }

Add DHCP Scope

Add-DHCPServerv4Scope -EndRange 10.2.1.254 -Name Vlan110 -StartRange 10.2.1.1 -SubnetMask 255.255.255.0 -State Active

Get all active ipv4 scopes

Get-DHCPServerv4Scope

Get all DHCP reservations for a scope

Get-DHCPServerv4Lease -ScopeId 10.2.1.0

Create a DHCP reservation

Get-DhcpServerv4Lease -ComputerName dhcpserver1 -IPAddress 10.2.1.8 | Add-DhcpServerv4Reservation -ComputerName server1

That is just scratching the server of managing DHCP with PowerShell. I’ve added a few links below to some additional resources for using Powershell.

Sources:

Subnetting and benefits of network segmentation

I’m not going to deep dive into subnetting because there are plenty of resources for that.

But… it helps to have some basic understanding of network when configuring DHCP scopes.

You don’t want to have just one big DHCP pool for all your devices, you should segment devices into separate networks. This also depends on the size of your network, if you have a small network then network segmentation is not as important.

Benefits of network segmentation

Security

By keeping devices on separate networks you have better control of the network. Do your printers need access to the internet? Probably not. Do computers in the finance department need to talk directly to computers in HR, absolutely NOT. By separating devices into their own network you have much better control of their access.

Limiting lateral movement in the network can really slow down attackers and viruses. It is important to enable firewalls or access control lists at the network level to limit lateral movement in your network.

Network performance

Putting everything on one big network will create a giant broadcast domain. This can lead to all sorts of issues, like spanning tree loops, broadcast and multicast storms. Segmenting your networks will break up the broadcast domains and reduce possible performance issues.

Control visitor/guest access

You don’t want your guest network to have access to your secure network. Separating this traffic to its own network allows you to filter this traffic and block access to your internal network.  I also use the guest network for IOT type devices that just need an internet connection.

Below is an example of how I segment network traffic.

  • Computers = 10.2.10.0/24 VLAN 110
  • Printers = 10.2.8.0/24 VLAN 108
  • Voice = 10.2.6.0/24 VLAN 106
  • Video Surveillance = 10.2.4.0/24 VLAN 104
  • Server = 10.2.2.0/24 = VLAN 102
  • Guest = 10.16.0.0/23 = VLAN 116

In addition to network segmentation try and keep your IP scheme simple, it really simplifies managing DHCP scopes.

DHCP Lease Duration Tips

A DHCP lease is the time period a DHCP server assigns an IP address to a client. The default DHCP lease time for DHCP scopes is 8 days.

Tip#1 increase lease time for fixed devices

For small networks, you can leave the lease time to the default setting of 8 hours.

For large networks, consider changing the DHCP scopes for fixed devices (workstations) to 16 days. This can reduce DHCP related network traffic. Workstations don’t move very often so they don’t need to go through the whole DHCP dance as often to obtain an IP address.

Tip#2 reduce the lease time for guest/mobile devices

If you provide guest wifi these DHCP scopes can become exhausted of available IPs very quickly. These devices most likely just need temporary access such as a few hours. For these scopes consider adjusting the DHCP lease time to 1 hour. If the device is still active it will renew but if the device disconnected it will free up an IP address. This should help with available IPs on your guest scopes.

This can also be the case with mobile devices, this one can be tricky though with more and more users having laptops. The default of 8 days may be sufficient but if you know of mobile devices that move around a lot you may consider reducing the lease time.

Summary
If you have DHCP scopes that serve specific devices such as workstations only then consider adjusting the DHCP lease times.

Use IP conflict detection only when it is needed

When two devices on the same LAN have the same IP address an IP address conflict occurs. This leads to one or both of the devices having issues communicating on the network.

The DHCP server has an option to help reduce IP conflicts. The conflict detection option on the DHCP server will first check if an IP is in use before assigning it to a device.

By default, this is disabled on all DHCP scopes.

Microsoft’s recommendation is to use this only when it is needed. DO NOT enable this for every scope. If you stay away from static IP assignments then you probably will never need to turn this on.

If you do turn this on set the detection attempts to 1 or 2.

Sources:

Run DHCP Best Practice Analyzer

Microsoft’s best practice analyzer is a tool that checks the DHCP configuration against Microsoft guidelines. The best practice analyzer is built into Windows Server and is available on the server management tool.

Steps to run the tool.

Step 1: Open Server Manager

Step 2: Click on DHCP

Step 3: Start a BPA scan

The results will display when the scan is complete

The BPA scanner should help discover any basic misconfigurations. Review your results and make any changes you feel are necessary for your environment.

Document IP addresses or us an IPAM

Document your IP scheme, VLANs, and static IP assignments.

For small networks, an excel spreadsheet may be sufficient.

For larger networks, I recommend an IP address management tool. For years I used an excel spreadsheet and as the network grew the spreadsheet became a nightmare. I eventually moved all the spreadsheets to SolarWinds IP Address Tracker and no longer worry about IP management. SolarWinds IPAM takes care of everything for me and best of all I can quickly search the entire database.

IPAM Benefits

  • Automatic IP address tracking
  • Can integrate with DHCP/DNS to track dhcp scope usage
  • Alerting and reporting of scope usage
  • Search IP addresses, comments, hostnames, etc. It is so nice being able to quickly search by a keyword to see what a device’s IP address it.

Download 30-Day Free Trial

Set DHCP Server Options

DHCP scope options allow you to auto configure additional TCP/IP settings on the client devices.

DHCP options can be configured at two different levels, at the server or per each DHCP scope.

I prefer at each scope, it’s more work but I may have scopes such as guest wifi that I don’t want using the internal DNS. Sometimes VOIP phones need special options to configure and I don’t want that at the server level.

The most common options used are:

003 Router

006 DNS servers

015 DNS Domain Name

Take advantage of the scope options so you can auto configure the IP settings on all devices.

DHCP Relay Agents

If you have a centralized DHCP server with multiple networks then you will need to use a DHCP relay agent.

DHCP messages are broadcasted and routers do not forward broadcast packets. To fix this issue you can enable the DHCP relay agent function on your router/switch to allow the DHCP broadcast packets to reach the device.

You will need to check with your router documentation for the commands to enable the relay agent.

Sources:

Prevent Rogue DHCP Servers

Have you ever had a user or someone in your own IT department plug a switch/router into an available port on the wall? Then the helpdesk phone starts blowing up because users can’t connect to the internet or other resources.

Rogue DHCP servers are a headache. In addition, they can be a security risk and used for various attacks.

The best way to block rogue DHCP servers is at the network switch. This can be done with an option called DHCP snooping or 802.1x port based network access.

DHCP Snooping

DHCP snooping is a layer 2 switch feature that blocks unauthorized (rogue) DHCP servers from dishing out IP addresses to devices.

DHCP works by categorizing switchports as either trusted or untrusted ports. A trusted port allows DHCP messages an untrusted port blocks DHCP messages.

You want your devices (computers, printers, phones) on an untrusted port so a rogue DHCP server cannot be plugged in.

802.1x port based network access

802.1x is an IEEE standard for port based network access control. It is a mechanism that can require devices to authenticate before providing them network access.

It’s not only good for rogue DHCP servers but for controlling network access to anything.

802.1x is typically configured at the switch level and requires a client and authentication server.

Backup DHCP Server

Your DHCP servers are critical to providing IP settings to your clients. In the event of a system crash you need to recover this server as soon as possible.

Did you know by default, Windows will back up the DHCP configuration every 60 minutes to this folder %SystemRoot%System32\DHCP\backup.

This is great but does you no good if the server crashes and you can’t access the folder.

If you don’t have any offsite replication in place then you would need to copy the backup folder to another location on a regular schedule.

This can be done with a script that copies the folder to another location or uses PowerShell to specify a remote location.

Backup-DhcpServer -ComputerName “DC01” -Path “C:\DHCPBackup”

You can read more on this in my article Backup and Restore Windows DHCP Server

DHCP MAC Address Filtering

The DHCP MAC address filtering feature allows you to block or allow IP address assignment based on MAC addresses.

This is useful if you want to have a DHCP scope provide IP addresses to an explicit list of devices. It’s also useful if you have unwanted devices on a VLAN getting an IP address.

For example, you have users putting BYOD devices on your secure VLAN. You could add these devices to the deny filter. The DHCP MAC filtering is a quick and simple way to control access to the network. If you have the time and resources the better option is to use 802.1x.

Conclusion

I’ve been using these tips for years when managing DHCP servers. When configured correctly DHCP can be a set and forget server with little or no issues. I hope you find these tips useful and please post any DHCP tips or best practices you have in the comments below.

20 thoughts on “Top 16 DHCP Best Practices: The Ultimate Guide”

  1. (God Forbid! The things a guy reads on Interwebz these days…)

    Yes. You should never install anything else in a DC. BUT DHCP IS NOT ONE OF THEM!

    All the examples in this article are pure nonsense. There are exactly ZERO gains in keeping a dedicated server for DHCP.

    1) A DHCP server causing CPU usage to skyrocket? Are you kidding me? DNS servers are queried THOUSANDS of times more than DHCP!

    2) If I needed a security patch for DHCP the same could be said for my DNS.

    3) Finally, rebooting a DC for security updates should not bring the hell on Earth upon your network. You DO have TWO or more of them, right? (a sensible recommendation from Microsoft).

    Each “problem” (patches, reboots, vulnerabilities) you cited about DHCP also applies to DNS.

    > How do you feel about these unmanaged devices being connected to your DHCP/DC server?

    This is so laughable to the point that you should actually learn about network security. For real.

    Reply
    • I quote Microsoft:

      For higher security and server hardening it is recommended not to install the DHCP Server role on domain controllers.

      Source: https://learn.microsoft.com/en-us/services-hub/unified/health/remediation-steps-ad/disable-or-remove-the-dhcp-server-service-installed-on-any-domain-controllers

      I understand small offices stuffing everything on one server but if you can its best to avoid this. All of the examples from the article are from real world experience.

      1. A DHCP server causing CPU usage to skyrocket. Yes, it was a known MS bug. The IP conflict detection had known issues but a client enabled this on their DHCP server and CPU usage went to 100%. It was a large environment with 10,000+ connected devices and the server was trying to do IP conflict so it brought the server to its knees. Thankfully, DHCP was on its own server and we could troubleshoot it, make changes, reboot and so on without effecting AD (such as rebooting or taking it offline).

      2. How do you feel about these unmanaged devices being connected to your DHCP/DC server? NO WAY would I want unmanaged devices sending broadcast message to my domain controllers and network. I always isolate public wifi and unmanaged devices into their own VLAN and block access to the secure network. Have a real security audit or pen test and this will get flagged (CJIS and PCI compliance has very strict requirements on network segmentation).

      3. You DO have TWO or more of them, right? Of course, AD is designed for fault tolerance and you should be able to do a rolling restart of your entire AD with zero downtime. This becomes difficult when you host other roles on the server. Having DHCP on two servers does not give you DHCP fault tolerance, it is not designed like AD.

      You could make an argument for everything I just said but it is well documented that the more stuff (roles, apps, services) you add to a server the greater the attack surface. Why take the risk?

      Reply
  2. Fantastic article! I am a technical trainer and this inspires some use-cases for my topics.

    Also, under the ‘don’t put your DHCP services on your DC’ section up top, in Issue #2, you state ‘The more software/services you install the bigger your attack survivance.’
    Did you mean ‘attack surface’? ‘Survivance’ is something else.

    Reply
  3. Thank you, thank you, thank you!!! I’ve been trying to find a well explained article on this and you have helped me out!

    Reply
  4. Excellent Article!

    On the subject of fixed IP addresses: do you prefer to exclude an IP address range or to allocate static addresses from outside the scope?

    For Example:

    Using scope 10.10.10.1-10.10.10.254 as follows:
    10.10.10.1 – 10.10.10.99 = DHCP allocated addresses (random)
    10.10.10.100 – 10.10.10.199 = DHCP allocated addresses (reserved)
    10.10.10.200 – 10.10.10.254 = Static/Fixed IP addresses

    Option 1:
    Address Scope: 10.10.10.1 – 10.10.10.254
    Excluded Range: 10.10.10.100 – 10.10.10.254 (covers fixed and reserved addresses)

    Option 2:
    Address Scope: 10.10.10.1 – 10.10.10.199
    Excluded Range: 10.10.10.100 – 10.10.10.199 (covers reserved addresses)
    The remaining addresses are assigned as fixed addresses

    I personally prefer Option 2, but am curious
    What are the pros and cons of each option and is there a preferred one?

    Thanks in advance

    Reply
  5. My thoughts exactly, very nice article.
    What is your recommendation for handling the random MAC address from mobile devices. Can DHCP Policies be used based on MAC address second nibble (x2, x6, xA, xE). it could work if there was a single character wild card indication,
    Something like “?[26AEae]:*” as a MAC policy to adjust the lease time to say 1 day.

    Thank You

    Reply
  6. Thanks for the article.

    What would you say is the best practice? Give a fixed or a (reserved) dhcp-address to an ADDS that is neither a DHCP or a DNS?

    It is indeed a pain if you have to go over all your devices to update the dns reference. And in the near future I’ll have to completely alter my addressing scheme.

    Thanks

    Reply
    • Fixed.

      You don’t want critical assets to depend on a DHCP server for an IP address. Something could go wrong with DHCP and give it a different IP or no IP.

      Reply
  7. Hi, does you know if another alternative exist for Solarwinds IPAM to manage IP, delegate DHCP roles, etc. ?

    We already test IPAM and we found it’s not very stable or so useful application than we would want.

    Reply
  8. Hi Robert,
    Thanks for putting this together. Very informative. I have a question regarding timestamps. Our ownership group wants us to write a script that captures the exact time that a dhcp address was issued to a client and then write that timestamp to a log. The previous requirement was just a monthly DHCP lease export which was easy to do, but now they want to know specifically when the address was issued. Thoughts? I appreciate any insight you may have.
    Thanks,
    Danny

    Reply

Leave a Reply to Ehsan Cancel reply