DNS根服務體系的發(fā)展研究

延志偉，耿光剛，李洪濤，李曉東

（1. 中國互聯(lián)網(wǎng)絡信息中心，北京 100190；2. 互聯(lián)網(wǎng)域名管理技術國家工程實驗室，北京 100190）

DNS根服務體系的發(fā)展研究

延志偉1,2，耿光剛1,2，李洪濤1,2，李曉東1,2

（1. 中國互聯(lián)網(wǎng)絡信息中心，北京 100190；2. 互聯(lián)網(wǎng)域名管理技術國家工程實驗室，北京 100190）

以DNS根服務體系發(fā)展歷史為切入點，闡述了根服務器及根區(qū)文件的管理模式，針對DNS根服務器管理模式面臨的效率、可擴展性以及穩(wěn)定性等方面的缺陷，從政策層面綜述了國際社群對擴展 DNS根服務器的相關討論和結論，并基于若干開放性原則進一步從技術層面詳細論述和分析了擴展 DNS根服務體系的相關解決方案。

域名服務；根系統(tǒng)；任播；泛在DNS根服務

1 引言

在互聯(lián)網(wǎng)蓬勃發(fā)展的今天，互聯(lián)網(wǎng)用戶迅猛增加，各種上層應用層出不窮。域名服務系統(tǒng)（DNS，domain name system）作為解析互聯(lián)網(wǎng)資源名字及互聯(lián)網(wǎng)資源地址的基礎服務，其重要性愈發(fā)突出。而作為DNS解析入口的根服務體系，其安全穩(wěn)定是整個域名解析業(yè)務正常高效運作的先決條件。

DNS根服務器用于響應用戶對根區(qū)文件（root zone file）的查詢請求，根區(qū)文件維護著頂級域名（TLD，top level domain）的位置信息，全球共有13臺根服務器。1997年8月，1臺根服務器被從美國轉移到日本，13臺根服務器的格局基本形成（除了位于日本的1臺外，9臺位于美國，歐洲的2臺分別位于英國和瑞典）。

由于 DNS所使用的傳輸協(xié)議——用戶數(shù)據(jù)報協(xié)議（UDP，user datagram protocol），對數(shù)據(jù)分組具有512 B的長度限制，要讓所有的DNS根服務器信息被包含在同一個UDP數(shù)據(jù)分組中，根服務器數(shù)量只能被限制為13（準確地說，13臺根服務器所需的DNS響應數(shù)據(jù)分組大小為436 B），且每個服務器要使用字母表中的單個字母（A～M）標識。13臺服務器由12個獨立機構運維（其中VeriSign運維2臺根服務器），這些機構起初都是以自愿者身份被選出。此外，出于DNS根服務多樣性考慮，這12個機構均按照自身規(guī)劃和模式管理對應的根服務器。當前13臺根服務器的基本信息如表1所示。

美國東部時間2002年10月21日下午，這13臺服務器遭受了有史以來最為嚴重的也是規(guī)模最為龐大的一次分布式拒絕服務（DDoS，distributed denial of service）攻擊。超過常規(guī)數(shù)量30～40倍的數(shù)據(jù)量猛烈地向這些服務器襲來，從而導致其中的9臺不能正常運行。事后，DNS根服務體系開始采用任播（anycast）技術進行DNS根服務的復制，到2004年，DNS根服務器鏡像節(jié)點已多達80臺，它們分布在34個不同的國家和地區(qū)。2007年2月6日，DNS根服務器再次遭受大規(guī)模DDoS攻擊，攻擊持續(xù)了近8 h，攻擊源幾乎遍布全球，該攻擊事件發(fā)生后，DNS根服務器鏡像已增加到130臺，分布在53個國家和地區(qū)。近幾年的一次根服務器大規(guī)模擴展發(fā)生在 2012年，著名黑客組織Anonymous在2012年2月宣稱要采用放大和反射攻擊摧毀DNS根服務體系，這一事件促使 DNS根服務體系在短短幾個月內幾乎在全世界各國都部署鏡像，其總量超過了300臺。截至2016年12月5日，13臺根服務器通過任播技術在全球部署服務節(jié)點已達641個。

中國在 2003年引進了第一個根服務器的鏡像——F根鏡像，是由ISC和中國電信共同建立的。2005年，I根的管理機構Autonomica在中國互聯(lián)網(wǎng)絡信息中心（CNNIC）設立了中國第二個根鏡像。2006年，中國網(wǎng)通與美國VeriSign公司合作，正式開通J根的中國鏡像服務器。2011年，CNNIC在北京新增一個F根鏡像。此外，CNNIC于2012年又部署了第一個L根鏡像節(jié)點。2014年，世紀互聯(lián)、北龍中網(wǎng)和天地互連3家公司分別與互聯(lián)網(wǎng)名稱與數(shù)字地址分配機構（ICANN，Internet corporation for assigned names and numbers）開展合作，在中國增設3臺L根域名服務器鏡像節(jié)點。阿里云與VeriSign合作在杭州建設了一個J根鏡像。這4個根服務器的9個鏡像節(jié)點成為我國境內DNS查詢請求主要的根服務節(jié)點。

因此，從歷史發(fā)展看，DNS根服務體系（本文所用“根服務體系”包括根區(qū)文件管理體系與根服務器管理體系）隨著互聯(lián)網(wǎng)的不斷繁榮，越來越成為各國政府機構、學術研究機構和產(chǎn)業(yè)界普遍關注的熱點，圍繞DNS根服務體系的擴展與架構演進的討論多年來一直在延續(xù)，如今隨著互聯(lián)網(wǎng)全球化管理模式的討論再次成為關注焦點。

