DHCP design

Design reference

Part V — DHCP in Windows Server and Active Directory: Government & Vendor Guidelines Design Reference (October 2026)

The defensible baseline for enterprise Windows DHCP is: run DHCP on dedicated, AD-authorized member servers (not domain controllers), make it highly available with a two- server DHCP failover relationship, have the DHCP server register DNS records with a dedicated low-privilege credential plus Name Protection rather than via the DnsUpdateProxy group, treat the DHCP Administrators group as a privileged tier, and put the actual anti-rogue/anti-spoofing load on the switch layer (DHCP snooping, Dynamic ARP Inspection, IP Source Guard, RA Guard/DHCPv6-Shield) and on log retention. No government body publishes a DHCP- specific standard; the IETF RFCs define the protocol, Microsoft defines the Windows implementation, DISA supplies the only hard numeric DHCP rule (log retention), and practitioner research (Akamai) supplies most of the AD-specific threat analysis.

1. TL;DR — design baseline

• Placement, HA and identity: Deploy Windows DHCP on dedicated domain-member servers authorized in AD (authorization requires Enterprise Admins or delegated rights on the NetServices container); avoid domain controllers, because a DHCP service on a DC inherits DC rights over AD-integrated DNS records and turns “DHCP Administrators” into a path to domain compromise. Use DHCP failover (load balance for co-located partners, hot standby for hub-and-spoke), which current Microsoft Learn documents as requiring Windows Server 2016 or later on both partners; keep split-scope (80/20) only for DHCPv6 or legacy cases.
• DNS integration: If the DHCP server must register DNS on clients’ behalf, configure one dedicated, non-privileged DNS-registration credential identical on all DHCP servers, enable Name Protection (DHCID, RFC 4701), keep zones “secure only”, and keep DnsUpdateProxy empty; if DHCP-driven registration is not needed, Akamai’s research recommends disabling it outright.
• Security and evidence: Message-level DHCP authentication (RFC 3118) is effectively unused, so rogue-server and spoofing protection belongs to the switch and hypervisor (DHCP snooping, DAI, IP Source Guard, Hyper-V DHCP Guard/Router Guard, RA Guard/DHCPv6-Shield); log hostname, MAC, IP and time, and retain DHCP logs 30 days online and 1 year offline — DISA Network Infrastructure Policy STIG V10R7 (2 Aug 2024), rule V-251361 / NET0198 (medium severity), whose fix text reads “Store the logs for a minimum of thirty days online and then offline for one year” — far beyond Windows’ default seven-day rolling audit files.

2. Authoritative design-source overview

Date /

Scope summaries in brief. IETF (1–9) define protocol behavior: RFC 2131 the lease state machine and the client/server/relay model; RFC 2132 the option codes (3 router, 6 DNS servers, 15 domain name, 42 NTP servers, 51 lease time, 66/67 TFTP server/bootfile); RFC 3046 relay- inserted Option 82 for location-aware policy and spoofing defense; RFC 3118 an authentication option that is defined but practically unused; RFC 4701–4703 the DHCID record and the client FQDN option that govern who updates A/PTR records; RFC 9915 is now the DHCPv6 base specification. Microsoft (10–11) is the only authority for Windows implementation behavior. NIST (12–14) has no DHCP-specific Special Publication; SP 800-81r3 addresses dynamic- update misuse and recommends correlating DNS logs with DHCP lease data; SP 800-53 supplies control language; SP 800-189 is inter-domain routing context only. NSA/CISA (15–16) provide network-device hardening and AD-compromise guidance; the AD guide does not, in the September 2024 text, address DHCP directly. DISA (17–18) gives the only numeric DHCP requirement (logging content and retention) and switch-level snooping rules; there is no standalone DISA “Windows DHCP Server” STIG. CIS (19–20) contributes an asset-inventory safeguard that names DHCP logging; benchmarks harden the host OS but contain no located DHCP-role or DnsUpdateProxy recommendation. Akamai (21) is the principal public analysis of AD-specific DHCP attack paths; it is vendor research, not guidance from a standards or government body.

3. Design areas

3.1 Server placement and authorization design

Decision at stake. Where the DHCP Server role runs, how many servers exist, and how AD controls which servers may answer clients.

Realistic options. (a) Dedicated domain-member DHCP servers; (b) DHCP co-located on domain controllers; (c) DHCP co-located with DNS on non-DC infrastructure servers; (d) network-appliance or router DHCP outside AD’s authorization model; (e) workgroup (non- domain) Windows DHCP.

What the authorities say.

• Microsoft lists “DHCP server authorization” as a core feature that “allows you to authorize DHCP servers in Active Directory, preventing unauthorized servers from providing IP addresses to clients.” Authorization is stored in the forest configuration partition (CN=NetServices,CN=Services,CN=Configuration), so by default only Enterprise Admins can authorize, though the right can be delegated on that container. An unauthorized domain-member Windows DHCP server does not lease addresses; workgroup servers do not need authorization. Members of DHCP Administrators cannot authorize or unauthorize servers because their rights are local.
• Microsoft (Dynamic update page) states that when installed on a domain controller, the DHCP Server service “inherits the security permissions of the domain controller”, giving it authority to update or delete any record in a secure AD-integrated zone, and instructs that on a DC the DHCP server be configured with a dedicated user account’s credentials so it does not inherit and possibly misuse DC privileges.
• Akamai (practitioner) reports in its 20 March 2024 blog that Microsoft DHCP server “was observed running in 40% of the networks monitored by Akamai,” and that “among the networks that we observed using Microsoft DHCP server, 57% have a DHCP server installed on a DC.” Its research shows that when DHCP runs on a DC, members of DHCP Administrators can reach domain-admin privileges; its mitigation is to identify DHCP on DCs with Invoke-DHCPCheckup and “if possible, disable the DHCP server service on all DCs.”
• NIST SP 800-81r3 (a DNS document) recommends dedicated DNS infrastructure but describes combining DNS with closely related services such as DHCP as acceptable where full separation is impractical — this addresses DNS/DHCP co-location, not DC co-location.
• DISA/CIS: no DHCP-placement rule was located; host hardening for any DHCP server comes from the applicable Windows Server STIG and CIS benchmark.

How many servers. Microsoft’s failover model is strictly pairwise (a relationship is always between two servers, though one server may hold many relationships), which drives the common pattern of two servers per site or a regional pair plus hub standby. No authority reviewed sets a numeric count; capacity, WAN topology and relay design decide it.

Trade-offs. DC co-location saves a server and was historically common in branches, but it couples a broadcast-facing, unauthenticated service to Tier 0 and enlarges the blast radius of DHCP Administrators membership. Dedicated servers cost licences and patching effort but keep DHCP compromise out of Tier 0. AD authorization only governs Windows DHCP servers; a rogue Linux box, router or VM ignores it.

