UniFi Gateway DNS Filtering: Content Filtering, Ad Blocking, and Encrypted DNS Per Network

Do you know which resolver every device on your network is actually asking? If you count on a UniFi gateway to filter content or block ads, you need to know, because each of those features only works when the client sends its DNS lookups to the gateway.

UniFi Network gives its gateways three DNS-related controls: content filtering, ad blocking, and encrypted DNS. They look like separate toggles in the Security settings, but they affect each other, and those interactions decide whether a rule still holds once a client starts resolving names on its own.

This guide covers how each feature works, where clients get around them, and how to scope each control to the networks that need it. Keep in mind that the menus have moved between UniFi Network releases, so use the paths here as a rough map and check them against the version running on your console.

Content filtering on a UniFi gateway is a policy that runs in the resolver. When a client on a filtered network asks the gateway to resolve a hostname, the gateway checks that name against a category database before it answers.

If the domain falls into a blocked category, the client gets a blocked response instead of the real address, so the connection never starts. That said, the filter never inspects the traffic itself — it only controls which names resolve.

Ubiquiti has historically offered preset levels rather than a blank slate, and the categories available to you depend on your Network version and whether a CyberSecure subscription is active on the gateway. The main pieces include:

• Preset levels. The Work and Family presets group categories such as adult content, malware, and phishing into one toggle. The stricter level adds gambling and similar categories.
• Category selection. Recent releases, especially with CyberSecure turned on, show a longer category list. That lets you block specific types of content instead of taking a whole preset.
• Safe Search enforcement. The gateway can rewrite DNS answers for Google, Bing, and YouTube so they point to the safe versions of those services. For YouTube, that means Restricted Mode.
• Allow and block lists. Domain-level exceptions let you unblock a false positive or block a specific domain the category database misses.

All of these take effect at lookup time. That makes filtering fast and cheap for the gateway, but it also means the filter is only as strong as your control over which resolver the client uses.

Be aware of DNS caching as well. A client that looked up a domain before you turned on the rule keeps that cached answer until its TTL runs out, so a new rule can look broken for several minutes when it is actually working.

Ad blocking uses the same mechanism with a different list. Instead of a category database, the gateway checks lookups against a list of known advertising and tracking domains and returns a blocked or empty answer when one matches.

The practical differences come down to scope and how things break:

• What gets blocked. Content filtering targets whole categories of sites. Ad blocking targets the third-party ad and tracking servers those sites load.
• How things break. When content filtering blocks something, it is obvious, because the whole site will not load. When ad blocking breaks something, it is easy to miss: a checkout iframe, a smart TV app's login flow, or a sponsored-link redirect stops working, and people rarely blame the network.
• What it cannot block. Some major video platforms serve ads from the same domain as the video itself. DNS can only block whole hostnames, so it cannot separate those ads from the content.

Keep in mind that ad blocking on IoT and streaming networks can be very useful, because smart TVs and streaming sticks contact tracking domains constantly. Moreover, those devices cannot run browser extensions, so the gateway is the only place you can block anything for them.

Encrypted DNS on a UniFi gateway, called DNS Shield in several Network releases, uses DNS-over-HTTPS to encrypt the connection between the gateway and its upstream resolver. Your ISP can no longer see the names your network looks up, and tampering with upstream answers in transit becomes much harder.

That protection covers only one part of the path. Clients still send plain DNS to the gateway on the LAN, and the gateway then forwards those queries over an encrypted connection to a provider such as Cloudflare, Google, Quad9, or NextDNS, or to a custom server you set up.

The interaction with filtering is where operators get caught out. Content filtering and encrypted DNS both need control of the gateway's upstream lookups, and UniFi has handled that conflict differently across releases — in some versions, turning on one has changed or disabled the other.

Accordingly, after you turn on both, test each one separately rather than trusting the dashboard toggles. A test domain in a blocked category should still fail to resolve, and a DNS leak test from a client should show your chosen encrypted provider rather than your ISP's resolver.

The other half of the problem is encrypted DNS on the clients themselves. Here are the main ways clients bypass the gateway:

• Browser DoH. Firefox, Chrome, Edge, and Safari can send lookups over HTTPS on port 443 straight to a DNS provider and skip the gateway entirely.
• OS-level encrypted DNS. Windows 11, recent macOS and iOS releases, and Android's Private DNS can be set to use an encrypted resolver for the whole device. Android's Private DNS uses DNS-over-TLS on port 853.
• Hardcoded resolvers. Some streaming devices and IoT hardware ship with a fixed DNS server, usually a public resolver on port 53. They ignore whatever DNS server DHCP gives them.
• VPN and relay services. A VPN client or a relay like iCloud Private Relay sends DNS through its tunnel along with everything else, so the gateway never sees the lookup.