表1 根服務器主要情況

本文對 DNS根服務體系的發(fā)展歷史進行了梳理，并闡述了DNS根服務體系的管理模式，對擴展DNS根服務體系的方案進行了分析，且對其未來的演進方向進行了探索。

2 DNS根服務體系管理模式

DNS通過層次化的形式管理域名數(shù)據(jù)，從而以分段的方式將人們可以記住的域名轉換為計算機使用的數(shù)字以尋找其對應的目的地。DNS管理體系中最為核心的角色便是互聯(lián)網(wǎng)數(shù)字分配機構（IANA，Internet assigned numbers authority），其職能由ICANN承擔。

ICANN是一個非盈利組織，總部設在美國，此前一直按照與美國商務部（US DoC/NTIA）簽訂的諒解備忘錄（MOU）來行使與互聯(lián)網(wǎng)碼號資源管理相關的職能。除了與美國商務部簽訂了諒解備忘錄之外，ICANN還按照其與商務部簽訂的一項單獨合同行使IANA的職能（這些職能具體包括根區(qū)管理、協(xié)調技術協(xié)議參數(shù)的分配以及互聯(lián)網(wǎng)碼號資源的分配）。圖1為從ICANN角度理解的IANA職能管理權移交前DNS根區(qū)管理模式；而在根區(qū)管理過程中，ICANN首先需要向NTIA提交來自國際頂級域名（gTLD）和國家代碼頂級域名（ccTLD）注冊管理機構對根區(qū)文件的修改申請，NTIA批準修改后，再授權運維隱藏根的 VeriSign公司進行對應的操作。修改后的文件最后會經(jīng)由隱藏根向13個根服務器進行擴散，進而擴散到全球的根鏡像節(jié)點。

鑒于ICANN和美國政府在DNS根區(qū)文件管理中所扮演的重要角色，業(yè)界一直認為美國政府和ICANN對DNS根服務體系這一互聯(lián)網(wǎng)重要基礎設施存在絕對的控制權。準確而言，這種認識是有偏頗的：為了保證根區(qū)文件的一致性，當前采用以ICANN協(xié)調、NTIA批準、VeriSign操作的集中模式（ICANN為IANA root zone management function operator，VeriSign為 root zone maintainer，NTIA為root zone administrator）。雖然ICANN也不斷優(yōu)化這一管理模式，如在2013年對外發(fā)布了根區(qū)管理的審計報告，但這模式在一定程度上有悖互聯(lián)網(wǎng)多利益相關方（multi-stakeholder）的原則：一方面，ICANN同時承擔了政策制定與操作實施的角色，對TLD可用性認定和具體操作實施沒有功能的分離；另一方面，由于美國政府涉入被視為國家資源的ccTLD的修改操作（盡管NTIA認為其角色僅是監(jiān)管操作流程是否合規(guī)進行），因此業(yè)界普遍認為此模式并不足夠公平開放。這一問題也是在IANA Transition進程中重要的議題，如社群廣泛建議應進一步明確根區(qū)管理的安全保證和外部審計機制、提升ICANN政策制定透明度、推動現(xiàn)有咨詢討論的公開透明化，以強化全球互聯(lián)網(wǎng)社群的參與和監(jiān)督。

圖1 域名體系管理模式

從根服務器的角度看，每個DNS根服務器運行機構才擁有對該服務器的絕對管理權，但并不存在對所有根服務器具有集中管理權利的實體（在2012年ICANN與NTIA簽訂的更新版合同中也明確ICANN對DNS根服務體系的管理限于根區(qū)（DNS root zone management）層面，而非以前較為含糊的 DNS監(jiān)管（domain name system supervision，1997年的合同）或 DNS根的監(jiān)管（administrative functions associated with root management，2000年的合同）等說法）。這種分布式管理模式旨在保證 DNS根服務的部署多樣性（diversity）和運行穩(wěn)定性（stability）。實際上，DNS根服務器架構的多樣性保證也體現(xiàn)在 DNS根服務器所使用的軟件上，為了避免單點失效和運行風險，這些根服務器盡量采用多樣化的DNS軟件并使用不同的版本。

在 IANA職能管理權移交后，美國政府將不再承擔相關審核和監(jiān)督職責，全球根管理合同基本格局將由ICANN主導的2份合同確定：一是與移交后IANA（PTI）簽訂IANA域名職能合同，授權 PTI履行 IANA職能運行工作；二是與VeriSign簽訂根區(qū)維護者服務協(xié)議（RZMA），授權 VeriSign繼續(xù)負責根區(qū)文件修改、生成、維護全球根區(qū)數(shù)據(jù)庫系統(tǒng)以及根區(qū)文件的分發(fā)。這 2份合同已分別于2016年10月1日和2016年10月20日生效。

由此可見，根區(qū)文件管理的優(yōu)化更多是國際政策層面的問題，本文重點從技術層面研究探討DNS根服務器運行管理模式存在的問題及可行的演進方向和擴展機制。

3 DNS根服務器擴展分析

對根服務器數(shù)量是否應該隨著域名解析系統(tǒng)的發(fā)展突破當前限制，以更加開放、可擴展的方式增設，國際互聯(lián)網(wǎng)協(xié)會（ISOC，Internet society）早年便有過對此問題的考慮，但其認為DNS根服務器的當前架構應以穩(wěn)定性為主，不宜輕易做出改動。無獨有偶，這個問題在國際電信聯(lián)盟（ITU，International Telecommunication Union）也討論過，結論也很明確。ITU認為增加根服務器并非受阻于技術問題，主要是對其分配和管理很難抉擇。然而，隨著互聯(lián)網(wǎng)的發(fā)展，各個國家和地區(qū)都有在本國本地區(qū)增設根服務器的期望，以此來強化對互聯(lián)網(wǎng)核心基礎設施管理的參與度并優(yōu)化DNS根解析的本地服務性能。

