關於KINDNS，你該知道的事

前言：

KINDNS（唸法同「kindness」）代表「Knowledge-Sharing and Instantiating Norms for DNS and Naming Security」，是ICANN所倡議的DNS最佳實務框架。KINDNS的網站https://kindns.org內容非常豐富，包含最佳實務建議、理由、做法等資訊。然而，內容豐富也是閱讀的負擔。筆者希望整理一版KINDNS的導覽（可以先看什麼再看什麼）、摘要（哪些可以跳過）與註記（以DNS從業人員的經驗補充些背景資訊或考量），希望為DNS安全貢獻棉薄之力。筆者以設想「對於KINDNS可能會有的疑問或需要」來分段，各位可依序閱讀或直接跳至感興趣的部分。

要從哪裡開始呢？

在KINDNS的首頁（註1），我們可以看到導覽列的「About」、「Operator Categories」、「Support & Engage」、「Tools & Guidelines」、「News」、「Events」，以及主視覺區的「JOIN US」、「SELF-ASSESSMENT」等選項（如下圖1）。筆者建議先試試SELF-ASSESSMENT（自評），以了解您所維護的DNS符合最佳實務建議的程度。其餘內容建議如下：

• 如果需要更多關於KINDNS自評的說明，比如DNS有哪些分類與如何區別、自評項目的理由（rationale）等，可參閱「Operator Categories」頁面（註2）。
• 如果願意採取行動但不知道如何實作，則可參閱「Tools & Guidelines」下的文件。
• 如果希望更積極地響應KINDNS，可追蹤「Events」所公告的活動，並從「JOIN US」或「Support & Engage」（兩者內容一樣）了解加入KINDNS社群討論mailing list等參與方式。
• 如果希望更全面地了解當代DNS的境況與挑戰，可閱讀「News」中的文章《A Tutorial on Addressing the Challenge of Modern DNS: For everyone that wants to know more》。

圖1.KINDNS首頁與筆者建議的瀏覽順序

資料來源：https://kindns.org/ ，筆者於2023年6月截圖與加註

KINDNS自評如何進行？

要進行KINDNS的自評非常簡單，不需要註冊帳號、不必要揭露身分或所服務的單位，因此可不用擔心自評結果影響形象，也可專注於思考自身與最佳實務建議的相符程度。KINDNS自評問卷以選擇與是非題構成，答完所有題目後，自評者可獲得一個評分並可下載自評報告。

圖2.KINDNS自評報告

資料來源：第四屆ICANN APAC-TWNIC Engagement Forum議程講者（Champika Wijayatunga）的KINDNS簡報

KINDNS的自評經過精心設計，不同DNS類型有相應的問卷版本。那麼，各位又該如何選擇自己所屬的DNS類型呢？我們先看看ICANN專家Champika Wijayatunga先生於第四屆ICANN APAC-TWNIC Engagement Forum所分享的KINDNS目標受眾示意圖如下圖3。關於其中的分類，請參考以下背景資訊、理解與建議：

圖3.KINDNS目標DNS營運者（operators）

資料來源：第四屆ICANN APAC-TWNIC Engagement Forum議程講者（Champika Wijayatunga）的KINDNS簡報

DNS可簡單分為「authoritative」與「recursive」兩類。前者（或稱「權威主機」）負責當某些域名的DNS紀錄源頭；後者（或稱「resolver／解析器」）則必須受理任何域名的DNS紀錄查詢，並依照域名的授權／NS紀錄設定找相應的權威主機索取答案，再回饋給查詢方。在此分工下，權威主機必須提供公開的服務，否則網路上就會有部分人無法解析此權威主機所負責的域名。故權威主機常以域名的層級或重要性來分類。相對的，解析器則可有公開程度之別，KINDNS將解析器分為「公開Public」、「共享私有Shared Private」、「私有Private」三類（可參閱「Operator Categories」頁面或下圖4）：

• 「Public」如Google的8.8.8、Cloudflare的1.1.1.1，歡迎全世界上網者使用。
• 「Shared Private」如電信等業者的解析器，一般只服務自家客戶（Shared來自自家客戶不只一人；Private則指別家客戶無法使用，筆者是這樣理解的）。
• 「Private」封閉性最高，指公司行號等機構建置於其內網的解析器（無法從Internet存取）。

圖4.DNS互動與分類

資料來源：筆者繪製

話說回來，自評時筆者建議先選最具挑戰性的DNS類別：Critical Zones的authoritative與Public Recursive Resolver，藉以了解KINDNS所有最佳實務建議（之後再斟酌取捨也不遲）。

KINDNS有建議哪些DNS最佳實務？

KINDNS自評問卷基本分為「Core DNS Operation Practices」與「Core System Security Practices」兩章。前者是專屬DNS領域的建議，也是本文接下來探討的重點；後者可細分為「Network Security」與「Host and Service Security」，對其他應用服務也具參考價值（如下圖5）。

