本文章簡單介紹一下兩種加密DNS協議：DNS over HTTPS 和 DNS over TLS。這兩種協議主要為了解決DNS帶來的隱私和中間人篡改問題。

0x01 DNS的安全及隱私

DNS設計之初并沒有考慮安全問題，所以大部分DNS查詢使用UDP傳輸，當然也可以用TCP。這兩種方式既沒有加密也沒有簽名。這就意味著中間人可以監聽到用戶訪問的域名，導致隱私泄露。另外因為沒有簽名驗證，中間人也可以篡改DNS返回的IP地址，導致用戶訪問釣魚網站。后來有了DNSSEC，引入了簽名機制，保證了從權威DNS服務器，到DNS遞歸服務器，再到客戶端都沒有被篡改。但是這依然沒有解決隱私問題。

[[227853]]

其實隱私問題之所以沒被重視，主要有幾點：第一，中間人肯定能知道你要訪問的服務器IP地址，多數情況下知道IP就知道是什么網站了。第二，有一些上層協議也會泄露域名，明文HTTP就不說了，TLS協議也有Server Name Indication（SNI），會暴露明文域名。（注：IETF TLS工作組目前正在探討草案《SNI Encryption in TLS Through Tunneling》，計劃加密SNI）。第三，一些上層協議，如TLS，能夠識別DNS是否被篡改，這使得簽名DNS本身顯得不那么重要。[1]

但即使有上述三點，加密DNS數據也有顯而易見的好處。第一，減小攻擊面。第二，用戶請求DNS之后，未必就非得訪問它呀，比如本文下述的子域名爆破，我們只對DNS數據本身感興趣，而不訪問其域名，這樣加密DNS就有了實際意義。

所以本文就要探討一下DNS over TLS和DNS over HTTPS。這兩個協議目前僅限于用戶客戶端和DNS遞歸服務器間的通信。截至2018年4月，遞歸服務器和權威服務器之間的通信不在這兩個協議的適用范圍內。也許以后遞歸服務器和權威服務器也會納入DNS over TLS協議里，不過目前我沒聽說有人實現它。

0x01 兩個協議

DNS over TLS的標準文檔是RFC7858。文檔很短，也比較易懂。客戶端先和遞歸服務器進行TLS握手，使用的TCP端口號是853。握手之后，把DNS數據包作為TLS的payload發給DNS遞歸服務器即可。請求和回答的報文與普通的DNS over TCP的報文格式一樣。

DNS over HTTPS目前沒有RFC文檔。只有草案《DNS Queries over HTTPS》。這個草案規定可以用GET和POST方法，如果用POST，就把普通的DNS over UDP報文作為HTTP的body發送，并且在HTTP Header中設置Content-Type為application/dns-message。如果用GET，就把普通DNS over UDP報文用base64編碼，把編碼后的字符串作為URL的dns參數發送。

有一些廠商還支持JSON格式的DNS over HTTPS協議，比如Google和CloudFlare的DNS服務器。出于兼容考慮，在格式方面，CloudFlare選擇和Google保持一致。具體格式參見Google文檔或CloudFlare文檔。

為了讓用戶好記，Google的DNS服務器是8.8.8.8和8.8.4.4，CloudFlare的DNS服務器是1.1.1.1和1.0.0.1。CloudFlare的DNS服務是2018年4月1日上線的，他們自稱是因為我們的IP有4個1，所以是4月1日。[2]

0x02 子域名爆破

我用C#寫了一個非常簡易的子域名爆破工具，為了演示DNS over HTTPS。（僅為技術討論使用，請勿用于違法用途！）使用的是JSON格式的DNS over HTTPS，可以從UI上選服務器。純字典搜索，字典是從dnsrecon項目復制過來的。

這個工具我只測試了Windows 10 + Visual Studio 2017 + .NET Framework 4.6.1。特別是Windows 10以前的操作系統可能連不上https://1.1.1.1 。我記得老版Windows不支持IP地址作為證書的Subject Alt Name，所以證書校驗可能會失敗。

工具的地址：【點擊底部閱讀原文下載】。歡迎大家提交issues和PR。

0x03 參考資料

[1] RFC7626 - DNS Privacy Considerations

[2] Announcing 1.1.1.1: the fastest, privacy-first consumer DNS service

[3] DNS over TLS - Cloudflare Resolver

[4] DNS over HTTPS - Cloudflare Resolver