重新認識DoT/DoH、DNSSEC的定位與原理

作者:中華電信 林方傑工程師

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 transactionDNS 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的差異與安全議題、對策

資料來源:筆者繪製

 

備註與參考

Leave a Comment

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *

Scroll to Top