Should the user be allowed to specify FQDNs for HS TARGETs?
Spinoff of #18029 (moved).
The current behavior is to accept any of a raw port, IP address + port, or FQDN + port. We also will accept oddball (historic) inet_aton() style IP addresses (raw hex) depending on if the system implements getaddrinfo() correctly or not.
I'm inclined to leave this as is, and if users care that the HS will hit up the system resolver at initialization time, it should be obvious that they need to specify the target by IP. That said, documentation clarification that an FQDN is acceptable would be ideal.
Since both torrc and ADD_ONION style HSes call into common code, changing the behavior to never hit up the resolver is trivial as well.
Activity
changed milestone to %Tor: unspecified
That said, documentation clarification that an FQDN is acceptable would be ideal.
Thanks. If we update the docs then HiddenServicePort is the spot. Is there a compelling use case for FQDN hidden service targets? If it's useful then by all means keep it as-is, but if not I'd shy toward simplicity by just accepting IPv4/6 addresses. We can always add FQDN support in the future if use cases crop up.
I'm not sure, maybe defining a HS backed by something DNS round robined? (But the correct thing to do there would be to specify multiple VIRTPORT/TARGET pairs with the same VIRTPORT).
Unless someone chimes in with a use case for FQDNs soon-ish, I'm likewise inclined to restrict this to IP addresses (and also deprecate supporting the old
inet_aton()style IPv4 addrs).Trac:
Summary: Should the user be allowed to specify FQDNs for HS VIRTPORTs? to Should the user be allowed to specify FQDNs for HS TARGETs?
I also don't know of anyone using FQDNs as hidden service targets, or of any interesting use cases for this. We could maybe ask the community more broadly to see if someone wants this feature, because I'm not a good person to simulate the HS community.
teor's point that we only do a single DNS query probably disallows the more crazy use cases here like DNS round robin anyway.
Assuming we can't think of something smart here, I think it does make sense to kill this "feature".
Maybe we can try asking in the future #18018 (moved) mailing list about this? :/
Question has been asked on tor-onions@: https://lists.torproject.org/pipermail/tor-onions/2016-February/000071.html
For a while, a nice person was running an onion service that pointed to irc.oftc.net. I think it's still up and in use. And we shouldn't want that person to hard-code just one of oftc's irc servers, right? Or even do some sort of dump of the current irc servers and hard-code that? This situation is what DNS is for.
(All of this said, our process for resolving onion service destinations is not great. There's #393 (moved) for one. And we have other klunky aspects to doing resolves while Tor is operating, like #10566 (moved) and #2106 (moved). I could see an argument for disabling the resolve for some of these, to simplify, but I don't think we can just rip out resolves in everything, or we'll hurt usability too much (like httpsproxy). And that makes ripping it out in some cases but still having to solve the other cases seem like a shame.)
I use all three forms of HSDir specification in torrc at different times, including for work.
-
port number - because lazy
-
IP address - because marginally less lazy and willing to type in 127.0.0.1 for localhost in reasonable certainty that it won't change
-
FQDN - because the loadbalancer VIP changes IP address from datacentre to datacentre and the FQDN is a safe way to record it
Given the recent controversy about Apache's special treatment of requests coming in from "localhost", I actually wonder if there ought to be a fourth syntax, vaguely IPv6 inspired, along the lines of:
HiddenServicePort interface:eth0 80
or
HiddenServicePort interface%eth0 80
or
HiddenServicePort [eth0] 80
...which regularly queries the named network interface and asks what IP address it is currently bound to, directing requests to that rather than "localhost"
-
-
Replying to alecmuffett:
Given the recent controversy about Apache's special treatment of requests coming in from "localhost", I actually wonder if there ought to be a fourth syntax, vaguely IPv6 inspired, along the lines of:
HiddenServicePort interface:eth0 80 [...] ...which regularly queries the named network interface and asks what IP address it is currently bound to, directing requests to that rather than "localhost"
Careful! At least in some cases, when I connect to my computer's external IP address from the same computer, the routing decides to send it "from" localhost. I suspect if we try one of these tricks we will learn that it is not reliable. I think the only reasonable answer is to either make the application not trust localhost too much, or to put the application on an actual different place (which would, in essence, be a variant on making the application not trust the Tor address too much).
Hi Roger - Yeah, plus I am being dumb. I just realised I meant BindAddress/ListenAddress not HiddenServicePort per the Apache config thing. I blame too much coding.
That said, there might be an argument from consistency for:
ListenAddress interface:eth0 HiddenServicePort: interface:eth0 80
...using such a mechanism to keep all traffic identifiable within one (virtual?) network interface?
On sensible systems, it's possible for the kernel to notify you when interface status (eg: IP address, up/down, routing table) changes. Having generic support for receiving/using that sort of information will be useful (and can be emulated via polling on less sensible systems).
I'd be somewhat worried about race conditions, but the same considerations apply to things like DNS round-robin and the ilk, so I don't think we'd be in a worse situation.
moved to tpo/core/tor#18037 (closed)
