If your UniFi setup runs multiple VLANs and you want IoT devices hitting a filtered resolver, Active Directory clients pointing at an internal DNS server, and the guest network going straight to Cloudflare — the exact path in the UniFi Network application is less obvious than it should be. The DNS-per-VLAN setting has moved across firmware generations, carries a well-known trap when you aim it back at the router's own IP, and fails silently in ways that only surface when you run dig and see the wrong nameserver answering. This guide covers the exact UI steps for every major UniFi software version, CLI verification on Windows, macOS, and Linux, and how to avoid the most common misconfigurations.

Why You Need Different DNS on Each VLAN

A flat DHCP config hands every device the same DNS server. That breaks down fast when your network is segmented:

  • IoT VLAN — lock smart devices to a filtered resolver like Cloudflare 1.1.1.3, CleanBrowsing, or a local Pi-hole to block telemetry callbacks and malicious domains without touching other networks.
  • Corporate or LAN VLAN — Windows AD environments require devices to resolve against the domain controller. Routing those queries to 8.8.8.8 breaks Group Policy, Kerberos, and internal hostname resolution immediately.
  • Guest VLAN — guests get a public resolver with zero visibility into internal hostnames. Add optional content filtering with OpenDNS Family Shield at 208.67.222.123.
  • Management VLAN — route to Pi-hole or an internal recursive resolver like Unbound for full query logging without polluting guest or IoT traffic.

UniFi's DHCP service on the gateway — whether that's a UDM, UDM Pro, UDM-SE, UDR, or a CloudKey running the Network application — sends DHCP option 6 (DNS server addresses) per network. Each VLAN maps to one network definition, giving you independent DNS per VLAN once you find the right field in the UI.

Which UniFi UI Version Are You On

Ubiquiti has shipped three distinct UI generations for the Network application, and the DNS setting location differs across all three:

  • Classic UI (Network 6.x and earlier) — dark sidebar, table-based network editor. The DNS field is labeled DHCP Name Server.
  • New UI First Generation (Network 7.x) — white card layout. DNS is under Advanced inside the network editor. Some builds require toggling Show Advanced Options.
  • New UI Current (Network 8.x and 9.x, 2024 to 2026) — fully redesigned. DHCP and DNS are inline in the network editor under a dedicated DHCP section.

Check your version at Settings → System → Updates or the version string at the bottom of any settings page. Steps below start with the current version.

Setting Custom DNS Per VLAN in UniFi Network 8.x and 9.x

This path applies to UniFi OS 3.x and Network application 8.x or later, running on UDM Pro, UDM-SE, UDM Pro Max, or CloudKey Gen2+.

  1. Open the UniFi Network application and click Settings (gear icon, bottom-left).
  2. Select Networks from the left sidebar.
  3. Click the network you want to modify — for example, your IoT or guest VLAN.
  4. Scroll to the DHCP section. Expand it if it appears collapsed.
  5. Under DNS Server, change the dropdown from Auto to Manual.
  6. Enter up to four DNS server IPs. For Cloudflare: 1.1.1.1 and 1.0.0.1. For Google: 8.8.8.8 and 8.8.4.4. For a local Pi-hole: enter the Pi-hole's LAN IP as primary and a public resolver as fallback.
  7. Click Save. The change applies immediately to new DHCP leases. Existing devices pick it up on lease renewal or after a manual release and renew.
💡 Before pushing a new resolver to production VLANs, confirm it is answering correctly for your key domains using the DNS Propagation Checker. A misconfigured upstream DNS fails silently — devices on that VLAN simply stop resolving names with no obvious error message.

Classic UI (Network 6.x) and Network 7.x

On Network 6.x with the classic dark UI:

  1. Go to Settings → Networks.
  2. Click the pencil icon on the target network.
  3. Scroll to DHCP Name Server. Switch from Auto to Manual.
  4. Fill in DNS Server 1 and DNS Server 2. Save.

On Network 7.x with the white card UI, the DNS field is inside the network editor card. If it is not immediately visible, look for a Show Advanced Options toggle near the top of the panel — the DNS field appears after enabling it.

The Router-IP Trap

A very common mistake is setting the VLAN's DNS server to the UniFi router's own gateway IP — for example 192.168.30.1 on a VLAN using the 192.168.30.0/24 subnet. The UDM does run a DNS forwarder (dnsmasq on older firmware, a modified resolver on newer builds), so queries appear to work. The problem is threefold:

  • No per-VLAN filtering — the router's forwarder sends all queries to the same upstream resolvers regardless of which VLAN originated them. Your IoT filter never applies.
  • Circular override — pointing DHCP option 6 at the router means your Manual setting produces no different result from Auto, since the router just forwards everything upstream anyway.
  • Single point of failure — a router restart kills DNS on all VLANs simultaneously rather than just one.

