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