The Tor Developer maillist is in the midst of discovering the consequences of LibCurl and/or its dependent DNS resolver libraries following RFC 7686 and starting to actively ban lookups for .onion network addresses in software namespaces that are meant for resolving DNS.

Regrettably it appears that for several years various anonymity tools have (ill-advisedly, riskily, unwisely, …?) been using DNS internally as a means of resolving Tor “darknet” .onion addresses as part of a transparent-proxy solution for small intranets and secure workstation solutions.

It’s a shame that they never asked anyone over 50 (or, then, 40) about this because we would have discussed things like “namespace violations” and “layering problems” and “alternative namespaces” and “well, Solaris solved this with nsswitch.conf and everyone else copied that…”

Yes, Virginia, avoiding polluting DNS is an old problem and there is a long established solution:

I have sympathy for the DNS resolver community being explicit about banning “.onion” and I think that doing so would be good for Onion privacy; but that doesn’t mean that I find the need to resolve .onion addresses to a virtual IP address to be illegitimate.

Back in the 1990s we used to deal with their being different namespaces for different networks using the /etc/nsswitch.conf service which was literally designed to address this kind of problem; the acronym stands for “Name Service Switch” and it’s how local naming in huge intranets used to be implemented.

As such, why not just build a small service to perform this mapping lookup properly and splice it into nsswitch.conf, and save yourself from having to police the DNS clients for data leakage re: “This IP address just tried to look up supersecretleakysite234567abcde.onion“?

https://lists.torproject.org/pipermail/tor-dev/2023-November/014865.html