The one valid exception: if you have AdGuard Home installed directly on the UDM via the community package manager or SSH, it intercepts port 53 before dnsmasq. Pointing DHCP DNS at the router IP is then intentional and correct. Confirm AdGuard is running before relying on this assumption:

ssh root@<udm-ip> ps aux | grep AdGuardHome

If that returns a process entry, the router-IP approach is valid for your config. If not, point the VLAN to an external resolver or a Pi-hole on a dedicated host.

Pi-hole Across VLANs — Firewall Rule Required

If your Pi-hole lives on VLAN 10 (management, 192.168.10.0/24) and IoT devices on VLAN 30 need to use it, cross-VLAN traffic must be explicitly permitted. Without a firewall rule, IoT devices time out on DNS queries and fall back to your secondary resolver — or fail entirely if no secondary is configured.

In UniFi Network 8.x, add the allow rule:

  1. Go to Settings → Firewall & Security → Rules.
  2. Add a new LAN In rule (traffic entering the router from a LAN-side VLAN).
  3. Set: Action = Accept, Source = IoT network subnet, Destination = Pi-hole IP, Protocol = TCP/UDP, Port = 53.
  4. Position this rule above any inter-VLAN drop rules. UniFi evaluates rules top-to-bottom; a catch-all deny above your accept silently blocks every DNS query.

Then set the IoT network's DHCP DNS to the Pi-hole IP as primary with a public resolver as secondary. The firewall rule is only needed when you already have a default inter-VLAN deny in place, which is best practice for IoT isolation anyway.

Forcing DNS Through Your Resolver — Blocking Hardcoded Bypass

Even with DHCP option 6 set correctly, a device can hardcode its own DNS and completely ignore DHCP. Smart TVs, game consoles, and certain IoT firmware frequently do this — pointing themselves at 8.8.8.8 regardless of what the network advertises. To enforce your assigned resolver, redirect all outbound port 53 traffic.

On UniFi OS with Traffic Rules available (Network 8.x and later):

  1. Go to Settings → Firewall & Security → Traffic Rules.
  2. Create a rule: block outbound TCP/UDP port 53 to any destination that is not your designated resolver IP.
  3. Add a separate accept rule for TCP/UDP port 53 to your resolver IP, placed above the block rule in the list.

For devices using DNS over HTTPS (port 443), traffic rules are not enough — DoH traffic is indistinguishable from normal HTTPS without deep packet inspection. To neutralize automatic DoH on IoT VLANs, block outbound connections from the IoT subnet to the major DoH resolver IPs (1.1.1.1, 1.0.0.1, 8.8.8.8, 8.8.4.4, 9.9.9.9, 94.140.14.14) on TCP port 443. This catches the majority of auto-configured DoH clients without requiring IPS hardware.

CLI Verification — Confirm the Right Resolver Is Answering

After saving the config and renewing your DHCP lease, verify which resolver is actually serving queries. Do not assume the UI change worked — test from a device on the target VLAN.

Linux

resolvectl status # Or on older distributions without systemd-resolved: cat /etc/resolv.conf # Query with an explicit server to baseline correctness: dig @1.1.1.1 example.com A # Check which server answered your system default query: dig example.com A | grep SERVER

macOS

scutil --dns | grep nameserver # Flush the DNS cache after DHCP renewal: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder # Verify the resolver in use: dig example.com A | grep SERVER

Windows

ipconfig /all REM Look for DNS Servers under the correct network adapter nslookup example.com REM Default Server line shows the active resolver REM Force DHCP lease renewal: ipconfig /release ipconfig /renew

iOS and Android

On iOS: go to Settings → Wi-Fi → [network name] → (i) → Configure DNS. If it shows Automatic with the correct IPs from your UniFi config, the push is working. On Android: Settings → Network & Internet → Wi-Fi → [network] → Advanced displays the DHCP-assigned DNS. One important catch — Android's Private DNS setting (DNS over TLS, under Network settings) overrides DHCP-assigned DNS entirely. If Private DNS is set to anything other than Off, your UniFi DHCP DNS setting is silently ignored for that device.

💡 Use the DNS Lookup tool to confirm that the resolvers you are assigning — Pi-hole IP, Cloudflare, or an internal AD DNS server — return correct records for both public domains and your internal hostnames before pushing the config to production VLANs.

IPv6, DoH, and DNSSEC in 2026

