One box, dnsmasq, and it can do DNS caching and DHCP for a whole small LAN without a heavyweight server behind it. You will configure dnsmasq 2.91 as a DNS cache and DHCP server for one small IPv4 LAN, then verify both services without guessing from a successful process start. The example keeps dnsmasq on one interface, gives clients addresses from a private pool, and assigns one predictable address to a printer or other fixed device.
Allow about 20 minutes if the host already has a working network interface and a service unit. You need root access, the dnsmasq-base package, an upstream resolver address, and the name of the LAN interface. Do not run a second DHCP server on the same LAN: if another router is already providing DHCP, disable that function first or use dnsmasq only for DNS.
Run the inspection commands as your ordinary user. Replace enp3s0 in later examples with the interface that connects to the client network. The address shown by ip -4 addr should belong to the same subnet as the DHCP pool you choose.
dnsmasq --version
ip -4 addr
ip route
On the machine used for this guide, the installed package is dnsmasq-base 2.91-0ubuntu0.24.04.1 and the binary reports dnsmasq version 2.91. The compile-time feature list includes DHCP, DHCPv6, DNSSEC, TFTP and nftset, although this guide uses only DNS and DHCP. If your version differs, check its local manual before copying an option.
Dnsmasq reads /etc/dnsmasq.conf at startup if it exists. A configuration file contains one long option per line without the leading two hyphens. The following example assumes the host has 192.168.50.1/24 on enp3s0. It forwards ordinary queries to two explicitly selected upstream resolvers, rather than silently inheriting the contents of /etc/resolv.conf.
Creating or replacing a system configuration is a privileged and service-affecting action. Preserve the current file first; if it does not exist, the backup command reports an error but changes nothing.
sudo cp -p /etc/dnsmasq.conf /etc/dnsmasq.conf.before-lan-guide
sudo tee /etc/dnsmasq.conf >/dev/null <<'EOF'
interface=enp3s0
bind-interfaces
listen-address=192.168.50.1
no-resolv
server=1.1.1.1
server=9.9.9.9
domain-needed
bogus-priv
dhcp-range=192.168.50.100,192.168.50.200,12h
dhcp-host=AA:BB:CC:DD:EE:FF,192.168.50.20,printer
EOF
interface restricts listening to the LAN interface, while listen-address restricts it to the host's LAN address. bind-interfaces makes the socket binding explicit. The no-resolv line is paired with two server lines, so changing the host's resolver file does not unexpectedly change dnsmasq's upstreams. Remove the example MAC address or replace it with the real device address; leaving it unchanged will not reserve an address for your device.
The DHCP range uses a 12-hour lease. The manual's default for IPv4 is one hour when no lease time is specified, but an explicit value makes this configuration easier to reason about. A fixed dhcp-host address must be in the same subnet as a valid DHCP range; the reserved address sits outside the dynamic pool, which avoids collisions.
Run dnsmasq's syntax check before touching the running service. It reads the configuration, exits with status zero when it is valid, and does not start dnsmasq.
sudo dnsmasq --test
Expected output is a short success message ending with syntax check OK and a zero exit status. If it fails, the line named in the error is the first place to inspect. Common causes are a misspelt interface, a LAN address not assigned to the host, an invalid MAC address, or a DHCP range that does not match the interface subnet. Correct the file and repeat the same test.
Syntax validation does not prove the network design is safe. Check that only one DHCP server exists, that 192.168.50.1 is really the host's address, and that the upstream resolver addresses are reachable from this machine.
Starting or restarting dnsmasq can disrupt name resolution and DHCP on the LAN. Apply the change from a local console or a reliable out-of-band session if this is a remote host. The exact service unit depends on the distribution; where a systemd unit is present, use:
sudo systemctl restart dnsmasq
sudo systemctl --no-pager --full status dnsmasq
The status should show an active service. A running process is not enough: inspect recent service messages if the status is failed.
sudo journalctl -u dnsmasq -n 50 --no-pager
If the restart fails after a valid syntax check, look for a port conflict. DNS uses port 53, and another resolver may already be listening. Confirm the owner before stopping anything:
sudo ss -lntup | grep -E '(:53[[:space:]]|:67[[:space:]])'
Do not disable a resolver or DHCP service merely because it owns a port. Decide which service should provide that function, then change only the intended service.
From the dnsmasq host, query the local listener directly. The dig utility is normally supplied by a DNS utilities package. A successful answer proves that something answered on port 53 at the address, so also check the service status to associate that answer with dnsmasq.
dig @192.168.50.1 example.org A +short
sudo systemctl is-active dnsmasq
From a client on the LAN, renew its DHCP lease using the client operating system's normal network controls, then inspect the lease file on the server:
sudo cat /var/lib/misc/dnsmasq.leases
Each active lease is recorded with an expiry time, MAC address, leased address, hostname and client identifier. The path is the usual Linux location documented by this installed build; check the FILES section if your distribution uses a different path. A missing lease usually means the request did not reach this dnsmasq instance, the interface or range does not match, or another DHCP server answered first.
For a fixed host, verify both the lease and the name:
dig @192.168.50.1 printer A +short
ping -c 1 192.168.50.20
Dnsmasq loads /etc/hosts as well as DHCP-derived names. The printer name above comes from dhcp-host, so it will not resolve until that client has contacted the DHCP server. A ping failure can be caused by the printer blocking ICMP; treat the DNS result and lease entry as the more useful checks.
Edit the configuration, run sudo dnsmasq --test, and restart only after the test passes. Changes to the main configuration file are not re-read by SIGHUP: the manual says SIGHUP clears the cache and reloads hosts, leases and related include files, but not the main configuration. Restart is therefore the clear operation for this example.
To undo the guide's configuration, stop the service if it should no longer provide DNS or DHCP, then restore the saved file and start the service again only if that is the intended state:
sudo systemctl stop dnsmasq
sudo mv /etc/dnsmasq.conf.before-lan-guide /etc/dnsmasq.conf
sudo dnsmasq --test
sudo systemctl start dnsmasq
If the backup did not exist, do not invent a replacement. Remove the guide's file only after checking what the host's package or service management expects, and also remove any client-side static DNS or address settings that were added while testing.
dnsmasq --version identified the installed build.sudo dnsmasq --test passes before each service change.dig @192.168.50.1 example.org A +short returns an address.