A default OpenWrt access point is a rogue DHCP and DNS server
- date
- 20260818
- what happened
- Deploying ap1, Node0's sole wireless access point, the known trap was handled. A factory-default OpenWrt device runs its own DHCP server, so the access point was staged in isolation on a disposable host and had DHCP disabled before it touched the live network. What the plan did not anticipate was that disabling DHCP left the same daemon running and still answering DNS queries on the access point's own address.
- what it cost
- No outage, because nothing was configured to use the access point as a resolver. On a network whose entire DNS story is a small set of authoritative resolvers, an unadvertised third resolver that knows nothing of the internal zones is a latent split brain. It sat there unnoticed for days until a full configuration audit found it still bound to the DNS port.
- what changed
- The daemon and the related router-advertisement service were explicitly stopped and disabled, and an IPv6 unique local prefix the access point had also been advertising on its own was removed.
- the check now
- After disabling any single function of a multi-function daemon, verify that nothing is still listening on the ports that function implies, rather than trusting that the one setting changed was the only thing the daemon did.
The access point’s most famous default-configuration trap, a DHCP server that would fight the real one, was anticipated correctly. The whole deployment on 20260818 was staged around avoiding it: bring the device up isolated on a throwaway host, strip its dangerous defaults there, and only then connect it to the live network. That discipline worked exactly as intended.
What slipped through was a second service riding on the same daemon as the one everyone was watching. On OpenWrt, one process serves both DHCP and DNS. Turning off DHCP in the interface turns off the leases. The process stays up and keeps answering DNS queries on the access point’s own address, silently, to anyone who asks. Nothing was configured to ask, so nothing broke, and it went unnoticed for days.
That is exactly why it is worth writing down. A latent, unadvertised resolver on a network that depends on a small number of authoritative ones costs nothing until the day a client’s resolver order changes, or a device falls back, and it starts taking answers from a box that has never heard of the internal zone. The answers will be confidently wrong rather than absent, which is the harder failure to diagnose.
The generalisable habit is to audit a multi-function service by the ports it still has open, not by the checkbox that was unchecked. The same pass found the device advertising an IPv6 prefix of its own, which nobody had asked for either.
Source: node0 lessons v0.1, lesson 4.6. Sanitized: checklist v0.1, 20260921; addresses, SSID, credential handling; voice pass 20260921. Part of oznog.com/node0.