DNSSEC自動化部署相關問題分析

郭川，冷峰

（中國互聯網絡信息中心，北京 100190）

DNSSEC自動化部署相關問題分析

郭川，冷峰

（中國互聯網絡信息中心，北京 100190）

基于國家頂級域名系統安全擴展協議部署實踐，總結了域名系統安全擴展協議發展背景，分析了域名系統安全擴展協議當前應用現狀，提出并分析了域名系統安全擴展協議部署中的自動化問題，總結并分析了在生產環境中部署實施域名系統安全擴展協議時所需要注意的若干問題。

域名系統；域名系統安全；域名系統安全擴展協議；自動化部署

1 引言

1.1 域名系統介紹

域名系統（DNS, domain name system）是一個提供主機名稱（域名）和網絡地址（IP地址）之間映射關系的分布式數據庫系統?；?DNS還可以提供其他類型的映射服務，如電子郵件服務器、服務類型或主機地理位置等。不夸張地說，幾乎所有的互聯網應用都會依賴于某種類型的DNS映射查詢服務。一次典型的域名解析查詢過程如圖1所示。

域名系統是一個分層授權管理的、松散耦合的分布式數據庫系統。域名系統層級結構如圖2所示。

1.2 DNSSEC發展背景

域名系統作為互聯網絡的中樞神經系統，其網絡關鍵基礎設施的位置決定了它在互聯網中所發揮作用的重要性。域名系統協議設計之初并未考慮過多的安全問題，到20世紀90年代，互聯網的商業化進程加速，接入網絡中的主機數目突增，域名系統中一直存在的安全問題凸顯，其所導致的后果也越來越嚴重。

1990年，貝爾實驗室研究人員Bellovin S M發現 DNS協議中存在嚴重的安全問題[1]，此時DNS已在互聯網中廣泛部署，此漏洞影響范圍又非常廣泛，因此，關于此漏洞的正式報告直至1995年才公開發布[2]。在此期間，IETF已開始組織域名系統安全擴展（DNSSEC, domain name system security extensions）協議制定活動，Vixie在1995年簡單介紹了在此期間IETF相關工作[3]。1997年，RFC2065的發布，標志著DNSSEC制定活動已基本完成[4]。1999年，RFC2535的發布，標志著DNSSEC協議已全部完成，BIND9的開發主要用于支持DNSSEC協議[5]。2000年，瑞典在其國家頂級域中首次嘗試部署DNSSEC協議，但發現存在隱私和擴展方面的問題。隨后幾年，DNSSEC協議修修補補[6]，在生產環境中的部署實施進展緩慢。

圖1 域名查詢過程

圖2 域名系統層級結構

2008年，安全研究人員發現DNS緩存攻擊漏洞，此漏洞利用方法簡單有效，影響巨大[7]。RFC5155隨之發布，解決了之前阻礙 DNSSEC部署進程的區數據枚舉問題[8]，在相關政府部門和組織機構的大力支持下，各國國家頂級域名及相關域名服務商逐步開始部署實施DNSSEC協議。

1.3 DNSSEC現狀及自動化需求

DNSSEC協議使用了公鑰加密的PKI體系，在 DNS的授權層級中附加了一層認證鏈，具體而言，就是父區對其所有子區的公鑰進行簽名[9～12]。DNSSEC認證鏈的建立過程如圖3所示。

全球13個根服務器是最早部署實施DNSSEC協議的域名服務器，頂級域名服務器也大多部署實施了DNSSEC，目前，根區數據文件中頂級域名數量為1 519個，其中，1 370個已使用DNSSEC協議簽名，1 359個在根區中發布了DS記錄。頂級域名一般多為各國政府或大型組織所擁有，具備部署實施DNSSEC所需的人力、物力等資源，但二級域名及以下級域名多為個人或小型組織所持有，大多不具備部署實施DNSSEC所需的技術水平，此外，部署實施DNSSEC協議大大增加了企業的維護成本，所以二級及以下層次的域名采用DNSSEC協議的現狀并不樂觀。

DNSSEC協議設計時并沒有考慮增量式部署的情況，其安全功能是基于所有DNS服務器全部采用DNSSEC協議這一假設的。如果某個域名從自身向上一直到根區的鏈條中有某一個區域是沒有部署DNSSEC協議的，則DNSSEC協議的認證鏈條無法通達，從而也就不具備其所提供的安全認證功能。

