自從知名瀏覽器陸續宣布支持DoH（DNS over HTTPS）以來，關於這項DNS（Domain Name System）安全協定的討論便相繼出現在各種報導、論壇與專欄[1]。筆者將從兩個面向對DoH議題進行剖析，包括：(1)協定的設計、(2)協定的推廣與應用。

DoH的協定設計面議題

依據RFC 8484，DoH訴求在client與resolver間建立加密通道，而此加密通道奠基於與網頁應用相同的技術。往好處想，連線的機密性（confidentiality）與真實性（authenticity）可得到一定程度的保護，甚至「HTTP/2 Server Push」[2]的功能也被期待能在client提問前就先由server主動提供答案，藉以提升網頁載入速度、優化使用者體驗。然而，負面議題亦存在如下：

對連線更高規格的要求使傳統DNS仰賴的UDP（User Datagram Protocol）傳輸不敷使用，取而代之的TCP（Transmission Control Protocol）將因經典的「三方交握」（Three-Way handshake）增加多少負擔？憑證等加解密運算又會對解析速度造成多大影響？對大家每天都在用的網路關鍵基礎設施DNS系統而言，「效能」是不容迴避的技術議題[3]。據筆者自身的觀點與經驗，DNS訊務若從UDP變為TCP，不只伺服器的處理能力，網路設備能承載的連線數、DDoS攻擊（distributed denial-of-service attack）防護的偵測門檻等，均需重新壓測評估。

以「CIA資安要素」的觀點，DoH屬「機密性」（confidentiality）的防護，藉加密通道避免「DNS transaction」在傳輸過程中被竊聽。請注意，DoH的保護效果僅止於傳輸「過程」而不包括「端點」。意即，提供DoH服務的業者（如Google、Cloudflare等）做為加密通道的另一端，依然可以掌握其用戶的DNS查詢內容與行為。姑且不論前述DoH保護力的侷限性，審查機制（Censorship）就算在DNS加密的情境中仍是可行的。透過分析被加密之DNS訊務的「size, timing, and direction」等特徵，仍有機會歸納出部分使用者造訪的網站[4]。

雖有「EDNS(0) padding」[5]（透過填充補位降低訊務size的可區別性）被提出，但這些補強方案的成熟度與普及度仍有進步的空間。此外，HTTPS通訊協定中headers與cookies所包含的資訊也可能降低隱私保護的效果，例如「TLS SNI」（Transport Layer Security Server Name Indication）[6]包含了用戶將造訪網站的資訊。該資訊允許伺服器在相同的IP位址甚至TCP埠號上呈現多個網站，且每個網站有各自的域名與SSL憑證。但原生的SNI資訊並未被加密，補救機制也仍在發展中[7]，這讓駭客就算不透過DNS訊務，也能一窺目標用戶到訪過哪些網站。

HTTPS是HTTP與TLS安全協議的組合[8]，而建立TLS連線需要經過複雜的協商程序[9]，為了有效率利用已建立的會話（session），「TLS Session Resumption」[10]被發展出來。傳統DNS基於UDP協定運作只能將DNS訊務對應到個別IP（除非搭配ISP將IP配發給用戶的資料，否則難以得知數個IP屬於同一個使用者的關聯）。TLS Session Resumption可構成一種跨網路、跨IP的追蹤機制，其蘊含的資訊及帶來的隱憂同樣值得關注。綜合上述，「究竟DoH能帶來多少DNS隱私的保護力、又或者造成更大的威脅」也是持續發酵的議題。

DoH的推廣與應用面議題

不管協定設計如何巧奪天工或者漏洞百出，沒有人實際拿來用，或沒有人致力推廣的話，都不具有影響力。而DoH之所以備受關注，知名龍頭業者參與（甚至主導[11]）該協定的設計與推廣是明顯的原因。

如前述，知名瀏覽器包括Firefox、Chrome陸續公布支援DoH的規劃。其中最具爭議的是：(1)DoH很可能是「by default」（且預設指向瀏覽器合作的DoH服務提供者），而非以「opt-in」讓用戶自主選擇採用的模式提供服務；(2)就算提供用戶自主選擇，一方面用戶多半會接受預設值，一方面選項應該也有限且必然經過瀏覽器業者的把關/過濾[12]。

「by default」預設啟用DoH的問題，除了會剝奪使用者自由選擇的權益，也可能導致網路生態的瞬間巨變。以這些瀏覽器目前的高市占率（如下圖示）與高使用率，一旦以更新等手段將新版軟體布達給全球用戶，則在短時間內以DoH取代傳統DNS服務（與業者）、並大量累積DoH的訊務資料絕非難事。相較於IPv6歷經多年的研究與推動，目前各界針對DoH所累積的討論與共識都還不足，冒然大規模啟用將難以管控驟變帶來的衝擊。

圖･瀏覽器市占率

