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

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

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

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

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

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

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

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

1 引言

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

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

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

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

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

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

表1 根服務(wù)器主要情況

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

2 DNS根服務(wù)體系管理模式

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

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

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

圖1 域名體系管理模式

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

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

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

3 DNS根服務(wù)器擴(kuò)展分析

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

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

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

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

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

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

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

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

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

3.2 BGP路由收斂開銷

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

3.3 解析性能探測與分析

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

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

圖3 根服務(wù)器平均解析時(shí)延

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

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

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

圖4 F節(jié)點(diǎn)解析時(shí)延

圖5 中國境內(nèi)F鏡像節(jié)點(diǎn)命中情況

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

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

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

圖6 J節(jié)點(diǎn)解析時(shí)延

圖7 中國境內(nèi)J鏡像節(jié)點(diǎn)命中情況

4 根服務(wù)器擴(kuò)展原則

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

1) 去中心化

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

2) 本地化

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

3) 可擴(kuò)展性

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

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

5 DNS根服務(wù)器擴(kuò)展方案

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

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

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

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

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

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

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

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

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

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

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

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

5.3 泛在DNS根服務(wù)體系

結(jié)合 DNS根服務(wù)體系演進(jìn)原則以及當(dāng)前解決方案的方向，本文提出一種泛在DNS根服務(wù)體系，如圖8所示。

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

圖8 泛在DNS根服務(wù)體系

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

1) 基于HINT RR的服務(wù)宣告

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

Zone Lifetime IN HINT Server-name

Zone標(biāo)識這個(gè)泛在DNS根服務(wù)器的作用范圍，如CN標(biāo)識在中國范圍，baidu.com標(biāo)識在百度的內(nèi)部網(wǎng)絡(luò)。

Lifetime標(biāo)識這個(gè)資源記錄的有效生存期。

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

HINT標(biāo)識這條資源記錄用于記錄該區(qū)域內(nèi)的泛在DNS根服務(wù)器。

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

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

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

② db.root.only.local：單獨(dú)維護(hù)和啟用泛在DNS根服務(wù)器。

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

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

6 結(jié)束語

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

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

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

[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)絡(luò)信息中心.中國域名服務(wù)安全狀況與態(tài)勢分析報(bào)告[R]. 2014. China Internet Network Information Center. Chinese domain name service security situation and trend analysis report[R] .2014.

[21] 中國互聯(lián)網(wǎng)絡(luò)信息中心. 第35次中國互聯(lián)網(wǎng)絡(luò)發(fā)展?fàn)顩r統(tǒng)計(jì)報(bào)告[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)絡(luò)信息中心副研究員，主要研究方向?yàn)镮Pv6移動(dòng)性管理、BGP安全機(jī)制、信息中心網(wǎng)絡(luò)架構(gòu)。

耿光剛（1980-），男，山東泰安人，博士，中國互聯(lián)網(wǎng)絡(luò)信息中心研究員，主要研究方向?yàn)闄C(jī)器學(xué)習(xí)、大數(shù)據(jù)分析和互聯(lián)網(wǎng)基礎(chǔ)資源安全。

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

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

2016-12-12；

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

國家自然科學(xué)基金資助項(xiàng)目（No.61375039, No.61303242）

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