Laptops already know where DNS is. Usually the DCs. Sometimes Unbound or BIND.
Option 6 on the DHCP subnet should stay pointed there on day one. Lattice is not asking you to move the forest.
Ack never waits on DNS
The grant happens first. A worker writes A/PTR after Ack into the DNS you already run. Names follow the grant — they do not block the Offer (latticeddi.com, Replace Windows DHCP).
On first subnet setup, Option 6 = the resolvers laptops already query — same idea as Microsoft scope option 006. Lattice does not invent that list when you enable name adapters later (First subnet).
If Option 6 is wrong, clients get addresses and still cannot resolve. That looks like “DHCP is broken.” It is DNS configuration on the subnet.
Operators burn hours chasing dhcpd when resolvectl already shows the wrong nameservers. Fix Option 6. Reprove the lease. Then talk about name adapters.
What Lattice is not
Not Microsoft DNS (unless you publish lattice-dns on purpose). Not recursive public DNS. Not the AD forest. Not DNSSEC theater.
Keep AD. Keep BIND. Keep Unbound. DNS is an adapter. One catalog for IPAM and DHCP (latticeddi.com).
phpIPAM was never the resolver either. Replacing the sheet does not require replacing the nameserver (phpIPAM vs Lattice).
Option 6 vs Option 15 vs DDNS
Option 6 = recursive resolvers for clients. Option 15 = DNS suffix. DDNS / name adapters = how Lattice writes A/PTR after Ack.
Mixing them up causes “DHCP works but nothing resolves” or “DNS updates but clients query the wrong place.”
Day one: get Option 6 right. Prove resolution. Day two: enable name follow into AD or BIND if you want Lattice to write records after Ack. Never make Ack wait on a nameserver. That is not the product (Replace Windows DHCP).
Cutover without a DNS project
- Map scopes and reservations.
- Set Option 6 to today’s resolvers (usually the DCs).
- List trusted relays. Point one helper at Lattice.
- Confirm a client gets an address and still resolves through the same resolvers (
ipconfig /all/resolvectl).
If names should follow the lease into AD or BIND, turn on the adapter after Ack is proven — not before. Ack never waits.
Split-brain DNS is worse than a slow cutover
If half the VLANs still get Option 6 from Windows scopes pointing at old DNS IPs you retired, clients look “randomly broken.” Inventory Option 6 with the same seriousness as helper addresses. Trusted relays and Option 6 are the two lists that make campus DHCP feel haunted when empty or wrong.
A slow, VLAN-by-VLAN cutover with correct Option 6 beats a “big bang” that leaves half the campus on retired DNS IPs.
A Tuesday that looks like DHCP
“Laptop got an IP but nothing loads.”
ipconfig /all shows DNS servers that retired last quarter.
Option 6 on that scope was never updated when DNS moved.
Fix Option 6 on the subnet. Renew the lease. Confirm resolution. Only then enable name adapters if you want A/PTR written after Ack.
Lattice did not break DNS. The subnet handed out a stale resolver list. Inventory Option 6 VLAN by VLAN the same week you inventory helpers and trusted relays.
Names follow — after, not instead
When you turn on a name adapter, Lattice writes A/PTR after Ack into AD or BIND. That is useful. It is not a substitute for Option 6.
Clients still need recursive resolvers in Option 6 to find anything. Servers that get static assignments still need resolvers somewhere — DHCP option or OS config. Do not treat “names follow the lease” as “we can blank Option 6.”
Prove: lease → Option 6 resolves → then optional A/PTR update. That order matches how the product works (Replace Windows DHCP).
Soft product line
Community covers Option 6 on one node. Starter HA does not change what Option 6 means — only where dhcpd runs behind the VIP (Pricing, HA).
Soft next step
Prove one VLAN with Option 6 unchanged. Soft-read Replace Windows DHCP and Why switch off Windows DHCP and the spreadsheet. Community for 1,000 managed IPs; Starter trial in the portal when you want HA (Pricing, Signup).
latticeddi.com