DNSSEC自動化部署相關(guān)問題分析

郭川，冷峰

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

DNSSEC自動化部署相關(guān)問題分析

郭川，冷峰

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

基于國家頂級域名系統(tǒng)安全擴(kuò)展協(xié)議部署實(shí)踐，總結(jié)了域名系統(tǒng)安全擴(kuò)展協(xié)議發(fā)展背景，分析了域名系統(tǒng)安全擴(kuò)展協(xié)議當(dāng)前應(yīng)用現(xiàn)狀，提出并分析了域名系統(tǒng)安全擴(kuò)展協(xié)議部署中的自動化問題，總結(jié)并分析了在生產(chǎn)環(huán)境中部署實(shí)施域名系統(tǒng)安全擴(kuò)展協(xié)議時所需要注意的若干問題。

域名系統(tǒng)；域名系統(tǒng)安全；域名系統(tǒng)安全擴(kuò)展協(xié)議；自動化部署

1 引言

1.1 域名系統(tǒng)介紹

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

域名系統(tǒng)是一個分層授權(quán)管理的、松散耦合的分布式數(shù)據(jù)庫系統(tǒng)。域名系統(tǒng)層級結(jié)構(gòu)如圖2所示。

1.2 DNSSEC發(fā)展背景

域名系統(tǒng)作為互聯(lián)網(wǎng)絡(luò)的中樞神經(jīng)系統(tǒng)，其網(wǎng)絡(luò)關(guān)鍵基礎(chǔ)設(shè)施的位置決定了它在互聯(lián)網(wǎng)中所發(fā)揮作用的重要性。域名系統(tǒng)協(xié)議設(shè)計之初并未考慮過多的安全問題，到20世紀(jì)90年代，互聯(lián)網(wǎng)的商業(yè)化進(jìn)程加速，接入網(wǎng)絡(luò)中的主機(jī)數(shù)目突增，域名系統(tǒng)中一直存在的安全問題凸顯，其所導(dǎo)致的后果也越來越嚴(yán)重。

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

圖1 域名查詢過程

圖2 域名系統(tǒng)層級結(jié)構(gòu)

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

1.3 DNSSEC現(xiàn)狀及自動化需求

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

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

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

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

圖3 DNSSEC認(rèn)證鏈的建立過程

2 DNSSEC自動化問題分析

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

2.1 DNSSEC自動化系統(tǒng)工作流程

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

按照圖4中標(biāo)識順序，介紹DNSSEC自動化系統(tǒng)的工作步驟。

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

2) 系統(tǒng)主模塊從原始DNS資源記錄數(shù)據(jù)存儲模塊獲取區(qū)數(shù)據(jù)信息，并生成區(qū)數(shù)據(jù)文件。

3) 系統(tǒng)主模塊將區(qū)數(shù)據(jù)文件發(fā)送至密鑰生成及存儲模塊，區(qū)數(shù)據(jù)在密鑰模塊中簽名加密，生成DNSSEC區(qū)數(shù)據(jù)文件。

4) 密鑰模塊將簽名完成的 DNSSEC區(qū)數(shù)據(jù)發(fā)送至系統(tǒng)主模塊。

5) 系統(tǒng)主模塊將 DNSSEC區(qū)數(shù)據(jù)分發(fā)至DNSSEC解析服務(wù)模塊，對外提供DNSSEC解析服務(wù)。

6) DNSSEC解析服務(wù)模塊向系統(tǒng)主模塊發(fā)送區(qū)數(shù)據(jù)更新探測請求，若有更新，則請求傳輸更新數(shù)據(jù)，否則保持周期性探測請求。

圖4 DNSSEC自動化系統(tǒng)工作流程

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

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

2) 原始數(shù)據(jù)是最終DNS服務(wù)安全的根基，原始數(shù)據(jù)存儲模塊可能是單獨(dú)的數(shù)據(jù)庫服務(wù)器或存儲服務(wù)器，需要注意其安全訪問權(quán)限。

