[tor-bugs] #19769 [Core Tor/Tor]: Round down DNS TTL to the nearest DEFAULT_DNS_TTL (30 minutes)

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Dec 21 19:17:45 UTC 2016


#19769: Round down DNS TTL to the nearest DEFAULT_DNS_TTL (30 minutes)
-------------------------------------------------+-------------------------
 Reporter:  teor                                 |          Owner:
     Type:  defect                               |         Status:
                                                 |  needs_information
 Priority:  Very High                            |      Milestone:  Tor:
                                                 |  0.3.0.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  029-proposed, dns,                   |  Actual Points:
  TorCoreTeam201609                              |
Parent ID:                                       |         Points:  0.5
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by pulls):

 == Concretely ==


 {{{
 MIN_DNS_TTL = 5*60;
 MAX_DNS_TTL = 60*60;

 dns_clip_ttl(uint32_t ttl)
 {
   if (ttl < MIN_DNS_TTL)
     return MIN_DNS_TTL;
   else
     return MAX_DNS_TTL;
 }
 }}}


 - Fix #19025 (otherwise ttl above will always be MIN_DNS_TTL).
 - Potentially refactor the DNS caching code to support evictions (while
 doing this, maybe rip out all old client-side DNS caching code?).
 - Add some form of logging to track cache size, usage, and eviction rate.
 - dns_get_expiry_ttl should be the same as dns_clip_ttl above. Please note
 that we are not sure these are the only relevant functions.


 == Given ==

 - For popular websites, caching at exits is highly likely, and DefecTor
 attacks are the same as WF attacks.
 - For unpopular websites, caching and TTLs are moot, since the probability
 of an DNS record being chached is negligible. Caching these records are
 just an extra burden on the exit and in a sense also a risk due to leaking
 recent activity at the exit on compromise. DefecTor attacks will be more
 precise than WF attacks here, and Tor needs WF defenses to mitigate
 (another long-term topic).
 - For long TTLs, for what it is worth, we know from #19025 that the real-
 world impact of ignoring these long TTLs are not a serious issue.
 - For short TTLs, the impact of increasing it is our primary worry since
 we might break something.
 - We want to prevent fine-grained TTLs to protect against tagging attacks.
 - We do not want too high TTLs to have a chance to auto-magically resolve
 DNS cache poisoning.
 - The total size of the cache might be a vector for DoS.
 - The client-side DNS cache remains off.


 == Goals for DefectTor mitigation ==

 - Allow long TTLs to be long(er).
 - For short TTLs, go as far up as we are comfortable to without
 significantly risking breaking things.


 == Proposal ==

 Stage changes: start with repairing the TTL bug #19025 and change clipping
 to 5*60 seconds for MIN_DNS_TTL and 60*60 seconds for MAX_DNS_TTL,
 honoring no intermediate values (see code above). Wait for feedback on
 unexpected breaks. If all manageable, increase MIN_DNS_TTL to 60*60 in a
 future patch, effectively always caching for 60 minutes. If DefecTor
 attacks become a real concern short-term, encourage concerned site owners
 to consider longer TTLs to hit the MAX_DNS_TTL value. Make the cache size
 limited and eviction when full uniformly random. We random to give an
 attacker less control since it can presumably cause evictions at will
 (LIFO is easy to manipulate for an attacker).

 Getting feedback on real-world cache size, usage, and eviction rate from
 exit operators would be useful, so perhaps some form of log output is
 reasonable?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/19769#comment:13>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list