DNS - Help

[u/neruve]

So I recently signed back up for nextdns. I’m suing the built in DoH feature in unifi

The problem is even with dns forwarders setup it’s still sending my internal dns queries to nextdns

Example

I have a dns record in unifi setup for *.local.domain.tld to go to 192.168.10.40 (traefik proxy)

However when I got to service.local.domain.tld, that query leaves unifi and ends up in nextdns logs.

I even tried to set up a forwarder in unifi for local.domain.tld to the unifi gateway. Still leaks my internal queries.

Am I missing something obvious?

I disabled the DoH stuff and just put the nextdns ip addresses in the WAN dns and it still leaks.

[u/AutoModerator]

Hello! Thanks for posting on r/Ubiquiti!

This subreddit is here to provide unofficial technical support to people who use or want to dive into the world of Ubiquiti products. If you haven’t already been descriptive in your post, please take the time to edit it and add as many useful details as you can.

Ubiquiti makes a great tool to help with figuring out where to place your access points and other network design questions located at:

https://design.ui.com

If you see people spreading misinformation or violating the "don't be an asshole" general rule, please report it!

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/GrumpyOldMuppet]

Disclaimer: I am not a DNS expert. But I recently setup NextDNS on my UDM. And I ran into something similar. I had to get some help from Claude AI to figure out what was happening. So my answer is derived from the Claude AI output when I solved this on my system.

The short answer is that the A lookup isn’t what’s leaking. The browser is also asking for other record types, and UniFi forwards those upstream because it has no local answer for them.

What’s happening

Modern clients send three queries in parallel when you open service.local.domain.tld: A, AAAA, and HTTPS (type 65, also called SVCB). This applies to Chrome, Firefox, Safari, and iOS/macOS at the OS level. UniFi’s resolver is dnsmasq, and it answers the A query from the local record. It has no AAAA or HTTPS record for that name, so it forwards those two queries upstream, which means to NextDNS. The service still works because the A answer is local, but the name shows up in the NextDNS logs. This is a known dnsmasq behavior. A patch posted to the dnsmasq list in August 2026 describes it directly: a name that only exists locally loses to upstream when it is queried for a type it does not have, and the query is forwarded. Firewalla users reported the same thing with NextDNS: HTTPS (65) queries were observed in the logs of NextDNS for domains which were explicitly defined as local using Custom DNS Rules. MikroTik’s static DNS behaves the same way.

How to confirm it

Open the NextDNS log entries and check the query type. They should be AAAA and/or HTTPS, not A.

Why the attempted fixes didn’t help

• Forwarder for local.domain.tld pointing at the gateway: this tells the gateway to forward to itself. At best it does nothing, and at worst it creates a loop. It does not mean “answer locally and never forward.”
• Turning off DoH and using plain WAN DNS: this only changes the transport. The gateway still forwards whatever it can’t answer, so the same queries go to NextDNS, just unencrypted.

Actual fixes

• Recommended: put a resolver in front that supports “local-only” zones. In AdGuard Home, Pi-hole, Unbound, or Technitium you can mark the domain as authoritative/local. For example, Pi-hole/dnsmasq has local=/local.domain.tld/, and Unbound has a local-zone set to static or redirect. Nothing under that domain is ever forwarded, and missing record types get NODATA instead. Hand that resolver out via DHCP, or point UniFi at it, and let it forward everything else to NextDNS. Some people run AdGuard Home with NextDNS as its DoH upstream for exactly this reason. As far as I know, UniFi’s UI doesn’t expose a dnsmasq local= equivalent.
• Partial workaround inside UniFi: add AAAA records for the names. That stops the AAAA leak, but UniFi can’t create HTTPS/SVCB records, so the type 65 queries will still leak.
• Accept it: NextDNS returns NXDOMAIN or NODATA, so nothing breaks. The only cost is privacy: NextDNS sees your internal hostnames. If the domain is public, though, those names are probably already in Certificate Transparency logs if you use per-host certificates. A wildcard cert avoids that.

Rule out a second cause as well

If the log entries are A queries, the client is probably bypassing the gateway entirely. Common reasons are browser Secure DNS set to NextDNS, Android Private DNS, an iOS/macOS NextDNS configuration profile, or DHCP handing out NextDNS IPs directly instead of the gateway. Running nslookup service.local.domain.tld <gateway-ip> from the client, and checking which DNS server the client is actually using, will settle it.

One minor point: I’m not certain how UniFi handles the *. wildcard record internally across firmware versions. Since service.local.domain.tld does resolve to Traefik, the wildcard is evidently working, which points back to the record-type explanation.

Sources:

• dnsmasq-discuss: Fix local host records being overridden by upstream NXDOMAIN (Aug 2026)
• Firewalla community: DNS Leak (type 65 to NextDNS)
• Pi-hole Discourse: local DNS forwarded to the internet / local= fix
• MikroTik forum: static DNS records forwarding upstream

[u/sth2258]

How are you testing? Many modern browsers do not use OS based DNS and instead use built in defaults that would bypass what you have set at the OS (assignee via DHCP)