在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,將能進一步縮短延遲。


Advertisement

更多 iThome相關內容