[tor-dev] When RFC 7686 and transparent proxies collide

[Alec Muffett]

Hi! I'm one of the authors of RFC 7686.

Although myself and Appelbaum[1] are cited on it, the document is the
result of a huge amount of argument and input from many people (shout out
to Mark Nottingham most especially, whom I feel should have gotten an
author credit) on various IETF maillists, and against considerable pressure
from some in the DNS, ICANN and other naming communities who didn't want to
set a precedent nor open a gateway to "more exceptions for new TLDs".

Reading this thread I can confirm that transparent proxies (of several
implementations) were considered to be outside of the scope of the
specification, not by intention but rather as a consequence of the DNS
community being **extremely motivated** to prevent the existence or
official sanction for anything that could be construed as extending DNS by
default, without going through the full DNS standards processes.

There was (and, I suspect, remains) very much an attitude of DNS being
practically sacred and unamendable unless overseen by an elite priesthood
of experts, and as such all the "Tor" stuff was presented to them and to
the standards committees as being *"something utterly different from DNS,
really, we swear, honest, this is more of a namespace bookkeeping issue
than anything else"* — in order to prevent the standard being shot to death
by DNS zealots.

Also: the ".onion" resolutions which "leak" into the global DNS network
were at the time — and probably remain — both a nuisance and a huge
information leak that gets mined by various state security agencies; those
participants who perceived that as an issue saw the RFC as an issue to
address both the noise and the leak by drawing a very firm line between DNS
and Onion addressing, hence the text which is under discussion here.

Myself? I am looking at the application wants sympathetically, but with a
perspective of 36 years of Unix. To be frank I believe that the process we
went through and the points that were made during the RFC are prettymuch
valid, and I believe that using DNS as transport for a hack to resolve
Onion addresses is ill-advised, even massively dangerous, for the reasons
described.

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[2] using the /etc/nsswitch.conf service which was
literally designed[3] to address this kind of problem; the acronym stands
for "Name Service Switch"[4] 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`"?

     - alec

[1] yes, I know
[2] see this https://www.youtube.com/watch?v=pebRZyg_bh8
[3] https://man7.org/linux/man-pages/man5/nsswitch.conf.5.html
[4] https://man7.org/linux/man-pages/man5/nss.5.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20231113/1941fb50/attachment.htm>