Skip to content

GitLab

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

Closed
Opened by Roger Dingledine@armaReporter

We still do client-side caching. We just don't use the cache.

In Tor 0.2.4.7-alpha, we said Turn off the client-side DNS cache by default. (Proposal 205, legacy/trac#7570 (moved))

But actually, in port_cfg_new() we say

  cfg->entry_cfg.cache_ipv4_answers = 1;

And similarly in parse_port_config() we say

      cache_ipv4 = 1,

Now, fortunately, there is a bonus surprise field named use_cached_ipv4 and that is left to 0. You can read more in commit ac990aa4 which removes the line

-  cfg->use_cached_ipv4_answers = 1;

Now, that's all well and good -- we keep a client-side dns cache but we don't use it. I hacked up my Tor client to confirm, and it's really true.

But then there's commit bbad23bf, which says No, client-side DNS cacheing should not be on by default. and its patch to parse_unix_socket_config() is

-        port->entry_cfg.cache_ipv4_answers = 1;
-        port->entry_cfg.cache_ipv6_answers = 1;
+        port->entry_cfg.cache_ipv4_answers = 0;
+        port->entry_cfg.cache_ipv6_answers = 0;

But then in commit 485fdcf8 we took out that whole parse_unix_socket_config() concept, unifying stuff back to the "yes, keep the client-side dns cache" default.

Do we want to set the cache to default to off? Since we don't use it? Does anything need it to be on? It would seem that anything that relies on it is a bug (and a surprise) at this point.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information