何崢，冷峰，張翠玲

在DNSSEC下保障頂級(jí)域名解析托管服務(wù)穩(wěn)定遷移的操作機(jī)制

何崢，冷峰，張翠玲

（中國(guó)互聯(lián)網(wǎng)絡(luò)信息中心，北京 100190）

基于頂級(jí)域解析服務(wù)托管平臺(tái)遷移部署實(shí)踐，重點(diǎn)研究分析了在DNSSEC環(huán)境下，為避免發(fā)生域名系統(tǒng)安全擴(kuò)展（DNSSEC，DNS security extension）信任鏈及解析服務(wù)中斷、域名NS記錄不一致等安全問題，如何在密鑰輪轉(zhuǎn)、DS和NS記錄變更、數(shù)據(jù)更新等環(huán)節(jié)中實(shí)現(xiàn)新舊服務(wù)托管商及互聯(lián)網(wǎng)數(shù)字分配機(jī)構(gòu)（IANA，internet assigned numbers authority）之間進(jìn)行解析服務(wù)平臺(tái)的遷移，并對(duì)平臺(tái)遷移操作的關(guān)鍵點(diǎn)進(jìn)行了詳細(xì)分析，提出了在解析托管服務(wù)遷移過程中能夠保證業(yè)務(wù)連續(xù)性的遷移機(jī)制。

DNS系統(tǒng)；DNS安全擴(kuò)展系統(tǒng)；密鑰輪轉(zhuǎn)；域名解析；信任鏈

1 引言

隨著域名系統(tǒng)（DNS，domain name system）的發(fā)展及應(yīng)用，許多安全漏洞逐步暴露出來，域名系統(tǒng)成為互聯(lián)網(wǎng)黑客們有針對(duì)性的安全攻擊對(duì)象，出現(xiàn)了DNS緩存污染、DNS放大攻擊及域名欺騙等針對(duì)域名服務(wù)器的攻擊事件。頂級(jí)域名服務(wù)托管是域名注冊(cè)管理局將頂級(jí)域的五大核心服務(wù)托管至具備較強(qiáng)技術(shù)能力和擁有穩(wěn)定平臺(tái)的域名平臺(tái)托管機(jī)構(gòu)，確保該頂級(jí)域的服務(wù)更加穩(wěn)定安全。當(dāng)托管平臺(tái)遭遇物理和網(wǎng)絡(luò)攻擊，造成域名解析平臺(tái)能力和穩(wěn)定性無法滿足域名注冊(cè)管理局的要求時(shí)，注冊(cè)管理機(jī)構(gòu)將被動(dòng)更換域名托管機(jī)構(gòu)，因此變更域名托管機(jī)構(gòu)是不可避免的。隨著2010年DNSSEC（DNS security extension）[1]逐步在全球13個(gè)根服務(wù)器和頂級(jí)域名服務(wù)器上進(jìn)行部署實(shí)施，2012年互聯(lián)網(wǎng)名稱與數(shù)字地址分配機(jī)構(gòu)（ICANN，Internet Corporation for Assigned Names and Numbers）開放申請(qǐng)的新通用頂級(jí)域也把支持DNSSEC協(xié)議作為準(zhǔn)入門檻，這樣極大地增加了域名管理機(jī)構(gòu)遷移域名托管平臺(tái)的復(fù)雜程度，因此在DNSSEC環(huán)境下遷移域名解析服務(wù)成為一個(gè)非常棘手的問題。目前，國(guó)內(nèi)乃至國(guó)際上的域名服務(wù)機(jī)構(gòu)都在積極開展相關(guān)技術(shù)研究，探索遷移解決方案，而在DNSSEC環(huán)境下遷移域名解析服務(wù)的成功案例并不多見。本文結(jié)合頂級(jí)域遷移的需求，將頂級(jí)域解析服務(wù)更換注冊(cè)局后臺(tái)托管機(jī)構(gòu)（BERO，Backend Registry Operator）過程定義了5個(gè)階段，重點(diǎn)分析了在5個(gè)階段中可能出現(xiàn)的3個(gè)關(guān)鍵性問題，提出了有效的解決方案，并結(jié)合實(shí)踐經(jīng)驗(yàn)，提出了一種在DNSSEC下保障頂級(jí)域名解析托管服務(wù)穩(wěn)定遷移的操作機(jī)制。

2 背景

2.1 域名系統(tǒng)及域名托管機(jī)構(gòu)介紹

域名系統(tǒng)是互聯(lián)網(wǎng)運(yùn)行的關(guān)鍵基礎(chǔ)設(shè)施和“中樞神經(jīng)系統(tǒng)”。DNS通過域名與IP地址之間的對(duì)應(yīng)關(guān)系（域名解析，簡(jiǎn)稱解析），為人們提供基于互聯(lián)網(wǎng)的通信服務(wù)。域名系統(tǒng)采用倒置的樹形結(jié)構(gòu)自頂向下構(gòu)建名稱，通過分級(jí)授權(quán)、各域自治的方式進(jìn)行管理。根位于DNS分層結(jié)構(gòu)的頂部，是DNS的解析服務(wù)的起點(diǎn)與DNSSEC信任鏈的信任錨點(diǎn)；其下依次是頂級(jí)域（如“.CN”“.COM”等）及其二級(jí)域、三級(jí)域等?；ヂ?lián)網(wǎng)用戶一般通過為其提供DNS查詢的遞歸解析服務(wù)商獲得所需的訪問信息。