圖5.KINDNS自評結構示意圖

資料來源：筆者繪製

筆者把各類DNS的最佳實務建議並列在一起如下表1（文字引用自導覽列「Operator Categories」頁面DNS Security段落）。其中，「authoritative」類採藍色系，「recursive」類採棕色系，各自再用淺色淡化重複出現的項目。如此可見深色的內容約僅占總篇幅的一半，且深色中還有重複項，如authoritative與recursive服務不能並存（coexist）、必須對服務與基礎建設狀態進行監控（monitoring）。透過此處理可大幅縮減建議數，這也是為何筆者建議直接挑KINDNS最高規格的自評（反正項目也沒差多少）。

表1.KINDNS DNS Security建議

資料來源：https://kindns.org/operator-categories/ 各分頁

為了幫大家更快抓到重點概念，筆者將表1中深色項目歸類為「資料完整性相關」、「隱私相關」、「韌性相關」、「存取管控相關」、「log相關」，並標記各項在原文中的關鍵字於圓括號中方便對應，分述如下：

資料完整性相關建議（關鍵字：DNSSEC、integrity）

DNSSEC是一種DNS的安全協定，核心是以數位簽章技術保護DNS紀錄在傳輸過程中的完整性（integrity）。既然是數位簽章的應用，就必須有簽署（signing）與查驗（validation）的動作（參閱圖6），前者由權威主機負責（因DNSSEC數位簽章也是一種DNS紀錄），後者則是由解析器連同查找DNS紀錄一併執行。必須注意的是，於權威主機執行DNSSEC簽署有相當的技術複雜度，且並非一次性作業而必須是週期性的（因數位簽章的加密金鑰需替換）。而解析器一旦啟動DNSSEC查驗，對於DNSSEC簽署有問題的域名就會判斷為無法解析（SERVFAIL）。從（解析器）DNS管理者的角度，開啟DNSSEC查驗後可能會面對更多（域名無法解析）申告，相關查測與回覆所需的人力等資源需要事先評估與規劃。

6.DNSSEC核心概念示意圖

資料來源：筆者繪製

再次強調DNSSEC防治的是DNS紀錄「在傳輸過程中」遭竄改的風險（如「cache poisoning快取汙染」攻擊）。如果DNS紀錄「在源頭」就遭變更，則DNSSEC也無保護力（因DNSSEC數位簽章也可能在源頭一併被偽造）。因此KINDNS也建議在權威主機端進行zone file（儲存域名DNS紀錄的檔案）完整性的管理。實務上可透過建立DNS紀錄異動申請流程，妥善保存申請單並進行抽查，或者安排系統排程執行檔案差異的檢測並告警非預期事件等。

隱私相關建議（關鍵字：privacy、DoT、DoH、QNAME minimization）

DoT、DoH也是DNS的安全協定，核心是以加密傳輸技術進行DNS查詢與回應的交換（如下圖7），藉以防範「DNS交易」（transaction）被竊聽。「DNS交易」代表「誰在何時查了什麼DNS紀錄」的資料，在解析器與使用者間就相當於使用者上網行為，因此有隱私保護的議題（詳可參閱註3等文章）。但必須注意的是，DoT、DoH因為使用了加密傳輸技術，訊務的質與量和傳統DNS有相當的差異。DNS系統是否有足夠的負載能力、是否有監控與防護機制可因應新攻擊等，筆者認為都是決策的重點。

圖7･DNSSEC核心概念示意圖

資料來源：筆者繪製

QNAME minimization（RFC 7816，圖8）也是一種保護隱私的安全機制。依DNS原始設計，解析器會將原始的DNS查詢內容傳給各層權威主機。例如我要查www.twnic.tw對應的IP，若解析器的快取並無相關資料，則必須依序查訪root根域名、.tw、twnic.tw各層權威主機才能得到答案。對根域名與頂級域名.tw的權威主機而言，它們只知道也只負責提供其下一層域名的授權資訊，www.twnic.tw的IP對它們來說太細節，不能也不需要回答（畢竟已授權由twnic.tw的權威主機負責）。如此一來，讓原始查詢內容被傳至上層域名權威主機既非解析的必要，也違反「need to know僅知」安全原則（詳可參閱註4、註5等文章）。目前主流DNS軟體版本都已預設支援QNAME minimization，而確保所使用的DNS軟體版本別太舊本來就是最佳實務之一，故對QNAME minimization的支援該是肯定的。

圖8･QNAME Minimization示意圖

資料來源：internetsociety DNS Privacy Frequently Asked Questions (FAQ) pdf 文件(註6)

韌性相關建議（關鍵字：distinct、diversity、resilience）

