dnsmasq DHCP Config Generator

Listen interface:

Use the interface attached to the DHCP broadcast domain.

Scope network CIDR:

Enter the IPv4 network for this scope, for example 10.44.60.0/24.

DHCP pool range:

Keep router, servers, and fixed reservations outside the dynamic pool where practical.

Lease time:

Short leases are useful while testing; longer leases reduce churn once the scope is stable.

Router option:

Leave blank only for an isolated lab segment that should not receive a default route.

DNS servers:

Use the dnsmasq host address or dedicated resolver IPs for this VLAN.

Local domain:

Use the local suffix clients should receive, such as lab.internal.

Emit local DNS zone helpers:

Turn on when dnsmasq should also publish local hostnames for this suffix.

{{ params.enableLocalZone ? 'Local zone lines on' : 'DHCP options only' }}

Mark DHCP authoritative:

Use only when dnsmasq is the intended DHCP authority for this broadcast domain.

{{ params.authoritative ? 'Authoritative' : 'Not authoritative' }}

Bind to selected interface:

Keep on for single-scope hosts; review when dnsmasq serves several interfaces from one config.

{{ params.bindInterfaces ? 'Interface bound' : 'Global listen allowed' }}

Static reservations:

One reservation per line using mac,ip,hostname,lease. Leave blank if this scope has no fixed hosts.

Samples stay local and replace the current form.

NTP servers:

Use when clients should receive time servers through DHCP option 42.

Classless static routes:

One route per line, for example 10.55.0.0/16,10.44.60.254.

Extra DHCP options:

Use for site-specific options such as wpad, tftp-server, or vendor settings.

Enable PXE/TFTP boot lines:

Turn on only for a scope that should offer network boot directives.

TFTP root:

The dnsmasq process must be able to read files under this path.

BIOS boot file:

Common examples include pxelinux.0 or undionly.kpxe.

UEFI x64 boot file:

Common examples include grubnetx64.efi.signed, bootx64.efi, or ipxe.efi.

Fix blocking configuration issues

{{ error }}

{{ result.config }}

Field	Value	Directive	Operator note	Copy
{{ row.field }}	{{ row.value }}	`{{ row.directive }}`	{{ row.note }}

Host	MAC	IP	Lease	dnsmasq line	Copy
{{ row.hostname \|\| 'unnamed host' }}	`{{ row.mac }}`	`{{ row.ip }}`	{{ row.lease \|\| 'scope default' }}	`{{ row.directive }}`
No static reservations configured Add reservation rows or load the PXE sample before exporting the reservation ledger.