2002年，日本研究人員對根服務器的數(shù)量和分布進行過研究，認為當時的根服務器分布嚴重不均，希望能對歐洲和美國的根服務器進行重新部署[1]，不過其背景是尚未采用anycast技術部署鏡像節(jié)點[2,3]。隨著互聯(lián)網(wǎng)的不斷發(fā)展，DNS根服務器隨著DNS的演進承載更多的功能，同時基于anycast技術在規(guī)模上不斷擴張，ICANN也意識到未來不斷擴展根服務器的需求和可能性，因此在2009年2月的董事會決議中要求根服務器咨詢委員會（RSSAC，root server system advisory committee）、安全和穩(wěn)定咨詢委員會（SSAC，security and stability advisory committee）和ICANN工作人員深入研究引入IPv6地址記錄、國際化頂級域名（IDN，internationalized domain name）、其他新的通用頂級域名，以及為支持DNS安全擴展協(xié)議（DNSSEC，domain name system security extensions）在根區(qū)增加新的資源記錄對DNS根服務器的穩(wěn)定性影響[4]。作為對該決議的答復，RSSAC、SSAC和ICANN工作人員成立了根擴展指導性工作組（RSSG，root scaling steering group）來為此次集中性的研究制定研究范疇和預計研究成果，并將其公布于 2009年 5月的參考條目（ToR）中[5]，該指導性工作組還成立了一個專家組（RSST，root scaling study team）著手該項研究[6]。作為主要成果，RSST于 2009年8月和2009年10月相繼發(fā)表了2篇研究報告，名為《擴展根：關于擴展根區(qū)規(guī)模及增大根區(qū)波動對DNS根系統(tǒng)影響的報告》[7]和《根擴展研究：DNS根擴展模型的描述》[8]。前者認為根區(qū)文件承載的內容越來越多，勢必對根服務器的穩(wěn)定性造成影響，特別是對網(wǎng)絡狀態(tài)較差的區(qū)域，在根區(qū)文件更新頻繁的時候可能會存在一定困難，進一步估算認為，當前的數(shù)據(jù)同步架構所能承受的每年新增根區(qū)文件數(shù)據(jù)的條目在O(100)量級，如若上升到O(1 000)的量級，勢必需要對當前的根服務器架構進行適應性調整；后者給出一個量化的根區(qū)數(shù)據(jù)管理模型，可用于仿真和評估根區(qū)擴展研究相關的問題。

除了參與RSST相關議題外，RSSAC還就如何高效、安全、穩(wěn)定地管理DNS根服務器提出若干建議，重點聲明根服務器運行機構僅是根區(qū)文件發(fā)布者（publisher）而非修訂者（editor）[9]；此外，應切實強化根服務器運行機構的可審計性并制定運維管理的相關準則和服務水平規(guī)范[10]；并表明根服務器作為DNS解析的入口，應及時更新相關功能支持（如TCP、IPv6等），保證根區(qū)文件的準確性及最大限度增強根服務器部署的泛在性[11]。

這些來自ICANN的研究和建議不僅從另一個角度對擴展當前的DNS根服務器體系提出實際需求，也在一定程度上為未來DNS根服務器體系的擴展奠定了技術和政策基礎。結合相關研究報告，本文從DNS根服務器運行的性能角度分析其部署架構，可發(fā)現(xiàn)影響其安全穩(wěn)定及服務性能的具體因素主要體現(xiàn)在 2個方面：根區(qū)文件的同步延時以及anycast節(jié)點造成的BGP路由收斂開銷。本節(jié)首先對這 2個方面進行分析，并進一步從實際運行狀態(tài)角度闡述DNS根服務器架構的缺陷。

3.1 根區(qū)文件同步時延

當前的根區(qū)文件更新操作由VeriSign負責，其頻率為一天2次，具體流程如圖2所示[8]。當新的根區(qū)文件產(chǎn)生后，分發(fā)主體（DM，distribution master），即上文提及的隱藏根，向所有的其他根服務器（RS，root server）發(fā)送 DNS通告消息（notify），每個 RS相應地回復確認消息（acknowledgement）。如果DM沒有在規(guī)定時間內接收到確認消息，將會重新發(fā)送通告消息，嘗試與RS建立聯(lián)系。RS成功發(fā)送確認消息之后，隨即向 DM 發(fā)送起始授權記錄（SOA，start of authority）請求，以此來驗證自己當前的根區(qū)文件版本與DM所維護的根區(qū)文件版本之間是否存在差異。DM以當前根區(qū)文件序列號進行響應。如果DM響應的版本號大于RS當前維護的根區(qū)文件的版本號，RS則啟動區(qū)傳輸（XFR，zone transfer）以請求更新根區(qū)文件。

