- 原文地址：DNS over TLS: Encrypting DNS end-to-end
- 原文作者：code.fb.com
- 譯文出自：掘金翻譯計劃
- 本文永久連結：github.com/xitu/gold-m…
- 譯者：lsvih
- 校對者：Qiuk17
為了加密網際網路流量中未被加密的最後一部分，我們與 Cloudflare DNS 合作進行了一個試點專案。這個試點專案利用安全傳輸層協議（即 TLS，一種被廣泛應用的、經過時間證明的機制，可用於雙方在不安全通道上建立通訊時，為通訊提供身份認證及加密）與 DNS 進行結合。這個 DNS over TLS（DoT）方案能夠加密並驗證 Web 流量的最後一部分。在 DoT 測試中，人們可以在瀏覽 Facebook 時使用 Cloudflare DNS 享受完全加密的體驗：不僅是在連線 Facebook 時用的 HTTPS 時進行了加密，而且在 DNS 級別，從使用者計算機到 Cloudflare DNS、從 Cloudflare DNS 到 Facebook 域名伺服器（NAMESERVER）中全程都採用了加密技術。
DNS 的歷史
二十世紀八十年代末，域名系統（DNS）被提出，可以讓人們用簡短易記的名稱來連線實體（比如 facebook.com），這使得網路安全發生了極大的變化。人們為網路安全做了許多的改進，比如現在大部分的網路流量都是通過 HTTPS 連線，但線上上傳輸明文時仍然存在一些問題。
2010 年，DNS 安全擴充（DNSSEC）部署實施，DNS 協議由此支援身份驗證功能。雖然 DNSSEC 支援對訊息進行身份驗證，但仍然會使用明文來傳輸 DNS 請求與應答。這也使得傳輸的內容可以被請求方與響應方中間路徑上任意節點輕鬆獲取。2014 年 10 月，國際網際網路工程任務組（IETF）建立了 DPRIVE 工作組，其章程包括為 DNS 提供保密性與身份驗證功能。
此工作組在於 2016 年提出 RFC 7858 指定了 DoT 標準。為此，Cloudflare 的 1.1.1.1 與 Quad9 的 9.9.9.9 等開放的解析器在 DoT 的支援下更加關注使用者的隱私。這也保護了終端使用者裝置到 DNS 解析器這一部分 DNS 通訊。但連線的其它部分仍然是明文傳輸。在 2018 年 5 月，DPRIVE 重新開發了一個方法，用於加密從解析器到域名伺服器間的通訊。
DoT 以前的 DNS
DoT 試驗
我們在過去的幾個月中一直在進行一項試驗，在 Cloudflare 1.1.1.1 遞迴解析器與我們的主域名伺服器間開啟 DoT。這個試驗的目的是瞭解大規模使用 DoT 的可行性，收集資訊以更好地瞭解 DoT 在接受應答時的延遲產生的開銷，並確定計算開銷。這個試驗讓我們更好地瞭解了 DoT 協議在真實環境下的表現。另外在生產環境負載中試驗把 DNS 從 UDP 等即發即棄方法換成 TLS 之類的加密連線協議，可以將一些設計協議時發現不了的問題給暴露出來。
DoT 下的 DNS
截至目前，通過觀察 Cloudflare DNS 與 Facebook 域名伺服器間的生產環境流量，已經可以證明該試驗是可行的解決方案。在初始化一個新連線的時候由於需要初始化請求，因此增加了延時；但我們可以重用 TLS 連線來處理其它更多的請求。因此，初始化增加的負載在均攤之後，降低到了 Cloudflare DNS 與 Facebook 主域名伺服器 UDP 基線的 p99 相同的程度。
下圖展示了我們從 TLS 切換回 UDP 時（在 17:30 時刻）延時的變化。它可以讓我們比較兩個協議請求的延時。第一個圖顯示了在沒有 TCP/TLS 會話建立開銷情況下的延時百分比。它展示了當連線建立後，TLS 與 UDP 在查詢和響應間的延時是相同的。
第二張圖加上了建立連線的時間來考慮請求的總體延遲。從圖中可以看到，使用 TLS 還是 UDP 對連線的總體延時也沒有影響。這是因為我們使用 TLS 的會話恢復技術，通過相同的 TLS 連線來執行多個請求，實質上分攤了初始化連線的開銷。
作為參考，下圖展示了在不使用 TLS 會話恢復技術，並在建立連線後僅處理少量請求時總延時的差異。在比 22:35 稍早的時刻完成了 TLS 到 UDP 的切換，可以看到總體而言 TLS 對大多數的請求的影響與 UDP 類似，但在 p95 或更高的統計指標下，請求的延時收到了影響。後面一張圖顯示，當連結已經建立時，延時不受影響。這兩張圖表明，第一張圖中的差異是由於建立新連線時產生的，並且實際上，建立新連線的頻率很高。
基本來說，瀏覽 Facebook 和使用帶 DoT 的 Cloudflare DNS 的使用者，無論是在用 HTTPS 連線時還是在 DNS 層面上，都可以享受完全加密的體驗。雖然我們已經實現了 TLS 會話恢復技術，但還沒有充分利用現代協議棧提供的全部優化方法。在將來，我們可以利用 TLS 的最新版本（TLS 1.3）和 TCP Fast Open 等技術帶來的改進，進一步降低延時。
DoT 的下一步
這個試驗已經證明了，我們可以使用 DoT 大規模處理生產環境的負荷，並且不會對使用者體驗產生任何負面影響。我們將這個試驗所得到的經驗和知識，作為一種可行的經驗回饋給 DNS 社群。
IETF 等標準社群開發協議時，有時候會缺乏與最終實施與執行協議的組織的意見，這導致了協議設計者、實施者、運營者間的脫節。通過這個試驗，我們可以根據在生產環境中執行協議得到的經驗，及時向工作組報告具體結果，同時也為有意於部署 DoT 的運營商和軟體供應商提供了最佳實踐。
我們希望這些初步的試驗結果可以激勵其它的行業合作伙伴加入我們的試驗，擴大 DoT 運營商的數量，並得到更多制定此協議時得到的經驗，從而提高反饋水準、得到更多的運營知識和最佳實踐。
感謝 Cloudflare 的 Marek Vavruša 在這個試驗中做出的貢獻。
如果發現譯文存在錯誤或其他需要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可獲得相應獎勵積分。文章開頭的 本文永久連結 即為本文在 GitHub 上的 MarkDown 連結。
掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。