3) 系統(tǒng)主模塊提供可配置的密鑰輪轉(zhuǎn)觸發(fā)功能，并提供操作接口和監(jiān)控接口。

4) 解析服務(wù)模塊可能涉及anycast廣播的多個服務(wù)節(jié)點(diǎn)，具體數(shù)據(jù)分發(fā)方式此處沒有具體描述。

2.2 自動化系統(tǒng)主要問題分析

2.2.1 密鑰生成及保存

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

2.2.2 密鑰輪轉(zhuǎn)

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

2.2.3 密鑰廢除

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

2.2.4 NSEC或NSEC3

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

2.2.5 資源消耗

DNSSEC協(xié)議會增加服務(wù)器的計算、存儲資源，也會增加網(wǎng)絡(luò)帶寬消耗。權(quán)威服務(wù)器在區(qū)數(shù)據(jù)簽名過程中需要額外消耗計算資源，解析軟件用于存儲區(qū)數(shù)據(jù)的內(nèi)存資源大大增加，區(qū)數(shù)據(jù)的存儲及日志存儲也需要消耗更多的存儲資源。因?yàn)楹灻麛?shù)據(jù)增大了響應(yīng)數(shù)據(jù)分組大小，所以也會增加網(wǎng)絡(luò)帶寬消耗。緩存服務(wù)器因?yàn)樾枰埱竺荑€及簽名記錄并且對簽名數(shù)據(jù)進(jìn)行認(rèn)證，所以會增加計算資源的消耗。大型組織多使用 anycast網(wǎng)絡(luò)廣播方式，此時簽名區(qū)數(shù)據(jù)向各廣播節(jié)點(diǎn)分發(fā)也會占用更多網(wǎng)絡(luò)資源，且分發(fā)過程會更依賴于網(wǎng)絡(luò)質(zhì)量，因此需要更多的監(jiān)控服務(wù)。

2.2.6 流程可控性

因?yàn)镈NSSEC協(xié)議較為復(fù)雜，為了更好地管理其各個功能模塊，需要對當(dāng)前及歷史執(zhí)行過程有一個方便的配置和查看工具。在密鑰保存服務(wù)器上，需要查看密鑰當(dāng)前及歷史使用記錄，而且可以配置密鑰輪轉(zhuǎn)過程中的各類時間參數(shù)。對于簽名過程，需要針對各個區(qū)進(jìn)行配置，或分別制定資源記錄TTL參數(shù)等。對于簽名數(shù)據(jù)下發(fā)，可實(shí)時監(jiān)控各廣播節(jié)點(diǎn)的數(shù)據(jù)一致性等?？傊?，對系統(tǒng)中的各個功能應(yīng)該模塊化，便于定位問題所在；操作又應(yīng)統(tǒng)一化，便于工作人員具體操作；監(jiān)控可視化，便于直觀發(fā)現(xiàn)問題。

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

3 未來研究方向

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

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

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

4 結(jié)束語

互聯(lián)網(wǎng)自20世紀(jì)60年代末期誕生伊始，就存在對名稱—地址映射解析的需求，DNS系統(tǒng)應(yīng)現(xiàn)實(shí)需求而生，嚴(yán)格依賴于域名系統(tǒng)的電子郵件和萬維網(wǎng)，自誕生到現(xiàn)在一直是全球互聯(lián)網(wǎng)中影響最為廣泛的應(yīng)用。DNS安全問題相較于同屬互聯(lián)網(wǎng)絡(luò)基礎(chǔ)設(shè)施層面的BGP安全問題，顯得更為急迫，因?yàn)镈NS安全問題比起B(yǎng)GP安全問題，技術(shù)門檻更低也更容易為不法分子所利用，更容易對日常網(wǎng)絡(luò)用戶造成嚴(yán)重不良影響。

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

[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-），男，河北石家莊人，碩士，中國互聯(lián)網(wǎng)絡(luò)信息中心系統(tǒng)工程師，主要研究方向?yàn)橛蛎到y(tǒng)安全。

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

2016-12-16；

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