當采用 anycast技術進行根服務器節(jié)點鏡像復制時，根區(qū)文件也可能采用相同的機制在鏡像節(jié)點進行同步。然而，由于不斷擴大的鏡像節(jié)點部署規(guī)模，這一機制也具有不斷增大的時延和開銷：第一階段是notify交互、SOA查詢以及XFR啟動過程；第二階段是區(qū)文件數(shù)據(jù)傳輸過程。當根服務器與其鏡像節(jié)點之間距離較遠時，文件同步時間會線性增加，此外，隨著根區(qū)文件的增大，數(shù)據(jù)同步時間也會相應增大，這一因素會受到很多DNS擴展技術的影響，如DNSSEC會將傳統(tǒng)區(qū)文件擴大7～10倍[12]，而IPv6資源記錄的引入會給每個域名帶來額外的128 bit[13]。另一方面，新的gTLD的不斷擴張也使根區(qū)文件不斷增大[14]。

圖2 DM和RS之間的交互流程

正如ICANN所分析的，當前有些根服務器運維機構已經(jīng)發(fā)現(xiàn)某些遠端鏡像節(jié)點在根區(qū)文件同步中暴露出效率問題，進一步認為，隨著根區(qū)的不斷擴大會給根區(qū)文件的同步帶來更大挑戰(zhàn)[7]。

3.2 BGP路由收斂開銷

研究表明，很多互聯(lián)網(wǎng)故障歸咎于路由聚合的延遲以及路由表的振蕩，骨干網(wǎng)路由尤其明顯，其平均聚合時間可達幾分鐘，這也是邊界網(wǎng)關協(xié)議（BGP，border gateway protocol）路由長久以來廣受詬病的原因之一[15]。基于距離矢量算法，BGP需要每個路由器維護到達可能目的地的距離以及下一跳的向量。當網(wǎng)絡連接狀態(tài)發(fā)生變化時，路由器需要重新計算到目的地的距離以更新路由表[16]。由于anycast完全依賴于BGP選擇最優(yōu)節(jié)點，BGP收斂的問題自然也影響到基于anycast的DNS根服務器服務穩(wěn)定性[17,18]。如果網(wǎng)絡狀態(tài)不穩(wěn)定或 BGP路由屬性誤配置，都有可能造成DNS根區(qū)解析服務的性能下降[19]，此外，BGP路由不斷進行動態(tài)調整和變化，如果DNS承載于傳輸控制協(xié)議（TCP，transmission control protocol）之上，還可能造成同一會話的不同數(shù)據(jù)報文被路由到不同鏡像節(jié)點的情況，從而導致DNS會話中斷。

3.3 解析性能探測與分析

為了直觀展示我國境內訪問DNS根服務器的性能，從而發(fā)現(xiàn)其可能的缺陷，本文在全國32個省市部署了61個監(jiān)測節(jié)點，以探測當前在我國境內部署的DNS根服務器鏡像節(jié)點的運行情況[20]。圖3為從兩大互聯(lián)網(wǎng)服務提供商ISP（Internet service provider）（中國電信和中國聯(lián)通）探測的13個DNS根服務器的平均解析時延。

由此可見，在國內部署鏡像節(jié)點的服務器具有較小的時延，但不同服務器節(jié)點的差異較大，這一結果從側面說明：當某個服務器失效或不可達時，該區(qū)域的DNS根區(qū)解析效果將受到較為顯著的影響。

圖3 根服務器平均解析時延

在我國部署鏡像的根服務器中，F(xiàn)節(jié)點性能最優(yōu)，圖4為從國內主要省份訪問F節(jié)點的性能。

因為監(jiān)測節(jié)點并未能在所有省份完全覆蓋2個ISP，所以圖4混合了2個ISP的探測結果（如在河北只有ISP2網(wǎng)絡的監(jiān)測節(jié)點）。上述結果表明，雖然不同位置具有較大差異，但F節(jié)點的解析時延整體較低（大多低于50 ms），這是因為大部分訪問F節(jié)點的請求都命中部署在國內的F鏡像節(jié)點。

如圖5所示，“pek2a”和“pek2b”是國內F鏡像節(jié)點所使用的2個IP地址的標識，10次測量都命中這2個IP地址。

圖4 F節(jié)點解析時延

圖5 中國境內F鏡像節(jié)點命中情況

相比于F節(jié)點，J節(jié)點的解析時延明顯增大，如圖6所示，大多數(shù)訪問的時間都超過150 ms。相應地，圖7給出了訪問J節(jié)點命中國內鏡像的情況。

圖7中“elbei1”標識J在國內鏡像節(jié)點所使用的IP地址，“v6sfol”為J在美國San Francisco的鏡像節(jié)點所使用的IP地址。當請求消息命中國內鏡像節(jié)點時，時延明顯較低，如在安徽和山東的監(jiān)測結果都低于50 ms。但是其他省份的監(jiān)測請求都命中了美國的鏡像節(jié)點，時延明顯增大。

上述探測結果受到該地區(qū)部署遞歸服務器的數(shù)量、性能及與國內鏡像節(jié)點之間距離和ISP在該地區(qū)鏈路狀態(tài)等諸多因素的影響，但也可以直觀地發(fā)現(xiàn)，在我國網(wǎng)絡覆蓋范圍較廣的情況下，集中式部署（幾乎均在北京）的 9個鏡像節(jié)點顯然不能為超過 6億互聯(lián)網(wǎng)用戶提供高效穩(wěn)定的DNS根解析服務[21]。從這個角度看，DNS根服務器的數(shù)量擴展和部署優(yōu)化確實存在很大空間。

圖6 J節(jié)點解析時延

圖7 中國境內J鏡像節(jié)點命中情況

4 根服務器擴展原則

雖然當前存在很多關于根服務器演進方案的討論，但要保證DNS根服務器架構能健康演進，首先需要從原則上進行研究和分析。回顧整個互聯(lián)網(wǎng)發(fā)展進程，由于其遵循去中心化（decentralization）、本地化（locality）、可擴展性（scalability）等多種根本性原則，才得以枝繁葉茂，長久繁榮[22]。那么DNS，特別是其根服務器架構是否在發(fā)展過程中良好地遵循這些原則？