注冊(cè)局后臺(tái)托管機(jī)構(gòu)指為某個(gè)頂級(jí)域（TLD，top level domain）注冊(cè)管理局持續(xù)提供關(guān)鍵域名注冊(cè)管理功能的運(yùn)維機(jī)構(gòu)，保障該頂級(jí)域正常解析，確保終端用戶的正常訪問，與TLD注冊(cè)管理局是不同的組織。2012年，在ICANN推出新通用頂級(jí)域（NGTLD，new gTLD）業(yè)務(wù)（如圖1所示）后，要求域名平臺(tái)托管機(jī)構(gòu)具備以下5個(gè)職能：①提供托管頂級(jí)域的DNS解析服務(wù)；②提供托管頂級(jí)域的DNSSEC應(yīng)用服務(wù)；③提供托管頂級(jí)域的注冊(cè)系統(tǒng)；④提供托管頂級(jí)域的WHOIS查詢服務(wù)；⑤協(xié)調(diào)注冊(cè)管理機(jī)構(gòu)數(shù)據(jù)托管服務(wù)。

圖1 頂級(jí)域部署邏輯示意

Figure 1 TLD registry service framework

很多企業(yè)或組織雖然申請(qǐng)了自己的NGTLD，但并不具備持續(xù)提供頂級(jí)域五大業(yè)務(wù)職能的能力。這種情況下，注冊(cè)管理局可以將自己申請(qǐng)的NGTLD托管至具備提供上述五大職能的域名托管機(jī)構(gòu)的平臺(tái)上運(yùn)維，甚至可以托管至其他國(guó)家的域名托管機(jī)構(gòu)。

正如互聯(lián)網(wǎng)早期的許多協(xié)議一樣，DNS協(xié)議在設(shè)計(jì)時(shí)缺乏對(duì)安全問題的考慮。所以，隨著DNS不斷發(fā)展和應(yīng)用的增長(zhǎng)，暴露了許多安全漏洞，逐漸成為互聯(lián)網(wǎng)黑客們有針對(duì)性的安全攻擊對(duì)象，出現(xiàn)了DNS緩存污染、DNS放大攻擊和洪泛攻擊、DNS動(dòng)態(tài)更新攻擊及域名欺騙等攻擊方式。例如，2008年7月，美國(guó)IOActive網(wǎng)絡(luò)安全公司的計(jì)算機(jī)安全研究專家Kaminsky公布了DNS系統(tǒng)的一個(gè)非常嚴(yán)重的漏洞，該漏洞會(huì)導(dǎo)致攻擊者輕松地偽造如Google、Gmail等網(wǎng)站，黑客利用該DNS漏洞可能在10 s內(nèi)發(fā)起一個(gè)“DNS Cache Posion”（DNS緩存中毒）攻擊，利用被攻擊的DNS服務(wù)器能夠?qū)⒂脩粢龑?dǎo)到惡意網(wǎng)站，這就是著名的“Kaminsky事件”[2]。由于DNS系統(tǒng)極易遭受攻擊，這樣會(huì)造成域名管理機(jī)構(gòu)變更域名托管機(jī)構(gòu)的情況。

2.2 DNSSEC的發(fā)展背景

域名系統(tǒng)安全擴(kuò)展為DNS提供了一種來源鑒定和數(shù)據(jù)完整性的擴(kuò)展，支持對(duì)數(shù)據(jù)源及事務(wù)和請(qǐng)求的認(rèn)證功能，從而在一定程度上遏制了針對(duì)域名系統(tǒng)的網(wǎng)絡(luò)攻擊。1995年，國(guó)際互聯(lián)網(wǎng)工程任務(wù)組（IETF，The Internet Engineering Task Force）開始組織DNSSEC協(xié)議制定活動(dòng)，由Vixie牽頭完成了RFC2065[3]和RFC2535[4]的發(fā)布，通過使用對(duì)稱密鑰實(shí)現(xiàn)了事務(wù)級(jí)的數(shù)據(jù)簽名，標(biāo)志著DNSSEC 協(xié)議已全部完成，BIND9 的開發(fā)主要用于支持DNSSEC協(xié)議。2005年發(fā)布的RFC4033-4035[5-7]提出了DNSSEC，定義了DNSSEC協(xié)議使用公鑰加密的PKI體系，在DNS的授權(quán)層級(jí)中附加了一層認(rèn)證鏈，利用DNS授權(quán)形成的“父子”關(guān)系，構(gòu)建了信任鏈，實(shí)現(xiàn)了基于非對(duì)稱密鑰的DNS數(shù)據(jù)簽名。

DNSSEC在原有DNS系統(tǒng)的基礎(chǔ)上，引入了4種主要的新記錄類型：DNSKEY、DS、RRSIG、NSEC/NSEC3[8]。其中前3種記錄類型為了模仿PKI系統(tǒng)在DNS中加入信任鏈。最后一種記錄為了滿足DNS服務(wù)的特殊需求，驗(yàn)證“數(shù)據(jù)不存在”應(yīng)答的有效性。

由圖2可見，DS記錄由父區(qū)發(fā)布，DNSKEY和RRSIG簽名記錄由子區(qū)發(fā)布。父區(qū)和子區(qū)之間通過DS記錄和DNSKEY記錄產(chǎn)生關(guān)聯(lián)，構(gòu)成信任鏈的一環(huán)。這個(gè)信任鏈條的初始是信任錨，即認(rèn)為信任錨是可信的，無須其他驗(yàn)證。在DNS中，這個(gè)信任錨可以是任一DS記錄或DNSKEY記錄，通常設(shè)置為根區(qū)的DS記錄或DNSKEY記錄。