資料來源：statcounter網站資料 https://gs.statcounter.com/browser-market-share

此外，資訊安全專家亦已發現駭客利用DoH發動攻擊的案例[13]，發展更完整的預防與善後配套機制刻不容緩。最後，有能力參與瀏覽器與DoH布局的龍頭業者畢竟是鳳毛麟角，這將使全球DoH訊務集中於少數業者，進而衍生出技術面、市場面的壟斷，並放大個別網路服務業者發生障礙的衝擊範圍。例如，Mozilla在推出Firefox 77的版本後，合作夥伴之一NextDNS無法承受DoH訊務量使服務可用度受到影響，最後透過釋出Firefox 77.0.1關閉（自動選擇DoH供應商）功能才得以緩解[14]。更多關於DoH「中心化」（centralization）之隱憂與衝擊的討論，可參閱《Centralized DNS over HTTPS (DoH) Implementation Issues and Risks》[15]等文章。

如果把服務與產品的高市占率視為龍頭業者影響DoH（乃至整體網際網路）發展的「能力」，接下來看看使用這能力的「動機」是否存在。DNS領域近年的大事，Open resolvers的興起肯定列在其中，有Google的Quad8、Cloudflare的Quad1、IBM的Quad9等供使用者自由選用。這些服務除了標榜穩定可用度、優秀使用者體驗及惡意域名阻擋等加值功能，也積極支援各種DNS安全協定，包括DNSSEC驗證以及本文討論的DoH等。從APNIC的統計來看，使用者是買單的（其實不用買，因為免費）。下圖顯示2020年中的Public DNS市占率。

圖･Public DNS市占率

資料來源：Geoff Huston 的《Where is the DNS heading?》https://blog.apnic.net/2020/06/18/where-is-the-dns-heading/

系統的建置與維運需要成本，況且目標客群是全球的用戶更是所費不貲，那麼這些營利公司為何要從事這樣的慈善事業？又為何如此積極推廣新技術？我們可以先看看官方或內部人員的說法。在Public DNS服務出現以前，DNS解析多半由各地ISP負責提供，除了服務品質、維護團隊素質不一，各自為政的背景下一旦出問題，申告、查測與障礙排除免不了跨組織的溝通成本。由於Google主打線上服務，自己提供DNS服務減少外部依賴性確實情有可原；Cloudflare也表示1.1.1.1能保證並優化自家域名的解析。但這真的是唯一或主要的動機嗎？

有趣且筆者認為極具說服力的是，在《The Big DNS Privacy Debate》這篇文章[16]提到Google人員透露：更快更好的網路將帶來更多的搜尋，更多的搜尋將使更多廣告被看到，更多廣告被看到就可以帶來更多營收。APNIC首席科學家Geoff Huston在《Opinion: What does DoH really mean for privacy?》一文[17]中提到「免費的產品與服務由廣告收益所資助，廣告的精準度與有效性來自對個別用戶的了解，而對於用戶的了解則需仰賴綿密且多面向的監視框架」，並以「Surveillance Capitalism」指稱上述邏輯（筆者圖示如下）。Geoff也表示，如今網路發展（不可否認Google等龍頭業者極具影響力）深受此驅動。如果將「收集資料、提升對使用者的了解及廣告精準度、增加收益」視為Google等龍頭業者的營利模式與「動機」，則將DoH與瀏覽器結合，標榜保護上網隱私以吸引更多用戶似乎就是種很有效、可掌握更多用戶上網行為的手段。

圖･Geoff Hustony在《Opinion: What does DoH really mean for privacy?》所描述的Surveillance Capitalism概念示意圖

資料來源：筆者繪製

同樣值得注意的是，報導指出Windows、iOS 14與macOS 11將新增對DoH的支援[18]。以這些作業系統（Operating System，除了電腦的OS也別忘了行動裝置的Android[19]等）不輸給瀏覽器（browser）的高普及度、市占率及集中度，可能對DNS乃至網際網路生態造成的影響不容小覷。此外，Netflix的App也被觀察到會另尋DNS解析服務，而非採用OS的配置[20]。應用程式的使用者與訊務規模雖然不見得有瀏覽器、作業系統來得大，一旦「自己決定DNS如何解析」蔚為風氣，多種App跟進而累積的DNS訊務也不該被忽視。

圖･手機作業系統的市占率

資料來源：statcounter網站資料

https://gs.statcounter.com/os-market-share/mobile/worldwide

綜合上述，DoH加密傳輸的功能導致現行惡意程式與內容的監管機制失效又或者被駭客所濫用、DoH訊務集中於少數業者形成壟斷、DoH太快速的普及各種配套不足、DNS訊務性質乃至網際網路生態短時間內被DoH大幅改變，這些議題並非杞人憂天，需要各界持續關注。