1) 去中心化

去中心化保證了互聯(lián)網(wǎng)控制的民主，增強了錯誤容忍[23]。在 DNS體系中，遞歸服務器層面完全遵循這一原則，因此，遞歸服務也是 DNS服務體系發(fā)展最為迅速的一環(huán)，并側面推動了整個DNS的發(fā)展。而根以下的權威服務可以被任何DNS區(qū)所用（甚至是私有區(qū)），這表明頂級及以下權威服務層面在一定程度上也符合去中心化的原則。但DNS根服務器自誕生之初就由12個不同的運營機構管理，雖然根區(qū)文件在理論上應該保證唯一性，但對于根服務器的運行管理卻沒有中心化的必要。

2) 本地化

本地化可以使互聯(lián)網(wǎng)的失效被限制在本地范圍[24,25]，從而增強互聯(lián)網(wǎng)的整體生存性和健壯性。從DNS服務體系看，遞歸服務器可以根據(jù)本地業(yè)務實際需求進行本地化部署，很好地遵循了這一原則。類似地，從頂級域及其以下，數(shù)據(jù)安全性受到DNSSEC的保障，并不需要服務器集中性部署和管理。但這一原則并未在 DNS根服務器上得到體現(xiàn)，雖然DNS根服務器采用了anycast技術，但是鏡像節(jié)點的管理受到上級節(jié)點的嚴格制約，這種自上而下的模式很顯然是對DNS根服務器本地化和多樣性需求的最大束縛。

3) 可擴展性

可擴展性保證了互聯(lián)網(wǎng)可以任意發(fā)展和擴張[26]。正如前所述，由于遵循去中心化和本地化原則，DNS遞歸服務器和頂級及以下權威服務器具有良好的可擴展性。但DNS根服務器的可擴展性卻受制于BGP路由體系，正如前所述，這也造成實際運行及未來發(fā)展的若干問題。

由此可見，設計去中心化的、本地化的以及不嚴格依賴于其他協(xié)議和服務體系的 DNS根服務器擴展機制才是保證 DNS根服務器架構順應互聯(lián)網(wǎng)發(fā)展理念的可行演進思路。

5 DNS根服務器擴展方案

對于未來擴展 DNS根服務體系的可行方向考慮，當前可分為2種思路：在當前13個根服務器基礎上新增根服務器并彌補 13個根服務器在地理位置分布不均等方面存在的缺陷[27～29]；設計能滿足長遠需求的開放DNS根服務體系架構。在此基礎上，本文結合第4節(jié)的演進原則提出一種泛在DNS根服務體系及其關鍵技術。

5.1 服務器數(shù)量擴展

DNS是一個分布式系統(tǒng)，所有的查詢在緩存沒有命中的情況下都是從根區(qū)開始的，因此遞歸服務器必須配置根服務器的地址，作為查詢的入口，這個配置文件稱之為根區(qū)提示文件（hint file），該文件包含所有根服務器的名字和對應的IP地址。遞歸服務器管理員可以從指定位置下載，同時遞歸服務器每一次啟動后，都會根據(jù)配置的根區(qū)提示文件，向其中一個根服務器查詢根服務器授權記錄以及Glue記錄（即服務器IP地址）來更新可能更改的根服務器信息，這個過程被稱為Priming，探測的過程是使用UDP發(fā)送查詢請求。所以為了完成一次探測，應答分組應獲得所有的根授權記錄和對應的Glue記錄，并以此作為以后查詢根區(qū)信息的依據(jù)。

在沒有任何IPv6記錄之前，根配置了13臺權威服務器，每個服務器有一條Glue記錄，整個應答分組大小為436 B，而IPv4網(wǎng)絡上最保守（基于路徑MTU（PMTU，path maximum transmission unit）安全值）的UDP報文大小限制在512 B內，這也是當初設計13臺根服務器時主要考慮的因素。

隨著IPv6協(xié)議的引入，根服務器開始配置使用IPv6的地址，從而造成Priming應答數(shù)據(jù)分組長度突破512 B。例如在7臺根服務器上配置IPv6地址，Priming應答消息將會增大到63 B，這就超過了IPv4中安全UDP報文限度值，一次探測應答的報文中，將包含所有的IPv4的地址，而只能包含2條IPv6的地址，返回哪2個根服務器的IPv6地址，不同的服務器可以有不同的實現(xiàn)，有的根服務器實現(xiàn)是不區(qū)分IPv4和IPv6地址的，即返回部分IPv4地址和部分IPv6地址，這就導致被返回IPv6地址的根服務器，潛在地接受更多的基于IPv6的DNS查詢。