Conflicts. Practice (57% on DCs per Akamai) diverges sharply from current Microsoft and Akamai guidance; Microsoft’s own legacy step-by-step guides used a DC as a DHCP failover partner in examples, while current Microsoft text warns about DC co-location.

3.2 High-availability design

Decision at stake. How DHCP service survives a server or link failure without duplicate addressing.

Realistic options. (a) DHCP failover, load-balance mode; (b) DHCP failover, hot-standby mode; (c) split-scope (classically 80/20) across two independent servers; (d) Windows Failover Clustering of the DHCP role (shared storage); (e) single standalone server with backup/restore.

What the authorities say (Microsoft).

• Failover model: Failover “replicates IP address leases and settings” for DHCPv4 scopes from a primary to a partner; both servers hold the whole scope and maintain separate synchronized lease databases — scopes are replicated, not pre-split. Microsoft’s implementation is based on the IETF DHCP Failover Protocol draft (draft- ietf-dhc-failover-12), not on a published RFC; load balancing uses the RFC 3074 MAC-hash bucket mechanism. Partners keep a persistent TCP connection on port 647.
• Minimum version: The current Microsoft Learn failover overview (WS2016–WS2025 and Azure Local) states partners “must both be running at least Windows Server 2016.” Legacy Microsoft pages for WS2012/2012 R2 say Windows Server 2012 or later, because the feature was introduced in Windows Server 2012. (Consistent once read as “introduced in 2012; currently documented support floor is 2016.”)
• Modes: Load balance is the default (50:50, adjustable 0–100%) and “best suited” to partners at the same site; hot standby (default 5% reserve for the standby) suits a central standby backing remote-site servers. Only one mode per relationship/scope; a server may hold relationships in both modes.
• MCLT and state switchover: The Maximum Client Lead Time is the maximum time one server can extend a lease beyond what its partner knows; a partner that cannot reach its peer renews existing clients only for MCLT and takes over the full pool only after entering PARTNER DOWN and waiting MCLT. The state switchover interval (automatic transition from COMMUNICATION INTERRUPTED to PARTNER DOWN) is optional; without it an administrator must declare partner down manually. Microsoft cmdlet examples use MCLT of 2 hours and a 2-hour auto-switchover.
• Shared secret: Optional message authentication between partners; when used with a clustered partner it must be manually replicated to every cluster node.
• Operational rules: Changes to failover scopes must be manually replicated (replication overwrites the partner); replicate from the newer-OS partner; clocks must agree within one minute or the wizard halts; both partners must use the same DNS registration credential.
• Split-scope: Microsoft retains split-scope as the HA answer for DHCPv6 (failover supports DHCPv4 only) and describes it as viable because DHCPv6 scopes rarely run at high utilization; the 80/20 split-scope wizard dates from Windows Server 2008 R2 SP1-era tooling.
• Clustering: Supported and can be combined with failover (a cluster counts as one failover partner, addressed by cluster name/IP).

Trade-offs. Failover gives full-scope availability with lease-state sharing, but adds a replication discipline and a time-sync dependency (cross-reference the NTP design reference). Split-scope needs no inter-server protocol but strands addresses (the 20% server can exhaust) and has no shared lease state. Clustering protects against node failure but not storage or site failure and adds cluster complexity. A long MCLT reduces duplicate-address risk during partitions but delays full-pool takeover; a short one does the reverse.

Conflicts. None between authorities; the main documented “conflict” is the version floor (2012 vs 2016) across Microsoft’s own legacy and current pages.

3.3 Scope and address-plan design

Decision at stake. How subnets map to scopes, which addresses are excluded or reserved, lease duration, option placement, and how to handle multinets and multicast.

Realistic options and Microsoft guidance.

• One scope per subnet/VLAN, served via relay agents (ip helper) for remote subnets; exclusion ranges for statically addressed infrastructure; reservations (MAC/client-ID bound) for devices needing stable addresses while still receiving centrally managed options.
• Superscopes group multiple scopes for a single physical segment carrying multiple logical subnets (multinet), or during renumbering.
• Multicast scopes (MADCAP) allocate multicast group addresses to MADCAP-aware applications; rarely used in modern enterprises.
• Option inheritance: Server-level options apply to all scopes; scope options override server options; policy/class-based options override scope options for matching clients; reservation options are most specific and win.
• Lease duration: Windows defaults to 8 days for new IPv4 scopes. Shorter leases suit high-churn segments (guest Wi-Fi, conference areas) and shrink stale-record windows but raise renew traffic and dependency on server availability; longer leases suit stable wired desktops and survive longer outages. In failover, renewals during a partition are capped at MCLT regardless of scope lease time.
• DISA: V- 251362 requires DHCP servers within SIPRNet infrastructure to use a minimum lease duration of 30 days, to support traceability — a classified-network-specific rule, not general guidance.

Trade-offs. Many small scopes improve segmentation and Option 82/policy precision but multiply administration; large flat scopes ease management but enlarge broadcast and spoofing domains. Short leases interact with DNS: the dynamic-update page notes DHCP-registered records use a 15-minute TTL by default and that stale A/PTR records require aging/scavenging (cross-reference the DNS design reference).

Conflicts. DISA’s 30-day SIPRNet floor favors attribution; general Microsoft and practitioner guidance favors shorter leases for mobile segments. These are context-dependent, not contradictory.

3.4 DHCP options design

Decision at stake. Which configuration DHCP pushes, at what level, and to which client groups.

Core options (RFC 2132 numbering). 003 Router; 006 DNS Servers (internal AD-integrated resolvers for domain clients); 015 DNS Domain Name; 042 NTP Servers (cross-reference the NTP design reference — domain-joined Windows clients normally use the AD domain hierarchy, not option 42); 051 lease time; 066/067 Boot Server Host Name / Bootfile Name for PXE (with modern PXE/WDS/ConfigMgr designs often using IP helpers or policies keyed on vendor class instead of global 066/067); 252 WPAD (proxy auto-discovery; a site-local private- use code, not an IANA standard option); Option 81 client FQDN (RFC 4702) governs DNS registration (§3.5); Option 82 relay agent information (RFC 3046) carries circuit/remote IDs.

Policies and classes (Microsoft). DHCP policies (Windows Server 2012 and later) let administrators group clients by vendor class, user class, client identifier, MAC address, relay agent information or FQDN and assign IP ranges and options per group; failover replicates policies with scopes. User classes (client-set, e.g., via ipconfig /setclassid) and vendor classes (e.g., “MSFT 5.0”, PXE client identifiers) remain the classic conditional-delivery mechanisms.

