I have Pi-hole set-up to use a local BIND server as a backend. It is the only backend server for Pi-hole, I've removed the default servers.
This local BIND server is set-up to act as a transparent proxy for Tor.
I also have routing in place to be able to access Tor domains directly on local LAN without needing any extra software.
Since installing Pi-hole I have encountered an issue. Pi-hole is refusing all .onion domain queries and returning "NXDOMAIN" instead of forwarding these queries to the configured DNS backend server. When I directly query the backend server directly (both from my work PC and Pi-hole's own VM), it responds to .onion queries correctly. But Pi-hole stubbornly refuses to resolve .onion domains. Clearing cache did not help. Tried adding *.onion to Pi-hole's whitelist, that did not help either.
Pi-hole logs claim the "NXDOMAIN" responses were returned from cache, which is false, since no actual query was made to the backend server.
Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:
pihole installs a file "/etc/dnsmasq.d/06-rfc6761.conf". In that file, there is a section:
# OpenWRT furthermore blocks bind, local, onion domains
# see https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob_plain;f=package/network/services/dnsmasq/files/rfc6761.conf;hb=HEAD
# and https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml
# We do not include the ".local" rule ourselves, see https://github.com/pi-hole/pi-hole/pull/4282#discussion_r689112972
server=/bind/
server=/onion/
Remove the last line, and restart pihole-FTL.
Be aware that this file is restored after every upgrade, so after 'pihole -up', you'll need to remove the line again, and restart.
Thanks for the tip. Didn't know this was a part of the default configuration.
.onion isn't in RFC6761. But since transparent .onion proxying is very rarely used, I suppose it made sense for Pi-hole devs to disable the .onion domain to avoid unnecessary DNS forwarding.
Marking the "06-rfc6761.conf" file as immutable should prevent it from being updated.
I often use the same trick to prevent hijacking of /etc/resolv.conf.
Yes, I mean the "chattr +i" command. Yes, it will prevent the file from being modified or deleted even by root. Of course, this isn't permanent, the immutable attribute can be cleared at any time.
Regarding your question whether marking the file as immutable will break updates. I did a little investigation on how the update process works.
"/usr/local/bin/pihole" script calls the update script in /opt/pihole which in turn uses scripts in /etc/.pihole. I took a quick look and the script which copies the dnsmasq config files (/etc/.pihole/automated install/basic-install.sh) does not check whether the copy command (it uses "install") has succeeded and will not stop the update on copy failure.
Not willing to test this in practice, since my Pi-hole UI and FTL are customized.
I will update individual components manually when necessary.
Caching DNS Servers: Caching servers, where not explicitly
adapted to interoperate with Tor, SHOULD NOT attempt to look up
records for .onion names. They MUST generate NXDOMAIN for all
such queries.
and:
Authoritative DNS Servers: Authoritative servers MUST respond to
queries for .onion with NXDOMAIN.
NXDOMAIN is the required reply, and the respective entries from 06-rfc6761.conf will have Pi-hole serve that reply immediately, instead of needlessly involving an additional roundtrip to its upstream servers, while preventing unintended .onion leakage at the same time.
EDIT:
You surely can configure Pi-hole for your use case, and you don't need to edit 06-rfc6761.conf for that.
Create a custom configuration file (e.g. /etc/dnsmasq.d/42-onion-forwards.conf) with:
server=/onion/<ip.ad.re.ss>#<port>
Substitute <ip.ad.re.ss>#<port> with the respective values for your Tor proxy and run pihole restartdns to apply.
I am fully aware of the .onion RFC.
True, .onion has no real DNS as such since it's decentralized. But Tor client does have a transparent proxy feature which allows to use it as a name server to "resolve" .onion domains to temporary fake IP addresses from a configurable IP range VIA DNS. This name sever can then be set as authoritative server for .onion TLD in something like BIND.
A simple routing rule redirecting the configured Tor IP range to Tor client will allow anyone on the network to access Tor's .onion domains like any other standard domain without requiring additional software. This is a niche but nevertheless a completely valid use case. Usage of Tor's transparent proxy is discouraged by Tor developers but the feature is still there since there are use cases where it can be useful.
RFC7686 compliance should be a configurable feature. Most, if not all browsers allow to disable RFC7686 compliance if desired.
Well, but since Pi-hole is open source, nothing prevents me from removing .onion domain handling from the default configuration.
While applications should block .onion if they do not support connecting to it, they are not are not requred do so. Firefox is the only browser engine I am aware of that blocks onion by default.Chrome just issues DNS requests for anything entered as URL by default, including .onion domains.
My previous reply was meant to explain how Pi-hole is applying sane defaults here.
You can address your use case by applying a custom dnsmasq configuration.
I've edited my post accordingly.
And that's exactly what I did. By removing the "/onion/" line from 06-rfc6761.conf. In my case this is a better fix than creating another configuration file as this allows me to just use the upstream DNS server that I have set in admin panel without having to set one separately for .onion TLD.
Now everything works as expected.
It's not clear from your description if you did employ BIND for that sole purpose?
But if that would be the case, my suggestion would allow you to forego using BIND completely, with the additional benefit of not being compromised by updates of 06-rfc6761.conf.
No. BIND is used as an internal local DNS. I have some services running on my local network which are also accessible externally. I use BIND to enable local devices to access these services without a NAT loopback.
I've added .onion TLD handling as an experiment. I have later decided to make this change permanent for convenience purposes (not having to install Tor on every device to access .onion domains).
