| 作者：中華電信林方傑工程師 |
自DNS問世至今已逾30年，雖然鮮少發生大規模解析障礙、運作算穩定，但隨著網際網路發展及各個國家對網路治理需求的不同，改變 DNS 現行體制與架構的想法也應運而生；其中，根域名伺服器的「去中心化」便是其中一個被提出的概念。在討論去中心化之前，首先說明有學者提出 DNS「中心化」的觀點為，過半數的主流13個根域名伺服器以及負責執行根域名伺服器zone file資料編輯的「Root Zone Maintainer」都由美籍機構所負責等。而「去中心化」即是希望能改變此現況，數個探討根域名伺服器新架構、新技術可能性的專案陸續出現。有關DNS運作方式及中心化治理議題之內涵，可參考導讀文章：「根域名伺服器的重要性、現況與爭議」 。
ICANN基於「One world, one Internet」的原則，並為避免域名解析結果不一致，對於非 IANA 體系的根域名伺服系統基本上態度是不支持的（可參閱《RFC 2826》。然而，在此背景下，仍存在「Yeti DNS」這個非13-root體系的根伺服器實驗專案，參與者包括中國、美國、日本、印度、俄羅斯、德國、法國等16國家的相關單位，計畫發起人中更有國際網際網路名人Paul Vixie博士；該專案近年也多次在中國與根域名伺服器相關的討論與報導中被提及，因此值得留意。本文主要介紹 Yeti DNS 實驗計畫之目的、其根伺服器分布情形，以及測試過程中的議題內涵。
首先，Yeti DNS官網聲明不會修改IANA所發行的TLD授權資料以確保與主流體系的相容（因此可將Yeti DNS歸於前述「Open Roots」分類），並以測試平台（testbed）驗證下段所述架構的可行性。值得一提的是，Yeti DNS專案也標榜著支援DNSSEC及僅運作於純IPv6的環境，研究團隊希望藉此預習未來推展這兩項協定過程中可能碰到的問題。
資料來源：IANA、Yeti DNS draft｜由筆者整理與製圖
圖1. 根域名伺服器－ IANA體系 vs. Yeti DNS
相較於主流的13-root體系，對外提供解析服務的「Yeti-Root servers」不只多達25個，至今仍開放新成員申請加入，而管理者的國籍也較為分散（參考圖1）。系統內部則同時配置了3個「Distribution Masters（簡稱DM）」做為Yeti-Root servers的zone file來源。此 3 個DM分別由來自中、日、美的機構所管理。任何一個 Yeti-Root server 都能與任何一個 DM 進行 zone transfer，而每一個 DM 也都有自己專屬的 key 能執行 DNSSEC 簽署。這與現行13-root主流架構中，僅由 Verisign 所管理的 A-root 扮演 DM 角色有很明顯的差異。
資料來源：Yeti DNS draft ｜由筆者整理與製圖
圖2. 加註元件相關議題後的 Yeti DNS testbed資料流示意圖
《Yeti DNS Testbed》這篇draft記載了研究團隊在實現multiple, independently-operated DNSSEC signers以及shared zone control等系統特色過程中所面對的問題與所累積的經驗。以下將Yeti testbed component與data flow圖合併、簡化，並將draft中的關鍵議題標記在示意圖中相關的元件側（如圖2），而各議題所欲達到的目的與主要面臨的挑戰則摘要如下表，希望能藉此幫助大家了解各議題在整個專案的定位，避免迷失於繁雜的技術細節。
表1. Yeti DNS議題摘要
| 議題 | 目的與挑戰 |
|---|---|
| Zone Retrieval | 取得zone file內容，對於承諾與主流體系相容的Yeti DNS而言，即是IANA所發布的Root zone file。 |
| Zone Transformation | 將Root zone file「加工」成Yeti DNS的版本，包括NS紀錄的置換與DNSSEC的簽署。
由於Yeti的25個根伺服器與現行的a到m共13個並無交集，因此關於root的NS紀錄等資料必須被調整。而如何製成、分配DNSSEC簽署所需要的金鑰，以賦予3個DM（同時也是3個signers）一定程度的獨立性亦是機制設計的重點。 |
| Yeti-Root Zone Distribution | 將備妥的zone file自DM發布給對外提供解析服務的Yeti-Root Servers。
這部分主要的挑戰在於資料同步的效率。由於每個DM會產出獨特的DNSSEC簽署結果，內容差異使得目前只能用full zone transfer（AXFR）。能否仍將incremental zone transfer（IXFR）應用進Yeti-DNS的架構是研究團隊待解決的問題。 |
| Synchronization of Service Metadata | 3個DM雖然彼此對等、互相獨立，但仍有需要同步的資訊，例如：Yeti-Root Servers的增減與重新命名等。目前Yeti DNS採用Git版控解決方案因應使需求。而Git本身的資安議題也因此成為Yeti DNS不可忽略的風險。 |
| Hint file automation | Hint file記載了根域名伺服器的IP，是resolver DNS進行解析必要的資訊。傳統上Hint file是透過手動程序部署，也因此不乏Hint file過期未更新的情況。
如何透過自動化機制確保此檔案的更新，是Yeti DNS研究團隊在探討根伺服器「架構改變 (structural change)」之技術可能性的同時也想一併解決的問題。 |
| IPv6 & DNSSEC support | IPv6與DNSSEC都是未來必須支援的協定，而IPv6-only operation可能會碰到的問題（例如IPv6 fragmentation所導致的封包移失）、DNSSEC金鑰乃至於演算法該如何更替等也確實都是Yeti DNS專案團隊明訂的研究目標。 |
| Large response failure rate | APNIC在IPv6 fragmentation的研究中 [註1]提到，「當DNS權威主機在IPv6的環境下發送被切割的UDP回應封包（fragmented UDP response），封包遺失率可能高達37%」。尤其在支援DNSSEC的情境下，因為需要交換數位簽章運作所需資料使封包變大而需要被切割的機率更高了。
在既有協定難變（例如IPv6 fragmentation control欄位已被移入Extension Header）、設備支援度不一（網路上不乏直接忽視帶有Extension Header的IPv6封包、便宜行事的節點）的挑戰下，如何降低IPv6 fragmentation所致之封包丟失率（例如改用TCP連線或更換DNSSEC使用之演算法縮小封包），是未來的重點項目。 |
資料來源：筆者彙整
雖然Yeti DNS被其專案團隊明確定位為以學術研究為目的之測試平台，相較於更具規模或知名度的根域名替代系統（例如OpenNIC）似乎影響力有限。但研讀Yeti DNS在發展過程中所探討的議題，除了能讓我們更具體地了解該專案的實作細節，也提醒了我們IPv6 fragmentation等共通、底層問題的不可忽視性。目前Yeti DNS專案已被延展至2019年底 [註2]，ECDSA演算法、blockchain技術的應用研究也都做為原因在公告中被提及，是否有更進一步的發展也值得關注。
—-
註1. 有關 APNIC在IPv6 fragmentation的研究，請參考以下連結 ：Dealing with IPv6 fragmentation in the DNS、Part 2。
註2. Yeti DNS專案延展的公告。
