2006-12-19 19:48:54 +00:00
|
|
|
$Id$
|
|
|
|
|
|
|
|
Special Hostnames in Tor
|
|
|
|
Nick Mathewson
|
|
|
|
|
|
|
|
1. Overview
|
|
|
|
|
2008-08-03 15:34:28 +00:00
|
|
|
Most of the time, Tor treats user-specified hostnames as opaque: When
|
|
|
|
the user connects to www.torproject.org, Tor picks an exit node and uses
|
|
|
|
that node to connect to "www.torproject.org". Some hostnames, however,
|
|
|
|
can be used to override Tor's default behavior and circuit-building
|
|
|
|
rules.
|
2006-12-19 19:48:54 +00:00
|
|
|
|
|
|
|
These hostnames can be passed to Tor as the address part of a SOCKS4a or
|
|
|
|
SOCKS5 request. If the application is connected to Tor using an IP-only
|
|
|
|
method (such as SOCKS4, TransPort, or NatdPort), these hostnames can be
|
|
|
|
substituted for certain IP addresses using the MapAddress configuration
|
|
|
|
option or the MAPADDRESS control command.
|
|
|
|
|
|
|
|
2. .exit
|
|
|
|
|
|
|
|
SYNTAX: [hostname].[name-or-digest].exit
|
|
|
|
[name-or-digest].exit
|
|
|
|
|
|
|
|
Hostname is a valid hostname; [name-or-digest] is either the nickname of a
|
|
|
|
Tor node or the hex-encoded digest of that node's public key.
|
|
|
|
|
|
|
|
When Tor sees an address in this format, it uses the specified hostname as
|
|
|
|
the exit node. If no "hostname" component is given, Tor defaults to the
|
|
|
|
published IPv4 address of the exit node.
|
|
|
|
|
2007-01-03 10:30:26 +00:00
|
|
|
It is valid to try to resolve hostnames, and in fact upon success Tor
|
|
|
|
will cache an internal mapaddress of the form
|
|
|
|
"www.google.com.foo.exit=64.233.161.99.foo.exit" to speed subsequent
|
|
|
|
lookups.
|
2006-12-19 19:48:54 +00:00
|
|
|
|
|
|
|
EXAMPLES:
|
|
|
|
www.example.com.exampletornode.exit
|
|
|
|
|
|
|
|
Connect to www.example.com from the node called "exampletornode."
|
|
|
|
|
|
|
|
exampletornode.exit
|
|
|
|
|
|
|
|
Connect to the published IP address of "exampletornode" using
|
|
|
|
"exampletornode" as the exit.
|
|
|
|
|
|
|
|
3. .onion
|
|
|
|
|
2007-01-03 10:30:26 +00:00
|
|
|
SYNTAX: [digest].onion
|
2006-12-19 19:48:54 +00:00
|
|
|
|
|
|
|
The digest is the first eighty bits of a SHA1 hash of the identity key for
|
|
|
|
a hidden service, encoded in base32.
|
|
|
|
|
|
|
|
When Tor sees an address in this format, it tries to look up and connect to
|
|
|
|
the specified hidden service. See rend-spec.txt for full details.
|
|
|
|
|
|
|
|
4. .noconnect
|
|
|
|
|
2007-01-03 10:30:26 +00:00
|
|
|
SYNTAX: [string].noconnect
|
2006-12-19 19:48:54 +00:00
|
|
|
|
|
|
|
When Tor sees an address in this format, it immediately closes the
|
|
|
|
connection without attaching it to any circuit. This is useful for
|
|
|
|
controllers that want to test whether a given application is indeed using
|
|
|
|
the same instance of Tor that they're controlling.
|
|
|
|
|
2007-03-02 05:17:31 +00:00
|
|
|
5. [XXX Is there a ".virtual" address that we expose too, or is that
|
|
|
|
just intended to be internal? -RD]
|
|
|
|
|