當前狀況是除了根區和頂級域名，其他二級域以及以下級域名上采用 DNSSEC協議認證功能的數量并不樂觀。其中一個主要原因就在于部署實施DNSSEC協議的復雜性，如果這一部署過程可以自動化完成，較少需要人工參與，會有利于DNSSEC協議在全球互聯網范圍內的部署實施。

圖3 DNSSEC認證鏈的建立過程

2 DNSSEC自動化問題分析

本節基于國家頂級域名實施 DNSSEC協議過程中所使用的自動化系統，指出并分析DNSSEC協議自動化部署過程中可能遇到的問題，以期出現更多的可用于各類場景的DNSSEC協議自動化部署實施系統。

2.1 DNSSEC自動化系統工作流程

DNSSEC協議最終目的仍舊是提供DNS解析服務，但是在原有DNS基礎上增加了提供安全驗證功能的資源記錄，這些資源記錄的生成、存儲以及使用，使DNSSEC自動化系統變得更加復雜。DNSSEC自動化系統工作流程如圖4所示。

按照圖4中標識順序，介紹DNSSEC自動化系統的工作步驟。

1) 密鑰生成及存儲模塊自動化生成 DNSSEC協議所需的KSK和ZSK密鑰對。

2) 系統主模塊從原始DNS資源記錄數據存儲模塊獲取區數據信息，并生成區數據文件。

3) 系統主模塊將區數據文件發送至密鑰生成及存儲模塊，區數據在密鑰模塊中簽名加密，生成DNSSEC區數據文件。

4) 密鑰模塊將簽名完成的 DNSSEC區數據發送至系統主模塊。

5) 系統主模塊將 DNSSEC區數據分發至DNSSEC解析服務模塊，對外提供DNSSEC解析服務。

6) DNSSEC解析服務模塊向系統主模塊發送區數據更新探測請求，若有更新，則請求傳輸更新數據，否則保持周期性探測請求。

圖4 DNSSEC自動化系統工作流程

此外，上述工作流程中需要注意的問題有以下幾個方面。

1) DNSSEC協議所用密鑰始終存在密鑰模塊，不會出現在其他功能模塊中，對其訪問也僅限于主系統模塊。

2) 原始數據是最終DNS服務安全的根基，原始數據存儲模塊可能是單獨的數據庫服務器或存儲服務器，需要注意其安全訪問權限。

3) 系統主模塊提供可配置的密鑰輪轉觸發功能，并提供操作接口和監控接口。

4) 解析服務模塊可能涉及anycast廣播的多個服務節點，具體數據分發方式此處沒有具體描述。

2.2 自動化系統主要問題分析

2.2.1 密鑰生成及保存

DNSSEC協議基于公鑰加密的PKI體系，公私鑰對的生成及保存是部署實施 DNSSEC時首要考慮的問題。密鑰生成需要考慮的主要是其強度，按照當前業界主流使用情況（ZSK：1 024 bit；KSK：2 048 bit），結合自身實際，合理選擇即可，此處不再多述。關于密鑰保存，理想情況下，私鑰應滿足離線保存的要求，但在自動化生產環境中，區數據簽名下發的自動化需求和私鑰的離線保存是相互沖突的。此時，可以考慮采用專用硬件加密機，從而既可以滿足私鑰訪問控制，又可以滿足區數據簽名自動化需求；另外一種節約硬件成本的考慮是使用網絡訪問控制手段，嚴格限制存儲私鑰服務器的訪問權限，如僅限于區數據的輸入和簽名區數據的輸出。

2.2.2 密鑰輪轉

為了防止密鑰泄露，定期或不定期地更換密鑰是有必要的。由于DNS系統中緩存服務器的存在，DNSSEC協議中的密鑰更換是個較復雜的問題。密鑰輪轉的目的是淘汰舊密鑰，使用新密鑰，然而在名稱服務器上刪除舊的DNSKEY-RR以及KSK情況下的 DS-RR，并不能保證密鑰在整個DNS系統中消失，它可能仍舊存在于某些緩存服務器中，使用舊密鑰生成的簽名記錄同樣可能仍舊存在緩存服務器中，這些緩存的記錄僅在TTL到期或簽名失效后才會被刪除。因此，密鑰更換主要考慮的問題是權威服務器中密鑰、簽名數據和緩存服務器中密鑰、簽名數據需要保持一致性，從而保證DNSSEC認證鏈的通達。

