Implement _dns.resolver.arpa as a special domain or add BLOCK_SVCB as a configuration option

Ladrien · February 27, 2025, 1:29am

As it stands, pi-hole does not provide an intuitive way to block DoH bypasses by itself.

The special domain _dns.resolver.arpa is used to upgrade clients to use DNS over HTTPS, and may provide a way around the pi-hole's blocking. With a pi-hole configured forwarder of 1.1.1.1, clients resolving _dns.resolver.arpa can be directed to instead use Cloudflare's DoH server directly. This is not limited to just Cloudflare.

This not only has privacy concerns for those running unbound, but also completely negates the pi-hole's blocking unless other measures are taken, such as a firewall rule with a hard-coded IP address list is implemented. I do not believe the average user would be aware of this bypass.

Edit: Including a relevant thread: Are SVCB queries sent through pi-hole of blocking concern?

DL6ER · March 1, 2025, 12:06pm

Thank you for the suggestion, it quite obviously seems a good idea. I had a look at the other discussion, too, dating back to the end of 2022 and think I missed parts of it back then. I seem to recall having only seen the discussion about a general blocking of all SVCB queries which seemed (and still seems) over the top. But your request is nonetheless a valid one IMO, see

github.com/pi-hole/FTL

Add Discovery of Designated Resolvers special zone blocking

development ← new/dns_resolver_arpa

opened 12:04PM - 01 Mar 25 UTC

DL6ER

+45 -3

# What does this implement/fix? Add Discovery of Designated Resolvers special… zone blocking to prevent a possible way to bypass Pi-hole depending on the configured upstream. For instance, if you are using Google DNS (`8.8.8.8`) a client locally querying ``` SVCB _dns.resolver.arpa ``` would get the reply ``` _dns.resolver.arpa. 86400 IN SVCB 1 dns.google. alpn="dot" _dns.resolver.arpa. 86400 IN SVCB 2 dns.google. alpn="h2,h3" key7="/dns-query{?dns}" ``` giving them a valid path to try to evade Pi-hole's blocking. This PR adds blocking for the new special zone `resolver.arpa` described in [RFC 9462](https://datatracker.ietf.org/doc/rfc9462/) and provides `NODATA` whenever this is enabled (default on). This behavior is recommended at the end of section 4: > If the recursive resolver that receives this query has no Designated > Resolvers, it SHOULD return NODATA for queries to the "resolver.arpa" > zone, to provide a consistent and accurate signal to clients that it > does not have a Designated Resolver. --- **Related issue or feature (if applicable):** https://discourse.pi-hole.net/t/are-svcb-queries-sent-through-pi-hole-of-blocking-concern/59983 **Pull request in [docs](https://github.com/pi-hole/docs) with documentation (if applicable):** N/A --- **By submitting this pull request, I confirm the following:** 1. I have read and understood the [contributors guide](https://docs.pi-hole.net/guides/github/contributing/), as well as this entire template. I understand which branch to base my commits and Pull Requests against. 2. I have commented my proposed changes within the code. 3. I am willing to help maintain this change if there are issues with it later. 4. It is compatible with the [EUPL 1.2 license](https://opensource.org/licenses/EUPL-1.1) 5. I have squashed any insignificant commits. ([`git rebase`](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html)) ## Checklist: - [x] The code change is tested and works locally. - [x] I based my code and PRs against the repositories `developmental` branch. - [x] I [signed off](https://docs.pi-hole.net/guides/github/how-to-signoff/) all commits. Pi-hole enforces the [DCO](https://docs.pi-hole.net/guides/github/dco/) for all contributions - [x] I [signed](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) all my commits. Pi-hole requires signatures to verify authorship - [x] I have read the above and my PR is ready for review.

for further details.

I'd be great if you could run

sudo pihole checkout ftl new/dns_resolver_arpa

and verify yourself that this is behaving as you expect it to.

bungh0l10 · March 1, 2025, 1:31pm

That's cool! I Iike it

Ladrien · March 1, 2025, 10:07pm

While everything looks good in the WebUI and the .toml, it's not returning with an NXDOMAIN. Functionally, it does block the query however.

EDIT: Just took a look at the RFC. NODATA is the correct response. Looks good to me! Thanks @DL6ER

DL6ER · March 11, 2025, 4:43pm

The feature has just been merged into development and will be part of the next FTL release.

Ladrien · March 15, 2025, 1:43am

Just some food for thought, Palo Alto themselves do recommend blocking all SVCB records:

See: Security Profile: Anti-Spyware

jpgpi250 · March 15, 2025, 8:48am

.*;querytype=ANY,HTTPS,SVCB;reply=nodata

I've bee running the "regex deny" for quite some time, without any noticeable impact. Be aware "whitelist always wins", so in order to enforce blocking for the specified query types, a whitelist entry (regex allow) needs to look like (example):

ctldl.windowsupdate.com;querytype=!ANY,SVCB,HTTPS

enforcing blocking also implies you cannot use "allow lists"...