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

0x01 DNS的安全及隱私

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

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

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

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

0x01 兩個協(xié)議

DNS over TLS的標準文檔是RFC7858。文檔很短，也比較易懂?？蛻舳讼群瓦f歸服務(wù)器進行TLS握手，使用的TCP端口號是853。握手之后，把DNS數(shù)據(jù)包作為TLS的payload發(fā)給DNS遞歸服務(wù)器即可。請求和回答的報文與普通的DNS over TCP的報文格式一樣。

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

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

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

0x02 子域名爆破

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

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