DNS資訊安全防護的最後一里路

在傳統上，DNS一直遭受到“最後一里”安全問題的困擾；DNS的客戶端與本地端的DNS伺服器之間的通訊幾乎一直都是“明碼”（未加密） 的傳輸。因為這樣，DNS容易受到Spoofing、攔截或是其它的干擾。對此，IETF提出了二種機制來解決此問題；一為TLS over DNS（DoT）與DNS over HTTPS（DoH）。但是，這二種機制都可以規避現在企業組織內部的資安防護架構。

對此，我們相信，這樣的機制對於企業組織的資安是百害而無一利的。接下來我們將跟各位詳細說明DoT與DoH，並跟各位敘述我們建議解決DNS Client安全的方法。

解釋DNS over TLS（DoT）與DNS over HTTPS（DoH）的運作：

當DNS Security Extensions (DNSSEC)對DNS加入身份驗證與數據完整性的檢查機制時，一般都會略過DNS Client的安全性。這個時候，本地端的DNS伺服器會執行DNSSEC的驗證，並建立其數據資料的真實性與完整性，然後將結果傳送給DNS Client，但是，這最後的過程可能會遭受到“Spoofing”的攻擊。

IETF的“DPRIVE”（DNS PRIVate Exchange）工作組開發了兩種新機制來解決DNS的“最後一里”的問題；TLS over DNS（簡稱DoT，並記錄於RFC7858）與DNS over HTTP （DoH），記錄於RFC8484。

DoT和DoH均提供重要的功能；使用DoT或DoH對DNS Client與DNS伺服器之間的通信進行加密，以提供數據機密性與完整性，而DNS Client可以選擇使用任一協議對DNS伺服器進行身份的驗證。

DoT只使用TCP port 853，而DoH使用HTTPS流量，與443使用的同一port。因此，很難將DoH與其他HTTPS流量區分開。

長時間來，我們一直建議客戶阻擋內部IP與Internet之間的直接溝通，此步驟可防止一些類型的惡意軟體，像是DNSChanger，且強制內部主機使用由IT管理的DNS設備，該內部的DNS設備可使用如“Response Policy Zones （RPZs）”的名稱解析策略。不過，使用DoH則難以阻擋內部主機查詢Internet上的DNS伺服器。（DoT只使用853 port，所以容易阻擋。）

一些支援DoH的應用程式也可能會故意略過Client端所設定本地端的DNS，像是Mozilla的Firefox，在某此版本中，提供了對DoH實險性的支援，啟用後，Firefox會忽略任何本地端的DNS設定，通過HTTPS直接將DNS查詢發送到Cloudflare。此舉將繞開任何本地端的安全機制，這樣將使得企業組織對於DNS解析是不透明的。如Firefox的應用，對於DNS名稱解析與其它的應用程式不同，也增加了對於DNS問題的複雜性。

我們不質疑DoH開發人員的動機；他們的目標也是在幫助保護Internet上經常對於DNS流量的窺察和利用DNS機制的一些行為，但是我們質疑它是否適合在企業網路上使用。

Infoblox對於使用DoT與DoH的一些建議：

我們的建議是公司應阻擋內部IP與Internet上的DNS服伺器（包括Cloudflare）之間的直接DNS傳輸（包括DoT和DoH），這種方法可迫使用戶使用公司內部的DNS，進而使公司IT組織可以應用DNS解析策略來排除問題。

阻擋內部I與外部標準DNS和DoT傳輸非常簡單。 只需防火牆規則就足夠了，例如只開放內部DNS主機對外存取53 port，並將內部除DNS主機外的IP阻擋內外的53與853 port的流量。

阻擋DoH較為棘手，對於防火牆而言，要區皆DoH與HTTPS是很難的，我們能針對像是Cloudflare或是Google等提供DNS服務的IP，針對其443 port做阻擋。

儘管我們認為規避內部DNS安全機制是一個壞主意，但Infoblox認為解決DNS“最後一里”的問題非常重要且值得，我們正在與合作夥伴Internet Systems Consortium密切合作，在即將發布的BIND版本以及Infoblox的NIOS中支援DoT。

資料來源：https://blogs.info blox.com/company/dot-doh-and-the-dns-last-mile-security-problem/