hackgfw / openwrt-gfw

Openwrt的翻墙解决方案
GNU General Public License v3.0
502 stars 111 forks source link

你好,发现AntiDNSPoisoning使用过程中的问题 #2

Closed sangood closed 11 years ago

sangood commented 11 years ago

你好,感谢您上次回复openvpn的问题,在使用AntiDNSPoisoning的时候,发现查询 www.facebook.com 的时候一直使用电信的dns,返回69.171.234.37 ,这个ip的确是facebook的,但这个ip无法访问,原因是无法使用8.8.8.8DNS 导致返回的IP不准确。AntiDNSPoisoning配置已经正确,twitter.com就没这个问题。 另外即使在resolv.conf指定了server=/www.facebook.com/8.8.8.8 server=/facebook.com/8.8.8.8 也不再起作用。

root@TP-LINK:/tmp# nslookup www.facebook.com Server: 127.0.0.1 Address 1: 127.0.0.1 localhost

Name: www.facebook.com Address 1: 2a03:2880:2110:cf01:face:b00c:0:9 edge-star6-ecmp-12-frc1.facebook.com Address 2: 69.171.234.37 root@TP-LINK:/tmp# nslookup www.facebook.com 8.8.8.8 Server: 8.8.8.8 Address 1: 8.8.8.8 google-public-dns-a.google.com

Name: www.facebook.com Address 1: 2a03:2880:2030:2f01:face:b00c:0:8 edge-star6-ecmp-02-ash3.facebook.com Address 2: 31.13.75.1 edge-star-shv-01-pao1.facebook.com root@TP-LINK:/tmp# nslookup www.facebook.com 218.85.152.99 Server: 218.85.152.99 Address 1: 218.85.152.99 FJ-DNS.xm.fj.cn

Name: www.facebook.com Address 1: 69.171.234.37

感谢您的分享!

hackgfw commented 11 years ago

这个问题挺蹊跷的:

我试了下用本地电信提供的DNS服务器查询 www.facebook.com, 每次返回的结果都不同, 且都是被污染的IP. 你用 218.85.152.99 查询,每次都是返回69.171.234.37吗?

sangood commented 11 years ago

是挺奇怪的,我现在还没找出来原因。 1、现在是用了您的AntiDNSPoisoning,google dns是使用了VPN 网关,本地dns没有使用vpn网关。 dnsmasq用的配置文件

root@TP-LINK:/etc/openvpn# cat /etc/config/resolv.conf nameserver 218.85.152.99 nameserver 218.85.157.99 nameserver 8.8.8.8 nameserver 8.8.4.4

server=/mail.google.com/205.185.112.68

server=/google.com/8.8.8.8 server=/appspot.com/8.8.8.8 server=/facebook.com/8.8.8.8 server=/fbcdn.net/8.8.8.8 server=/twitter.com/8.8.8.8 server=/accounts.youtube.com/8.8.8.8 server=/youtube.com/8.8.8.8 server=/ytimg.com/8.8.8.8 server=/imageshack.us/8.8.8.8 server=/books.com.tw/8.8.8.8 server=/book.com.tw/8.8.8.8 server=/nownews.com/8.8.8.8 server=/gov.tw/8.8.8.8 server=/trailers.apple.com/58.63.244.120 server=/www.facebook.com/8.8.8.8 //这行无论是否添加都一样,应该是dnsmasq同时查询所有dns服务器

现在这个IP69.171.234.37应该是www.facebook.com的废弃地址,不可以ping通,我在vps上ping的时候都无法ping。 我无论是否去掉vpn每次本地dns都是返回同一个地址: C:\Users\Sangood>nslookup www.facebook.com 服务器: openwrt-dreambox.lan Address: 192.168.1.1

非权威应答: 名称: star.c10r.facebook.com Addresses: 2a03:2880:2030:2f01:face:b00c:0:8 69.171.234.37 Aliases: www.facebook.com

C:\Users\Sangood>nslookup www.facebook.com 218.85.152.99 服务器: FJ-DNS.xm.fj.cn Address: 218.85.152.99

非权威应答: DNS request timed out. timeout was 2 seconds. 名称: www.facebook.com Address: 69.171.234.37

C:\Users\Sangood>nslookup www.facebook.com 218.85.152.99 服务器: FJ-DNS.xm.fj.cn Address: 218.85.152.99

非权威应答: DNS request timed out. timeout was 2 seconds. 名称: www.facebook.com Address: 69.171.234.37 我猜测本地DNS提供的这个IP应该是www.facebook.com废弃的,所以GFW就没管。我看您写的“放入POSIONEDDOMAIN的域名应保证该域名以后不会提供DNS解析服务,同时该域名也不太容易被GFW解封”这句话前提是www.facebook.com不会提供解析服务。

hackgfw commented 11 years ago

server=/xxxxx/xxxxxx 这些设置应该放到 /etc/dnsmasq.conf , 否则应该不会起作用. 查询 192.168.1.1 ,每次返回的dns结果应该是一样的,因为dnsmasq有缓存,你可以尝试执行 /etc/init.d/dnsmasq restart 再试试结果是多少. 我注意到你查询 218.85.152.99, 会遇到超时, 很费解, 如果本地ISP的DNS超时的话,反而会使用google DNS的正确结果, 你用 218.85.152.99 查询其他域名会超时吗? 如果执行 /etc/init.d/protectdns stop (停止AntiDNSPoisoning)再 nslookup www.facebook.com 218.85.152.99 还会超时吗?

sangood commented 11 years ago

谢谢,已经解决问题了。 把server=/*_/_**放到/etc/dnsmasq.conf解决了绑定dns解析的问题。 我们上面的查询都是有重启dnsmasq之后的,应该不是缓存问题引起的。的确218.85.152.99有时候会超时,而且解析需要大概5秒,其他的解析都很快的,也不会超时。 停止AntiDNSPoisoning后,用218.85.152.99解析还是一样的。 所以感觉应该是本地电信dns的问题。 我现在绑定server之后,解决了解析错误IP问题,感谢!

hackgfw commented 11 years ago

如果218.85.152.99经常超时的话, CDN可能会不起作用, 因为其返回速度慢于国外的. 感觉这个像是 218.85.152.99 错误配置导致的, 可以试试换个DNS服务器看看.

sangood commented 11 years ago

好的,218.85.152.99不会经常超时的,其他域名基本没出现这样的情况,就是这个facebook的会比较慢。 现在问题基本解决了,感谢您的帮助。

在 2013年5月11日下午12:58,hackgfw notifications@github.com写道:

如果218.85.152.99经常超时的话, CDN可能会不起作用, 因为其返回速度慢于国外的. 感觉这个像是 218.85.152.99 错误配置导致的, 可以试试换个DNS服务器看看.

— Reply to this email directly or view it on GitHubhttps://github.com/hackgfw/openwrt-gfw/issues/2#issuecomment-17754471 .