臉書也開始試驗加密DNS，測試結果顯示加密不會增加整體延遲

在Mozilla與Cloudflare合作提供DNS over HTTPS服務後，臉書也要對網路流量的最後一哩路DNS，提供加密服務，現在臉書也與Cloudflare合作，進行DNS over TLS的試驗。

臉書與Cloudflare DNS合作實驗計畫，該計畫以傳輸層安全性（TLS）這個廣泛使用的協定，在不安全的通道上提供DNS雙方受驗證與機密的通訊。DNS over TLS解決方案，能為剩餘還未完全加密的網頁流量，提供加密和驗證服務。

透過這個實驗計畫，臉書使用者可以使用Cloudflare DNS，獲得更近一步的安全體驗，不只是以HTTPS連接臉書，更在DNS層級，保護裝置連接到Cloudflare DNS，以及從Cloudflare DNS到臉書域名伺服器的流量。

從過去幾個月開始，臉書就開始在Cloudflare的1.1.1.1遞迴解析器以及臉書自己的權威域伺服器之間，啟用DNS over TLS服務，目的是為了要了解大規模部署的可行性，透過收集各項指標，取得接收DNS解答延遲的額外成本。臉書表示，這項實驗能幫助他們了解，當DNS over TLS在外部執行時，所會發生的情況，而且在生產工作負載中實驗，才能發現DNS從UDP轉換至加密協定可能產生的問題。

臉書提到，該試驗到目前為止，證明了將DNS over TLS用於Cloudflare DNS和臉書域名伺服器之間的生產負載流量，是個可行的解決方案。雖然在第一次連接時的初始請求，會增加額外的延遲，但是之後能以重用TLS連接來執行多個請求，所以初始額外成本便會被分攤到Cloudflare DNS和臉書權威域伺服器之間DNS延遲的p99，而這與UDP基準相當。

臉書實驗了從TLS切換到UDP所產生的延遲影響，而這能讓臉書比較兩種協定的請求延遲。下圖顯示的延遲百分位數，沒有計算TCP/TLS對話建立的成本，在17:30時，連結從TLS切換到UDP，即果說明了一旦連結建立了，無論是TLS或是UDP，查詢和回應的延遲都相同。

而下圖則是將建立連結的時間考慮進去，評估整體的延遲。同樣在17:30時，協定從TLS切換到UDP，結果顯示，無論是TLS還是UDP，對整體延遲都沒有差異，臉書解釋，這是因為使用TLS對話恢復技術，並且透過相同的TLS連結執行多項請求，以分攤初始連接設定的成本。

臉書提到，雖然他們實作了TLS對話恢復，但是當前配置尚未充份利用新協定帶來的最佳化，在之後使用最新版本的TLS 1.3和TCP Fast Open，將能進一步縮短延遲。