DNS (下)

網域名稱系統安全擴充(DNSSEC)

經歷上述的資安問題,為了解決使用者無法辨識收到的資訊是否有遭到竄改,因此,網際網路中,出現了「網域名稱系統安全擴充 (Domain Name System Security Extensions, DNSSEC)」。

在DNSSEC中,為了確保網路DNS的使用安全,使用了兩項相關技術:數位簽章以及DNS延伸安全協定(Extension Mechanisms for DNS, EDNS)。

DNSSEC與數位簽章

數位簽章

此協議主要是確保DNS 權威主機中的資料都是未經有心人士竄改之資料。當DNS權威主機收到請求後,在回覆訊息中,會放入含憑證之RRSIG。此時,DNSSEC並不會直接傳遞明文之資訊,會透過加密密鑰對發送之DNS訊息透過雜湊函式(hash function) 進行雜湊運算,經雜湊後之文件稱作「雜湊摘要 (Digest)」。並將此雜湊摘要(明文經雜湊後產生之雜湊值),以DNS權威主機之金鑰進行加密,此時,權威主機將訊息明文及加密後之雜湊摘要同時傳給DNS伺服器。

DNS伺服器收到後,會透過DNS權威主機金鑰(DNSKEY)進行解密。同時,為了確認該金鑰確實屬於此網域所有,因此將位於上一層之DNS權威主機中之DS (Delegation Signer) 進行驗證,確保金鑰沒有被偽裝或竄改。

DNS伺服器確認過後,將加密過之雜湊摘要以權威主機的金鑰解密,以取得完整雜湊摘要。此時若成功解碼,則代表此封包確實為該DNS權威主機所傳遞;否則若該封包非該權威主機傳遞,以該權威主機之金鑰無法解密。同時,再以同樣雜湊函式將明文進行雜湊運算,取得其雜湊摘要。最終,DNS伺服器會將本身運算出之雜湊摘要,和收到的雜湊摘要進行比對,若經他人竄改,即便是肉眼難以辨別之空格,均會造成雜湊數值之大幅變動;若相同則代表未經他人竄改。

如此,DNS伺服器便可透過以上動作確認:(1)該訊息確實為該DNS權威主機發送、(2)訊息未經他人竄改、(3)DNS權威主機無法否認發送此封包。

目前,各大DNS廠商均開始進行DNSSEC之運作,以確保大眾使用之安全性。同時,網際網路名稱與數字位址分配機構(ICANN)也於本月發文公告,敦促全球網域相關產業全面採用DNSSEC。DNSSEC可以完全相容於舊有DNS架構,並且可以大幅避免DNS紀錄被竄改之問題。為了DNS的安全,ICANN正努力進行推廣和執行,希望能及早促成DNSSEC之普及。

👉HINT:DNSSEC可以看做寄送機密信件。傳送者為了保護手中機密文件,因此將內容以中英文鍵盤對照轉換的方法編撰成一般人看不懂的密碼,然後再用帶鎖的盒子鎖起來,和機密文件一起送出去。接收者會將從傳送者那收到的鑰匙將盒子解鎖,代表確實是傳送者所寄。接著將收到的機密信件透過同樣方式編撰成密碼,再和帶鎖盒子中加密文件比對,若相同則代表沒有被任何人修改其中文字。

NSEC

以舊有DNS而言,若使用者查詢之網址並不存在,DNS權威主機僅會回覆使用者「不存在」之訊息。但未添加任何驗證訊息的「不存在」封包,很有可能會被有心人士擷取後,用以對一般使用者在查詢正常網域時,發送該網域不存在之訊息,導致使用者無法取得正確網域資訊及連接該網站。

因此,除了上述DNS訊息外,此機制會替此「不存在」之訊息進行簽章,以保障使用者取得「不存在」訊息,代表此網頁是確實不存在,而非他人偽造該訊息。回應並包含驗證之「不存在」之紀錄,稱作NSEC。

NSEC,全名為Next Secure,主要用以解決負面回應訊息(「不存在」訊息)之問題。此紀錄主要是將該網域下,所有的網域名稱進行排序,並透過兩者網域間之空隙,取得該被查詢網域之前後網域名稱做為紀錄並回傳。