圖2 DNSSEC信任鏈?zhǔn)疽?/p>

Figure 2 DNSSEC trust chain

由于DNSSEC的部署涉及軟件實(shí)現(xiàn)的變更，以及服務(wù)部署的復(fù)雜性，在其被提出的最初幾年并沒有引起研究人員廣泛的興趣和重視。然而，隨著2008年卡明斯基漏洞的公布，DNSSEC的部署顯得迫在眉睫，極大地推動(dòng)了DNSSEC相關(guān)協(xié)議的軟件實(shí)現(xiàn)及服務(wù)部署。全球13個(gè)根服務(wù)器是最早部署實(shí)施DNSSEC協(xié)議的域名服務(wù)器[9]，頂級(jí)域名服務(wù)器也大多部署實(shí)施了DNSSEC，2012年ICANN開放申請(qǐng)的新通用頂級(jí)域把支持DNSSEC協(xié)議作為準(zhǔn)入門檻。截至2020年1月，根區(qū)數(shù)據(jù)文件中頂級(jí)域名數(shù)量為1 514個(gè)，其中，1 385個(gè)已使用DNSSEC協(xié)議簽名，1 375個(gè)在根區(qū)中發(fā)布了DS 記錄[10]，其中1 235個(gè)是新gTLD[11]。國(guó)內(nèi)學(xué)者、國(guó)家域名注冊(cè)管理機(jī)構(gòu)以及運(yùn)營(yíng)商對(duì)DNSSEC的部署和實(shí)施進(jìn)行了研究[12-14]。

隨著云計(jì)算、大數(shù)據(jù)、人工智能、物聯(lián)網(wǎng)和5G等新技術(shù)出現(xiàn)，各種互聯(lián)網(wǎng)應(yīng)用層出不窮，對(duì)于域名系統(tǒng)這一互聯(lián)網(wǎng)基礎(chǔ)設(shè)施的服務(wù)穩(wěn)定性要求越來越高，因此如何避免由于在DNSSEC環(huán)境下變更域名托管平臺(tái)而造成頂級(jí)域名解析服務(wù)中斷的可能，將變成十分棘手的問題。下一節(jié)將詳細(xì)分析域名解析服務(wù)的變更過程中可能遇到的問題。

3 頂級(jí)域名變更BERO的問題分析

本節(jié)基于新通用頂級(jí)域在DNSSEC背景下進(jìn)行解析服務(wù)更換BERO的過程，指出并分析解析服務(wù)更換BERO過程中可能遇到的問題。

3.1 頂級(jí)域解析服務(wù)變更BERO的過程

本文主要討論基于DNSSEC背景下的新通用頂級(jí)域解析服務(wù)更換BERO的過程。遷移過程涉及TLD遷出方、TLD遷入方及ICANN的IANA機(jī)構(gòu)這3個(gè)角色，為了確保整個(gè)遷移過程中對(duì)數(shù)據(jù)一致性、DNSSEC信任鏈完整性、服務(wù)連續(xù)性的要求，3個(gè)角色的操作耦合比較緊密，需要相互配合完成。本文將新通用頂級(jí)域解析服務(wù)更換BERO的過程定義了5個(gè)階段（狀態(tài)）。

（1）新DNSKEY記錄發(fā)布前（狀態(tài)1）

（2）根區(qū)發(fā)布新DS記錄后（狀態(tài)2）

發(fā)布新DS記錄之前，根區(qū)只有原BERO的DS記錄；發(fā)布新DS記錄后，根區(qū)中有新舊BERO的DS記錄，標(biāo)志著新DNSKEY將參與到信任鏈的驗(yàn)證中。這個(gè)階段為新簽名數(shù)據(jù)的生效做好準(zhǔn)備。

（3）新BERO刪除原NS記錄后（狀態(tài)3）

刪除原NS記錄之前，新BERO的權(quán)威服務(wù)器上有兩組NS記錄；刪除原NS記錄后，新BERO的權(quán)威服務(wù)器上有1組NS記錄。這個(gè)階段是在為原BERO的權(quán)威服務(wù)器退出解析系統(tǒng)做準(zhǔn)備，訪問至新BERO的客戶端將不再獲取到原NS記錄。

（4）根區(qū)刪除原NS記錄后（狀態(tài)4）

刪除原NS記錄之前，互聯(lián)網(wǎng)用戶會(huì)看到兩組NS記錄，新舊BERO的權(quán)威服務(wù)器都將收到查詢；刪除原NS記錄開始，等待TTL時(shí)長(zhǎng)之后，互聯(lián)網(wǎng)用戶將看不到原NS記錄，標(biāo)志著原BERO的NS服務(wù)器正式退出解析系統(tǒng)。

（5）根區(qū)刪除原DS記錄后（狀態(tài)5）

刪除原DS記錄之前，根區(qū)中有兩條DS記錄；刪除原DS記錄之后，根區(qū)中只保留新BERO的DS記錄。這是遷移操作的一個(gè)收尾步驟，將已不再使用的原DS記錄從解析系統(tǒng)中徹底刪除。

3.2 變更BERO遇到的主要問題

3.2.1 遷移期間DNSSCE信任鏈完整性問題

