Are SVCB queries sent through pi-hole of blocking concern?

As said before, I've been collecting DoH information for 2.5 years now.

I don't know if any of you looked at the svcb server list and svcb data list, I added in one of the posts?
Given the DNS server selection a user can choose from, while installing pi-hole (looking at basic-install.sh here), 6 out of 9 choices return valid svcb data. True, some users install unbound, cloudflared, ... as upstream, but some users will simply use one of the recommended upstream choices. This implies even a good behaving client, such as apparently the apple devices, will get valid svcb info, usable to setup a DoH / DoT / DoQ client, thus bypassing pi-hole.

Let's be clear, whenever I read an interesting topic like this, I investigate to the best of my abilities, the possible ways an app / device could use the feature to bypass pi-hole, trying to find appropriate measures to prevent this, however, most of the users will not invest that amount of time to ensure bypassing doesn't work, they will simply assume pi-hole takes care of this, hence the suggestion to implement BLOCK_SVCB=true, but, as always, it's up to the developers to decide.

For now, the regex and the firewall redirection appear to cover the basics, as said before, a decent suricata rule to block type64 will ensure this method (svcb data) will not work.

Hardcoded IP addresses (and ports) will work for providers, such as clouflare, google, quad9, ... however, a lot of the discovered DoH servers are hosted at cloud providers (aws, rackspacecloud, ...) The addresses for these domains change all the time, I even had to get creative to maintain DoH IP blocking, using unbound RPZ. Hardcoding won't work here, DNS (port 53) queries will always be required to get the DoH / DoT / DoQ info.

Of course, you're HTTPS API solution bypasses everything, this sounds like an alternative for DNS, don't give them ideas...

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.