Indeed it might be the wisest thing to do if no other choice exists. At least it will make it easier for users to have safely configured apps, especially if they are intent on manually installing them anyway.
I did some digging. Its possible with redsocks to redirect DNS over TCP. Here is a detailed outline of the options you have with redsocks:
opened 08:59AM - 30 Aug 17 UTC
closed 08:22PM - 01 Feb 18 UTC
Hi, I know that this topic have been discussed several times already, but I stil… l having troubles with setting it up.
I have tried different approaches here they are
First of I redirected all DNS (UDP queries to port 53) to my proxy machine like that
`iptables -t nat -A PREROUTING -s 192.168.0.113 -p udp --dport 53 -j DNAT --to-destination 192.168.0.145:5300`
Then I tried
```
redudp {
local_ip = 0.0.0.0;
local_port = 10053;
// `ip' and `port' of socks5 proxy server.
ip = 22.22.22.22;
port = 2222;
login = login;
password = pass;
dest_ip = 8.8.8.8;
dest_port = 53;
udp_timeout = 30;
udp_timeout_stream = 180;
}
```
But it doesn't work, packets are just dropped.
```
1504080987.699956 debug redudp.c:474 redudp_relay_connected(...) [192.168.0.113:52730->8.8.8.8:53]: via 23.249.216.107:56776
1504080987.812315 debug redudp.c:430 redudp_read_auth_methods(...) [192.168.0.113:52730->8.8.8.8:53]: <trace>
1504080987.845857 debug redudp.c:288 redudp_enqeue_pkt(...) [192.168.0.113:51871->8.8.8.8:53]: <trace>
1504080987.924875 debug redudp.c:394 redudp_read_auth_reply(...) [192.168.0.113:52730->8.8.8.8:53]: <trace>
1504080988.850860 debug redudp.c:288 redudp_enqeue_pkt(...) [192.168.0.113:50662->8.8.8.8:53]: <trace>
1504080989.845690 debug redudp.c:288 redudp_enqeue_pkt(...) [192.168.0.113:51871->8.8.8.8:53]: <trace>
1504080992.846606 debug redudp.c:288 redudp_enqeue_pkt(...) [192.168.0.113:50662->8.8.8.8:53]: <trace>
1504080993.855851 debug redudp.c:288 redudp_enqeue_pkt(...) [192.168.0.113:51871->8.8.8.8:53]: <trace>
1504080996.371397 notice redudp.c:500 redudp_relay_error(...) [192.168.0.113:50662->8.8.8.8:53]: redudp_relay_error
1504080996.371452 info redudp.c:217 redudp_drop_client(...) [192.168.0.113:50662->8.8.8.8:53]: Dropping...
1504080997.302259 notice redudp.c:500 redudp_relay_error(...) [192.168.0.113:51871->8.8.8.8:53]: redudp_relay_error
1504080997.302313 info redudp.c:217 redudp_drop_client(...) [192.168.0.113:51871->8.8.8.8:53]: Dropping...
```
Could you explain what it is the purpose of **dest_ip** and **dest_port** here ?
The next option I have tried is to use truncated DNS responses as you have mentioned in your README
```
1504082310.695400 info dnstc.c:94 dnstc_pkt_from_client(...) [192.168.0.113:63094->0.0.0.0:5300]: sent truncated DNS reply
1504082311.699424 info dnstc.c:94 dnstc_pkt_from_client(...) [192.168.0.113:63094->0.0.0.0:5300]: sent truncated DNS reply
1504082313.699975 info dnstc.c:94 dnstc_pkt_from_client(...) [192.168.0.113:63094->0.0.0.0:5300]: sent truncated DNS reply
1504082313.962738 info dnstc.c:94 dnstc_pkt_from_client(...) [192.168.0.113:61305->0.0.0.0:5300]: sent truncated DNS reply
1504082317.704753 info dnstc.c:94 dnstc_pkt_from_client(...) [192.168.0.113:63094->0.0.0.0:5300]: sent truncated DNS reply
```
However it seems according to TCP dump and connections in the kernel on my router after getting the truncated response the resolver doesn't try to use TCP, as I can assume an RFC compliant resolver should send DNS request via the TCP request on the port 53 ?
To be honest I am not a professional in a low level packet analysis. I have tried to understand the implementation of DNS resolution in different applications like firefox, winproxy, but there are a lot of stuff to read and debug in order to get this.
According the RFC SOCKS5 accepts UDP packets with the **0x03: associate a UDP port**
I have successfully managed to use DNS resolution over SOCKS5 with this small application https://github.com/jtripper/dns-tcp-socks-proxy .
As far as I can understand this application just parses predefined list of DNS servers that work over TCP chooses a random one and sends a simple TCP request to a proxy server.
Here is the part of the implementation
```
// select random dns server
in_addr_t remote_dns = inet_addr(dns_servers[rand() % (NUM_DNS - 1)]);
memcpy(tmp, "\x05\x01\x00\x01", 4);
memcpy(tmp + 4, &remote_dns, 4);
memcpy(tmp + 8, "\x00\x35", 2);
```
However using the DNS resolution in this way will not pretend that a local DNS server is used. This configuration is equal to the statically set DNS server, for example in a router as far as the name resolution is made through the public DNS servers, am I right ?
Could you please suggest the direction to follow and answer my question ? I would be grateful for any help
OP has combined it with iptables though in his case, the software he’s using isn’t working but its a useful example of how it hcan be done:
opened 08:59AM - 30 Aug 17 UTC
closed 08:22PM - 01 Feb 18 UTC
Hi, I know that this topic have been discussed several times already, but I stil… l having troubles with setting it up.
I have tried different approaches here they are
First of I redirected all DNS (UDP queries to port 53) to my proxy machine like that
`iptables -t nat -A PREROUTING -s 192.168.0.113 -p udp --dport 53 -j DNAT --to-destination 192.168.0.145:5300`
Then I tried
```
redudp {
local_ip = 0.0.0.0;
local_port = 10053;
// `ip' and `port' of socks5 proxy server.
ip = 22.22.22.22;
port = 2222;
login = login;
password = pass;
dest_ip = 8.8.8.8;
dest_port = 53;
udp_timeout = 30;
udp_timeout_stream = 180;
}
```
But it doesn't work, packets are just dropped.
```
1504080987.699956 debug redudp.c:474 redudp_relay_connected(...) [192.168.0.113:52730->8.8.8.8:53]: via 23.249.216.107:56776
1504080987.812315 debug redudp.c:430 redudp_read_auth_methods(...) [192.168.0.113:52730->8.8.8.8:53]: <trace>
1504080987.845857 debug redudp.c:288 redudp_enqeue_pkt(...) [192.168.0.113:51871->8.8.8.8:53]: <trace>
1504080987.924875 debug redudp.c:394 redudp_read_auth_reply(...) [192.168.0.113:52730->8.8.8.8:53]: <trace>
1504080988.850860 debug redudp.c:288 redudp_enqeue_pkt(...) [192.168.0.113:50662->8.8.8.8:53]: <trace>
1504080989.845690 debug redudp.c:288 redudp_enqeue_pkt(...) [192.168.0.113:51871->8.8.8.8:53]: <trace>
1504080992.846606 debug redudp.c:288 redudp_enqeue_pkt(...) [192.168.0.113:50662->8.8.8.8:53]: <trace>
1504080993.855851 debug redudp.c:288 redudp_enqeue_pkt(...) [192.168.0.113:51871->8.8.8.8:53]: <trace>
1504080996.371397 notice redudp.c:500 redudp_relay_error(...) [192.168.0.113:50662->8.8.8.8:53]: redudp_relay_error
1504080996.371452 info redudp.c:217 redudp_drop_client(...) [192.168.0.113:50662->8.8.8.8:53]: Dropping...
1504080997.302259 notice redudp.c:500 redudp_relay_error(...) [192.168.0.113:51871->8.8.8.8:53]: redudp_relay_error
1504080997.302313 info redudp.c:217 redudp_drop_client(...) [192.168.0.113:51871->8.8.8.8:53]: Dropping...
```
Could you explain what it is the purpose of **dest_ip** and **dest_port** here ?
The next option I have tried is to use truncated DNS responses as you have mentioned in your README
```
1504082310.695400 info dnstc.c:94 dnstc_pkt_from_client(...) [192.168.0.113:63094->0.0.0.0:5300]: sent truncated DNS reply
1504082311.699424 info dnstc.c:94 dnstc_pkt_from_client(...) [192.168.0.113:63094->0.0.0.0:5300]: sent truncated DNS reply
1504082313.699975 info dnstc.c:94 dnstc_pkt_from_client(...) [192.168.0.113:63094->0.0.0.0:5300]: sent truncated DNS reply
1504082313.962738 info dnstc.c:94 dnstc_pkt_from_client(...) [192.168.0.113:61305->0.0.0.0:5300]: sent truncated DNS reply
1504082317.704753 info dnstc.c:94 dnstc_pkt_from_client(...) [192.168.0.113:63094->0.0.0.0:5300]: sent truncated DNS reply
```
However it seems according to TCP dump and connections in the kernel on my router after getting the truncated response the resolver doesn't try to use TCP, as I can assume an RFC compliant resolver should send DNS request via the TCP request on the port 53 ?
To be honest I am not a professional in a low level packet analysis. I have tried to understand the implementation of DNS resolution in different applications like firefox, winproxy, but there are a lot of stuff to read and debug in order to get this.
According the RFC SOCKS5 accepts UDP packets with the **0x03: associate a UDP port**
I have successfully managed to use DNS resolution over SOCKS5 with this small application https://github.com/jtripper/dns-tcp-socks-proxy .
As far as I can understand this application just parses predefined list of DNS servers that work over TCP chooses a random one and sends a simple TCP request to a proxy server.
Here is the part of the implementation
```
// select random dns server
in_addr_t remote_dns = inet_addr(dns_servers[rand() % (NUM_DNS - 1)]);
memcpy(tmp, "\x05\x01\x00\x01", 4);
memcpy(tmp + 4, &remote_dns, 4);
memcpy(tmp + 8, "\x00\x35", 2);
```
However using the DNS resolution in this way will not pretend that a local DNS server is used. This configuration is equal to the statically set DNS server, for example in a router as far as the name resolution is made through the public DNS servers, am I right ?
Could you please suggest the direction to follow and answer my question ? I would be grateful for any help
Another tool that des something similar is GitHub - jtripper/dns-tcp-socks-proxy: Simple daemon to tunnel DNS requests over SOCKS
1 Like