由于這個缺陷，DNS遞歸服務器軟件在BIND9之后開始啟用EDNS0（extension mechanisms for DNS version 0）[30]擴展協(xié)議，通過在遞歸服務器和權威服務器之間協(xié)商和探測能支持的UDP分組大小，來增大UDP分組的最大限制以容納整個應答。CNNIC的探測結果表明，當前遞歸服務器對EDNS0的支持率已經(jīng)高達98%[20]。因此，隨著IPv6的普及，如果所有的根服務器都已配置了IPv6地址[31]（當前已有11臺支持IPv6），13臺根服務器信息的報文總長度為811 B（包含一個11 B的OPT記錄）[32]。基于RIPE的測試和統(tǒng)計，目前使用的絕大部分的遞歸服務器都能支持811 B以上的UDP報文，而且目前使用中的大部分網(wǎng)絡中間設備都允許大于512 B的UDP報文通過。進一步地，2010年 7月，根區(qū)數(shù)據(jù)將被DNSSEC簽名，使每個DNS查詢的應答中都會包含新的簽名記錄，超過512 B已經(jīng)是非常普遍的事情。為此，RFC4035[33]指出，支持DNSSEC的服務器必須支持EDNS0。這就表明隨著互聯(lián)網(wǎng)的發(fā)展，已經(jīng)不能再將DNS報文小于512 B作為無法增加新的根服務器的阻礙。同時，RFC5966[34]還要求DNS服務器支持TCP查詢。一次TCP應答的最大長度是65 535 B，在這種情況下，再增加新的根服務器對報文長度的影響就變得更小。而 CNNIC探測結果表明，當前遞歸服務器對于 TCP查詢的支持率也已經(jīng)達到74%[20]。

由上述分析可見，當前增設新的根服務器從技術上是完全可行的，這些新增的服務器為后續(xù)更加分布式、平衡地部署DNS根服務器創(chuàng)造了可能。

5.2 服務模式優(yōu)化

為了優(yōu)化DNS根服務器架構，當前DNS根服務器的運行模式也隨著國際社區(qū)全面推進的IANA Transition被提上議程。ICANN的RSSAC成立了 Caucus[35]，作為其重點工作，Caucus就DNS根服務器安全、穩(wěn)定以及未來演進的相關問題進行深入研究并向ICANN提供技術性咨詢。與此同時，ICANN還就當前DNS根服務器運行的模式、根服務器運行機構的審計、準入和推出機制征集了廣泛的社群意見[36]。

同時，互聯(lián)網(wǎng)工程任務組（IETF，Internet engineering task force）也從技術角度開展了相關問題的討論。DNSOP（domain name system operations）工作組[37]提出了2種解決方案，分別從遞歸服務器一側和權威服務器一側實現(xiàn) DNS根服務器的擴展。前者[38]主張通過在遞歸服務器的本地環(huán)回接口（loopback）上維護根區(qū)文件以實現(xiàn)DNS根服務的本地化；而后者[39,40]則通過開放當前13臺根服務器中的某個（或多個）服務器的地址或通過增設第14臺開放根服務器，實現(xiàn)根服務器的開放anycast，以優(yōu)化根服務節(jié)點的可擴展能力。從功能和性能上對比，前者弱化了 DNS根服務器的重要性，并能實現(xiàn)DNS根區(qū)解析性能最大程度的優(yōu)化，且避免了當前大量無效請求影響根服務器整體運行性能的問題。但該方案首先無法保證所有遞歸服務器運營機構有能力提供和維護這一服務，其次對傳統(tǒng)遞歸服務器運行邏輯改造較大。后者適合靈活部署和推廣，但是仍然依賴于anycast技術[41]，所以大量的DNS根服務器節(jié)點可能由于配置不當對 BGP路由體系造成較大影響[42,43]。雖然這2個方案的共同點是均依賴于 DNSSEC技術保證根區(qū)文件同步的安全性及弱化根區(qū)文件的來源權威性，但根區(qū)文件同步的效率是這2個方案共同存在的核心難題。

基于在遞歸服務層面實現(xiàn)本地化根服務這一方案在實際部署中存在的問題，CNNIC又提出了共享緩存的解決方案，該方案通過在自治范圍內或多個自治范圍間共享根區(qū)文件緩存服務器，實現(xiàn)根區(qū)文件解析的本地化，經(jīng)過廣泛調研，這一機制也是當前很多遞歸服務提供機構實際采用的運作模式[44]，但由于DNS整個生態(tài)體系存在扭曲，這種工作模式并未被正式討論和規(guī)范。

此外，還有很多文獻提出了采用對等網(wǎng)絡（P2P，peer-to-peer）實現(xiàn)分布式根服務器管理架構[45]以及區(qū)域性對等根服務器架構（alternative DNS root）[46]，但由于此類研究僅存在于理論層面或有損互聯(lián)網(wǎng)平等互聯(lián)原則[47]，考慮到 DNS根服務對整個互聯(lián)網(wǎng)安全和穩(wěn)定的特殊作用，這些方案并不足夠成熟以進行實際和大規(guī)模廣泛部署。

5.3 泛在DNS根服務體系

結合 DNS根服務體系演進原則以及當前解決方案的方向，本文提出一種泛在DNS根服務體系，如圖8所示。

基于DNSSEC，根區(qū)文件的完整性和正確性有了保障，因此，DNS根服務可以由 DNS服務體系中的任何邏輯功能來承擔（本文將這種可能部署在任何邏輯功能上的 DNS根服務器稱為泛在 DNS根服務器），但傳統(tǒng)的13臺DNS根服務器及其鏡像節(jié)點、新增的DNS開放根服務器及其本地鏡像節(jié)點、遞歸服務器的loopback接口、甚至頂級及以下的權威服務器。這種架構不僅能滿足 DNS根區(qū)解析的性能最優(yōu)，而且最大程度地保證了 DNS根區(qū)服務的可靠性。

圖8 泛在DNS根服務體系

顯然，在泛在DNS根服務體系中，DNS服務的部署已經(jīng)不是問題，但DNS服務的泛在化帶來的2個重大挑戰(zhàn)是DNS根服務的宣告和根區(qū)文件的同步：前者保證了泛在 DNS根服務能夠被用戶配置和使用；而后者保證了大量泛在DNS服務器能夠高效地得到最新的根區(qū)文件。