在基于DNSSEC環(huán)境下的域名頂級(jí)域平臺(tái)托管機(jī)構(gòu)遷移，增加了確保DNSSEC信任鏈完整性的要求。頂級(jí)域注冊(cè)管理局在變更域名平臺(tái)托管機(jī)構(gòu)時(shí)，新舊域名頂級(jí)域平臺(tái)將持有各自的私鑰，且不會(huì)共享彼此的私鑰。私鑰用于對(duì)域名區(qū)文件中的權(quán)威數(shù)據(jù)進(jìn)行簽名，對(duì)于頂級(jí)域來說，權(quán)威數(shù)據(jù)通常包括SOA、NS、DS記錄等。當(dāng)區(qū)文件中的權(quán)威數(shù)據(jù)發(fā)生變化時(shí)，需要對(duì)變化的數(shù)據(jù)進(jìn)行簽名。域名頂級(jí)域平臺(tái)的更換增加了這類操作的復(fù)雜性。一方面，因?yàn)槌钟信f密鑰和新密鑰的是兩個(gè)不同的單位，他們之間不能共享彼此的私鑰，另一方面，為了保證數(shù)據(jù)的簽名始終可以通過驗(yàn)證，必須有舊平臺(tái)托管機(jī)構(gòu)的配合及簽名時(shí)的流程與技術(shù)保障，否則DNSSEC信任鏈將中斷，無法保證在DNSSEC背景下頂級(jí)域名遷移信任鏈的完整性。

3.2.2 遷移期間解析服務(wù)的連續(xù)性問題

解析服務(wù)的連續(xù)性是衡量域名平臺(tái)托管機(jī)構(gòu)提供的域名服務(wù)是否穩(wěn)定的關(guān)鍵指標(biāo)。因此在變更域名平臺(tái)托管機(jī)構(gòu)的過程中，每一步操作都要確保解析服務(wù)的連續(xù)性。變更操作涉及的都是權(quán)威服務(wù)器，所以往往會(huì)忽略對(duì)遞歸服務(wù)器端的影響，特別是新NS記錄的生效時(shí)間、解析數(shù)據(jù)的TTL、遞歸緩存數(shù)據(jù)過期等問題，這些都會(huì)直接或間接影響解析服務(wù)的連續(xù)性和可用性。負(fù)責(zé)根區(qū)解析服務(wù)的IANA將遷移過程中解析服務(wù)的連續(xù)性和DNSSEC信任鏈完整性作為關(guān)鍵的技術(shù)檢查內(nèi)容，避免對(duì)互聯(lián)網(wǎng)的穩(wěn)定運(yùn)行造成嚴(yán)重影響。

3.2.3 遷移期間TLD數(shù)據(jù)一致性問題

頂級(jí)域注冊(cè)管理機(jī)構(gòu)在變更BERO時(shí)，需要遷移域名注冊(cè)服務(wù)、域名目錄查詢服務(wù)、域名解析服務(wù)、DNSSEC服務(wù)及數(shù)據(jù)托管服務(wù)5部分。由于涉及內(nèi)容較多，因此更換BERO至少需要一個(gè)月。域名管理機(jī)構(gòu)為了減小對(duì)其服務(wù)造成的影響，往往采用分步遷移的方式進(jìn)行，即先完成注冊(cè)服務(wù)、查詢服務(wù)和數(shù)據(jù)托管服務(wù)的遷移，再進(jìn)行解析服務(wù)和DNSSEC服務(wù)的遷移工作。為縮短解析服務(wù)的中斷時(shí)間，極有可能在新BERO與原BERO同時(shí)提供服務(wù)的情況下，完成注冊(cè)服務(wù)的遷移。在解析服務(wù)未成功遷移至新托管機(jī)構(gòu)前，開通注冊(cè)服務(wù)會(huì)導(dǎo)致頂級(jí)域數(shù)據(jù)更新，極易造成新舊托管機(jī)構(gòu)的解析數(shù)據(jù)不一致，這樣會(huì)對(duì)互聯(lián)網(wǎng)用戶造成嚴(yán)重的影響。因此必須考慮如何解決新BERO與原BERO解析數(shù)據(jù)一致性的問題。

4 變更BERO的實(shí)施機(jī)制

4.1 提交新舊DS記錄并預(yù)發(fā)布新DNSKEY

在DNSSEC背景下頂級(jí)域更換BERO的過程中，向IANA提交新舊托管機(jī)構(gòu)私鑰所生成的DS記錄和預(yù)發(fā)布新DNSKEY記錄并加入?yún)^(qū)文件這兩步尤為關(guān)鍵，將直接影響DNSSEC信任鏈的完整性。

首先，為了保證在頂級(jí)域解析服務(wù)遷移過程的DNSSEC信任鏈不中斷，必須在新舊托管平臺(tái)上使用各自的私鑰對(duì)SOA、NS、DNSKEY進(jìn)行簽名；然后，向IANA提交新舊DS記錄且生效后，再進(jìn)行更換NS和更換密鑰等過程。對(duì)于更換密鑰的操作來說，類似密鑰輪轉(zhuǎn)操作，要解決的關(guān)鍵問題是，任何時(shí)間點(diǎn)遞歸緩存的數(shù)據(jù)都能滿足如下兩個(gè)條件：

1) 多組密鑰及多組簽名中，至少有一組是對(duì)應(yīng)的；

2) 多組密鑰及多組摘要中，至少有一組是對(duì)應(yīng)的。