Trade-offs. Server-level options minimize duplication but propagate mistakes everywhere; policy-based options give precision at the cost of debugging complexity. Policies keyed on MAC or vendor class are spoofable by the client, so they are configuration conveniences, not security boundaries. Option 252/WPAD and 066/067 are attractive attack targets; Akamai’s escalation research shows that whoever can change options (e.g., the DNS Servers option) can redirect or coerce clients and the server, so option-change rights are security-relevant.

Conflicts. None between authorities; the risk is under-appreciating that option authority equals traffic-steering authority.

3.5 DHCP–DNS dynamic update integration design

Decision at stake. Who registers and owns A and PTR records for DHCP clients, with what credential, and how ownership is protected.

Realistic options. (1) Client registers A, server registers PTR (Windows default, Option 81 flag 0). (2) Server always registers A and PTR (“Always dynamically update DNS records”, flag 3), including for non-Windows/legacy clients. (3) Server registers using its machine account (default when no credential configured). (4) Server registers using a dedicated DNS- registration user credential (DHCP > IPv4 > Advanced > Credentials, or Set- DhcpServerDnsCredential). (5) DnsUpdateProxy membership (records created unsecured so another server or the client can later take ownership). (6) Name Protection (DHCID-based, introduced in Windows Server 2008 R2). (7) Disable DHCP-driven DNS updates entirely.

What the authorities say.

• Microsoft (Dynamic update): Members of DnsUpdateProxy register names unsecured, so “the first user to modify the set of records associated with a DNS name becomes its owner”; Microsoft says not to use the group in secure-only AD-integrated zones “without taking additional steps.” It recommends a dedicated standard user account whose credentials multiple DHCP servers can share, and states it must be used when DHCP runs on a DC. It warns that if the credential belongs to a DnsUpdateProxy member, the next registrant becomes owner, and that the DNS credential is not backed up with the DHCP database and must be re-entered after restore. It also advises ipconfig /renew, not ipconfig /registerdns, for DHCP-managed Windows clients, because the latter can reset ownership so the DHCP server can no longer update the record.
• Microsoft (Failover): Both failover partners must use the same DNS credential or updates by the surviving partner fail.
• Microsoft (Name Protection): With Name Protection, the server writes a DHCID record and checks it before updating, preventing name squatting by other clients; settings for “discard A and PTR records when lease is deleted” and “dynamically update for clients that do not request updates” sit on the same DNS tab.
• IETF RFC 4701/4703: Define the DHCID RR and the conflict-resolution procedure that Name Protection implements.
• Akamai (practitioner, December 2023): Demonstrated unauthenticated DNS spoofing via DHCP DNS dynamic updates in the default configuration, including overwriting arbitrary records when DHCP runs on a DC (ENTERPRISE DOMAIN CONTROLLERS has write permission on every record in the zone). Microsoft told Akamai a fix is not planned. Mitigations: disable DHCP DNS dynamic updates if not needed; do not use DnsUpdateProxy; use the same weak (non-privileged) DNS credential on all DHCP servers; enable Name Protection (not enabled by default on new scopes); avoid DHCP on DCs. Akamai also notes Name Protection can be partially bypassed (e.g., spoofed DHCP Release) and that the Windows DHCID value is brute-forceable — it raises cost, not certainty.
• NIST SP 800-81r3: Treats dynamic-update misuse as a DNS threat, recommends restricting dynamic updates to authorized sources, and recommends correlating DNS query logs with DHCP lease history for incident response.
• CISA/NSA: No DHCP-dynamic- update-specific guidance was located in the reviewed AD-compromise guide text (see Caveats).

Trade-offs. DnsUpdateProxy is convenient — any DHCP server or upgraded client can take over records — but leaves records unsecured. A dedicated credential gives clean ownership but becomes a sensitive secret shared across servers and is lost on restore. Server-always-updates gives consistent records for non-Windows devices but means the DHCP server will register names asserted by unauthenticated clients. Disabling DHCP updates removes the attack path but leaves non-Windows devices unregistered.

Conflicts. Older community guidance (widely circulated, including Microsoft-hosted TechNet wiki/forum posts) recommends both DnsUpdateProxy membership and credentials; current Microsoft Learn and Akamai recommend credentials without DnsUpdateProxy.

3.6 Security and hardening design

Decision at stake. How to prevent rogue servers, spoofed clients, and privilege escalation through DHCP administration.

Controls and authorities.

• AD authorization as anti-rogue control (Microsoft): Only stops rogue Windows domain-member DHCP servers; it is not a network control.
• DHCP Administrators vs DHCP Users (Microsoft): DHCP Users have read-only console access; DHCP Administrators can change any DHCP setting, including export/import of configuration and database, but only on the local server and cannot authorize servers. Groups are created at role install (or with Add-DhcpServerSecurityGroup / netsh dhcp add securitygroups); on a DC they are domain-local groups.
• DHCP Administrators → Domain Admins (Akamai, March 2024): DHCP Administrators can abuse legitimate features (option configuration, DNS Server option plus a coercion scope, relay-agent option) to coerce the DHCP server’s machine account into authenticating to an attacker and relay it (e.g., Kerberos relay to AD CS web enrollment). On a DC this yields domain compromise; the same configuration can serve as stealthy persistence that requires no credentials once set up. Mitigations: treat DHCP Administrators as a high-value group and monitor it; disable DHCP on DCs; harden AD CS against relay (EPA/HTTPS, disable NTLM where possible); block RPC to DHCP servers from non-admin endpoints; block DHCP traffic to/from the internet; watch for DNS anomalies.
• Layer-2 controls (NSA Network Infrastructure Security Guide; DISA switch STIGs): DHCP snooping (trusted uplink ports only; rate-limit on access ports), Dynamic ARP Inspection validated against the snooping binding table, IP Source Guard, port security, and 802.1X/NAC. DISA’s Cisco L2 switch STIG requires DHCP snooping on all user VLANs to validate DHCP messages from untrusted sources. These are switch features, not DHCP-server features.
• Hypervisor controls (Microsoft): Hyper-V DHCP Guard drops DHCP server messages from VMs not authorized to act as DHCP servers; Router Guard drops router advertisements and redirects. Both are off by default because of a small performance cost.
• Option 82 / SAVI context (IETF): RFC 3046 lets relays tag requests with circuit IDs for policy and anti-spoofing; RFC 7513/7039 frame source-address validation that DHCP snooping/IP Source Guard implement; NIST SP 800-189 applies the same source-address-validation principle at inter-domain layer 3.
• MAC filtering (Microsoft allow/deny lists): Useful hygiene, weak security, because MACs are trivially spoofed.
• RFC 3118 authentication: Defined but essentially unimplemented in mainstream clients and servers, including Windows; RFC 9915 retains only Reconfigure-key authentication for DHCPv6. Message authentication is therefore not a practical design control.
• NIST SP 800-53 Rev. 5: CM-6 (configuration settings) and CM- 7 (least functionality — disable unneeded roles such as DHCP on DCs), AC-6 (least privilege for DHCP Administrators), SC-7 (boundary protection — block DHCP/RPC exposure), SI-4 (monitoring).
• CIS Controls v8.1: Network-infrastructure and access-control safeguards (e.g., 12.x secure network infrastructure; 13.9 port-level access control) support snooping/802.1X.