None of these are unusual. In fact, some browsers turn on DoH automatically when they detect a supported resolver, so a filtered network can leak lookups even when nobody on it is trying to get around the filter.

Filtering only works when the gateway is the only resolver a client can reach. On UniFi Network releases with the zone-based firewall, that means writing a short set of policies for each filtered zone. Our UniFi zone firewall guide explains how those policies work.

The policies go in this order:

1. Allow DNS to the gateway. Permit UDP and TCP port 53 from the filtered network to the gateway's own address on that network.
2. Block outbound plain DNS. Drop UDP and TCP port 53 from the filtered network to the External zone so hardcoded resolvers fail.
3. Block DNS-over-TLS. Drop outbound TCP port 853, which stops Android Private DNS and other DoT clients from reaching a public resolver.
4. Block known DoH endpoints. Build an IP or domain group for the major DoH providers and block port 443 to those destinations from the filtered network.

The first three rules are simple and dependable. The fourth needs regular upkeep, because DoH uses port 443 just like normal web traffic and providers add new endpoints often.

Two lighter controls help with what the rules miss. Firefox checks a canary domain, use-application-dns.net, and turns off automatic DoH when that lookup fails, so adding that domain to the gateway's block list disables Firefox's default DoH for most users.

For devices you manage, browser and OS policy settings can turn off DoH completely. That setting lives in your device management tools rather than on the gateway, but it is the most reliable fix for a home or office fleet of laptops you control.

Remember that devices with hardcoded DNS sometimes stop working when outbound port 53 is blocked, instead of falling back to the gateway. If a device breaks after rule two, check whether your release automatically redirects port 53 traffic to the gateway on that network. If it does not, the usual fix is a destination NAT rule that sends outbound port 53 traffic to the gateway.

Every control in this guide is set per network rather than globally. That fits naturally with a VLAN plan. If you have not split your network into VLANs yet, start with UniFi VLANs explained, because without separate networks you are stuck with one DNS policy for every device you own.

A typical home-lab or small-office plan sets the controls like this:

Network	Content filtering	Ad blocking	Bypass enforcement
Trusted LAN	Off, or malware and phishing only	Optional	Light — adults may run their own DoH
Kids / family	Family preset plus Safe Search	On	Full rule set, including DoH blocks
IoT	Off	On	Block outbound 53 and 853
Guest	Malware and phishing categories	On	Block outbound 53 and 853
Management	Off	Off	Not applicable — lock down by firewall

The IoT row needs a note. Ad blocking cuts down on tracking traffic from TVs and appliances, but content filtering does little there because those devices do not browse. Our Home Assistant IoT VLAN guide shows how to keep those devices on their own network without breaking device discovery.

Guest networks need only light filtering. Blocking malware and phishing categories protects visitors and keeps your connection from being used for abuse, and the UniFi guest networks guide covers how to isolate guests from the rest of your network.

Recent Network releases also let you apply content filtering to specific client devices instead of whole networks. That helps with something like one shared tablet on the trusted LAN, although network-level rules are easier to review when you come back to the configuration a year later.

Note that a client's DNS server comes from its DHCP lease. If a network's DHCP DNS option points to a resolver other than the gateway, such as a Pi-hole, the gateway's content filtering and ad blocking never see those queries, even when the toggles show as on.

Test every rule from a client on the target network, not from the console. These four checks catch most mistakes:

• Resolver check. Run nslookup or dig against a known domain and confirm the answer comes from the gateway's address on that VLAN.
• Category check. Look up a domain in a blocked category and confirm it fails or returns the block response.
• Bypass check. Query a public resolver directly on port 53 and over DoT. Both should time out once the firewall rules are in place.
• Leak check. Run a DNS leak test in a browser with DoH left at its default setting to confirm the browser is not going around the gateway.

Most failures come from one of three causes. When a rule shows as on but does nothing, the reason is almost always a stale client cache, a DHCP DNS option pointing somewhere else, or a browser using its own DoH.

At some point the built-in tools stop being enough. A separate resolver such as Pi-hole or AdGuard Home is worth running when you need query logs per client, regex blocking, conditional forwarding for local domains, or allowlists that change every week. It can run on the same small machine you use for Home Assistant.

If you go that route, point each network's DHCP DNS option at the resolver and keep the same firewall rules, using the resolver's address instead of the gateway's. Then turn off the gateway's own filtering on those networks, so you only have one set of filters to troubleshoot.

Finally, pick a gateway that can handle every security feature you plan to turn on. DNS filtering is light work for any current UniFi gateway, but adding threat management can cut throughput. Our IDS/IPS throughput guide and the UniFi gateway buyer's guide cover that tradeoff, and the full lineup is on our gateways page.

If you're planning a VLAN layout and want filtering that holds up against browser DoH and hardcoded resolvers, start with the network map. Write the bypass rules before you turn on the filters, then test from a client on every network you filter.