Article delegate-en <_A3623@delegate-en.ML_>
  upper oldest olders older1 this newer1 newers latest
search
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
[delegate-en/3623] [Reference:<_A3622@delegate-en.ML_>]
Newsgroups: mail-lists.delegate-en

[DeleGate-En] Re: Trying to get selectable-SOCKS working (application level routing)
29 Jan 2007 00:03:12 GMT Timothy Brown <pdyhabdyi.ml@ml.delegate.org>


> 1) DNS query for www.cnn.com is also forwarded to the upstream  
> SOCKS server
>    at localhost:9250.  This seems a bug in the implementation of  
> DeleGate.

I would think this is actually the correct behavior, as what we want  
is for the remote side to reply with the DNS response:  It may have a  
different view of DNS than the host machine (e.g. in situations where  
you are connecting to a network via SSH where DNS internally is  
different than DNS externally.

>
> 2) by somewhat unknown reason, the upstream SOCKS server does not  
> support,
>    accept, or surve the DNS relay over SOCKS (I'm curious about the  
> reason)

This is also somewhat interesting.   I know the browser is supposed  
to forward the DNS query over SOCKS  (I've seen this happen but not  
with delegate - but since delegate shows the debug of a DNS request  
hitting it it seems there is no problem with the browser).   
RESOLV=sys does in fact work to resolve the problem but I am  
concerned that this may not get us where we want to go.   I have  
verified this problem exists in both OpenSSH 4.2p1 (shipped with Mac  
OS X) and 4.5p1 (downloaded separately).

My intended behavior would be that delegate accepts the DNS request  
(this seems to work OK) and then forwards it to the SSH proxy based  
on the DNS lookup.   I have verified via tcpdump that the remote host  
does not send the DNS request on, so either delegate is not  
forwarding the SOCKSified DNS request over the SSH connection or the  
SSH server or client is the source of the problem.

Of course we see this:

01/28 18:44:59.03 [13937] 3+3: {R} [i.a.cnn.net]*1 q=1,a=0, s=1,r=0 (2s)
01/28 18:44:59.08 [13937] 3+3: SocksV5_connect [7f000001] 
127.0.0.1:9050 ...
01/28 18:44:59.08 [13937] 3+3: [SocksV5-clnt] UDPASSOC [1] 
0.0.0.0:61751 sent(10/10)
01/28 18:44:59.08 [13937] 3+3: SocksV5_udpassoc: UDP ASSOC error(V5 0)
01/28 18:44:59.29 [13940] 6+1: {R} [ads.cnn.com]*1 q=1,a=0, s=1,r=0 (2s)
01/28 18:44:59.30 [13942] 8+1: {R} [ads.cnn.com]*1 q=1,a=0, s=1,r=0 (2s)
01/28 18:44:59.30 [13941] 7+1: {R} [ads.cnn.com]*1 q=1,a=0, s=1,r=0 (2s)
01/28 18:44:59.31 [13943] 9+1: {R} [ads.cnn.com]*1 q=1,a=0, s=1,r=0 (2s)
01/28 18:44:59.32 [13944] 10+1: {R} [cnn.dyn.cnn.com]*1 q=1,a=0,  
s=1,r=0 (2s)

But how can we be assured that delegate is actually doing the DNS  
lookup over the SOCKS connection?  It should.  In situations where  
you want to use Tor, for instance, having the DNS lookup performed by  
the system is very bad for cases of anonymity.

Thank you for all your help.

Tim

>
> For a while, the problem might be able to be bypassed by a parameter
> as follows:
>
>   RESOLV=sys
>
> Cheers,
> Yutaka
> --
>   9 9   Yutaka Sato <y.sato@delegate.org> http://delegate.org/y.sato/
>  ( ~ )  National Institute of Advanced Industrial Science and  
> Technology
> _<   >_ 1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan
> Do the more with the less -- B. Fuller


  admin search upper oldest olders older1 this newer1 newers latest
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
@_@V