本APNIC文摘原標題為The path to resolverless DNS，由Geoff Huston撰文。
本文為系列文章下篇，說明免費開放DNS解析服務衍生的DNS隱私顧慮，以及相應而生的新興技術，無解析器DNS亦為其中之一。
DNS隱私的興起
然而，公開DNS解析服務也帶來另一種隱私和資料完整性風險。不再使用ISP提供的遞迴解析器，代表客戶端本地解析器送出的查詢，必須經由公共網際網路抵達遞迴解析器。
本地解析器和遞迴解析器之間的DNS交流，使用未加密的用戶資料報協定（User Datagram Protocol，UDP），無法防範竊聽或中途竄改。本地解析器基本上不會執行DNSSEC驗證，所以無法偵測發現遭竄改的訊息。DNS over UDP也不執行任何類型的伺服器驗證，這表示，即使開放DNS解析器的位址被路由挾持轉向別的DNS解析器，本地解析器也不會發現。簡單來說，遠離使用者的DNS解析，會產生訊務遭妨礙或監聽等一系列的問題。
目前集中於本地 — 遞迴連線加密傳輸的技術包括：
- DNS over TLS（DoT）：利用TLS安全協定建立的加密通道傳輸資料（RFC 7858）。
- DNS over QUIC （DoQ）：利用QUIC安全協定建立的加密通道傳輸資料（RFC 9250）。
- DNS over HTTPS（DoH）：利用加密HTTPS安全協定傳輸資料（RFC 8484）。
這些做法的相同之處，在於本地解析器能夠驗證遞迴解析器身份，藉此減緩各種傳輸遭中途攔截的風險。這些做法能成功阻擋大部分的中途挾持轉向或竄改的威脅，但無法避免竊聽。
DNS over HTTPS
如果DoT、DoQ和DoH都可以有效防止本地和遞迴解析器因網路中轉被分開的問題，為什麼DoH還沒消失？
一種看法是DoH根本沒必要。雖然DoH有效將DNS查詢和回應藏在HTTPS訊務中，有心人士還是可以竊聽緊接的下一筆訊務以推斷原始的DNS交流。更全面的做法是把所有訊務都塞進一個加密通信中，就像VPN一樣，但如果已經使用VPN的話，DoH其實沒有什麼額外的安全效果。
DoH不只和網路訊務一起使用port 443，還會使用通用HTTP快取控制，管理DNS回應的本地庫存。HTTP/2和HTTP/3都支援平行傳輸、重新要求回應和表頭壓縮，應用程式無需使用本地解析器，可以選擇將DNS查詢傳到任何自選的HTTPS伺服器。更重要的是，HTTP/2和HTTP/3都含有server push：
HTTP/2容許伺服器在回應客戶端送出的請求時，連帶預先傳送（push）另一筆回應（和預期將收到的對應請求）。 這在使用者知道客戶會需要多筆回應以完成原始請求時很有用。（RFC 7540）
HTTP/3中也有類似功能：
Server push是一種互動模式，容許伺服器在預期客戶端將提出請求時，事先將該筆查詢和回應同時推送（push）給客戶端。這種做法是用網路用量交換降低延遲。HTTP/3的server push和HTTP2類似，但使用不同機制。
每筆server push都有伺服器指派的單一推送ID。此推送ID是用來在HTTP/3連線的不同脈絡中指涉此「推送」（push）。（draft-ietf-quic-http）
這表示伺服器在回傳HTTP查詢回應時，可以同時將未查詢的HTTP物件打包傳送到客戶端。傳統上，這些物件可能包含HTML樣式表、圖片和其他元素，現在有了DoH，物件中還可以多加上HTTP包裹的DNS回應。如此一來，客戶端可以直接使用DNS回應，無需再經歷DNS解析和衍生的延遲或隱私問題。
但客戶端仍面臨一個問題：他怎麼知道伺服器推送的是真實的DNS回應？雖然傳送路徑已經加密以防止第三方竊聽或偷換，但仍無法保證伺服器傳送的DNS資訊正確。當然，這種不確定性並非無解析器DNS所獨有。
目前唯一能解決此問題，確保來源真實的方案是DNS安全擴充（DNS Security Extensions，DNSSEC）。若查詢域名有DNSSEC簽署，則無論客戶端是透過server push或傳統的DNS解析流程取得回應，都可確認資料為真。
在傳統DNS解析流程中，若域名有DNSSEC簽署，客戶端還需經歷一系列驗證確認後回傳等繁瑣步驟，這會拉長整體解析時間，也因此本地解析器很少執行DNSSEC驗證。在DoH的server push模式中，上述驗證確認回傳等需要的物件，則都由伺服器這邊推送。後者顯然可以提升使用者體驗，但問題是使用者實際上也難以確認伺服器聲稱的DNSSEC簽署是否屬實。
為什麼無解析器的DNS引人興趣？
作者認為，這要從網際網路的經濟版圖變化談起。
現在的網際網路，是靠提供內容和服務創造經濟價值。奠基於通用基礎建設和協定層的免費穩定上，應用層持續開發商機並回收利潤。這造成的問題是通用基礎建設缺乏改善演進的動機，而應用層等不及底層架構跟上自身需求，於是把所有問題帶到應用層上，自行試圖在客戶端解決。
無解析器DNS就是此情境下的產物。這個做法不會改變DNS的通用基礎架構，只是改變應用程式使用DNS的方式，藉此強化應用程式對使用者經驗的掌控。
過去十年來，網際網路變得更快也更強健：
- 內容傳遞網路（Content Delivery Network，CDN）的應用把內容和服務帶到使用者身邊。
- 能善加利用平行傳輸的非封鎖式傳輸協定（如QUIC）出現。
- TCP和許多網路行為持續調整，創造更快、效率更高的網路傳輸。
- DNS現在承載更多資訊（如HTTPS紀錄），所以服務可以更快啟動。
然而，在這些改善演化中，唯有DNS仍停滯不前。事實上，DNS仍是遲緩、隱私洩露、不明原因失敗等諸多問題的來源。
無解析器DNS不會一次解決所有DNS的問題。這本來就是不可能的任務。但以HTTPS為基礎的應用程式和服務能因此取得大部分應用程式與服務品質的掌控權。它會比傳統DNS快很多。它可以大幅淡化客戶終端在傳統DNS解析流程中的角色。它也可能用來降低失敗頻率。基於這些原因，作者認為，無解析器DNS會是DNS演化進程中，值得關注的一步。
*台灣網路資訊中心（TWNIC）與亞太網路資訊中心（APNIC）合作，定期精選APNIC Blog文章翻譯摘要，提供中心部落格讀者了解目前亞太地區網路發展之最新趨勢。原文標題為The path to resolverless DNS。
