[譯] DNS over TLS：端到端加密的 DNS

• 原文地址：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、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。