Padavan的DNS代理工作方式探究。。。

gaze

作为padavan的忠实拥趸
对其中的s*s的工作最为推崇，非常简洁省事。
但是，对于其dns代理的工作流程一直没搞明白。
最近有时间，稍微探索了一下，与各位同好分享，
浅薄之处，请各位大神不吝赐教予以斧正。

在padavan的： http://192.168.123.1/Advanced_DHCP_Content.asp

下面有个{高级设置}，里面有｛自定义配置文件 "dnsmasq.conf"｝
点击开，看到基本都是“#”注释掉的信息，
然后，在最后一行是

        “conf-dir=/tmp/ss/dnsmasq.d”

据此，我们在 /tmp/ss/dnsmasq.d 目录下发现一些临时生成的conf文件

-rw-rw-rw-    1 admin    root        360828 Oct 16 10:17 r.gfwlist.conf
-rw-rw-rw-    1 admin    root           140 Oct 16 10:17 r.wantoss.conf

分别cat一下可见：

ipset=/zuobiao.me/gfwlist
server=/zuola.com/127.0.0.1#8053
ipset=/zuola.com/gfwlist
server=/zvereff.com/127.0.0.1#8053
ipset=/zvereff.com/gfwlist
server=/zynaima.com/127.0.0.1#8053
ipset=/zynaima.com/gfwlist
server=/zynamics.com/127.0.0.1#8053
ipset=/zynamics.com/gfwlist
server=/zyns.com/127.0.0.1#8053
ipset=/zyns.com/gfwlist
server=/zyzc9.com/127.0.0.1#8053
ipset=/zyzc9.com/gfwlist
server=/zzcartoon.com/127.0.0.1#8053


cat /tmp/ss/dnsmasq.d/r.wantoss.conf

        ipset=/githubusercontent.com/gfwlist
        server=/githubusercontent.com/127.0.0.1#8053
        ipset=/github.io/gfwlist
        server=/github.io/127.0.0.1#8053

而8053端口，正是我们的dnsproxy或者pdnsd等等工作在代理模式时候的监听端口
执行如下命令，即可清晰地看到。

        netstat -ltnp | grep dns  

==============================

由上述可见，防止dns污染的整个流程是这样的（以gfwlist模式为例）

1】路由器的s*s工作在gfwlist模式
2】软件修改dnsmasq的conf配置，指向/tmp/ss/dnsmasq.d目录下
3】使用ipset，如果客户机查询的是gwflist里的域名，则把查询包重定向到路由器的8053端口
4】路由器的dnsproxy在8053端口监听到查询，通过socks转发到外部8.8.8.8这样的DNS进行查询，并返回结果给客户机。
5】客户机使用真实ip地址通过s*s与服务器进行通讯。

gaze

现在尚不清楚，

在WAN口设置的DNS服务器地址参数、以及在LAN口设置的DNS服务器地址参数，
会对这个判断--转发 过程产生什么影响。

还是说，毫无影响？

正在逐步试验中。

keke1023

openwrt下的设置比较明确点（虽然麻烦），原理应该是一模一样的~

gaze

但是，工作一段时间后，在syslog里能看到如下提示：
        dnsmasq[28385]: nameserver 127.0.0.1 refused to do a recursive query

其原因在于（http://bbs.m0n0china.org/viewthread.php?tid=1079）：

        这个域名服务器（127.0.0.1:8053）可能是某域的主域名服务器，但是它并未配置成为某特定域的提供解析服务。这样配置的域名服务器

不适合被设置为dnsmasq域名转发器的上游服务器。这是由于dnsmasq的工作特点决定的，dnsmasq会按负载均衡的方式（可能是依次轮询）来使用

所有设置的上游服务器。当这种域名服务器被轮询到的时候，dnsmasq工作就不正常了。由于是轮询，所以这种问题会是时而出现。因此，不要在

dnsmasq域名转发器中设置这种域名服务器（显然，其他工作不正常的服务器也不应被设入）。


这个问题会导致dnsmasq时不时地工作不正常，
目前尚未想出来，如何能解决这个问题，
即，

又能分流gfw的域名给dnsproxy的8053端口，
又能保证dnsmasq不认为这个上游dns服务器有问题。

好痛苦哇，
各位大神都是怎么处理的呢？

gaze

改用了pdnsd之后，效果好很多（然而Hiboy大神在界面里推荐的是dnsproxy）

         pdnsd -c /etc/storage/pdnsd.conf

pdnsd类似于dnsproxy，
但它把收到的来自客户机的UDP类型dns查询数据包转成tcp后通过socks发到外界dns
这个过程，貌似比较可靠些，看上去，速度也比socks转发的UDP方式的dns查询要快些。

KisThFir

gaze 发表于 2018-10-16 13:54
改用了pdnsd之后，效果好很多（然而Hiboy大神在界面里推荐的是dnsproxy）

         pdnsd -c /etc/storage/pd ...

小白帮顶，经验是pdnsd很稳定，不知道原理，稳定就用，也感觉不出跟其他方式的差别

漫游者

我都是按ss默认的设置用的。。。

srrshweee

padavan的ss或者v2瑞都一个问题，就是换了fan greatwall服务器地址以后，因为中间有短暂的切换网络，pc上的dns就回被污染，需要在pc上面清除一下dns缓存。这个问题解决了就基本没有问题了。

tulanding

防止DNS污染第一步是DHCP中设置DNS的地址为内部网关地址，不要自定义设置公网DNS，否则路由器就没控制权了

gaze

srrshweee 发表于 2018-12-2 11:14
padavan的ss或者v2瑞都一个问题，就是换了fan greatwall服务器地址以后，因为中间有短暂的切换网络，pc上 ...

恩，我这个问题到不是出在客户机上，
而是dnsproxy的8053端口暂停了对dnsmaq的服务，或者说，给予了一个不正常的应答。
一直没有能验证，
但是，
我猜测可能是dnsproxy使用原生的socks通过UDP模式向外部8.8.8.8进行查询而容易被中断，
后来换用了pdnsd后，pdnsd是用的tcp模式向外部8.8.8.8进行查询，故而失败率较低，
所以在dnsmasq向psdns查询的时候，不容易失败，从而不容易导致dnsmasq产生错误。

目前还不大清楚为何UDP模式的dnsproxy的查询就容易被中断掉，，，

gaze

tulanding 发表于 2018-12-2 11:45
防止DNS污染第一步是DHCP中设置DNS的地址为内部网关地址，不要自定义设置公网DNS，否则路由器就没控制权了

恩，我是如此设置的，客户机的DNS都是指向路由器内网IP的。
出现的问题不是在客户机这边，
是在dnsmasq转发xx类的DNS查询到dnsproxy的时候。

srrshweee

gaze 发表于 2018-12-3 12:45
恩，我这个问题到不是出在客户机上，
而是dnsproxy的8053端口暂停了对dnsmaq的服务，或者说，给予了一个 ...

墙就是这么工作的。针对你最后一句话的问题。

zhengxinhn

dnsproxy 描述有误，据 bigandy 说他修改了 dnsproxy，默认使用 tcp 查询而非UDP。

漫游者

大佬666666

wofl5629

基本看懂了，就是想问下大佬你解决时不时出现的“nameserver 127.0.0.1 refused to do a recursive query”问题没有。
还是说只要dnsproxy服务不能保证百分百可用，就会出现这样的报错？