密鑰輪轉(zhuǎn)常見的兩種方式是預(yù)發(fā)布和雙簽。本文采用的是預(yù)發(fā)布的密鑰輪轉(zhuǎn)方式，雙簽方式需要簽名方同時(shí)掌握新舊兩套私鑰。因頂級(jí)域更換BERO時(shí)無法共享密鑰，所以不能采用雙簽的輪轉(zhuǎn)方式，只能采用預(yù)發(fā)布方式。預(yù)發(fā)布方式指先在區(qū)文件中添加新的DNSKEY記錄，確認(rèn)遞歸中緩存的舊數(shù)據(jù)失效后，再用新DNSKEY對(duì)應(yīng)的私鑰對(duì)數(shù)據(jù)進(jìn)行簽名，并替換區(qū)文件中的簽名。

接下來將結(jié)合圖3對(duì)上述內(nèi)容進(jìn)行具體的分析。

處于狀態(tài)1時(shí)，權(quán)威服務(wù)器發(fā)布的數(shù)據(jù)是一組DNSKEY、一組RRSIG和一組DS。其中DNSKEY-A是可以驗(yàn)證RRSIG-A的公鑰，DS-A是DNSKEY-A的摘要。DS-AàDNSKEY-Aà RRSIG-A構(gòu)成了信任鏈的一部分，而且可以用于驗(yàn)證。

處于狀態(tài)2時(shí)，權(quán)威服務(wù)器發(fā)布的數(shù)據(jù)是兩組DNSKEY、一組RRSIG和兩組DS。其中DNSKEY-A是可以驗(yàn)證RRSIG-A的公鑰，DNSKEY-B是預(yù)發(fā)布的公鑰，計(jì)劃將來使用。DS-A是DNSKEY-A的摘要，DS-B是DNSKEY-B的摘要。DS-AàDNSKEY-AàRRSIG-A構(gòu)成了信任鏈的一部分，而且可以用于驗(yàn)證。DS-BàDNSKEY-B也構(gòu)成了信任鏈的一部分，但由于沒有對(duì)應(yīng)的RRSIG記錄，所以這條信任鏈暫時(shí)無法驗(yàn)證通過。

遞歸服務(wù)器可能緩存的數(shù)據(jù)如表1所示。如果某個(gè)數(shù)據(jù)未被緩存或已過期，在取回新數(shù)據(jù)后，可以對(duì)應(yīng)至其中一種情況。針對(duì)表1中的4種情況，能夠驗(yàn)證通過的信任鏈只有一種可能：DS-AàDNSKEY-AàRRSIG-A。

圖3 更換BERO示意

Figure 3 Procedures of changing BERO

表1 狀態(tài)1過渡至狀態(tài)2過程中遞歸服務(wù)器可能緩存的數(shù)據(jù)

處于狀態(tài)3時(shí)，由于BERO A和BERO B的權(quán)威服務(wù)器同時(shí)對(duì)外提供服務(wù)，數(shù)據(jù)可能存在一定時(shí)間的不同步。BERO A的NS服務(wù)器發(fā)布的數(shù)據(jù)是兩組DNSKEY、RRSIG-A和兩組DS，BERO B的NS服務(wù)器發(fā)布的數(shù)據(jù)是兩組DNSKEY、RRSIG-B和兩組DS。

遞歸服務(wù)器可能緩存的數(shù)據(jù)如表2所示。如果某個(gè)數(shù)據(jù)未被緩存或已過期，在取回新數(shù)據(jù)后，可以對(duì)應(yīng)至其中一種情況。針對(duì)表2中的情況1，能夠驗(yàn)證通過的信任鏈?zhǔn)荄S-AàDNSKEY-Aà RRSIG-A；情況2，能夠驗(yàn)證通過的信任鏈?zhǔn)荄S-BàDNSKEY-BàRRSIG-B。

表2 狀態(tài)2過渡至狀態(tài)3過程中遞歸服務(wù)器可能緩存的數(shù)據(jù)

需要注意的是，如果在狀態(tài)2等待的理論時(shí)間需要大于一個(gè)TTL周期，實(shí)際情況考慮網(wǎng)絡(luò)時(shí)延情況應(yīng)大于2~3個(gè)TTL周期，否則在狀態(tài)3遞歸可能緩存的數(shù)據(jù)如表3所示。如果某個(gè)數(shù)據(jù)未被緩存或已過期，在取回新數(shù)據(jù)后，可以對(duì)應(yīng)其中一種情況。針對(duì)表3中的情況1、情況2，能夠驗(yàn)證通過的信任鏈?zhǔn)荄S-AàDNSKEY-AàRRSIG-A；情況3，能夠驗(yàn)證通過的信任鏈?zhǔn)荄S-BàDNSKEY-Bà RRSIG-B；情況4，信任鏈無法驗(yàn)證通過。可見狀態(tài)2的等待操作是必要的。

處于狀態(tài)4時(shí)，權(quán)威服務(wù)器發(fā)布的數(shù)據(jù)是兩組DNSKEY、一組RRSIG和兩組DS。其中DNSKEY-B是可以驗(yàn)證RRSIG-B的公鑰，DNSKEY-A是待清除的公鑰。DS-A是DNSKEY-A的摘要，DS-B是DNSKEY-B的摘要。DS-AàDNSKEY-A構(gòu)成了信任鏈的一部分，但由于沒有對(duì)應(yīng)的RRSIG，所以這條信任鏈無法驗(yàn)證通過。DS-BàDNSKEY-BàRRSIG-B也構(gòu)成了信任鏈的一部分，而且可以用于驗(yàn)證。