筆者做為DNS從業人員，可能有更多機會與誘因涉獵DNS相關的資訊，藉此機會與各位分享個人對於DoH議題參考的資料與摘錄的要點。若本文能發揮些許「索引」的功能、帶給大家一種對於DoH議題「先廣後深」的認識體驗（在有相對宏觀的認識後，再視需要深入鑽研相關參考文獻），是筆者莫大的榮幸。

Photo created by freepik

[1] DoH相關新聞如 https://www.ithome.com.tw/tags/doh

[2] 關於HTTP/2 Server Push筆者參閱《RFC7540》https://tools.ietf.org/html/rfc7540#section-8.2

[3] 關於DNS加密傳輸方案對效能的影響筆者參閱《Page load times not affected by DoH and DoT》https://blog.apnic.net/2019/10/08/page-load-times-not-affected-by-doh-and-dot/

[4] 關於DoH加密訊務的分析筆者參閱《Traffic analysis still possible when using DoT and DoH》https://blog.apnic.net/2020/01/30/traffic-analysis-still-possible-when-using-dot-and-doh/、《Eavesdroppers and censors can still monitor what you’re viewing even if you’re using encrypted DNS》https://blog.apnic.net/2019/10/22/eavesdroppers-and-censors-can-still-monitor-what-youre-viewing-even-if-youre-using-encrypted-dns/

[5] 關於EDNS(0) padding筆者參閱《RFC 7830》https://tools.ietf.org/html/rfc7830、《RFC 8467》https://tools.ietf.org/html/rfc8467

[6] 關於TLS SNI(的功用與加密發展)筆者參閱《What Is SNI? How TLS Server Name Indication Works》https://www.cloudflare.com/learning/ssl/what-is-sni/、《Encrypt it or lose it: how encrypted SNI works》https://blog.cloudflare.com/encrypted-sni/、https://en.wikipedia.org/wiki/Server_Name_Indication

[7] 關於TLS SNI encryption筆者參閱《TLS Encrypted Client Hello》https://datatracker.ietf.org/doc/draft-ietf-tls-esni/

[8] 關於HTTPS與TLS筆者參閱《淺談 HTTPS 和 SSL/TLS 協議的背景與基礎》https://kknews.cc/zh-tw/tech/xm3aeog.html

[9] 關於TLS Handshake筆者參閱《那些關於SSL/TLS的二三事(九) — SSL (HTTPS)Communication》https://medium.com/@clu1022/%E9%82%A3%E4%BA%9B%E9%97%9C%E6%96%BCssl-tls%E7%9A%84%E4%BA%8C%E4%B8%89%E4%BA%8B-%E4%B9%9D-ssl-communication-31a2a8a888a6

[10] 關於TLS Session Resumption筆者參閱《什麼是TLS會話恢復（TLS Session Resumption）》https://kknews.cc/zh-tw/code/qvorvey.html

[11] 《RFC 8484》的作者可見Mozilla的人員 https://tools.ietf.org/html/rfc8484

[12] 從《Comcast成為第一個加入Mozilla可信遞迴解析計畫的ISP》https://www.ithome.com.tw/news/138469 的報導可見Mozilla在精選「可信遞迴解析器（Trusted Recursive Resolver，TRR）」的努力，但決定信任誰不是由上網用戶自己決定而是由瀏覽器業者代勞，這樣的分工也著實引發了些非議

[13] 關於DoH被駭客濫用筆者參閱《安全專家發現伊朗駭客率先利用DoH暗中竊密》https://times.hinet.net/topic/23001624

[14] 關於DoH障礙的案例筆者參閱《Firefox 77讓DoH供應商超載，Mozilla緊急釋出Firefox 77.0.1修補》https://www.ithome.com.tw/news/138078

[15] 《Centralized DNS over HTTPS (DoH) Implementation Issues and Risks》https://tools.ietf.org/html/draft-livingood-doh-implementation-risks-issues-04

[16] 《The Big DNS Privacy Debate》 https://labs.ripe.net/Members/bert_hubert/the-big-dns-privacy-debate

[17] 《Opinion: What does DoH really mean for privacy?》 https://blog.apnic.net/2019/04/08/opinion-what-does-doh-really-mean-for-privacy/
TWNIC提供部分摘要：https://blog.twnic.tw/tag/cyber-governance/

[18] 關於OS支援DoH筆者參閱以下網頁資訊
(Windows) https://techcommunity.microsoft.com/t5/networking-blog/windows-will-improve-user-privacy-with-dns-over-https/ba-p/1014229
(Apple) https://www.ithome.com.tw/news/138485

[19] 關於Android Pie使用DNS加密服務筆者參閱《Opinion: DNS privacy debate》 https://blog.apnic.net/2019/02/08/opinion-dns-privacy-debate/

[20] 關於Netflix App有自己的DNS解析行為筆者參閱《Opinion: What does DoH really mean for privacy?》  https://blog.apnic.net/2019/04/08/opinion-what-does-doh-really-mean-for-privacy/