Reserve the nickname "Unnamed" for routers that can't pick a hostname; any
router can call itself Unnamed; directory servers will never allocate Unnamed
to any particular router; clients won't believe that any router is the
canonical Unnamed.
svn:r8529
[Needs review.] Add a BEGIN_DIR relay cell type for an easier
in-protocol way to connect to directory servers through Tor.
Previously, clients could only connect to director servers over Tor
from exit nodes, but couldn't get directory information anonymously
from a non-exit cache without getting a directory server involved.
This needs testing, and needs client-side code to actually exercise it.
svn:r8527
Make "is a v1 authority", "is a v2 authority", and "is a hidden service authority" into separate flags so we can eventually migrate more trust away from moria.
svn:r8523
Another tweak to guard logic: ignore check for the Guard flag if a server is listed on EntryNodes. (Also remove redundant checks for always-set variables.)
svn:r8522
Improvement to last entry guards patch: track when we last attempted to connect to a node in our state file along with how long it has been unreachable. Also clarify behavior of parse_iso_time() when it gets extra characters.
svn:r8520
Refactor entry guard status logic a lot; allow more factors [like not
having a Guard flag or being listed in ExcludeNodes] to render a guard
"unlisted" (now called "unusable"); track guard down status (now
called "unreachable") separately from is_running.
svn:r8519
router_set_networkstatus() gets a list of status documents we asked for from
connection_dir_client_reached_eof(). However, as a cache we (sometimes?) just
ask for "all". router_set_networkstatus() would freak out over that, meaning
it would log a warning and drop the status document instead of caching it
as it is supposed to. Now we let router_set_networkstatus() know if the
data comes from an all-request so it can do the right thing.
svn:r8513
client asks us to resolve (not connect to) an address, and we have a
cached answer, give them the cached answer. Previously, we would give
them no answer at all.
svn:r8478
Instead of just checking known-invalid addresses for DNS hijacking, we
now check randomly generated addresses, and if too many of them map to
the same IP, we assume that IP is the destination of a DNS hijack
attempt.
A little bird tells me that some DNS hijackers think that declining to
give an A record for RFC2606 addresses (like .invalid and .example)
makes them more standards compliant. Standardswise, this is like an
illicit brothel making sure that nobody has pulled the tags off the
mattresss, but that doesn't get us out of working around it.
svn:r8465