Severity	Check	Detail	Recommendation	Copy
{{ row.severity }}	{{ row.check }}	{{ row.detail }}	{{ row.recommendation }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

On a routed LAN or lab VLAN, the DHCP reply is often the first network policy a client receives. It gives the client an IPv4 address, a subnet mask, a lease time, and the optional details that make the address usable: a default gateway, DNS resolvers, a search domain, time servers, static routes, or boot hints for machines that start from the network. dnsmasq is popular in that space because one small service can provide DNS, DHCP, TFTP, and PXE support for router appliances, virtualization hosts, workshop benches, isolated build networks, and small office segments.

A dnsmasq DHCP scope is not just a start and end address. The scope must match the interface that hears client broadcasts, the pool must stay inside the selected subnet, reserved hosts should not collide with dynamic leases, and the options sent to clients must describe the actual network. A wrong router option can strand clients without a route. A bad DNS option can make name lookups fail even when the address lease succeeds. A PXE filename can be syntactically valid and still fail if it does not match the client firmware or the TFTP root on disk.

Scope network: The IPv4 CIDR that defines the address space, netmask, and broadcast address for one DHCP segment.
Dynamic pool: The inclusive range of addresses that may be leased automatically to ordinary clients.
Reservation: A fixed lease tied to a MAC address, usually used for infrastructure hosts or machines that need stable addresses.
DHCP option: Extra client configuration carried with the lease, such as router, DNS server, NTP server, domain search, or classless routes.
PXE/TFTP: Network-boot metadata that tells firmware where to fetch a boot file before an operating system is installed.

Most DHCP mistakes are not complicated. They come from small mismatches between the written scope and the real network: a pool edge that touches the broadcast address, a router placed inside the dynamic range, a duplicate reservation, or an option copied from another VLAN. Text configuration makes these mistakes easy to overlook because a line can look plausible while pointing at the wrong subnet or service.

Validation can reduce those errors before rollout, but it cannot replace a live service check. The final dnsmasq file still has to be tested on the host that will run it, with the real interface, include path, permissions, TFTP files, relay behavior, and any other DHCP servers on the same broadcast domain accounted for.

How to Use This Tool:

Work from the network boundary inward. Enter the interface and CIDR first, then add the options that clients on that segment should receive.

Set Listen interface and Scope network CIDR. The scope audit normalizes the network address and shows the netmask and broadcast address used for the generated range line.
Enter the DHCP pool range and Lease time. Use the validation review to catch reversed ranges, addresses outside the CIDR, unusable edge addresses, or lease strings that dnsmasq would not accept.
Add the Router option, DNS servers, and Local domain. Leave the router blank only for an intentionally isolated segment, and keep resolver addresses in dotted-quad IPv4 form.
Use Static reservations for fixed hosts, one CSV row per host in mac,ip,hostname,lease order. Invalid reservation rows remain visible in the ledger, but their dhcp-host line is not emitted until the row validates.
Open Advanced when the scope needs NTP servers, DHCP option 121 classless routes, custom option values, or PXE/TFTP boot lines. The PXE fields should match files that exist under the target TFTP root.
Review Validation Review before copying dnsmasq Config. Errors need correction; warnings mark choices that may be valid but deserve an operator check before a service restart.
Treat the generated config as ready for handoff only after the review has no blocking errors and the target host can still pass a dnsmasq syntax test and controlled client lease test.

Interpreting Results:

The summary count is the size of the dynamic pool after the core range checks pass. It is useful for address planning, but it is not a live inventory of available leases. Existing leases, unmanaged static hosts, client behavior, relay agents, and another DHCP server can all change what happens on the wire.

How to interpret dnsmasq DHCP generator result tabs
Result tab	Useful signal	Outside check
`dnsmasq Config`	Generated directives for the interface, pool, options, reservations, and optional PXE/TFTP lines. The range is withheld when core validation fails.	Run a dnsmasq syntax test and confirm the file is placed in an included configuration path.
`Scope Audit`	Normalized subnet, netmask, broadcast address, pool size, option counts, PXE state, and the directive family each item affects.	Compare these rows with the VLAN plan, gateway address, resolver plan, and IP address management record.
`Reservation Ledger`	Parsed fixed-host rows, normalized MAC addresses, emitted lease lines, and invalid-row placeholders.	Confirm every MAC belongs to the intended device and every fixed IP is unique on the segment.
`Validation Review`	Error, warning, pass, and info rows for the current values, including router-in-pool, duplicate reservation, unsafe token, and PXE checks.	Decide whether each warning is acceptable for the actual network before applying the config.
`JSON`	A structured snapshot of the generated config, scope values, valid options, reservations, and validation rows.	Do not treat the JSON as proof that the service loaded or that clients accepted the lease.

The copy and download actions are for handoff and review. CSV and DOCX exports are helpful for change records, but the generated text should still pass dnsmasq --test and a controlled client lease test before production traffic depends on it.

Technical Details:

DHCPv4 uses a client-server exchange to allocate an address and deliver configuration parameters. The address lease is only one binding in that exchange. Options tell the client which router to use, which name servers to query, which domain suffix to try, which time servers or classless routes to install, and, for network boot, which boot file to request.

dnsmasq expresses those choices as short directives. A range directive combines the start address, end address, netmask, and lease duration. Option directives map readable option names or numeric option codes to values. Reservation directives bind a MAC address to a stable address, optional hostname, and optional lease time. PXE adds TFTP service lines and boot-file selection rules.

IPv4 validation depends on integer address ordering. A dotted-quad address can be converted to a 32-bit value, then compared against the network address, broadcast address, and pool boundaries. For ordinary prefixes from /1 through /30, the network and broadcast addresses are not normal host leases, so a pool that touches either edge is treated as risky. Very small prefixes such as /31 and /32 need special operational care because they do not behave like a normal shared-client DHCP segment.

Formula Core:

The dynamic pool count is an inclusive range size after the start and end addresses validate and the start is not higher than the end.

dynamic leases = {IP}_{end} - {IP}_{start} + 1

With a pool from 10.44.60.100 to 10.44.60.220, the first three octets match, so the visible arithmetic is 220 - 100 + 1 = 121. Across different subnets, the same rule is applied to the full 32-bit IPv4 values.

Rule Core:

dnsmasq DHCP configuration rule core
Area	Emitted pattern	Validation boundary
Interface ownership	`interface=...` with optional `bind-interfaces`	The name must use a simple interface token. Names beyond the common Linux interface length are warnings because the target host may still reject them.
Dynamic pool	`dhcp-range=start,end,netmask,lease`	The CIDR must parse as IPv4, both pool edges must be IPv4 addresses, and the pool must remain inside the selected scope.
Router and DNS	`dhcp-option=option:router,...` and `dhcp-option=option:dns-server,...`	Values must be valid IPv4 addresses. Missing values are allowed only as reviewed omissions because clients may lack routing or name resolution.
Local DNS helpers	`domain`, `local`, `expand-hosts`, `domain-name`, and `domain-search`	The suffix must be plain DNS-label text without protocol, path, underscore, or whitespace characters.
Static reservations	`dhcp-host=mac,hostname,ip,lease`	MAC and IP are required. Hostname and lease are optional, but present values must pass hostname and lease syntax checks.
Classless routes	`dhcp-option=121,destination,gateway`	The destination must be IPv4 CIDR and the gateway must be IPv4. A gateway outside the scope is warned because clients may not be able to reach it directly.
Extra options	`dhcp-option=option-or-code,value...`	Option names and values use conservative tokens to avoid spaces, quotes, and commas that could change generated directive meaning.
PXE/TFTP	`enable-tftp`, `tftp-root`, `dhcp-match`, and `dhcp-boot`	The TFTP root must be an absolute path, and boot filenames must be TFTP-relative tokens. Architecture matches are emitted for common EFI client-architecture values before the untagged BIOS boot file.

Configuration Skeleton:

The generated order keeps service ownership first, then address assignment, client options, fixed hosts, and optional network-boot directives.

# dnsmasq DHCP scope
interface=br0
bind-interfaces
domain-needed
bogus-priv
domain=lab.internal
local=/lab.internal/
expand-hosts
dhcp-authoritative

dhcp-range=10.44.60.100,10.44.60.220,255.255.255.0,12h
dhcp-option=option:router,10.44.60.1
dhcp-option=option:dns-server,10.44.10.53,10.44.10.54
dhcp-host=52:54:00:60:10:11,lab-pxe01,10.44.60.20,infinite

Validation Boundaries:

The checks are intentionally narrower than a full network audit. They can reject malformed IPv4 addresses, unsafe domains, invalid leases, bad reservation rows, risky option tokens, reversed pools, and obvious scope collisions. They do not inspect the running daemon, load the file, ping the gateway, list active leases, verify TFTP permissions, detect relay-agent behavior, or prove that another DHCP authority will stay silent.

Limits and Privacy Notes:

The generated config is a draft for review, not an applied change. dnsmasq versions, distribution packaging, include directories, service wrappers, SELinux or AppArmor policy, TFTP file permissions, and local network topology can all affect whether the same text works on the target host.

The calculation and text generation run from the values entered in the browser. No remote lookup is needed to build the config, audit tables, reservation ledger, validation review, or JSON output. Treat exported files as potentially sensitive because they can reveal internal addressing, MAC addresses, hostnames, and boot infrastructure.

Worked Examples:

Small lab VLAN

A scope on br0 for 10.44.60.0/24 with a pool from 10.44.60.100 to 10.44.60.220 produces 121 dynamic leases when the lease string is valid. The audit should show netmask 255.255.255.0, broadcast 10.44.60.255, the router option, and the configured DNS resolver count.

Build bench with network boot

The PXE sample changes the interface to vlan60, shortens the pool, adds an NTP server, includes an option 121 classless route, and enables TFTP under /srv/tftp. The config should include enable-tftp, the TFTP root, EFI architecture matches, a tagged UEFI boot file, and an untagged BIOS boot file.

Gateway accidentally inside the pool

If the router is 10.44.60.120 while the dynamic pool remains 10.44.60.100 to 10.44.60.220, the review warns that the router sits inside the pool. Move the start address above the router, move the end address below it, or change the gateway address before clients can lease the gateway address by mistake.

Reservation row with several mistakes

A row such as 52-54-00-60-10-11,10.44.61.20,lab.pxe01,forever has a normalizable MAC style, but the IP is outside the sample scope, the hostname contains a dot, and the lease word is invalid. The ledger keeps the row visible and withholds the directive until those values are corrected.

FAQ:

Can this build several scopes at once?

No. It builds one IPv4 scope for one listen interface. Create separate reviewed configs for separate VLANs, bridges, or routed segments.

Which lease time formats are accepted?

Use infinite or a number followed by s, m, h, d, or w, such as 30m, 12h, 2d, or 1w.

Why is a valid-looking reservation not emitted?

The row needs a valid MAC address and IPv4 address. If a hostname or lease is present, those values must also pass the hostname and lease checks. Invalid rows stay visible so they can be fixed without silently disappearing.

Should static reservations be outside the dynamic pool?

That is usually safer because it reduces accidental address conflicts and makes the address plan easier to audit. The review warns when a fixed host sits inside the dynamic range.

What does authoritative mode mean here?

It emits dhcp-authoritative, which is appropriate only when this dnsmasq instance is meant to own DHCP service for the broadcast domain. Do not use it casually on a segment where another server may answer clients.

Does the generated config test the running service?

No. It generates and reviews text from the entered values. It does not query dnsmasq, inspect active leases, validate operating-system paths, verify TFTP files, or check for competing DHCP servers.

Glossary:

dnsmasq: A lightweight DNS, DHCP, router-advertisement, TFTP, and network-boot service commonly used on small networks and lab systems.
DHCPv4: The IPv4 version of Dynamic Host Configuration Protocol, used to lease addresses and send client configuration parameters.
DHCP scope: The network, dynamic pool, options, and fixed assignments served for one segment.
Option 121: The DHCPv4 classless static route option, used to send destination CIDR and gateway pairs to clients.
PXE: Preboot Execution Environment, a network boot process that uses DHCP metadata and boot files before an operating system loads.
TFTP root: The directory served by dnsmasq's TFTP service when network boot support is enabled.

References:

Dnsmasq project documentation, dnsmasq project.
dnsmasq manual page, dnsmasq project.
Dynamic Host Configuration Protocol, IETF RFC 2131, March 1997.
DHCP Options and BOOTP Vendor Extensions, IETF RFC 2132, March 1997.
The Classless Static Route Option for DHCPv4, IETF RFC 3442, December 2002.
DHCP Options for PXE, IETF RFC 4578, November 2006.
How to synchronize time with NTP in Linux, Simplified Guide.
How to configure a static IP address in Linux, Simplified Guide.
How to check the default route in Linux, Simplified Guide.