Trade-offs. Snooping/DAI/IPSG are the most effective controls but require consistent switch configuration, static-binding exceptions for statically addressed hosts, and trusted-port discipline; misconfiguration causes outages. Tightening DHCP Administrators membership reduces escalation risk but may require new delegation workflows.

Conflicts. None in substance; the gap is that no authority reviewed publishes a Windows-DHCP- server hardening baseline, so the server side is covered by generic host baselines plus vendor research.

3.7 DHCPv6 and dual-stack design

Decision at stake. Whether hosts get IPv6 addresses via SLAAC, stateless DHCPv6 (options only) or stateful DHCPv6, and how rogue RAs and rogue DHCPv6 servers are blocked.

Options and authorities.

• IETF RFC 9915 is the current DHCPv6 base specification, obsoleting RFC 8415; it applies verified errata and obsoletes temporary-address assignment (IA_TA) and the Server Unicast option. DHCPv6 can operate “in place of or in addition to” SLAAC. Router Advertisement M (Managed) and O (Other configuration) flags signal stateful vs stateless DHCPv6 to hosts.
• Identity: DHCPv6 identifies clients by DUID, not MAC; RFC 6939 lets relays supply the client link-layer address so MAC-based reservations, logging and correlation remain possible.
• Option differences: DHCPv6 has no default-gateway option (gateways come from RAs); DNS servers and search lists are DHCPv6 options; option codes differ from DHCPv4.
• Microsoft: Windows DHCP supports stateful and stateless DHCPv6 scopes, but DHCP failover does not support DHCPv6; Microsoft recommends identical option configuration on two servers for stateless HA and split-scope for stateful HA. Audit logs for IPv6 are written separately (DhcpV6SrvLog-.log).
• First-hop protection: RFC 7610 DHCPv6-Shield blocks DHCPv6 server messages on untrusted switch ports; RA Guard blocks rogue RAs; Hyper-V Router Guard drops ICMPv6 type 134 RAs from VMs.

Trade-offs. SLAAC is simplest but weakens address-to-host attribution; stateful DHCPv6 improves attribution and DNS registration control but lacks Windows failover. Dual-stack doubles the rogue-server surface: an attacker answering DHCPv6 or sending RAs can capture DNS on IPv4-oriented networks, so IPv6 first-hop controls matter even where IPv6 is “not used.”

Conflicts. None between authorities; the main currency risk is citing RFC 8415 instead of RFC 9915.

3.8 Logging, monitoring, and database design

Decision at stake. What DHCP evidence is kept, for how long, how capacity is monitored, and how the DHCP database is protected and migrated.

Microsoft behavior.

• Audit log: Enabled by default on modern Windows Server; written to %SystemRoot%as DhcpSrvLog-.log (IPv4) and DhcpV6SrvLog-.log (IPv6); each weekday’s file is overwritten the following week, so native retention is about seven days. Configure with Get-/Set-DhcpServerAuditLog (path, MaxMBFileSize, DiskCheckInterval, MinMBDiskSpace); logging pauses when disk space falls below the minimum. Event channels (DHCP-Server operational/admin, failover events) supplement text logs.
• Conflict detection: Server-side ping before offering (attempts 0–5, default 0), useful when importing scopes or after failures, at a small latency cost.
• Database: ESE/JET database (dhcp.mdb) with automatic backups (default every 60 minutes to the dhcpfolder); Backup- DhcpServer/Restore-DhcpServer for database backups; Export- DhcpServer/Import-DhcpServer (XML, optionally with leases) for migration and consolidation; netsh dhcp server export/import remains for legacy. DNS registration credentials are not included in backups.
• Monitoring: Scope statistics (Get- DhcpServerv4ScopeStatistics), failover state events, and performance counters support utilization alerting.

Authority requirements.

• DISA Network Infrastructure Policy STIG V10R7 (2 Aug 2024), V-251361 (NET0198, SV-251361r853649_rule, CAT II/medium, CCI-001902): DHCP audit and event logs must record hostname and MAC address in addition to IP and date/time; the fix text reads “Store the logs for a minimum of thirty days online and then offline for one year.” (The same STIG’s V-251374 imposes the same retention on syslog.)
• NIST SP 800-53 AU- 8: Time stamps mapped to UTC from an authoritative source — directly relevant because failover also requires partner clocks within one minute; AU-11 audit retention; AU-6 review.
• NIST SP 800-81r3: Correlate DNS logs with DHCP lease history in the SIEM.
• CIS Controls v8.1 Safeguard 1.4: “Use DHCP logging on all DHCP servers or Internet Protocol (IP) address management tools to update the enterprise’s asset inventory,” reviewing logs “weekly, or more frequently”; Control 8 covers collecting, centralizing and retaining audit logs.

Trade-offs. Forwarding audit logs to a SIEM satisfies retention and correlation but adds pipeline dependencies; relying on local files violates DISA retention by design. Larger MaxMBFileSize avoids silent pauses but consumes disk. Export-based migration is fast but must be followed by credential re-entry and failover re-establishment.

Conflicts. None; Windows defaults simply fall far short of the DISA requirement.

4. Where authorities agree, differ, or conflict

• Failover vs split-scope. Agreement: Microsoft positions failover as the default DHCPv4 HA mechanism and split-scope as the DHCPv6/legacy fallback. Difference: Microsoft’s own pages state different version floors (2012 legacy vs 2016 current). No government authority expresses a preference.
• DHCP on a domain controller. Strong agreement among Microsoft’s current dynamic- update guidance and Akamai’s research that DC co-location is risky; Akamai recommends disabling it outright; Microsoft prescribes a dedicated credential if it must occur. Conflict with practice: Akamai observed a DHCP server on a DC in 57% of the networks it saw using Microsoft DHCP. NIST SP 800-81r3 accepts DNS+DHCP co- location, which is a different question.
• DnsUpdateProxy: convenience vs risk. Microsoft documents the group’s purpose (record takeover across servers/clients) and its risk (unsecured records); Akamai says not to use it. Older community and archived Microsoft-hosted guidance recommending “DnsUpdateProxy plus credentials” conflicts with current guidance.
• Short vs long leases. Context-driven: DISA mandates ≥30 days on SIPRNet for traceability; Microsoft defaults to 8 days; practitioner norms favor hours for guest/wireless. No authority sets a general enterprise value.
• Is message-level DHCP authentication practical? Effectively all sources agree it is not: RFC 3118 is defined but unused, Windows does not implement it, and RFC 9915 keeps only Reconfigure-key authentication. Security therefore shifts to layer 2 and to AD authorization.
• No government DHCP standard. NIST has no DHCP SP; DISA has no Windows DHCP STIG; CIS has no located DHCP/DnsUpdateProxy benchmark item. The security load is carried by switch controls (NSA guide, DISA switch STIGs), generic controls (SP 800-53, CIS Controls), one DISA logging rule, Microsoft documentation and Akamai research.
• Disable DHCP DNS updates vs secure them. Akamai favors disabling where not required; Microsoft documents secure use (credential plus Name Protection). Both are defensible; the choice depends on whether non-Windows devices need DHCP-registered names.