DNS做為網路的關鍵基礎服務，可用性（availability）的重要性不言可喻，而在極端情況下讓可用度得以延續的「resilience韌性」也就至關重要。實務上，增加軟硬體的備援與多樣性（diversity）、採高可用度（high availability，HA）架構、使用負載平衡技術等都有助於降低單點失效（single point of failure，SPOF）、阻斷式攻擊、零日攻擊（zero-day attack）等風險。故若成本與技術力可負擔，也非常推薦在此面向多著墨。

存取管控相關建議（關鍵字：ACL、TSIG）

域名需要權威主機做為DNS紀錄的源頭。為了提高韌性，權威主機最好至少成對（只要有存活的權威主機域名就可持續被解析）。而當權威主機不只一台，就需要資料同步（否則每個DNS紀錄異動都得在每一台權威主機重複執行會是相當大的維運負擔）。zone transfer是DNS既有的資料同步機制。為了確保資料的來源有限、正確，便有了對zone transfer介接進行存取管控的建議。此外，TSIG（transaction signature，RFC 2845，圖9）也被提及用於強化zone transfer的安全。TSIG是基於對稱式加密的資料保護機制（詳可參閱註7、註8）。實作面，筆者建議至少透過網路層存取控制清單（access control list，ACL）或防火牆與應用層allow-transfer等設定做到點對點的管控以降低風險。

圖9･TSIG示意圖

資料來源：LPIC2 Exam Guide 207.3. Securing a DNS server (註9)

log相關建議（關鍵字：data collected）

一如前述，DNS查詢（DNS queries）可能涉及用戶上網行為，是DNS log中有隱私議題的資料。縱使DoT、DoH等協定／技術可提高在傳輸過程中竊聽此資料的難度，但卻無法阻止提供服務的伺服器輸出並保留log。連同其他類型的資料被合法、合理地使用，服務提供者的自律、恪遵法規是不可或缺的。

還有哪些建議（包含線上資源）與小結

限於篇幅，筆者謹將「Core System Security Practices」的建議匯集如下圖10並標記關鍵字供大家參考。另外，導覽列的「Tools & Guidelines」除了提供各項建議的實作指引外，也建立各種資源的索引，包含各方（如ISC (Internet Systems Consortium)²、美國政府、Google等）的最佳實務文件（註10），以及域名、DNSSEC狀態的線上檢測工具（註11），如 DNSSEC Analyzer（verisignlabs.com）、ZoneMaster等。但不管資源再多，實際採取行動、朝著最佳實務努力才能有效提升DNS安全，筆者與各位共勉。

圖10･KINDNS強化平台的建議

資料來源：筆者繪製 (文字引用自https://kindns.org/operator-categories/)

參考資料

1. ICANN (2022). KINDNS 首頁。ICANN
   檢自：https://kindns.org/ (Sep., 2022)
2. ICANN (2022). KINDNS / Operator Categories。ICANN
   檢自：https://kindns.org/operator-categories/ (Sep., 2022)
3. 林方傑 (2020)。「重新認識DoT/DoH、DNSSEC的定位與原理」。TWNIC Blog。
   檢自：https://blog.twnic.tw/2020/02/27/6205/ (Feb. 27 , 2020)
4. ISC (2019)。「QNAME Minimization and Your Privacy」。ISC
   檢自：https://www.isc.org/blogs/qname-minimization-and-privacy/ (Mar. 06, 2019)
5. 國際瞭望專欄 (2023)。「最小化 DNS 解析：進入半影區」。TWNIC Blog
   檢自：https://blog.twnic.tw/2023/05/04/26546/ (May. 4 , 2020)
6. Internet Society (2019). DNS Privacy Frequently Asked Questions (FAQ) / Fernando Gont。Internet Society
   檢自：https://www.internetsociety.org/wp-content/uploads/2019/03/deploy360-dns-privacy-faq-v1.1.pdf (Mar., 2019)
7. TWNIC (2003)。「DNS server安全防護」。TWNIC
   檢自：http://dns-learning.twnic.net.tw/bind/security.html (2003)
8. 楊啟倫 (2010)。「徹底解決DNS快取中毒的關鍵技術：DNSSEC」。iThome
   檢自：https://www.ithome.com.tw/tech/92685 (Oct. 22, 2010)
9. gitbook.io (2022). 207.3. Securing a DNS server / Payam Borosan。Linuxcert.ir
   檢自：https://borosan.gitbook.io/lpic2-exam-guide/2073-securing-a-dns-server (Dec., 2022)
10. ICANN (2022). KINDNS / DNS Security Resources。ICANN
    檢自：https://kindns.org/dns-security-resources/ (Sep., 2022)
11. ICANN (2022). KINDNS / Assessment End Tools。ICANN
    檢自：https://kindns.org/assessments-tools/ (Sep., 2022)