表3 進(jìn)入狀態(tài)3遞歸服務(wù)器可能緩存的數(shù)據(jù)

狀態(tài)3過渡至狀態(tài)4過程中遞歸服務(wù)器可能緩存的數(shù)據(jù)只有一種情況，如表4所示。如果某個(gè)數(shù)據(jù)未被緩存或已過期，在取回新數(shù)據(jù)后，也是對(duì)應(yīng)這種情況。能夠驗(yàn)證通過的信任鏈?zhǔn)荄S-Bà DNSKEY-BàRRSIG-B。

處于狀態(tài)5時(shí)，權(quán)威服務(wù)器發(fā)布的數(shù)據(jù)是一組DNSKEY、一組RRSIG和一組DS。其中DNSKEY-B是可以驗(yàn)證RRSIG的公鑰，DS-B是DNSKEY-B的摘要。DS-BàDNSKEY-Bà RRSIG-B構(gòu)成了信任鏈的一部分，而且可以用于驗(yàn)證。

狀態(tài)4過渡至狀態(tài)5過程中遞歸服務(wù)器可能緩存的數(shù)據(jù)如表5所示。如果某個(gè)數(shù)據(jù)未被緩存或已過期，在取回新數(shù)據(jù)后，可以對(duì)應(yīng)至其中一種情況。針對(duì)表5中的4種情況，能夠驗(yàn)證通過的信任鏈只有一種可能：DS-BàDNSKEY-Bà RRSIG-B。

需要注意的是，如果在狀態(tài)4等待的理論時(shí)間需要大于一個(gè)TTL周期，實(shí)際情況考慮網(wǎng)絡(luò)時(shí)延情況應(yīng)大于2~3個(gè)TTL周期，否則在狀態(tài)5遞歸可能緩存的數(shù)據(jù)如表6所示。如果某個(gè)數(shù)據(jù)未被緩存或已過期，在取回新數(shù)據(jù)后，可以對(duì)應(yīng)其中一種情況。針對(duì)表6中的情況1、情況2，能夠驗(yàn)證通過的信任鏈?zhǔn)荄S-Aà DNSKEY-AàRRSIG-A；情況5、情況6，能夠驗(yàn)證通過的信任鏈?zhǔn)荄S-BàDNSKEY-Bà RRSIG-B；情況3、情況4，信任鏈無法驗(yàn)證通過?？梢?，在沒有做數(shù)據(jù)反向同步的情況下，狀態(tài)4的等待操作是必要的。

通過上述分析可知，在保證等待時(shí)間的理論時(shí)間大于一個(gè)TTL周期，實(shí)際考慮網(wǎng)絡(luò)時(shí)延情況應(yīng)大于2~3個(gè)TTL周期的前提下，在遷移的各個(gè)階段，都能保證至少有一條信任鏈可通過驗(yàn)證，從而保證了DNSSEC背景下域名更換BERO的信任鏈完整性。

4.2 提交新舊NS記錄并寫入?yún)^(qū)文件

由于遞歸服務(wù)器具有緩存功能，其無法實(shí)時(shí)獲知根區(qū)和頂級(jí)域權(quán)威服務(wù)器的數(shù)據(jù)變更。為保證解析服務(wù)的連續(xù)性，應(yīng)該在新BERO的NS記錄加入頂級(jí)域和根區(qū)的解析系統(tǒng)期間，以及在IANA刪除原BERO的NS記錄之后一段時(shí)間，原BERO的權(quán)威服務(wù)器持續(xù)在線并正常提供服務(wù)。

變更NS記錄的操作步驟，與DNSSEC密鑰輪轉(zhuǎn)中的雙簽操作類似。初始狀態(tài)為原BERO的權(quán)威服務(wù)器單獨(dú)提供服務(wù)；然后，新BERO的權(quán)威服務(wù)器上線，將NS記錄添加至頂級(jí)域和根區(qū)，此時(shí)原BERO和新BERO同時(shí)在線提供服務(wù)，這個(gè)階段需要等待大于一個(gè)TTL周期，即頂級(jí)域和根區(qū)中該NS的TTL為最大值，才能進(jìn)入下一階段；最后，從頂級(jí)域和根區(qū)中刪除原BERO的NS記錄，完成此操作后，在保證等待理論時(shí)間大于一個(gè)TTL周期，實(shí)際考慮網(wǎng)絡(luò)時(shí)延情況應(yīng)大于2~3個(gè)TTL周期，確保兩組權(quán)威服務(wù)器均能正常提供服務(wù)。需要注意的是，增加新BERO的NS記錄和刪除原BERO的NS記錄時(shí)，一定要按照先操作頂級(jí)域再操作根區(qū)的順序進(jìn)行。

表5 狀態(tài)4過渡至狀態(tài)5過程中遞歸服務(wù)器可能緩存的數(shù)據(jù)

表6 進(jìn)入狀態(tài)3遞歸服務(wù)器可能緩存的數(shù)據(jù)

考慮到ICANN要對(duì)EBRO提交的NS記錄進(jìn)行技術(shù)檢測(cè)，因此新舊NS記錄在根區(qū)文件中生效一般需要5~7天。只有根區(qū)完成新舊NS記錄加載后，才能進(jìn)行新舊EBRO的遷移，否則可能出現(xiàn)服務(wù)中斷的情況。

