DNS, DoH, DoT, DoQ, DNSCrypt, DNSSEC - Privacy and Filtering

[OPNenthu]

I think this is as good a thread as any to request a peer review of a DNS rule matrix and maybe some others will get something from it, too.

I made some updates to try and take DoQ (DNS-over-QUIC) and DoH3 (DNS-over-HTTP/3) into account, but this might have some holes in it that I'd be grateful to get feedback on.  Blocking these protocols and all their known/common ports (at a minimum) is becoming tedious.

The goals:

• Redirect plain DNS (Do53) to OPNsense on a loopback device
• Block plain DNS escapes and also DoT (tcp/853) outbound
• Block DoQ to standard UDP ports (853, 784) outbound
• Block DoH (tcp/443) and DoH3 (udp/443) to public DNS IP lists ...but try to minimize breakage of HTTP/3 and QUIC for general web traffic!
• Cover a few lesser known but still "standard" or semi-standard ports
• Selectively allow some web clients to Quad9 for all encrypted protocols including their new DoH3/DoQ.  These are mainly Androids with "private DNS" turned on and have no plain DNS fallback for when at home.

For the resolver IP block lists ("NETS_PUBLIC_DNS") I use these:

• https://raw.githubusercontent.com/dibdot/DoH-IP-blocklists/refs/heads/master/doh-ipv4.txt
• https://raw.githubusercontent.com/dibdot/DoH-IP-blocklists/refs/heads/master/doh-ipv6.txt
• https://public-dns.info/nameservers.txt
• https://raw.githubusercontent.com/oneoffdallas/dohservers/master/iplist.txt
• https://raw.githubusercontent.com/oneoffdallas/dohservers/refs/heads/master/ipv6list.txt
• https://raw.githubusercontent.com/jameshas/Public-DoH-Lists/refs/heads/main/lists/doh_ips_plain.txt

*There is an embedded alias within this one for adding negated overrides (!host) in case an important site breaks.

For DNS-based block lists in Unbound I use:

• [hagezi] DoH/VPN/TOR/Proxy Bypass (built-in)
• [hagezi] Dynamic DNS blocking (built-in)
• https://dbl.ipfire.org/lists/doh/domains.txt

*Ditto, Unbound supports allowlist overrides to fix the occasional break.

Rules on local interface group:
You cannot view this attachment.

DNAT (using auto "Pass" rule):
You cannot view this attachment.

Ports alias:
You cannot view this attachment.


Are there cracks here for things to slip through, aside from 1) remote services on non-standard ports, and 2) missed resolver IPs in block lists?

[nero355]

but try to minimize breakage of HTTP/3 and QUIC for general web traffic!

Why ?!

The whole reason QUIC exists is so that it can be used for advertising since it bypasses your DNS based adblocking !!

If you can kill it : JUST DO IT! :)
_{Not like Nike LOL!}

[OPNenthu]

There's no easy way to block any of these as they can run on non-standard ports.  What method do you recommend that doesn't require enterprise level setups?  Can my rules be improved upon other than just bluntly blocking udp/443 and udp/853?

[nero355]

What method do you recommend that doesn't require enterprise level setups?

- Chromium based browsers : chrome://flags
- Microsoft Edge specific : edge://flags
- Mozilla Firefox based browsers : about:config
With the small exception that the regular Android version does not support this sadly and only the Android Nightly version does !!

Simply do whatever you can as much as possible and hope for the best :)

[Mario_Rossi]

I think I've achieved a good level of DNS management.

These are my NAT rules:
You cannot view this attachment.
I take everything not destined for AGH on port 53 and 853 and forward it to AGH.
I take everything not arriving from AGH to Unbound and forward it to AGH (so only AGH can query Unbound).
I take everything not arriving from Unbound/OPNsense to DNSCrypt and forward it to AGH (so only Unbound/OPNsense can query DNSCrypt).


While these are my firewall rules:
You cannot view this attachment.
All local networks can reach AGH on ports 53/443/853 UDP/TCP.
The smart TV on the Guest VLAN can only access the Internet through ports 80 and 443 UDP/TCP; everything else is blocked.
Other objects on the Guest VLAN can only access the Internet.

This is the AGH encryption configuration
You cannot view this attachment.

In the AGH logs, I see that it handles:
Type: A, Simple DNS
Type: AAAA, Simple DNS
Type: A, DNS over TLS
Type: HTTPS, Simple DNS

All DNS traffic (and variants) passing through standard ports should be handled.
Now everything else is missing, and for that I can't find anything better than a Layer-7 filter.
Without paying for external software like Zenarmor, the only valid alternative at home is Suricata.

[felipe0123]

I while ago I was trying to accomplish something similar, here's what I did:

- local Unbound + blocklists
- NAT rule redirecting all DNS queries to locally running unbound
- OPNsense firewall blocking known DoH/T/... hosts traffic, to accomplish that I'm relying on public lists like https://github.com/hagezi/dns-blocklists and https://github.com/dibdot/DoH-IP-blocklists + https://github.com/galmeida/blocklist-dns-resolver. blocklist-dns-resolver allows me to exclude entries from those lists based on their domain or IP. I realized I needed blocklist-dns-resolver because some GitHub CDN hosts and app servers used by iOS and MacOS are in those lists.

[Mario_Rossi]

Okay, but here we're still talking about DNS filters on more or less standard ports.
Everything that's encrypted DNS and on non-standard ports can't be stopped with these lists on unbound or various DNS servers.
We need a layer 7, possibly without HTTPS inspection, but one that can at least understand from the patterns what's in the packet and can at least read the SNI field.

[OPNenthu]

- Or you could use Pi-Hole + Unbound the way it's explained here : https://docs.pi-hole.net/guides/dns/unbound/

Their main website (https://pi-hole.net/) get blocked on my end by a DoH IP list.  Looks like a CDN domain (*.b-cdn.net) according to uBlock origin and it has a high abuse score to boot:

https://www.ipqualityscore.com/free-ip-lookup-proxy-vpn-test/lookup/37.19.207.37

I've used Pi-Hole in the past and wanted to experiment with it again in a Proxmox container, but I don't want to whitelist these IPs.  Not a good look for a privacy-focused DNS project :-/

No issue with their GitHub repo, though.

As I haven't used Pi-Hole in years and haven't followed the project, do you still find them trustworthy now in 2026?  Any concerning developments or money ties?