2.2.3 密鑰廢除

如果發現當前使用的密鑰已泄露，應啟動密鑰廢除機制。RFC4641中描述的單一的密鑰輪轉流程中，假設舊密鑰在輪轉期間依然是安全的，文檔中提到的在密鑰被破解（或懷疑被破解）從而“應急密鑰輪轉”時，需要主動的“密鑰廢除”行動[13]。在密鑰撤銷過程中，舊私鑰想必已為攻擊者所有并且可被用于偽造區數據；攻擊者重放舊公鑰時也不受TTL的限制。實際上，攻擊者可以一直重放舊密鑰，直到有關簽名記錄（KSK對應的DS-RR的簽名，或ZSK對應的DNSKEYRRset記錄的簽名）的絕對過期時間到來，這個時間可能是幾天甚至超過一個月。在這之前，此區及其子區的DNSSEC認證都是被污染的。理想情況是盡快廢除被破解的密鑰。RFC5011中介紹的多重密鑰輪轉流程，同時使用激活和備用密鑰[14]。如果只有激活密鑰被破解，可以廢除此密鑰并即刻切換到備用密鑰。類似地，如果只有備用密鑰被破解，可以直接廢除備用密鑰。

2.2.4 NSEC或NSEC3

DNSSEC協議提供否定緩存的認證。最初的設計是采用NSEC方法，但是存在區數據枚舉問題，即可以方便地枚舉一個區中所有的子域名及對應的資源記錄類型，此問題也是2008年前很多廠商不愿部署實施 DNSSEC的一個主要原因。2008年之后，RFC5155提出替代方法NSEC3，基于一定的計算復雜度這一前提，避免了區數據枚舉問題[15]。業界關于區數據枚舉是否屬于安全漏洞這一問題有不同的看法，有人認為DNS數據本就應該是公開的，因此也就不存在所謂的區數據枚舉問題，但有人認為這會讓惡意攻擊者獲取互聯網域名數據及域名注冊人信息的困難度大大降低，是個潛在風險。目前看來，針對這一問題并沒有達成一致意見，如美國國家頂級域名和巴西國家頂級域名仍舊是使用NSEC方式，其他頂級域名大多已采用NSEC3方式。NSEC和NSEC3是 DNSSEC協議中較復雜的問題，可參考RFC7129詳細地了解[16]。

2.2.5 資源消耗

DNSSEC協議會增加服務器的計算、存儲資源，也會增加網絡帶寬消耗。權威服務器在區數據簽名過程中需要額外消耗計算資源，解析軟件用于存儲區數據的內存資源大大增加，區數據的存儲及日志存儲也需要消耗更多的存儲資源。因為簽名數據增大了響應數據分組大小，所以也會增加網絡帶寬消耗。緩存服務器因為需要請求密鑰及簽名記錄并且對簽名數據進行認證，所以會增加計算資源的消耗。大型組織多使用 anycast網絡廣播方式，此時簽名區數據向各廣播節點分發也會占用更多網絡資源，且分發過程會更依賴于網絡質量，因此需要更多的監控服務。

2.2.6 流程可控性

因為DNSSEC協議較為復雜，為了更好地管理其各個功能模塊，需要對當前及歷史執行過程有一個方便的配置和查看工具。在密鑰保存服務器上，需要查看密鑰當前及歷史使用記錄，而且可以配置密鑰輪轉過程中的各類時間參數。對于簽名過程，需要針對各個區進行配置，或分別制定資源記錄TTL參數等。對于簽名數據下發，可實時監控各廣播節點的數據一致性等。總之，對系統中的各個功能應該模塊化，便于定位問題所在；操作又應統一化，便于工作人員具體操作；監控可視化，便于直觀發現問題。

本節結合國家頂級域名部署實踐，提出并分析了 DNSSEC自動化部署實施中需要注意的問題，對密鑰生成和保存、密鑰輪轉、密鑰廢除、NSEC或者NSEC3的選擇、DNSSEC對占用資源的要求、流程可控等問題進行了簡單的介紹和分析，希望能對后續進行此方面工作的相關人員有所參考借鑒作用。

3 未來研究方向