4.3 保證新舊托管平臺(tái)DNS數(shù)據(jù)文件實(shí)時(shí)更新

基于實(shí)驗(yàn)得出，遷移域名托管平臺(tái)至少需要持續(xù)一個(gè)月的時(shí)間才能順利完成。域名管理機(jī)構(gòu)為了減小對(duì)其服務(wù)造成的影響，往往采用分步遷移的方式進(jìn)行，即先完成注冊(cè)服務(wù)、查詢服務(wù)和數(shù)據(jù)托管服務(wù)的遷移，再進(jìn)行解析服務(wù)和DNSSEC服務(wù)的遷移工作，這樣會(huì)出現(xiàn)大量變更的解析數(shù)據(jù)。為了避免發(fā)生新舊托管機(jī)構(gòu)的解析數(shù)據(jù)不一致的情況，建議采用簡(jiǎn)單有效的DNS區(qū)傳送更新的方式，將在此期間發(fā)生的數(shù)據(jù)變化同步到新舊托管平臺(tái)的DNS域名服務(wù)器。通常的做法是負(fù)責(zé)產(chǎn)生數(shù)據(jù)的一方通過DNS區(qū)傳送協(xié)議將最新的數(shù)據(jù)傳輸給另一方，產(chǎn)生數(shù)據(jù)的一方指的是維護(hù)注冊(cè)數(shù)據(jù)庫的一方，約定在IANA增加NS之前是原BERO，在IANA增加NS之后是新BERO，這個(gè)問題在有無DNSSEC背景的情況下均需考慮。這種狀態(tài)一直維持到舊NS記錄從區(qū)文件中刪除后且遞歸服務(wù)器緩存中舊的NS記錄已經(jīng)過期，才能中斷DNS數(shù)據(jù)更新。

4.4 DNSSEC背景下頂級(jí)域名解析服務(wù)更換BERO的實(shí)施過程

為了便于實(shí)際操作，本文以頂級(jí)域“ABC”為例，闡述在部署DNSSEC背景下，TLD更換BERO（主要涉及NS記錄、DNSKEY記錄和DS記錄）的具體操作步驟。

以頂級(jí)域ABC為例，原BERO A有臺(tái)NS服務(wù)器，其集合表示為NS-A，DNSSEC密鑰對(duì)應(yīng)的DNSKEY記錄為KSK-A、ZSK-A，其集合表示為DNSKEY-A，KSK-A對(duì)應(yīng)的根區(qū)中的DS記錄為DS-A；將BERO A更換為BERO B，B有臺(tái)NS服務(wù)器，其集合表示為NS-B，DNSSEC密鑰對(duì)應(yīng)的DNSKEY記錄為KSK-B，ZSK-B，其集合表示為DNSKEY-B，KSK-B對(duì)應(yīng)的根區(qū)中的DS記錄為DS-B。操作步驟如下。

（1）BERO A和BERO B：BERO B的全部NS服務(wù)器同BERO A的全部NS服務(wù)器建立數(shù)據(jù)同步關(guān)系，數(shù)據(jù)保持一致。

（2）BERO A：區(qū)數(shù)據(jù)中增加BERO B的NS記錄、DNSKEY記錄（包括KSK-A及ZSK-A）。

（3）注冊(cè)局：向IANA提交申請(qǐng)?jiān)黾覤ERO B的NS、DS記錄。

（4）IANA：IANA將BERO B的NS、DS記錄添加到根區(qū)數(shù)據(jù)中（等待TTL時(shí)間）。

（5）BERO B：使用BERO B的密鑰對(duì)區(qū)數(shù)據(jù)簽名，并反向同步數(shù)據(jù)（等待TTL時(shí)間）。

（6）BERO B：區(qū)數(shù)據(jù)中刪除BERO A的NS、DNSKEY記錄。

（7）注冊(cè)局：向IANA提交申請(qǐng)刪除BERO A的NS記錄。

（8）IANA：IANA將BERO A的NS記錄從根區(qū)數(shù)據(jù)中刪除（等待TTL時(shí)間）。

（9）注冊(cè)局：向IANA提交申請(qǐng)刪除BERO A的DS記錄。

（10）IANA：IANA將BERO A的DS記錄從根區(qū)數(shù)據(jù)中刪除（等待TTL時(shí)間）。

（11）BERO B：停止BERO B的NS服務(wù)器和BERO A的NS服務(wù)器的數(shù)據(jù)同步關(guān)系，遷移結(jié)束。

注：“等待TTL時(shí)間”中的TTL指根區(qū)及TLD區(qū)中相同記錄集TTL的最大值。

5 結(jié)束語

隨著ICANN新通用頂級(jí)域業(yè)務(wù)的展開，越來越多的頂級(jí)域名實(shí)現(xiàn)了DNSSEC部署，但近年來大量域名運(yùn)營(yíng)機(jī)構(gòu)遭遇網(wǎng)絡(luò)攻擊，造成其不能正常運(yùn)轉(zhuǎn)，出現(xiàn)了在實(shí)施DNSSEC的情況下更換BERO的情況。本文指出并分析了頂級(jí)域解析平臺(tái)遷移過程中可能遇到的DNSSEC信任鏈中斷、域名解析服務(wù)中斷、域名NS記錄不一致等安全問題和遷移過程中與根區(qū)數(shù)據(jù)交互的操作問題，提出了有效的解決方案和遷移操作機(jī)制，已成功應(yīng)用于“成信息”“息在線”“中文網(wǎng)”等十多個(gè)頂級(jí)域遷移的場(chǎng)景，實(shí)現(xiàn)了頂級(jí)域遷移過程中的解析服務(wù)可用性達(dá)到100%，且確保了頂級(jí)域的DNSSCE信任鏈完整性，并在實(shí)施過程中通過ICANN的全球解析服務(wù)監(jiān)測(cè)系統(tǒng)的服務(wù)可用性監(jiān)測(cè)。本文為頂級(jí)域管理機(jī)構(gòu)遷移解析平臺(tái)提供了一些經(jīng)驗(yàn)分享和實(shí)踐部署步驟。

