I DON'T agree with this statement.
Here's what I investigated, using the valuable info from chrislph.
I've been collecting DoH domain names and IP addresses for 2,5 years now, available on GitHub here.
In order to find the IP addresses that need to be blocked on the firewall, I run the following commands:
dig +tries=3 +time=4 +short <domain>
this returns the IP address(es) and possible CNAME information of the domains, extracted from the lists.
now, using this query (${IP} is the result of the previous dig)
dig +tries=2 +time=3 @"${IP}" _dns.resolver.arpa svcb +short
the SVCB info is returned, some examples:
1 dns.khanhtran.me. alpn="h2" port=443 key7="/dns-query{?dns}"
1 dns.khanhtran.me. alpn="dot" port=853
1 dns.khanhtran.me. alpn="doq" port=784
1 dns.quad9.net. alpn="dot" port=853 ipv4hint=9.9.9.9,149.112.112.112 ipv6hint=2620:fe::fe
2 dns.quad9.net. alpn="h2" port=443 ipv4hint=9.9.9.9,149.112.112.112 ipv6hint=2620:fe::fe key7="/dns-query{?dns}"
1 3krkr.tonedtanya.com. alpn="h2" port=443 key7="/dns-query{?dns}"
1 3krkr.tonedtanya.com. alpn="doq" port=8853
As you can see, the SVCB info returned, contains info for DoH, DoT and DoQ, using not only ports 443 (DoH) and 853 (DoT), but also some none standard ports.
here is the list of all IPs (& domains) that reply to a SVCB query (from the DoH IP block lists)
svcb-servers.zip (5.9 KB)
here is the registered reply (SVCB info)
svcb-data.zip (4.8 KB)
In my view, the information of the first dig request can only be blocked, using a blocklist (pihole, RPZ or suricata), but the problem here is the domain must be in one of the source lists.
The second dig request will never be registered by pihole (target is @${ip} - bypasses pihole), unless, see later...
The second dig request will provide all the necessary information to a "rogue" app to use a DoH / DoT / DoQ DNS server, thus the ability to bypass pihole.
Two methods to prevent this:
- block the target IP, using a firewall rule, that blocks all known (see lists) DoH / DoT / DoQ IP's, again, the limitation is the domain must be in one of the lists
- the most effective way is probably to ensure all DNS requests, not originating from pihole are blocked, however...
If pihole is using a recursive upstream, such as unbound, the result will be NXDOMAIN (as mentioned by jfb).
If pihole is using an upstream resolver such as dns.quad9.net (as mentioned by slicedpi), a possibly "rogue" app could use this information to bypass pihole, using DoH / DoT / DoQ.
Because Apple devices appear to behave, sending the SVCB query to the configured DNS server (pihole), using the regex, mentioned earlier, will prevent any application using the provided SVCB info (blocked by regex), however, warning, I don't know if SVCB data is used to provide other info than the currently provided DNS info (see file), it may work against you in the future.
If the SVCB info is retrieved from another server than pihole, this information could be used to provide a build in dns client with the necessary info to bypass pihole.
Conclusion:
- the regex, provided earlier, only works if the client uses the system configured DNS server (like apple devices appear to do).
- to prevent apps and devices to retrieve SVCB info from other dns servers, it is necessary to configure the firewall to redirect all DNS queries, not originating from pihole, to pihole.
- port 853 appears to be the only port, used for DoT
- several ports need to be blocked to block DoQ (853, 784, 8853 in the SVCB results)
I'm currently looking into the option to block opcode type64 (SVCB) DNS requests, using suricata, no luck so far...
DL6ERs opinion would be highly appreciated. Might I suggest an FTL option to block type64 (SVCB) queries, this for less experienced users, not using a recursive upstream?
It can only deliver information by the resolver you are using anyway - but, yes, it has the potential to give them a shortcut bypassing your Pi-hole (see IP hints in the reply by