Unbound DNS returning NXDOMAIN only for some domain lookups

[foss-johnny]

I'm using wireguard to connect from an iphone to opnsense.

The tunnel is working and my DNS is resolving most domains. DNS is using ubnbound, and the wireguard client is set to wireguard tunnel ip.

I'm finding that some domain return "NXDOMAIN" and do not resolve to an ip when using nslookup/dig.

Example: x.com doesn't resolver and either do some iphone apple.com services.

What could be causing this?

[foss-johnny]

After further fiddling, when I disable DNS over TLS and tick "Use system nameservers", then in System > Settings > General add 1.1.1.1 to the DNS servers list, DNS resolution is working.

Does anyone know why DNS over TLS resolution does not work for all domains?

[OPNenthu]

I ran into something like this before.  If it's only certain domains not resolving then my first guess is you either have some strict DNS setting enabled like "QNAME Minimisation" that breaks some sites, or the particular DoT provider you are forwarding to is doing some filtering.

[foss-johnny]

I ran into something like this before.  If it's only certain domains not resolving then my first guess is you either have some strict DNS setting enabled like "QNAME Minimisation" that breaks some sites, or the particular DoT provider you are forwarding to is doing some filtering.

Thank you OPNenthu. It turned out to be the DoT DNS provider I was using. It was filtering ads, malware and viruses. After changing the DNS server to the option that does not filter anything, DNS is now resolving. Appreciate your help to narrow it down, and hope this post helps someone else in future.

If anyone else knows why this causes NXDOMAIN responses, it would be useful to understand it further?

[dseven]

There are different methods for DNS blocking - here's one (TL;DR) discussion about them: https://support.adamnet.works/t/comparing-dns-blocking-methods/1245

Presumably your DoT DNS provider chose the NXDOMAIN method. You'd have to ask them why...

[OPNenthu]

I actually prefer the NXDOMAIN response and leave this enabled in my Unbound settings (Services->Unbound DNS->Blocklist->"advanced mode" ticked->Return NXDOMAIN").

I've read somewhere (long ago) that Apple devices sometimes don't respond well to "0.0.0.0" from DNS and in those cases NXDOMAIN works better.  I don't know if this is true or not but in my home network with an older iOS device I haven't noticed any problems so far.  YMMV.

The more valid reason to use it has to do with iCloud Private Relay.  If you have a requirement to disable that so that it doesn't bypass your DNS filtering, then you need to sinkhole a few specific Apple domains with NXDOMAIN.  More on that here:

https://help.dnsfilter.com/hc/en-us/articles/14811352360083-Block-Apple-iCloud-Private-Relay-from-bypassing-DNSFilter

https://developer.apple.com/icloud/prepare-your-network-for-icloud-private-relay/

Finally (personal opinion) I feel that returning "0.0.0.0" is a clear signal to a client that they've been filtered.  In a school/work environment that's not a problem and you'll likely have some message from your IT department notifying you of the block anyway.  In a home network with potentially naughty IoT devices, why give away that information just to encourage them to try bypassing your DNS by other means?  Let them think the domain doesn't exist.  (Assuming you're also going through the trouble of redirecting or blocking all public DNS queries not destined for your DNS resolver, then I think this approach makes sense).

A potential downside to NXDOMAIN as documented by Pi-hole is that clients may retry more often:

https://docs.pi-hole.net/ftldns/blockingmode/?h=nxdomain#pi-holes-nxdomain-blocking-mode

... so maybe not the best idea for a very large network.

[foss-johnny]

There are different methods for DNS blocking - here's one (TL;DR) discussion about them: https://support.adamnet.works/t/comparing-dns-blocking-methods/1245

Presumably your DoT DNS provider chose the NXDOMAIN method. You'd have to ask them why...

Excellent post on the different methods! Thanks for sharing that.