| 作者：中華電信 林方傑工程師 |
DNS（Domain Name System）自1980年代被發明以來，一直扮演著網際網路中不可或缺的角色。然而，隨著各種網路應用的蓬勃發展，DNS潛在的風險也開始被重視，DNSSEC（Domain Name System Security Extensions）、DoH（DNS over HTTPS）等DNS安全協定也因應而生。有鑑於網路上已經不乏DNSSEC設定、DoH建置等技術面的探討，本文將著重於概念的釐清，以Q&A的型式為大家爬梳這些技術協定，各自做為一種解決方案究竟源自什麼（what）問題及如何（how）緩解。協助大家建構一套對於DNS安全議題與技術發展的理解脈絡。
Q: DNS解析牽涉哪些步驟與角色？
首先，我們以情境簡單回顧「DNS解析（resolution）」流程如下：
當客戶瀏覽A公司的官網www.a.com.tw[註1]，其電腦或手機得先向預設的「DNS Resolver」提出「www.a.com.tw的IP是什麼」的查詢（如下圖步驟1）。但天下域名及衍生出的DNS紀錄之多，縱使知名且規模龐大如Google的DNS 8.8.8.8也難以獨立維護，因此DNS解析是以一種「階層分工」的模式運作——舉凡a.com.tw的DNS紀錄都源自A公司所安排的「權威主機（Authoritation Name Server）」（如下圖步驟2）；各方resolver（包括8.8.8.8）則扮演「代理人」的角色，替用戶向權威主機索取指定DNS紀錄的設定值。至於resolver如何知道A公司權威主機為何方神聖，則是仰賴「上層域名」（在此情境為com.tw）權威主機的指引[註2]。完成上述步驟後，resolver便將取得的答案返回給用戶（如下圖步驟3）並存入快取。
圖･DNS解析流程與關鍵角色示意圖
資料來源：筆者繪製
Q: DNS transaction、DNS data傻傻分不清楚？
上述解析流程看起來很聰明[註3]、順暢，事實上DNS也如此運作了近40年。但是，因DNS被設計時資安的意識與需求尚不普及，故除了分散式阻斷服務攻擊（distributed denial-of-service attack，簡稱DDoS攻擊）、系統遭駭等常見攻擊手法的威脅，DNS在協定（protocol）面也存在了些與生俱來的弱點，給予駭客「竊聽」或「竄改」的機會。
在進一步說明DNS解析與竊聽、竄改兩種風險的關係之前，我們得先釐清「DNS data」與「DNS transaction」的差異。
「DNS data」泛指各種DNS「資源紀錄（Resource Record）」[註4]以及設定值。例如A公司官網www.a.com.tw做為公開的線上服務，本來就該允許任何人透過DNS解析取得A公司網頁主機的IP，因此儲存著網域名稱與對應IP（v4 address）的A紀錄本質為公開資料。（同理，定義了A公司域名權威主機的NS紀錄、郵件主機的MX紀錄等也都是公開的DNS data）
相對的，如果小傑同學半夜偷上色情網站，則「凌晨1點32分小傑家IP發送了色情網站的A紀錄查詢」這樣的log，至少小傑本人絕對不會想被他娘發現。也就是說，雖然DNS data為公開資料，但包含了「某client IP於何時查詢了什麼DNS data」的「DNS transaction」，因為涉及個人上網行為而屬於隱私、非公開資料[註5]。
非公開資料怕人竊聽；公開資料沒有竊聽問題但怕被竄改。以下分論兩種挑戰的因應對策：
Q: 怎確保DNS transaction不被竊聽？
由於DNS查詢與回覆的封包都是以明碼傳送，容易遭有心人攔截、竊聽，從而衍生出「DNS privacy」議題。若駭客介入「client終端向其預設DNS提出查詢」的過程，小傑同學偷偷上網的祕密就面臨了曝光的風險（如下圖示）。
圖･駭客竊聽DNS transaction
資料來源：筆者繪製
既然怕DNS查詢封包（屬於DNS transaction的範疇）被竊聽，那我們就建立加密傳輸通道把往返的資料變成密文（cipher）。缺少解碼的金鑰，駭客就難以得知傳輸內容了。如果加密傳輸通道是用TLS安全協定所建，就構成所謂「DoT（DNS over TLS）」，協定代表port號是853（TCP）。
圖･以DoT加密傳輸保護DNS transaction
資料來源：筆者繪製
但問題還沒結束！使用DoT，外界雖然很難破譯被加密傳輸的資料（DNS transaction），但透過port scan能發現port 853的開通從而判斷DoT正在被使用。除了會產生一種「欲蓋彌彰」的嫌疑，有心人士也可輕易地干擾DoT服務的運作（例如阻擋port 853的存取）。值得留意的是，這裡的「有心人士」不限於惡意的駭客。例如英國有內容過濾（content filtering）的法律，對色情、暴力等不良資訊會要求ISP等業者配合加以控管。一旦DNS封包的傳輸開始被加密，監管的範圍與效力將大打折扣。阻擋853 port以妨礙/禁用DoT的可能性不容被忽視。
圖･以DoH加密傳輸保護DNS transaction
資料來源：筆者繪製
那麼，如何因應port被阻擋？
如果加密傳輸與熱門的HTTPS協定共用443 port，則port的阻擋就會窒礙難行了！因為HTTPS是當今各種網頁服務仰賴的主流協定，而阻擋用戶瀏覽臉書或使用各種網頁服務勢必引發民怨甚至眾怒。如此以HTTPS協定傳輸DNS封包，就是所謂「DoH（DNS over HTTPS）」。雖然上述需求未經證實為DoH的源起，但不失為理解兩種協定之用途與差異的方法之一，分享給各位。
Q: 如何確保DNS data不被竄改？
雖然確保了傳輸過程的隱私安全，萬一被傳送的資訊有錯，例如小傑明明要去A公司的官網，但取得的IP卻遭惡意竄改為某釣魚網站（而非A公司的網頁主機），同樣會衍生出資安問題。由於在DNS原始協定設計中，resolver收到權威主機回覆封包時沒有嚴謹的查驗機制，若有心人士偽造權威主機的答覆搶先提供給resolver，會導致client被誤導而向錯誤的主機建立連線。這就是所謂「cache poisoning」。
圖･cache poisoning攻擊
資料來源：筆者繪製
要緩解答案被竄改的問題，讓resolver能夠查驗所收資料（DNS data）的「內容」與「來源」是個直覺的解決方案。
如何實踐查驗呢？「數位簽章（Digital Signature）」技術可以幫上忙，其hash的應用，使原文就算被加上個空白也會被反映在截然不同的「message digest」，可確保內容的「完整性（integrity）」；而「非對稱式加密（Asymmetric Encryption）」的應用（私鑰加密、公鑰解密）也使訊息的來源得以被確保。限於篇幅，圖示數位簽章技術的原理如下，有興趣或需要的朋友可參閱相關說明[註6]。
圖･數位簽章的原理
資料來源：筆者繪製
簡而言之：如何防範「涉及用戶上網隱私的」DNS transaction被竊聽？我們可建立加密傳輸通道；如何防範「應該來自權威主機的」DNS data被竄改？我們可以為資料加上數位簽章，供查詢者核對。而傳輸加密、數位簽章分別就是DoT/DoH與DNSSEC的核心概念。
圖･DNS data與DNS transaction的差異與安全議題、對策
- 註1：依照TWNIC的規定（https://www.twnic.net.tw/dnservice_announce_announce_2.php），不包含TLD或SLD，網域名稱至少須有2個字元，因此「com.tw」是一個現實不存在的範例。
- 註2：關於詳細的DNS解析流程，讀者可參閱TWNIC的線上教材說明 ── http://dns-learning.twnic.net.tw/dns/03opDNS.html。
- 註3：上述「階層分工」的設計（或稱「DNS Hierarchy」）大幅降低了DNS初期所面臨的單點失效、缺乏擴容性等問題（https://en.wikibooks.org/wiki/Communication_Networks/DNS#Why_not_centralize_DNS?），也減輕了參與業者及設備的負擔。
- 註4：關於DNS資源紀錄的類型與用途，可參閱TWNIC線上說明（http://dns-learning.twnic.net.tw/bind/intro6.html#bc）。
- 註5：關於DNS data與DNS transaction的概念，可參閱《RFC 7626 – DNS Privacy Considerations》https://tools.ietf.org/html/rfc7626。
- 註6：關於數位簽章的原理可參閱台網中心電子報《DNSSEC─數位簽章與 EDNS0》 http://www.myhome.net.tw/2011_03/p03.htm。
- 駭客圖源 https://www.cleanpng.com/png-logo-computer-icons-clip-art-white-hat-hacker-icon-5595839/download-png.html。
- 警察圖源 https://www.freeiconspng.com/img/29950