5. Caveats and items that could not be verified

• CISA/NSA “Detecting and Mitigating Active Directory Compromises” DHCP content. The September 2024 text reviewed (through Appendix B, about page 58) contains no DHCP, DnsUpdateProxy, dynamic-update or DHCP Administrators content; “coerce” appears only regarding the Print Spooler on DCs. The request’s premise that this guide covers the DHCP-coerce escalation and DHCP DNS spoofing could not be confirmed; those attack paths are documented by Akamai, not by this guide. The guide is ASD-led and co-sealed by non-US agencies; it is included only for its CISA/NSA co- authorship. NSA lists a September 2026 update that could not be reviewed; it may or may not add DHCP content.
• Akamai dates and figures. The DDSpoof research is dated 7 December 2023 (confirmed). The DHCP Administrators escalation blog is dated 20 March 2024, not February 2024. The 40% figure is “networks monitored by Akamai.” The 57% figure’s denominator is stated in Akamai’s 20 March 2024 blog: “among the networks that we observed using Microsoft DHCP server, 57% have a DHCP server installed on a DC” — press restatements as 57% of all monitored networks are inaccurate.
• NSA Network Infrastructure Security Guide wording. Version 1.2 (October 2023) was confirmed, but the PDF could not be retrieved (bot-blocked), so its exact layer-2 recommendations (DHCP snooping, DAI, IP Source Guard) are not quoted here and should be checked against the document.
• DISA currency. The latest Network Infrastructure Policy STIG located is V10R7 (2 Aug 2024), from third-party mirrors; cyber.mil was not checked directly, so a newer release cannot be excluded. No Windows Server STIG rule specific to DHCP or DnsUpdateProxy membership was located.
• CIS Benchmarks. No DnsUpdateProxy or DHCP-role recommendation was located in CIS Windows Server benchmarks (2022 v4.0.0–v5.1.0; 2025 v1.0.0–v2.1.0); the only DHCP mention found is profile applicability. Full-text verification of current releases was not possible.
• NIST SP 800-189 revision status, Windows default values (8-day lease, 60-minute database backup, conflict-detection default 0) and the WS2016 “What’s New in DHCP” contents are stated from Microsoft/IETF/NIST documentation knowledge and were not all re-fetched for this edition; RFC 9915 (January 2026, STD 102) and CIS Controls v8.1 Safeguard 1.4 wording were verified.
• Microsoft licence terms. Microsoft Learn content is copyrighted under Microsoft’s terms of use; the open-source docs repositories carry CC BY 4.0 (text) and MIT (code), but reuse should follow the specific repository’s licence file.
• Neutrality. This reference is environment-agnostic; values such as MCLT, lease duration and failover mode must be set from local topology, client mix and compliance regime.

Annotated source catalog

DHCP for Windows/Enterprise Environments: Verified Reference Collection (as of October 2026)

There is no dedicated government DHCP security standard. The baseline for Windows DHCP is made up of Microsoft’s product documentation, the IETF protocol RFCs, scattered rules in DISA STIGs and one CIS Controls safeguard, with Akamai’s practitioner research filling the security gap. Several items in the prior pass need correcting, notably the failover OS minimum, which mode the reserve percentage belongs to, and the current DHCPv6 RFC.

TL;DR

• No government DHCP baseline exists; the guidance is operational, not prescriptive. NIST has no DHCP Special Publication, CISA/NSA have nothing DHCP-specific, and DISA has no stand-alone DHCP STIG. DHCP shows up only indirectly: in NIST SP 800-81r3 (DNS, March 2026), the DISA Network Infrastructure Policy STIG (DHCP log retention), DISA Layer 2 switch STIGs (DHCP snooping), and CIS Controls v8.1 Safeguard 1.4 (DHCP logging for asset inventory). Microsoft Learn and the IETF RFCs are therefore the primary technical sources.
• Microsoft’s operational model is confirmed, with corrections. Microsoft calls DHCP Failover “the preferred option,” with two modes: load balance (the default, 50:50) and hot standby. The default 5% reserve percentage belongs to hot standby, not load balance. The shared secret is optional. The current Learn page requires both partners to run at least Windows Server 2016 (the feature first shipped in Server 2012). Microsoft also confirms the BPA statement “Name protection requires secure update to work. Without name protection DNS names may be hijacked.”
• The main security risk is in DHCP-to-DNS integration, and the vendor won’t patch it. Akamai (non-governmental research) found that DHCP DNS Dynamic Updates “don’t require any credentials, and work with the default configuration” and that Microsoft does not plan a fix. A follow-on post showed DHCP Administrators can reach domain admin when DHCP runs on a domain controller. Logging is the one control that every source agrees on.

Guidance landscape overview

Section A — Microsoft official guidance by topic

A1. DHCP Server role and training