1) 基于HINT RR的服務宣告

為了規(guī)范化泛在DNS服務器配置，本文提出一種新的DNS資源記錄，稱為HINT，其格式如下。

Zone Lifetime IN HINT Server-name

Zone標識這個泛在DNS根服務器的作用范圍，如CN標識在中國范圍，baidu.com標識在百度的內部網(wǎng)絡。

Lifetime標識這個資源記錄的有效生存期。

IN標識是一條互聯(lián)網(wǎng)類型（Internet class）的資源記錄。

HINT標識這條資源記錄用于記錄該區(qū)域內的泛在DNS根服務器。

Server-name為提供該泛在DNS根服務器的服務器名稱。

遞歸服務器如果需要配置泛在 DNS根服務器，就查詢對應區(qū)的HINT資源記錄，并將其相應數(shù)據(jù)加入db.root文件中，作為該遞歸服務器查詢根服務器的啟動文件。那么遞歸服務器將可以采用如下2種具體策略使用13臺服務器之外的其他DNS根服務器。

① db.root.global.with.local：泛在DNS根服務器與傳統(tǒng) A-M 根混用，這是本文建議采用的默認方案，當泛在根服務器不可用時，可以迅速切換到傳統(tǒng)的DNS根服務器。

② db.root.only.local：單獨維護和啟用泛在DNS根服務器。

2)主被動混合的根區(qū)文件同步

如圖8所示，除了傳統(tǒng)根服務器的文件同步方式外，泛在DNS根服務體系中的根區(qū)文件同步可采用2種模式：泛在DNS根服務器主動經(jīng)由根區(qū)文件發(fā)布點（如FTP）進行文件下載和更新、采用基于Pub/Sub的被動接收方式。其中，前者適用于服務范圍較小的泛在DNS根服務器，從而可以減輕DNS根區(qū)文件發(fā)布點的壓力；后者適用于服務范圍較大的泛在DNS根服務器，從而可以保證根區(qū)文件能在更新后最短時間內得到更新。而FTP站點、任何傳統(tǒng)的DNS根服務器以及開放根都可以作為 DNS根區(qū)文件發(fā)布站點，為了避免大量泛在DNS根服務器部署造成的根區(qū)文件發(fā)布瓶頸效應，建議采用層次方式進行數(shù)據(jù)同步。

6 結束語

作為支撐互聯(lián)網(wǎng)正常運作的核心基礎服務，DNS隨著互聯(lián)網(wǎng)在普及廣度和應用深度的雙重驅動下凸顯著越發(fā)重要的作用。隨著IANA職能轉移（IANA transition）的完成，DNS根服務體系如何順勢演進也成為整個互聯(lián)網(wǎng)社區(qū)關注的焦點。

本文首先對 DNS根服務體系的演進歷史和當前的運行和管理模式進行了介紹，然后分析了當前DNS根服務器運行和管理架構面臨的效率、可擴展性以及穩(wěn)定性方面的問題，并針對中國的網(wǎng)絡環(huán)境，實際探測了主要省份的根服務性能，從側面表明需要對當前 DNS根服務器進行優(yōu)化擴展的實際需求。

此外，本文從互聯(lián)網(wǎng)演進的角度出發(fā)，提出了DNS根服務器未來演進應遵循的若干原則，總結了當前業(yè)界討論的若干方案且進行了分析比較，在此基礎上提出了一種泛在DNS根服務體系并對關鍵問題給出針對性解決方案。

[1] LEE T, HUFFAKER B, FOMENKOV M, et al. On the problem of optimization of DNS root servers' placement[C]//Passive and Active Network Measurement Workshop (PAM). 2003.

[2] HARDIE T. Distributing authoritative name servers via shared unicast addresses[S]. IETF RFC3258, 2002.

[3] PARTRIDGE C, MENDEZ T, MILLIKEN W. Host anycasting service[S]. IETF RFC1546, 1993.

[4] ICANN Board of Directors. Draft minutes of the special board meeting[R]. 2009.

[5] ICANN Root Scaling Steering Group (RSSG). Root scaling study terms of reference[R]. 2009.

[6] ICANN. Report of the security and stability advisory committee on root scaling[R]. 2010.

[7] ICANN. Scaling the root-report on the impact on the DNS root system of increasing the size and volatility of the root zone[R]. 2009.

[8] ICANN. Description of the DNS root scaling model, TNO information and communication technology[R]. 2009.

[9] ICANN Root Server System Advisory Committee (RSSAC). Draft proposal, based on initial community feedback, of the principles and mechanisms and the process to develop a proposal to transition NTIA’s stewardship of the IANA functions[R]. 2014.

[10] ICANN. Service expectations of root servers[R]. 2013.

[11] ICANN. RSSAC recommendation on measurements of the root server system[R]. 2014.

[12] [EB/OL]http://www.cisco.com/web/about/ac123/ac147/archived_ issues/ipj_ 7-2/dnssec.html.

[13] ICANN. Accommodating IP version 6 address resource records for the root of the domain name system[R]. 2007.

[14] CAIDA. Analysis of the DNS root and gTLD nameserver system: status and progress report[R]. 2008.

[15] PERLMAN R. Interconnections[R]. 1999.

[16] GARCIA-LUNA-ACEVES J J. Loop-free routing using diffusing computations[C]//IEEE/ACM Trans. on Networking. 1993: 130-141. [17] LABOVITZ C, AHUJA A. Delayed Internet routing convergence[C]//IEEE/ACM Trans. on Networking. 2001: 293-306.

