盡管有一個實時項目正在推進消除不安全的HTTP信息流量，DNS基本上還是一個依賴於未授權明文的網絡服務。然而，還是有一些努力可以來嘗試和修復這個問題的。這篇文章就是我使用Debian筆記本來同時利用DNSSEC 和 DNSCrypt進行安全的DNS通信的開始。
DNSCrypt
DNSCrypt是為了使終端用戶能夠加密它和DNS解析服務器之間的信息流量而被發明出來的服務。
為了調整你的互聯網提供商(ISP)默認的DNS解析服務器為一個DNSCrypt服務器，只要簡單地安裝dnscrypt-proxypackage並且在/etc/resolv.conf設置默認解析服務器即可：
?
如果你使用的是靜態網絡配置，就在/etc/dhcp/dhclient.conf中更改：
?
如果你依賴基於DHCP動態網絡配置，那麼你在選擇你的DNSCrypt 服務器的時候，需要有兩件事情牢記於心：
它們對DNS信息流量是否會保留日志記錄
它們是否支持DNSSEC
我個人選擇的是一家位於冰島的解析服務器，我在/etc/default/dnscrypt-proxy中的配置如下：
?
盡管有一個實時項目正在推進消除不安全的HTTP信息流量，DNS基本上還是一個依賴於未授權明文的網絡服務。然而，還是有一些努力可以來嘗試和修復這個問題的。這篇文章就是我使用Debian筆記本來同時利用DNSSEC 和 DNSCrypt進行安全的DNS通信的開始。
DNSCrypt
DNSCrypt是為了使終端用戶能夠加密它和DNS解析服務器之間的信息流量而被發明出來的服務。
為了調整你的互聯網提供商(ISP)默認的DNS解析服務器為一個DNSCrypt服務器，只要簡單地安裝dnscrypt-proxypackage並且在/etc/resolv.conf設置默認解析服務器即可：
?
如果你使用的是靜態網絡配置，就在/etc/dhcp/dhclient.conf中更改：
?
如果你依賴基於DHCP動態網絡配置，那麼你在選擇你的DNSCrypt 服務器的時候，需要有兩件事情牢記於心：
它們對DNS信息流量是否會保留日志記錄
它們是否支持DNSSEC
我個人選擇的是一家位於冰島的解析服務器，我在/etc/default/dnscrypt-proxy中的配置如下：
?
可靠性
在我的體驗中，DNSSEC和DNSCrypt代理是相當可靠的，但是他們最終由於網絡變化而變得復雜和模糊（推測），所以開始返回錯誤。
為此，我想到了一個非常原始但是可靠的變通方法，那就是在/etc/cron.d/restart-dns.conf創建一個cronjob每天重啟這兩個服務。
?
強制網頁門戶
做了如上工作之後，我還要解決一個問題，那就是強制網頁門戶認證。這在消息傳遞中是非常惱人的，因為認證強制要求我使用門戶網站的DNS解析服務器來連接可以解鎖wifi連接的啟動畫面。
dnssec-triggerpackage看起來是非常可靠的，但是當我在我的jessie筆記本上嘗試的時候，它並不是很有用。
我目前暫時的解決辦法是，每當我需要連接這些煩人的強制門戶網站時，就在/etc/dhcp/dhclient.conf注釋掉這一行
?