DHCP option 6 assigns a resolver IP but does not control the protocol clients use to reach it. Three considerations specific to current deployments:

  • IPv6 DNS (DHCPv6 option 23) — if your VLANs have IPv6 enabled, devices receive separate IPv6 DNS addresses via DHCPv6 or SLAAC router advertisements. In UniFi Network 8.x, check the IPv6 subsection of the network editor for a separate DNS field and set it explicitly. A device with an IPv6 address can bypass your IPv4 Pi-hole entirely by querying an IPv6 resolver. Cloudflare's IPv6 DNS: 2606:4700:4700::1111 and 2606:4700:4700::1001.
  • DoH bypass — Firefox, Chrome, and Android 9 and later default to encrypted DNS over HTTPS, ignoring DHCP option 6 completely. Per-VLAN DNS enforcement for these clients requires the port 53 redirect and DoH IP blocking described in the previous section.
  • DNSSEC — public resolvers like 1.1.1.1 and 8.8.8.8 validate DNSSEC automatically; you get this for free. If you run Unbound as an internal recursive resolver, enable DNSSEC validation in unbound.conf with val-permissive-mode: no. Pi-hole in forwarding mode inherits DNSSEC behavior from its upstream; for end-to-end validation, run a local Unbound instance and configure Pi-hole to use it as upstream instead of a public resolver.

The DHCP option 6 mechanism used by UniFi is specified in RFC 2132 — DHCP Options and BOOTP Vendor Extensions, which defines DNS server delivery as advisory rather than enforced. That is why a client with a hardcoded or DoH-based resolver can legally ignore it — the RFC makes no provision for the server to mandate compliance.

Common Misdiagnoses

Setting reverts to Auto after saving

Check whether DHCP Guarding is enabled on the network. Certain UniFi builds force DNS back to the router when Guarding is active. Disable Guarding, set DNS to Manual, then save again.

Devices ignore the new DNS after the change

DHCP leases default to 24 hours in UniFi. The device will not pick up the new setting until lease renewal. Force it on Windows with ipconfig /release followed by ipconfig /renew. On Linux, run sudo dhclient -r eth0 && sudo dhclient eth0 on the correct interface, or disconnect and reconnect. On iOS and Android, forget the network and rejoin, or toggle Wi-Fi off and back on.

Pi-hole log shows no queries from IoT devices

Either the firewall rule is missing or it sits below a deny-all inter-VLAN rule. Check Settings → Firewall & Security → Rules and confirm your accept rule for TCP/UDP port 53 from the IoT subnet to the Pi-hole IP is above the inter-VLAN block. Also verify Pi-hole is listening on the right interface: Pi-hole admin → Settings → DNS → Interface settings → set to Listen on all interfaces.

Internal hostnames stop resolving after switching to public DNS

You've pointed the VLAN at 1.1.1.1, but devices still need to resolve internal names like corp.local or nas.home. Public resolvers have no knowledge of RFC 1918 hostnames. Fix options: (a) keep the internal resolver as primary with a public resolver as secondary, (b) run Pi-hole with local DNS entries for your internal hostnames, or (c) use Pi-hole conditional forwarding to send internal domain queries to your AD DNS while forwarding everything else upstream.

macOS shows wrong DNS even after DHCP renewal

macOS caches DNS aggressively at the system level. After a DHCP renewal, flush the cache: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Run scutil --dns again afterward to confirm the new resolver is registered before testing.

Confirming the Fix Worked

After a DHCP renewal on the target VLAN, run these four checks before closing the ticket:

  1. ipconfig /all on Windows or resolvectl status on Linux — the DNS Server field must show your intended IP, not the router gateway.
  2. nslookup example.com — the Server line must match your intended resolver, not 192.168.x.1.
  3. If using Pi-hole — open the Pi-hole admin Query Log in real time and make a DNS request from the device. The device's LAN IP must appear in the log within seconds.
  4. If using filtered DNS — query a known-blocked domain (for example doubleclick.net) from the IoT device. The response must be NXDOMAIN or the Pi-hole block page IP, not a real A record.

Preventing Future Drift

  • Document per-VLAN DNS assignments in a network diagram or internal wiki. UniFi provides no single-view summary of which DNS server each network uses — you will not remember in six months.
  • After firmware upgrades, spot-check DHCP DNS on each network. Major version upgrades on UniFi OS have been known to reset Manual DNS fields back to Auto, silently removing your configuration.
  • Always configure a secondary DNS fallback IP for every VLAN. If Pi-hole goes offline with no fallback set, all devices on that VLAN lose all DNS resolution entirely — not just ad blocking, but every name lookup.
  • Monitor Pi-hole uptime independently with a tool like Uptime Kuma or a simple HTTP check. A silent Pi-hole failure with no fallback DNS is indistinguishable from a complete network outage from the end device's perspective.