[18] LABOVITZ C. The impact of internet policy and topology on delayed routing convergence[C]// IEEE Infocom, 2001.

[19] SARAT S, PAPPAS V, TERZIS A. On the use of anycast in DNS[C]//IEEE ICCCN. 2006.

[20] 中國互聯(lián)網(wǎng)絡信息中心.中國域名服務安全狀況與態(tài)勢分析報告[R]. 2014. China Internet Network Information Center. Chinese domain name service security situation and trend analysis report[R] .2014.

[21] 中國互聯(lián)網(wǎng)絡信息中心. 第35次中國互聯(lián)網(wǎng)絡發(fā)展狀況統(tǒng)計報告[R]. 2015. China Internet Network Information Center. The 35th China Internet network development state statistic report[R]. 2015.

[22] CARPENTER B. Architectural principles of the Internet[S]. IETF RFC1958, 1996.

[23] LIMONCELLI T A, HOGAN C J, CHALUP S R. The practice of system and network administration[R]. 2007.

[24] DENNING P J. The locality principle[J].ACM Communication, 2005, 48(7):19-24.

[25] Future Internet Architecture (FIArch) Group. Future Internet design principles[R]. 2012.

[26] CLARK D, CHAPIN L, CERF V, et al. Towards the Future Internet Architecture[S] .IETF RFC1287, 1991.

[27] ABLEY J. Hierarchical anycast for global service distribution[R]. ISC technical note 2003-1, 2003.

[28] SAVAGE S. The end-to-end effects of internet path selection[C]//ACM Sigcomm. 1999.

[29] SPRING N, MAHAJAN R, ANDERSON T. Quantifying the causes of path inflation[C]//ACM Sigcomm. 2003.

[30] VIXIE P. Extension mechanisms for DNS(EDNS0)[S]. IETF RFC2671. 1999.

[31] VIXIE P, KATO A, ABLEY J. DNS response size issues[R]. 2014.

[32] ARENDS R. Protocol modifications for the DNS security extensions[S]. IETF RFC4035. 2005.

[33] BELLIS R. DNS transport over TCP-implementation requirements[S]. IETF RFC5966. 2010.

[34] DEERING S, HINDEN R. Internet protocol, version 6 (IPv6) Specification[S]. RFC2460. 1998.

[35] [EB/OL]https://www.icann.org/resources/pages/rssac-caucus-2014-05-06-en.

[36] ICANN. Overview and history of the IANA functions[N]. 2014.

[37] [EB/OL]http://tools.ietf.org/wg/dnsop.

[38] KUMARI W, HOFFMAN P. Decreasing access time to root servers by running one on loopback[R]. 2015.

[39] LEE X D, VIXIE P, YAN Z W. How to scale the DNS root system?[R]. 2014.

[40] OHTA M. Distributing root name servers via shared unicast addresses[R]. 1999.

[41] SATO S, MATSUURA T, MORISHITA Y. BGP anycast node requirements for authoritative name servers[R]. 2007.

[42] BUSH R, KARRENBERG D, KOSTERS M, et al. Root name server operational requirements[S]. IETF RFC2870, 2000.

[43] Identifying and characterizing anycast in the domain name system[R]. USC/ISI Technical Report. 2011.

[44] WANG W, YAN Z W. A survey of the DNS cache service in China[J]. Modern Preventive Medicine, 2015.

[45] COX R, MUTHITACHAROEN A, MORRIS R T. Serving DNS using a peer-to-peer lookup service[C]//The International Workshop on Peer-to-Peer Systems. 2002.

[46] MUELLER M L. Competing DNS roots: creative destruction or just plain destruction[C]//Research Conference on Communication, Information. 2001.

[47] IAB. IAB technical comment on the unique DNS root[S]. IETF RFC2826, 2000.

Study on the development of the DNS root system

YAN Zhi-wei1,2, GENG Guang-gang1,2, LI Hong-tao1,2, LI Xiao-dong1,2
(1. China Internet Network Information Center, Beijing 100190, China; 2. National Engineering Laboratory for Internet Domain Name Management, Beijing 100190, China)

The development history of the DNS root system was described and the management of the DNS root service was explained in detail. Based on the shortcomings on efficiency, scalability and stability of the current DNS root server management model, the extension schemes from both policy and technology points of views were summarized and analyzed.

domain name, root system, anycast, ubiquitous DNS root service

TP391

A

10.11959/j.issn.2096-109x.2017.00150

延志偉（1985-），男，山西興縣人，博士，中國互聯(lián)網(wǎng)絡信息中心副研究員，主要研究方向為IPv6移動性管理、BGP安全機制、信息中心網(wǎng)絡架構。

耿光剛（1980-），男，山東泰安人，博士，中國互聯(lián)網(wǎng)絡信息中心研究員，主要研究方向為機器學習、大數(shù)據(jù)分析和互聯(lián)網(wǎng)基礎資源安全。

李洪濤（1977-），男，河北保定人，中國互聯(lián)網(wǎng)絡信息中心高級工程師，主要研究方向為IPv6、網(wǎng)絡安全、大數(shù)據(jù)。

李曉東（1976-），男，山東菏澤人，博士，中國互聯(lián)網(wǎng)絡信息中心研究員，主要研究方向為互聯(lián)網(wǎng)基礎資源管理及網(wǎng)絡安全技術。

2016-12-12；

2017-02-11。通信作者：耿光剛，gengguanggang@cnnic.cn

國家自然科學基金資助項目（No.61375039, No.61303242）

Foundation Item: The National Natural Science Foundation of China (No.61375039, No.61303242)