本文主要基于國家頂級域名部署實踐分析DNSSEC自動化部署相關問題，并沒有考慮域名托管服務商同時托管大量域名的場景，此場景下大量域名權威服務器需要分別部署實施DNSSEC協議，可能有筆者考慮不到的其他需要注意的問題。

全球互聯網名稱與地址資源分配機構ICANN于2012年開啟的新一輪新頂級域名申請程序大大增加了根區頂級域名的數量，這一過程中ICANN對新申請的頂級域名提出了多種保障其能安全穩定運行的方案，如數據托管、應急恢復等流程，各新頂級域名運行機構技術能力參差不一，雖然按照 ICANN要求都有部署實施DNSSEC協議，但筆者在本文中并沒有針對這一問題做專門分析。

DNSSEC協議完整認證鏈的使用除了依賴于各層權威服務器DNSSEC協議的部署實施，還依賴于大量各自為政的緩存服務器DNSSEC認證功能的開啟，緩存服務器在DNSSEC認證過程中需要注意的問題，本文未多做介紹。

4 結束語

互聯網自20世紀60年代末期誕生伊始，就存在對名稱—地址映射解析的需求，DNS系統應現實需求而生，嚴格依賴于域名系統的電子郵件和萬維網，自誕生到現在一直是全球互聯網中影響最為廣泛的應用。DNS安全問題相較于同屬互聯網絡基礎設施層面的BGP安全問題，顯得更為急迫，因為DNS安全問題比起BGP安全問題，技術門檻更低也更容易為不法分子所利用，更容易對日常網絡用戶造成嚴重不良影響。

DNSSEC協議集結眾多研究人員多年的心血，不僅解決了DNS協議本身固有的安全問題，還有望給全球互聯網披上一層安全的盔甲，但囿于其復雜性，生產環境部署實施更是進展緩慢。本文基于國家頂級域名DNSSEC協議部署實踐，指出并分析了DNSSEC協議自動化部署實施過程中可能會遇到的問題，希望能為后來者參考借鑒。

[1] BELLOVIN S M. Using the domain name system for system break-ins[C]//Usenix Unix Security Symposium. 1996.

[2] SCHUBA C L, SPAFFORD E H. Addressing weaknesses in the domain name system protocol[D]. Indiana: Purdue University,1994.

[3] VIXIE P. DNS and BIND security issues[C]//Usenix Unix Security Symposium. 1995:263-279.

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

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

[6] AUSTEIN R. RFC 3833: threat analysis of the domain name system[S]. RFC IETF, 2004.

[7] US-CERT. Multiple DNS implementations vulnerable to cache poisoning[EB/OL]. http://www.kb.cert.org/vuls/id/800113.

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

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

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

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

[12] YANG H, OSTERWEIL E, MASSEY D, et al. Deploying cryptography in internet-scale systems: a case study on DNSSEC[J]. IEEE Transactions on Dependable & Secure Computing, 2010, 8(5): 656-669.

[13] KOLKMAN O, GIEBEN R. RFC4641: DNSSEC operational practices[S]. RFC IETF, 2006.

[14] STJOHNS M. RFC5011: automated updates of dns security (DNSSEC) trust anchors[S]. RFC IETF, 2007.

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

[16] GIEBEN R, MEKKING W. RFC7129: authenticated denial of existence in the DNS[S]. RFC IETF, 2014.

Analysis of problems in the DNSSEC automation deployment

GUO Chuan, LENG Feng
(China Internet Network Information Center, Beijing 100190, China)

Based on the practice of domain name system security extensions protocols' deployment in country code top-level domain, the development background of the domain name system security extensions protocols were summarized, the current applications of the domain name system security extensions protocols were analyzed, the automation problems in the domain name system security extensions protocols' deployment were put forward and analyzed, several issues that need to be addressed when deploying the domain name system security extensions protocols in the production environment were summarized and analyzed.

domain name system, DNS security, DNSSEC protocol, DNSSEC automation

TP393

A

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

郭川（1988-），男，河北石家莊人，碩士，中國互聯網絡信息中心系統工程師，主要研究方向為域名系統安全。

冷峰（1982-），男，山東煙臺人，中國互聯網絡信息中心規劃工程師，主要研究方向為域名服務平臺優化和域名系統安全。

2016-12-16；

2017-02-09。通信作者：郭川，guochuan@cnnic.cn