Feature: Windows DHCP scope/reservation sync (agentless, via WinRM)

[deku-m]

Summary

Add a Windows DHCP integration module that syncs scopes, exclusion ranges, and reservations between danbyte and one or more Windows Server DHCP roles, connecting agentlessly over WinRM. Unlike read-only IPAM/discovery tools, this should be bidirectional: danbyte becomes the source of truth for reservations, and changes made in danbyte push out to the live DHCP server(s).

Motivation

danbyte currently has no Windows DHCP support. Given danbyte's design goal of being a lighter, self-hosted NetBox alternative, an agentless module that both reads and writes DHCP scopes/reservations directly — without requiring any extra agent stack on the DHCP server — is a meaningful capability gap to close.

Proposed design

Connectivity

• No agent required on the DHCP server. Windows Server ships the DhcpServer PowerShell module with the DHCP role, and WinRM (WS-Management) is enabled by default on Server 2012 R2+.
• Connect via WinRM, either:
  • Shell exec mode: open a WinRM shell, run powershell.exe -NoProfile -NonInteractive -EncodedCommand <base64>, parse JSON stdout. Simple, stateless, easy to implement in Go with masterzen/winrm.
  • PSRP mode: full PowerShell Remoting Protocol session (what pypsrp / NetBox Labs' integration uses). More overhead to implement but gives cleaner structured object handling and reusable sessions for high-frequency polling.
  • Recommend starting with shell-exec mode for v1 — it covers the read/write cmdlet calls we need without the extra protocol complexity, and can be swapped for PSRP later if session reuse becomes a performance concern.
• Default to WinRM over HTTPS (5986). Since most DHCP boxes run self-signed certs, default verify_ssl: false with an option to enable strict verification for orgs with real internal CA certs.
• Auth: support both NTLM and Kerberos.
  • NTLM as the default/easy path (service account + password, no domain-join requirement on the danbyte host).
  • Kerberos as the hardened option for domain-joined danbyte deployments.
• Firewall guidance in docs: restrict inbound WinRM on the DHCP server to the danbyte host IP only.
• Recommend a dedicated service account in the DHCP Administrators group — not Domain Admin. Note in docs that Windows DHCP has no per-scope ACLs, so this account can touch all scopes on that server.
• Optional hardening path (documented, not required for v1): register a JEA (Just Enough Administration)constrained endpoint on the DHCP server exposing only the required DhcpServer cmdlets, so a compromised service account/channel can't pivot beyond DHCP operations.

Sync (read: DHCP → danbyte)

Poll on a configurable interval (default suggestion: 5 min) per configured DHCP server:

Windows DHCP object | danbyte object | Cmdlet -- | -- | -- Scope | Prefix | Get-DhcpServerv4Scope Exclusion range | IP range | Get-DhcpServerv4ExclusionRange Reservation | IP address (reserved) | Get-DhcpServerv4Reservation Lease (opt-in, per-scope) | IP address (dhcp-assigned) | Get-DhcpServerv4Lease Scope options (DNS, router, lease time, etc.) | Metadata field on prefix | Get-DhcpServerv4OptionValue

• Reservation should always take precedence over a lease on the same address if both exist.
• Store per-scope DHCP options as structured metadata rather than flattening them, so they stay inspectable.
• Lease sync should be opt-in per scope (not automatic) — leases churn constantly and syncing all of them by default would flood the DB with noise for large scopes.
• Tag/flag synced objects clearly with source server, so it's obvious in the UI which objects are DHCP-managed vs. manually created in danbyte.

Push (write: danbyte → DHCP)

This is the key gap vs. existing tools:

• Creating/editing a reservation in danbyte should call Add-DhcpServerv4Reservation / Set-DhcpServerv4Reservation / Remove-DhcpServerv4Reservation on the target scope's server.
• Needs conflict handling: if the same IP was reserved or leased directly on the DHCP server between polls, danbyte should detect the drift on next sync and flag it for review rather than silently overwriting.
• Consider a "danbyte-managed" marker in the reservation description (mirroring the pattern of tagging synced objects) so it's clear in the Windows DHCP console which reservations originated from danbyte.

Configuration (per DHCP server)

• Host/IP
• WinRM port + TLS on/off
• Auth mode (NTLM / Kerberos) + credentials or credential reference
• SSL verification on/off
• Poll interval
• Lease sync scope allowlist (opt-in list of scope IDs)

Out of scope for v1

• DHCP failover cluster awareness (syncing both partners in a failover relationship) — worth a follow-up issue once basic sync is stable.
• DNS registration side-effects of DHCP leases (separate from Microsoft DNS integration territory).

With the help of AI.
Sorry if i have to many ideas or request.

[DenDanskeMine]

Seems to be a good candidate for a v12 release.
I might even include Windows DNS as well in this release.

[DenDanskeMine]

Sorry if i have to many ideas or request

nono not at all!
Keep it coming 😎