[1] 苑朋朋, 王常青. DNS安全威脅及應(yīng)對(duì)措施研究[J]. 網(wǎng)絡(luò)空間安全, 2018, 9(5): 50-54.

YUAN P P, WANG C Q. Research on DNS security threats and countermeasures, 2018, 9(5): 50-54.

[2] KOLKMAN O, MEKKING W, GIEBEN R. RFC 6781: DNSSEC operational PRactices[S]. RFC IETF, 2012.

[3] EASTLAKE D. RFC 2065: domain name system security extensions[S]. RFC IETF, 1997.

[4] EASTLAKE D. RFC 2535: domain name system security extensions[S]. RFC IETF, 1999.

[5] AUSTEIN R, LARSON M. RFC 4033: DNS security introduction and requirements[S]. RFC IETF, 2005.

[6] ARENDS R, AUSTEIN R, LARSON M, et al. RFC4034: resource records for the dns security extensions[S]. RFC IETF, 2005.

[7] ARENDS R, AUSTEIN R, LARSON M, et al. RFC4035: protocol modifications for the dns security extensions[S]. RFC IETF, 2005.

[8] LAURIE B, SISSON G, ARENDS R, et al. RFC 5155: DNS security(DNSSEC) hashed authenticated denial of existence[S]. RFC IETF, 2003.

[9] Root DNSSEC update[EB].

[10] TLD DNSSEC report[EB].

[11] New gTLD program statistics[EB].

[12] 段海新. DNSSEC原理、配置與部署[J]. 中國(guó)教育網(wǎng)絡(luò), 2011, (6): 29-31.

DUAN H X. DNSSEC principle, configuration and deployment[J]. China Education Network, 2011, (6): 29-31.

[13] 段海新. DNSSEC原理、配置與部署（二）[J]. 中國(guó)教育網(wǎng)絡(luò), 2011, (7): 34-35.

DUAN H X. DNSSEC principle, configuration and deployment(2)[J]. China Education Network, 2011, (7): 34-35.

[14] 高二輝, 張躍冬, 何崢. DNSSEC技術(shù)原理及應(yīng)用研究[J]. 信息安全與技術(shù), 2013, (1): 10-15.

GAO E H, ZHANG Y D, HE Z. The principle and application research of DNSSEC[J]. Information Security and Technology, 2013, (1): 10-15.

Operation mechanism for ensuring the stable migration of top-level domain name resolution hosting services with DNSSEC

HE Zheng, LENG Feng, ZHANG Cuiling

China Internet Network Information Center, Beijing 100190, China

Based on the migration and deployment practice of the top-level domain resolution service hosting platform, in order to avoid the occurrence of domain name system security extension (DNSSEC, DNS security ex-tension) trust chain and resolution service interruption, domain name NS record inconsistency and other security issues in the DNSSEC environment, research and analysis was focused on how to migrate the resolution service between the old and new service hosting platform and the internet assigned numbers authority (IANA) without breaking the integrity of the DNSSEC trust chain during the key rollover, DS and NS record changes, data update and other stages. To improve the availability of domain name system services, the key points of the platform migration operation were analyzed in detail, and the migration mechanism that can ensure business continuity during the migration process were proposed.

DNS system, DNS security extension system, key rollover, domain name resolution, trust chain

TP393

A

10.11959/j.issn.2096?109x.2021059

2020?06?02；

2020?12?18

張翠玲，zhangcuiling@cnnic.cn

北京市科技新星計(jì)劃項(xiàng)目（Z191100001119113）

Beijing Nova Program of Science and Technology (Z191100001119113)

何崢, 冷峰, 張翠玲. 在DNSSEC下保障頂級(jí)域名解析托管服務(wù)穩(wěn)定遷移的操作機(jī)制[J]. 網(wǎng)絡(luò)與信息安全學(xué)報(bào), 2021, 7(3): 156-165.

HE Z, LENG F, ZHANG C L. Operation mechanism for ensuring the stable migration of top-level domain name resolution hosting services with DNSSEC[J]. Chinese Journal of Network and Information Security, 2021, 7(3): 156-165.

何崢（1978?），男，北京人，中國(guó)互聯(lián)網(wǎng)絡(luò)信息中心高級(jí)工程師，主要研究方向?yàn)橛蛎到y(tǒng)運(yùn)行與安全。

冷峰（1982?），男，山東萊陽人，博士，中國(guó)互聯(lián)網(wǎng)絡(luò)信息中心高級(jí)工程師，主要研究方向?yàn)橛蛎?wù)平臺(tái)優(yōu)化和域名系統(tǒng)安全。

張翠玲（1982?），女，山東膠南人，中國(guó)互聯(lián)網(wǎng)絡(luò)信息中心高級(jí)工程師，主要研究方向?yàn)橛蛎到y(tǒng)運(yùn)行與安全。