[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #8596 [Tor]: Inconsistent addrmap events when resolving hostname (regression)

#8596: Inconsistent addrmap events when resolving hostname (regression)
---------------------------------------+------------------------------------
 Reporter:  Desoxy                     |          Owner:                     
     Type:  defect                     |         Status:  new                
 Priority:  normal                     |      Milestone:  Tor: 0.2.4.x-final 
Component:  Tor                        |        Version:  Tor: 0.2.4.11-alpha
 Keywords:  tor-client controller dns  |         Parent:                     
   Points:                             |   Actualpoints:                     
---------------------------------------+------------------------------------

Comment(by nickm):

 Replying to [comment:2 Desoxy]:
 > I like the idea of using a flag or setting the expiry time in the past.
 It really depends on the meaning of the expiry time: Does it mean "The
 remote DNS server specified this TTL for this A/AAAA/PTR record" or does
 it mean "Tor will cache this record until that time"? For the first, a
 flag would be better, for the latter I think that setting the expiry time
 to the first of January 1970 would be best. Since the cache is now per
 circuit, it would also be possible to add an CIRC_ID field that indicates
 for which circuit the hostname was cached.

 I'm inclined to say "let's not lose info", and do the flag.

 (The cache is not actually per-circuit.  Mostly, we just don't cache at
 the client side at all. This is approximately equivalent to a per-circuit
 cache, since the exit node caches too. Is there a lingering documentation
 bug too?)

 > I hope that this can go into 0.2.4. The fix shouldn't be too difficult
 once we have decided on how to change the control spec. Having ADDRMAP
 work in 0.2.3, then not always work in 0.2.4 and then work again in 0.2.5
 would be bad.

 I agree, but we should consider the risks too:

  * If it turns out that Vidalia or controller can't cope with a new flag,
 it would be bad to have to delay 0.2.4 packages until that controller
 could catch up.
  * If the fix is tricky enough, it would be bad to delay 0.2.4 stability
 for it.

 But with any luck, if the fix can come soon, and the relevant controllers
 don't choke on it, and it's nice and simple, I think it can be 0.2.4
 material.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/8596#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs