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

何崢，冷峰，張翠玲

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

何崢，冷峰，張翠玲

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

基于頂級域解析服務(wù)托管平臺遷移部署實(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ù)平臺的遷移，并對平臺遷移操作的關(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)黑客們有針對性的安全攻擊對象，出現(xiàn)了DNS緩存污染、DNS放大攻擊及域名欺騙等針對域名服務(wù)器的攻擊事件。頂級域名服務(wù)托管是域名注冊管理局將頂級域的五大核心服務(wù)托管至具備較強(qiáng)技術(shù)能力和擁有穩(wěn)定平臺的域名平臺托管機(jī)構(gòu)，確保該頂級域的服務(wù)更加穩(wěn)定安全。當(dāng)托管平臺遭遇物理和網(wǎng)絡(luò)攻擊，造成域名解析平臺能力和穩(wěn)定性無法滿足域名注冊管理局的要求時，注冊管理機(jī)構(gòu)將被動更換域名托管機(jī)構(gòu)，因此變更域名托管機(jī)構(gòu)是不可避免的。隨著2010年DNSSEC（DNS security extension）[1]逐步在全球13個根服務(wù)器和頂級域名服務(wù)器上進(jìn)行部署實(shí)施，2012年互聯(lián)網(wǎng)名稱與數(shù)字地址分配機(jī)構(gòu)（ICANN，Internet Corporation for Assigned Names and Numbers）開放申請的新通用頂級域也把支持DNSSEC協(xié)議作為準(zhǔn)入門檻，這樣極大地增加了域名管理機(jī)構(gòu)遷移域名托管平臺的復(fù)雜程度，因此在DNSSEC環(huán)境下遷移域名解析服務(wù)成為一個非常棘手的問題。目前，國內(nèi)乃至國際上的域名服務(wù)機(jī)構(gòu)都在積極開展相關(guān)技術(shù)研究，探索遷移解決方案，而在DNSSEC環(huán)境下遷移域名解析服務(wù)的成功案例并不多見。本文結(jié)合頂級域遷移的需求，將頂級域解析服務(wù)更換注冊局后臺托管機(jī)構(gòu)（BERO，Backend Registry Operator）過程定義了5個階段，重點(diǎn)分析了在5個階段中可能出現(xiàn)的3個關(guān)鍵性問題，提出了有效的解決方案，并結(jié)合實(shí)踐經(jīng)驗(yàn)，提出了一種在DNSSEC下保障頂級域名解析托管服務(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地址之間的對應(yīng)關(guān)系（域名解析，簡稱解析），為人們提供基于互聯(lián)網(wǎng)的通信服務(wù)。域名系統(tǒng)采用倒置的樹形結(jié)構(gòu)自頂向下構(gòu)建名稱，通過分級授權(quán)、各域自治的方式進(jìn)行管理。根位于DNS分層結(jié)構(gòu)的頂部，是DNS的解析服務(wù)的起點(diǎn)與DNSSEC信任鏈的信任錨點(diǎn)；其下依次是頂級域（如“.CN”“.COM”等）及其二級域、三級域等。互聯(lián)網(wǎng)用戶一般通過為其提供DNS查詢的遞歸解析服務(wù)商獲得所需的訪問信息。

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

圖1 頂級域部署邏輯示意

Figure 1 TLD registry service framework

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

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

2.2 DNSSEC的發(fā)展背景

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

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

Figure 2 DNSSEC trust chain

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

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

3 頂級域名變更BERO的問題分析

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

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

本文主要討論基于DNSSEC背景下的新通用頂級域解析服務(wù)更換BERO的過程。遷移過程涉及TLD遷出方、TLD遷入方及ICANN的IANA機(jī)構(gòu)這3個角色，為了確保整個遷移過程中對數(shù)據(jù)一致性、DNSSEC信任鏈完整性、服務(wù)連續(xù)性的要求，3個角色的操作耦合比較緊密，需要相互配合完成。本文將新通用頂級域解析服務(wù)更換BERO的過程定義了5個階段（狀態(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)證中。這個階段為新簽名數(shù)據(jù)的生效做好準(zhǔn)備。

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

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

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

刪除原NS記錄之前，互聯(lián)網(wǎng)用戶會看到兩組NS記錄，新舊BERO的權(quán)威服務(wù)器都將收到查詢；刪除原NS記錄開始，等待TTL時長之后，互聯(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記錄。這是遷移操作的一個收尾步驟，將已不再使用的原DS記錄從解析系統(tǒng)中徹底刪除。

3.2 變更BERO遇到的主要問題

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

遞歸服務(wù)器可能緩存的數(shù)據(jù)如表1所示。如果某個數(shù)據(jù)未被緩存或已過期，在取回新數(shù)據(jù)后，可以對應(yīng)至其中一種情況。針對表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時，由于BERO A和BERO B的權(quán)威服務(wù)器同時對外提供服務(wù)，數(shù)據(jù)可能存在一定時間的不同步。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所示。如果某個數(shù)據(jù)未被緩存或已過期，在取回新數(shù)據(jù)后，可以對應(yīng)至其中一種情況。針對表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等待的理論時間需要大于一個TTL周期，實(shí)際情況考慮網(wǎng)絡(luò)時延情況應(yīng)大于2~3個TTL周期，否則在狀態(tài)3遞歸可能緩存的數(shù)據(jù)如表3所示。如果某個數(shù)據(jù)未被緩存或已過期，在取回新數(shù)據(jù)后，可以對應(yīng)其中一種情況。針對表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時，權(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)成了信任鏈的一部分，但由于沒有對應(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所示。如果某個數(shù)據(jù)未被緩存或已過期，在取回新數(shù)據(jù)后，也是對應(yīng)這種情況。能夠驗(yàn)證通過的信任鏈?zhǔn)荄S-Bà DNSKEY-BàRRSIG-B。

處于狀態(tài)5時，權(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所示。如果某個數(shù)據(jù)未被緩存或已過期，在取回新數(shù)據(jù)后，可以對應(yīng)至其中一種情況。針對表5中的4種情況，能夠驗(yàn)證通過的信任鏈只有一種可能：DS-BàDNSKEY-Bà RRSIG-B。

需要注意的是，如果在狀態(tài)4等待的理論時間需要大于一個TTL周期，實(shí)際情況考慮網(wǎng)絡(luò)時延情況應(yīng)大于2~3個TTL周期，否則在狀態(tài)5遞歸可能緩存的數(shù)據(jù)如表6所示。如果某個數(shù)據(jù)未被緩存或已過期，在取回新數(shù)據(jù)后，可以對應(yīng)其中一種情況。針對表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的等待操作是必要的。

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

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

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

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

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

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

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

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

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

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

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

以頂級域ABC為例，原BERO A有臺NS服務(wù)器，其集合表示為NS-A，DNSSEC密鑰對應(yīng)的DNSKEY記錄為KSK-A、ZSK-A，其集合表示為DNSKEY-A，KSK-A對應(yīng)的根區(qū)中的DS記錄為DS-A；將BERO A更換為BERO B，B有臺NS服務(wù)器，其集合表示為NS-B，DNSSEC密鑰對應(yīng)的DNSKEY記錄為KSK-B，ZSK-B，其集合表示為DNSKEY-B，KSK-B對應(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）注冊局：向IANA提交申請增加BERO B的NS、DS記錄。

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

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

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

（7）注冊局：向IANA提交申請刪除BERO A的NS記錄。

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

（9）注冊局：向IANA提交申請刪除BERO A的DS記錄。

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

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

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

5 結(jié)束語

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

[1] 苑朋朋, 王常青. DNS安全威脅及應(yīng)對措施研究[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]. 中國教育網(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]. 中國教育網(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

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

Beijing Nova Program of Science and Technology (Z191100001119113)

何崢, 冷峰, 張翠玲. 在DNSSEC下保障頂級域名解析托管服務(wù)穩(wěn)定遷移的操作機(jī)制[J]. 網(wǎng)絡(luò)與信息安全學(xué)報, 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?），男，北京人，中國互聯(lián)網(wǎng)絡(luò)信息中心高級工程師，主要研究方向?yàn)橛蛎到y(tǒng)運(yùn)行與安全。

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

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