這樣描述有些難以理解,因此舉例而言,若在twcert.org.tw網域下,有a.twcert.org.tw、ma.twcert.org.tw、pop.twcert.org.tw、te.st.twcert.org.tw、let.twcert.org.tw、move.twcert.org.tw等6筆網域名稱,則在該網域下,此些網域名稱會被排序為:

twcert.org.tw

a.twcert.org.tw

let.twcert.org.tw

ma.twcert.org.tw

move.twcert.org.tw

pop.twcert.org.tw

te.st.twcert.org.tw

此時,若使用者查詢love.twcert.org.tw,則使用者會獲得理論上於該查詢網域的前一筆和後一筆,亦即前一筆let.twcert.org.tw以及後一筆之ma.twcert.org.tw,代表兩者之間並無love.twcert.org.tw網域,因此驗證確實該網域並不存在。同時,若該訊息被有心人士擷取,由於有網域之驗證,此訊息也無法用於一般使用者查詢網域之偽造訊息,保障「不存在」之訊息正確性。

👉HINT:NSEC可看作將號碼牌按照上面數字排放,例如已經排放了1、2、3、5、6、7、8、10、12,若此時,有一位一號使用者來信要求取得9號號碼牌,負責人卻發覺並無9號號碼牌,因此回信給一號使用者說明並無此號碼牌之狀況。若該信中僅說明沒有9號號碼牌,而無其他驗證資訊,則一號使用者可以在另外的二號使用者要求10號號碼牌時,將那封信偽造成負責人所寄,告訴二號使用者沒有10號號碼牌,導致二號使用者拿不到該號碼牌。而若當初負責人告之一號使用者的信中除了告知沒有9號號碼牌之外,同時也說明前面是8號、後面是10號,確定中間無任何號碼牌,則收到此封信的一號使用者,即便他想欺騙二號使用者,卻會因為裡面的驗證訊息(8號和10號號碼牌資訊)而偽造不成,避免了一次詐騙。

DNSSEC與EDNS

EDNS,又稱為EDNS0,全名為Extension Mechanisms for DNS,譯為DNS延伸安全協定。是DNSSEC中的一項技術,主要用於提升DNS運作之安全性。

有鑒於DNSSEC的建立和發展,其所需之功能訊愈來愈多,若維持以往之DNS形式,所需的功能標示將難以以舊有格式完整表達。因此,在舊有的DNS封包中,延伸出更多的區段,用以支持未來期望表達的特徵值。

例如當初的DNS封包是使用UDP Port 53封包進行傳輸,本身大小限制為512 bytes。若以過往的DNS封包所應傳輸之內容而言是足夠的,但在DNSSEC中,由於增添了數位簽章的部分,其封包大小在包含數位簽章資料後已不足以負荷。而若此時使用EDNS,可以將其封包大小上限大幅增加,可容納4,096 bytes的資料,如此,方可將DNSSEC所需資料內容完整地進行傳輸。

DNS封包

在DNS所傳輸的封包中,分為許多欄位,例如表頭(Header)、查詢區域(Question Section)、回覆區域(Answer Section)、授權區域(Authority Section)以及額外紀錄區域(Additional Records Section)。

表頭主要標示此封包之編號、描述此訊息封包的功能,例如此封包為查詢或是回應用等、以及相關紀錄的數量。查詢區域,則是用以描述問題名稱、型態(是查詢IP位址、名稱伺服器……等等),以及問題類別(是否為IP位址格式)。

回覆區域則是記錄權威主機所回應之資料,例如資源名稱(針對哪一個問題進行回覆)、資源型態(對應查詢區域中的型態)、資源類別(對應查詢區域中的問題類別)、存活時間(封包傳送時存活的時間,若過久未到達目的地則會進行刪除)、資源資料長度(表示資源資料的長度),以及資源資料(詢問回覆之答案)。

第三、授權區域,此區域並非使用者詢問問題之確切答案,而是在DNS詢問中,上層之其他DNS權威主機之資訊,引導DNS伺服器對上層之DNS權威主機進行詢問,直到得到答案為止。

最後,額外記錄區域則是當授權區域有除上述訊息外之額外訊息,方放入額外紀錄區域。

EDNS

對於EDNS,DNS伺服器不一定有支援EDNS,因此,為了標示該伺服器是否有支援EDNS,會在Additional Records Section中,加入一「opt」資訊。此時,若權威伺服器收到該封包,發覺額外紀錄區域有「opt」資訊,則可知使用者之DNS伺服器有支援EDNS,並且於回覆時,也會於額外紀錄區域加上opt資訊進行回覆,代表此為EDNS封包。

但此封包為EDNS封包,卻不一定為DNSSEC封包,必須於EDNS訊息中的「do」區域被設定為1時,方為DNSSEC封包。

支援EDNS後,由於擴展了針對其他的DNS所需功能表達之特徵值欄位,並且亦擴增了封包大小限制,因此,除了DNS訊息傳遞時,可以包含數位簽章之資訊內容外,亦可以包含舊有DNS未能包含之特殊特徵值,讓DNS的運作更加安全。

由於意識到EDNS的重要性,在今年的二月一日,Clouflare、Google、IBM等大型公共DNS業者進行了EDNS的符合性驗證。雖此次驗證僅有一天時間,但同時也是期盼未來EDNS發展的起點。

👉HINT:EDNS就像是一小手拿包,雖然平常放錢包手機已經足夠,但是當外面天氣不好、下雨時,雨傘便放不進去;或者帶著讀到一半的書籍,想去舒適的咖啡廳閱讀,但是A5大小的書籍,一般小型手拿包亦放不下去。因此,可以拿一較大的包,將手拿包放入大包中,並且將雨傘、書籍都排放進去,如此一來,便可容納所需的大部分東西,甚至不需對手拿包進行改造便可。

DNSSEC

透過數位簽章及EDNS的運作,DNSSEC額外確保三項資訊安全項目:

  1. 資料完整性 (Data Integrity):確保收到的資料是完整的,未經有心人士等第三者進行竄改。
  2. 來源可驗證性 (Origin Authenti-cation of DNS Data):確保資訊的寄送者為正確之DNS權威主機/DNS伺服器,而非收到有心人士偽造出之假資訊,被導入錯誤之釣魚網站。
  3. 可驗證之不存在性(Authenti-cated Denial of Existence):確保當使用者收到「該網址/位址不存在」訊息,可透過NSEC進行驗證,驗證該網域確實不存在,而非遭他人竄改。

為了彌補DNS亦遭受有心人士攻擊之問題,開啟了DNSSEC的技術。如此一來,可以大幅減少DNS相關駭侵攻擊,保障使用者的運作安全。在台灣,許多電信業者已紛紛跟進,根據台灣網路資訊中心(TWNIC)之註冊機構資訊,截至目前,中華電信、亞太電信、pchome、新世紀資通、台灣大哥大、Neustar、中華國際通訊網路、Gandi SAS、Key-Systems GmbH等,均已註冊並使用DNSSEC服務。期盼未來有更多相關業者參與及使用DNSSEC,令使用者擁有一個完整且安全的完善網路,不再被不法人士劫持,能真正自由安心地使用網路服務。

資料來源:

  1. http://www.cc.ntu.edu.tw/chinese/epaper/0022/20120920_2206.html
  2. http://www.myhome.net.tw/2011_03/p03.htm
  3. https://www.lijyyh.com/2012/07/dnssec-introduction-to-dnssec.html
  4. https://medium.com/@sj82516/dnssec-%E5%9F%BA%E6%9C%AC%E5%8E%9F%E7%90%86%E4%BB%8B%E7%B4%B9-65841439d0a5
  5. https://blog.longwin.com.tw/2019/01/dnssec-dns-sign-edns-check-2019/
  6. https://blog.twnic.net.tw/2019/01/23/2286/
  7. https://blog.csdn.net/star_xiong/article/details/40429457
  8. http://net.ndhu.edu.tw/~net/DL/20110330.pdf
  9. https://en.wikipedia.org/wiki/Extension_mechanisms_for_DNS
  10. http://dnssec.nctu.edu.tw/images/DNSSEC/DNSSECtech.pdf
  11. http://www.myhome.net.tw/2011_07/p05.htm
  12. https://www.twnic.net.tw/dnservice_company_intro.php
Scroll to Top