• Title: Deploy and manage DHCP (training module). Publisher: Microsoft Learn. URL: https://learn.microsoft.com/en-us/training/modules/deploy-manage-dynamic-host- configuration-protocol/ . Status: current; free.
• Scope: the DORA lease process, role installation “including server authorization in AD DS,” options at server/scope/reservation level, scopes with “address ranges, exclusions, and reservations,” HA choices and failover. Units include “Configure DHCP options,” “Configure DHCP scopes,” “Select DHCP high availability options,” and “Implement DHCP Failover.”
• Parent learning path: “Implement and manage an on-premises and hybrid networking infrastructure” (https://learn.microsoft.com/en-us/training/paths/implement-manage-premises- hybrid-networking-infrastructure/). It also uses IPAM “to centrally manage your DNS and DHCP infrastructure.”
• Not re-verified: the standalone DHCP role overview URL (historically under /windows-server/networking/technologies/dhcp/) was not fetched this pass; treat the URL as unconfirmed.

A2. High availability (failover, clustering, split scope)

• Training unit “Select DHCP high availability options.” URL: https://learn.microsoft.com/en-us/training/modules/deploy-manage-dynamic-host- configuration-protocol/6-select-dynamic-host-configuration-protocol-high-availability- options (ms.date 2024-04-15).
  • It lists three options: DHCP Failover, the DHCP role in a Windows Server failover cluster (config on shared storage), and split scopes.
  • It states: “DHCP Failover is the preferred option for highly available DHCP service,” and calls it “the only high availability method in which the DHCP servers actively coordinate.”
  • Split scope: each server holds part of the range, and the secondary uses the scope Delay configuration attribute so the primary answers first.
• “DHCP failover overview.” URL: https://learn.microsoft.com/en-us/windows- server/networking/technologies/dhcp/dhcp-failover (ms.date 2025-03-11). Verified points:
  • Two modes. Hot standby: an active/standby pair. The reserve percentage applies here, defaulting to “5%”; after MCLT expires, the standby may use the whole pool. Load balance: “the default mode,” with both servers serving clients and a default “50:50” ratio, using the RFC 3074 MAC-hash buckets.
  • IPv4 only; “DHCPv6 scopes can’t be failover-enabled.” For DHCPv6 HA, Microsoft recommends identical stateless option configuration or split scope.
  • “DHCP failover partners must both be running at least Windows Server 2016.” Correction: the prior pass said “Server 2012+”. Failover was introduced in Server 2012 (legacy page dn338983), but the current page sets a 2016 minimum.
  • Correction on “matching scopes”: Microsoft says scopes are replicated from the primary to the partner when failover is configured, and later changes “must be manually replicated.” The partner doesn’t need pre-built matching scopes.
  • The shared secret is optional (message authentication). Failover uses TCP 647. Server clocks must be within one minute of each other. Both partners must use the same DNS dynamic-update credentials. Clustered DHCP can be a failover partner, provided you reference it by cluster name/IP.
  • Microsoft’s failover is based on the IETF failover draft (draft-ietf-dhc-failover- 12), which never became an RFC.
• Training unit “Implement DHCP Failover.” It confirms MCLT (“how long a DHCP server should wait when a partner is unavailable before it assumes control”), the 5% hot-standby default, the shared secret and TCP 647.

A3. Scopes, options, reservations, exclusions

• The training module explicitly covers scopes, exclusions, reservations and server/scope/reservation-level options for “DNS servers, default gateways.”
• The option code numbers (003 Router, 006 DNS Servers, 015 DNS Domain Name) come from RFC 2132. I didn’t re-fetch them from a Microsoft page this pass; they are consistent with RFC 2132 but not re-verified here.

A4. AD authorization (rogue Windows DHCP control)

• [MS-DHCPE] §7.1, “Windows DHCP Server Authorization in Domain Joined Scenario.”
  • A domain-joined DHCP server “is authorized by a domain administrator in Active Directory Domain Services.”
  • Any domain-joined server that needs to serve clients must have an AD object.
  • The server “validates its authorization in AD DS every hour” over LDAP.
• “Troubleshoot problems on the DHCP server” (https://learn.microsoft.com/en- us/windows-server/troubleshoot/troubleshoot-problems-on-dhcp-server) lists “The DHCP server is authorized” as a checklist item.
• Limitation: authorization only governs Windows DHCP servers. Non-Windows or workgroup rogue servers are not stopped by it, which is why network-layer controls appear in Section B.

A5. DNS dynamic updates, Name Protection (DHCID), DnsUpdateProxy

• “Dynamic DNS Update in Windows and Windows Server” (https://learn.microsoft.com/en-us/windows-server/networking/dns/dynamic- update):
  • When a DHCP server performs a secure update, “it becomes the owner of that name.”
  • A DHCP server in the DnsUpdateProxy group “doesn’t secure the DNS domain names it registers.”
  • Microsoft advises creating “a dedicated user account” for DHCP DNS updates.
  • It warns: “When installed on a domain controller, the DHCP Server service inherits the security permissions of the domain controller.”
• BPA topic ee941152 (WS 2008 R2/2012). The exact quote is confirmed: “Name protection requires secure update to work. Without name protection DNS names may be hijacked.” The remedy is AD-integrated zones with “Secure only” updates.
• Archived TeamDHCP “What is Name Protection”: Name Protection relies on the DHCID RR; “Secure Dynamic DNS updates must be enabled for name protection to work”; it prevents server/client name squatting.
• Default behavior: Akamai documents (with screenshots) that DHCP DNS dynamic updates are on by default, and that the default setting registers records only when the client asks (FQDN option, RFC 4702). I did not find a current Microsoft page stating the default explicitly; this is flagged in Caveats.

A6. Built-in groups (DHCP Administrators / DHCP Users)

• DHCP Administrators is described in Akamai’s research: it lets members “query and modify the configuration of the DHCP service” but grants no rights over the host itself.
• Not verified on a Microsoft page this pass: the Microsoft definitions of DHCP Administrators and DHCP Users (read-only). Treat the groups’ existence as well established, but Microsoft’s exact wording as unconfirmed.

A7. Relay / IP helper / RRAS

• The failover overview confirms that relay agents are “commonly configured” on network devices via ip helper-address, or on Windows Server with the Remote Access role (“Deploy the DHCP Relay Agent”).
• Failover deployments need a helper address for both partners.
• VRRP/HSRP can produce duplicate relayed requests.
• Azure Learn guidance notes that broadcast DHCP doesn’t work in an Azure VNet, so a relay is required there.

A8. Policies and filtering

• The failover overview confirms policy-based assignment: clients can be grouped by vendor class, user class, client identifier, or MAC address, and given different options or ranges.
• Not re-verified this pass: the dedicated Microsoft page for link-layer (MAC) allow/deny filtering.

A9. Audit logging

• Microsoft’s Event ID 1060 topic says “DHCP audit logs are located by default at %windir %”. On log-size limits, Microsoft’s archived blog “All about DHCP Auditing” (Nov 2, 2006) defines DhcpLogFilesMaxSize (REG_DWORD, MB) as “the maximum combined size of one week’s worth of Dynamic Host Configuration Protocol (DHCP) audit logs. If the audit logs exceed the size specified by this value, DHCP stops writing to the audit log until sufficient space becomes available.”
• A current Microsoft KB shows the file pattern DhcpSrvLog-<Day>.log.
• The DHCP-Server event channels (Operational, Admin, Audit, Filter Notification) are listed in the DHCP troubleshooting guidance.
• “On by default” is supported only by third-party sources: TechTarget’s “Use advanced DHCP logging techniques for troubleshooting” says “Windows enables DHCP logging by default.” ManageEngine’s KB disagrees: “On some Windows Server installations, it’s enabled by default; on others it isn’t.” I did not see the default stated on a current Microsoft page.

A10. IPAM

• The Microsoft Learn path confirms IPAM for central DNS/DHCP management (module “Implement IP Address Management”).

A11. DHCPv6 and mitm6

• mitm6 origin: Fox-IT published mitm6 on Jan 11, 2018 (author Dirk-jan Mollema). Fox- IT is non-US; it’s cited here only to identify the origin. The tool answers Windows DHCPv6 solicitations and makes the attacker the victim’s IPv6 DNS server.
• Mitigations: Fox-IT’s original post called disabling IPv6 when it isn’t used “the only defense… we are currently aware of.” Later practitioner guidance adds:
  • blocking inbound DHCPv6 and Router Advertisements via Windows Firewall GPO;
  • RA Guard / DHCPv6 Guard on switches (standards anchor: RFC 7610);
  • LDAP signing/channel binding and SMB signing to break the NTLM relay step.
• I found no Microsoft or government page codifying mitm6 mitigations.

A12. Windows DHCP Server CVEs (2023–2026)

• Confirmed on MSRC (title and release date seen in the Security Update Guide):
  • CVE-2023-38162 (DoS, Sep 12, 2023). MSRC notes servers not configured for failover are not affected.
  • CVE-2024-26215 (DoS, Apr 9, 2024).
  • CVE-2024-38236 (DoS, Sep 10, 2024).
  • 2026 RCEs: CVE-2026-69847 (heap overflow, “authorized attacker… adjacent network,” Sep 8, 2026); CVE-2026-69876 (use-after-free, adjacent, Sep 8, 2026); CVE-2026-70058 (out-of-bounds write, “unauthorized attacker… over a network,” Oct 13, 2026); CVE-2026-88120 (rated Critical, Oct 13, 2026).
• Secondary-source only (not opened on MSRC):
  • CVE-2023-28231 (Apr 2023, DHCPv6 relay-forward RCE).
  • CVE-2023-35638 (Dec 2023 DoS); CVE-2023-38152 and CVE-2023-36801 (info disclosure, Sep 2023); CVE-2024-30019 (May 2024 DoS).
  • CVE-2026-50518 (Jul 2026; reported CVSS 9.8 Critical); CVE-2026-72979 (Sep 2026, Critical); CVE-2026-69620 (Important); CVE-2026-77889 (DoS).
• Out of scope: CVE-2025-21379 is a DHCP Client issue, not Server.
• Relevance: network-reachable RCEs in a service that runs on many DCs (Akamai: 57%) make this a high-priority patching surface.

Section B — Government and standards guidance

B1. NIST

• No DHCP Special Publication was found. That absence is itself a finding.
• SP 800-81r3, Secure Domain Name System (DNS) Deployment Guide.
  • URL: https://doi.org/10.6028/NIST.SP.800-81r3 . Published March 2026 (approved 2026-03-04); supersedes SP 800-81-2 (Sept 2013). Free; US government work.
  • Authors: the title page lists Rose, Liu, Gibson, while the suggested citation lists “Nodurft.” This internal inconsistency is in the PDF.
  • DHCP-relevant statements:
  • Mapping an IP to an asset during an incident needs allocation history “such as a Dynamic Host Configuration Protocol (DHCP) lease history.”
  • On co-location: “If having systems dedicated only to DNS is not feasible, then incorporating related core services (e.g., DHCP) may be appropriate.”
  • Dynamic updates “generally originate from hosts (e.g., DHCP servers)” and “should only be accepted from authorized senders (e.g., by TSIG or ACL).”
  • Threats listed: unauthorized updates, tampering, replay and update-flood DoS. Hidden primaries are “strongly encouraged” for zones that accept dynamic updates.
• SP 800-53 Rev. 5 mapping (this document’s interpretation; NIST does not name DHCP):
  • AU-2/AU-3/AU-11/AU-12 for audit-log content and retention;
  • CM-6/CM-7 for configuration and least functionality (e.g., disabling DDNS if unneeded);
  • CM-8 for inventory (DHCP leases);
  • SC-7 and AC-4 for boundary protection and flow control (relay, segmentation, snooping);
  • AC-6 for least privilege (DHCP Administrators, DNS credential);
  • SI-4 for monitoring (rogue offers).

B2. CISA / NSA

• No DHCP-specific CISA or NSA guidance was found.
• SP 800-81r3 cites CISA’s Protective DNS program and the FCEB encrypted-DNS requirement; neither is DHCP guidance.
• “Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators” was released Aug 13, 2025 by CISA, NSA, FBI and EPA, co-sealed with ASD’s ACSC, the Canadian Centre for Cyber Security, BSI, NCSC-NL and NCSC-NZ (per NSA’s press release “NSA Joins CISA and Others to Share OT Asset Inventory Guidance”). I did not confirm any DHCP text in it, and its foreign co-seals put it at the edge of this scope.

B3. DISA

• No stand-alone DHCP STIG or SRG was found. This comes from searching mirrors (stigviewer, cyber.trackr, NIST NCP); cyber.mil itself could not be fully crawled.
• DHCP-relevant rules found:
  • Network Infrastructure Policy STIG. V-251361 / NET0198 (Medium): “DHCP audit and event logs must record sufficient forensic data to be stored online for thirty days and offline for one year,” including hostname and MAC. V-251362 / NET0199 (Low): SIPRNet DHCP minimum lease of 30 days.
  • Layer 2 Switch SRG and vendor L2S STIGs: DHCP snooping “for all user VLANs.” Examples: Cisco IOS V-220633 (CISC-L2-000130), Cisco IOS XE V-220659, NX-OS V-220684, Arista V-255973, Juniper EX V-253959, HP FlexFabric V-66071 (which also requires rate-limiting). The same STIGs include IP Source Guard and DAI rules that rely on the snooping binding table.
  • Legacy Windows DNS STIG (2013-04-12). V-4501 / DNS0805 (High) requires DHCP disabled on 2000/2003 DNS servers supporting dynamic updates, because a DC-hosted DHCP can alter DC SRV records. This is the closest DISA analogue to the Akamai DC finding. No DHCP rule was found in later Windows DNS STIGs (not exhaustively checked).
  • Infoblox 7.x DNS STIG. V-68621: DHCP must not run on an external authoritative name server.
• Windows Server OS STIGs (2022 V2R10, 278 rules, Aug–Sep 2026; 2025 V1R3, 291 rules, Aug 2026) contain no DHCP-specific rule. The host is hardened through the general OS rules. The WS2008 R2 Member Server STIG V-3487 lists “DHCP Server” only as a documented service.

B4. CIS (nonprofit)

• CIS Controls v8.1 (June 2024; v8.1.2 March 2025).
  • Safeguard 1.4 (IG2/IG3): “Use DHCP logging on all DHCP servers or Internet Protocol (IP) address management tools to update the enterprise’s asset inventory. Review and use logs to update the enterprise’s asset inventory weekly, or more frequently.” This is the only DHCP-named safeguard.
  • Related safeguards (my mapping): 1.1/1.2 asset inventory and unauthorized assets; 4.1/4.2 secure configuration of assets and network infrastructure; 8.2/8.10 audit log collection and retention; 12.2 secure network architecture; 13.x network monitoring (rogue DHCP detection).
  • Licence: CC BY-NC-ND 4.0.
• CIS Microsoft Windows Server Benchmarks (Member Server profile): not verified this pass. I’m not aware of a DHCP-role benchmark; the DHCP host would be covered by the general Member Server profile.

B5. IETF (primary for the protocol)

Section B6 — Akamai practitioner research (NON-GOVERNMENTAL)

1. “Spoofing DNS Records by Abusing DHCP DNS Dynamic Updates.” Ori David, Akamai, Dec 7, 2023. URL: https://www.akamai.com/blog/security-research/spoofing-dns-by-abusing- dhcp . Free; Akamai copyright.

Confirmed findings:

• The attacks “don’t require any credentials, and work with the default configuration of Microsoft DHCP server.” Microsoft DHCP servers “have this feature enabled by default.”
• Attackers can create records and can overwrite DHCP-managed records, the DHCP server’s own record, and, when DHCP runs on a DC, “any DNS A record inside the ADI zone.” This works because ENTERPRISE DOMAIN CONTROLLERS has write rights on every record.
• “57% have a DHCP server installed on a DC.”
• “We reported our findings to Microsoft, but a fix is not planned.”
• Name Protection can be bypassed with a spoofed DHCP Release carrying the victim’s MAC, or by brute-forcing the DHCID.
• Akamai found the DnsUpdateProxy group to be both a risk and apparently buggy.
• The “40%” figure appears in two forms: the summary says “40% of the networks monitored by Akamai,” while the body says “40% of the data center networks we monitor.”

Mitigations:

• Confirmed: disable DHCP DNS Dynamic Updates if not needed; avoid DnsUpdateProxy; use static records for sensitive non-Windows hosts (“Managed records can’t be protected from spoofing with any configuration”).
• Partly confirmed (the page was truncated): use a weak DNS credential and use the same credential on all DHCP servers.

Tooling: Invoke-DHCPCheckup (detection, PowerShell) and DDSpoof (offensive).

2. “Abusing the DHCP Administrators Group to Escalate Privileges in Windows Domains.” Ori David, Mar 20, 2024. URL: https://www.akamai.com/blog/security-research/abusing-dhcp-administrators-group-for- privilege-escalation-in-windows-domains .

• Findings: DHCP options (WPAD 252, DNS Server) can be abused to run code on DHCP servers and coerce Kerberos authentication. Where DHCP runs on a DC, this gives domain admin.
• “doesn’t rely on any vulnerability. Therefore, a fix for it doesn’t exist.”
• Mitigations: treat DHCP Administrators as high-value and limit membership; avoid DHCP on DCs; segment; detect DNS anomalies (DHCP updates going to non-standard DNS servers).
• Akamai uses the “DHCP Coerce” label in the post itself: a section is headed “DHCP Coerce to Kerberos relay,” and the text says “DHCP Coerce opens an opportunity for a Kerberos relay attack.” The related script in Akamai’s DDSpoof repo is dhcp_coerce.py.

Topic crosswalk

Agreements, differences and conflicts

1. No government DHCP baseline. Every federal source treats DHCP indirectly: as a DNS client (NIST), a log source (DISA, CIS), or a switch-layer threat (DISA L2S). Microsoft’s product documentation is effectively the configuration baseline.
2. DDNS is unauthenticated by design, and Microsoft won’t patch it. Microsoft’s documentation frames the risk as record ownership. Akamai shows unauthenticated overwrite under default settings and reports that no fix is planned. NIST’s “authorized senders only” principle is satisfied only at the DHCP→DNS hop, not client→DHCP. That gap is the core conflict.
3. DHCP on a DC vs. tiering.
   • Microsoft documents that DC-hosted DHCP “inherits the security permissions of the domain controller” but does not forbid it.
   • DISA’s legacy V-4501 and both Akamai posts argue against it.
   • NIST 800-81r3 allows co-locating DHCP with DNS when dedicated servers aren’t feasible. That speaks to DNS servers, not DCs, so it is not a direct contradiction.
   • Position: keep DHCP off DCs. If you can’t, set a dedicated low-privilege DNS credential.
4. Rogue defense is layered, and no single source covers it all.
   • AD authorization (Microsoft) stops only Windows servers.
   • DHCP snooping (DISA L2S) and RFC 7610 / RA Guard cover IPv4/IPv6 at layer 2.
   • Monitoring (CIS 13) adds detection.
   • You need all three.
5. There is no usable DHCP protocol authentication. RFC 3118 is effectively unused, and DHCPv6 delayed authentication was obsoleted in RFC 8415. The only “authentication” in Windows DHCP is the optional failover shared secret.
6. Logging is the one clean agreement. Microsoft (on by default, %windir%), NIST (lease history for DFIR), DISA (30 days online / 1 year offline, with MAC and hostname) and CIS (Safeguard 1.4, weekly inventory reconciliation) all point the same way.
   • Practical caveat: Windows keeps one audit file per weekday. Per Microsoft’s archived “All about DHCP Auditing” blog, at each day change “DhcpSrvLog- Wed.log is closed and the file named DhcpSrvLog-Thu.log is opened,” and “If the audit log file has existed without modification for more than 24 hours, it is overwritten.” That leaves about a week of logs locally, which cannot meet DISA retention without forwarding logs to a SIEM.

Caveats and unverified items

• Corrections to the prior pass:
  • The failover minimum is Windows Server 2016 on the current page, not 2012.
  • The reserve percentage belongs to hot standby, not load balance.
  • The shared secret is optional.
  • Scopes are replicated, not pre-matched.
  • RFC 8415 is now obsoleted by RFC 9915.
  • CVE-2025-21379 is a DHCP Client CVE.
• Not verified on a primary page this pass:
  • Microsoft’s explicit statement of the DDNS default and of audit logging being on by default.
  • Microsoft’s definitions of the DHCP Administrators/Users groups.
  • The link-layer filtering page.
  • The current DHCP role overview URL.
  • Exact text of RFCs 3046, 3118, 3942, 4388 (from IETF records/knowledge; not re- fetched).
  • CIS Benchmark DHCP coverage.
  • The latest SP 800-53 release number.
• MSRC pages render client-side. CVE details came from MSRC search-index snippets. The CVEs marked secondary-source (including CVSS 9.8 claims) should be confirmed in the Security Update Guide before being cited.
• DISA: the “no DHCP STIG” conclusion and the WS2022 V2R10 / WS2025 V1R3 dates come from mirrors (cyber.trackr, NIST NCP, Tenable). They disagree on exact dates (e.g., 10 Aug vs. 10 Sep 2026).
• Akamai’s prevalence figures (40%, 57%) come from its own customer telemetry and are not independently verifiable. Its mitigation list was only partly visible.
• Scope: mitm6 originated at Fox-IT (Netherlands). It’s referenced only to identify the attack; no other governments' sources were used.