尽管有一个实时项目正在推进 消除不安全的HTTP信息流量 ,DNS基本上还是一个依赖于未授权明文的网络服务。然而,还是有一些努力可以来尝试和修复这个问题的。这篇文章就是我使用Debian笔记本来同时利用 DNSSEC 和 DNSCrypt 进行安全的DNS通信的开始。
DNSCrypt
DNSCrypt是为了使终端用户能够加密它和DNS解析服务器之间的信息流量而被发明出来的服务。
为了调整你的互联网提供商(ISP)默认的DNS解析服务器为一个DNSCrypt服务器,只要简单地安装 dnscrypt-proxypackage 并且在/etc/resolv.conf设置默认解析服务器即可:
nameserver 127.0.2.1
如果你使用的是静态网络配置,就在/etc/dhcp/dhclient.conf中更改:
supersede domain-name-servers 127.0.2.1;
如果你依赖基于DHCP动态网络配置,那么你在选择你的 DNSCrypt 服务器 的时候,需要有两件事情牢记于心:
它们对DNS信息流量是否会保留日志记录
它们是否支持DNSSEC
我个人选择的是一家位于冰岛的解析服务器,我在/etc/default/dnscrypt-proxy中的配置如下:
DNSCRYPT_PROXY_RESOLVER_NAME=ns0.dnscrypt.is
当DNSCrypt保护着我们DNS请求的保密性时,它并没有保证我们请求得到的结果也是保密的。为了认证结果的正确性并且防止DNS污染,一个层次性的加密系统被创造了出来:DNSSEC
为了能够使用它,我在我的电脑上设置了一个 本地非绑定的DNSSEC解析服务器 ,并把配置文件/etc/resolv.conf(或/etc/dhcp/dhclient.conf)指向了我建立在127.0.0.1地址上的安装。
然后我在/etc/unbound/unbound.conf.d/dnscrypt.conf中写入了这些:
server: # Remove localhost from the donotquery list do-not-query-localhost: no forward-zone: name: "." forward-addr: 127.0.2.1@53
来使电脑不是直接自由地从DNS解析,而是经过加密的DNSCrypt代理。
在我的体验中,DNSSEC和DNSCrypt代理是相当可靠的,但是他们最终由于网络变化而变得复杂和模糊(推测),所以开始返回错误。
为此,我想到了一个非常原始但是可靠的变通方法,那就是在/etc/cron.d/restart-dns.conf创建一个cronjob每天重启这两个服务。
0 3 * * * root /usr/sbin/service dnscrypt-proxy restart 1 3 * * * root /usr/sbin/service unbound restart
做了如上工作之后,我还要解决一个问题,那就是 强制网页门户认证 。这在消息传递中是非常恼人的,因为认证强制要求我使用门户网站的DNS解析服务器来连接可以解锁wifi连接的启动画面。
dnssec-triggerpackage 看起来是非常可靠的,但是当我在我的jessie笔记本上尝试的时候,它并不是很有用。
我目前暂时的解决办法是,每当我需要连接这些烦人的强制门户网站时,就在/etc/dhcp/dhclient.conf注释掉这一行
#supersede domain-name-servers 127.0.0.1;
如果你有更好的解决方法,请留下你的评论!