文/段海新

DNSSEC原理、配置與部署(二)

文/段海新

DNSSEC是為解決DNS欺騙和緩存污染而設計的一種安全機制。本文概要介紹DNSSEC的背景、工作原理以及在BIND上的配置，最后介紹它在國際上的部署情況和可能對互聯(lián)網(wǎng)安全機制的影響。本刊上期已經(jīng)刊載其背景、目的和工作原理。

DNSSEC是為解決DNS欺騙和緩存污染而設計的一種安全機制。本文概要介紹DNSSEC在BIND上的配置，最后介紹國際上的部署情況和它可能對互聯(lián)網(wǎng)安全機制的影響。

DNSSEC的配置

盡管DNSSEC的工作原理看起來讓人氣餒，實際的配置操作卻并不復雜。本節(jié)以BIND 9為例介紹DNSSEC的基本配置。盡管BIND 9.3以上就開始支持DNSSEC，仍然建議使用當前最高版本的BIND（當前最新的版本是9.8）。

配置或部署DNSSEC有兩種場景：

（1）配置安全的域名解析服務器（Resolver），該服務器可以保護使用它的用戶，防止被DNS 欺騙攻擊。這里只涉及數(shù)字簽名的驗證工作。

（2）配置安全的權(quán)威域名服務器（Name Server），對權(quán)威域的資源記錄進行簽名，保護服務器不被域名欺騙攻擊。

配置安全解析服務器

激活D N S S E C

首先，在BIND的配置文件（一般是/etc/named.conf）中打開DNSSEC選項，比如：

配置Trust anchor

其次，要給解析服務器配置可信錨（Trust Anchors），也就是你所信任的權(quán)威域的DNSKEY。理想情況下我們可以配置一個根的密鑰就夠了，但是目前DNSSEC還沒有完全部署的情況下，我們需要配置很多安全島（Secure Island）的密鑰，可以從很多公開的網(wǎng)站下載這些可信域的DNSKEY文件，包括：

（1）Root Zone DNSSEC Trust Anchors：https://www.iana.org/dnssec/。2010年7月部署實施，如果DNSSEC全部部署成功，這一個公開密鑰就足夠了。

（2）The UCLA secspider ： https://secspider.cs.ucla.edu，由美國加州大學洛杉磯分校（UCLA）張麗霞教授的實驗室維護。

（3）The IKS Jena TAR：https://www.iksjena.de/leistungen/dnssec.php

這些文件大概是這樣的格式：

假設上述trust anchors的文件為/var/named/trust-anchors.conf，則在/etc/named.conf中增加下面一行：

測試

在完成上述配置修改之后重新啟動named進程，然后選擇一個trust anchor文件中有的區(qū)或者它下一級的域名，在解析服務器上用dig測試一下，例如：

如果配置正確，應該返回test.net的SOA記錄和相應的RRSIG記錄，另外返回的頭部中應該包含A D標志位，表示DNSSEC相關(guān)的數(shù)字簽名驗證是正確的，類似下面的樣子：

如果沒有得到期望的結(jié)果，需要查看DNS的日志來找出問題。BIND為DNSSEC相關(guān)的事件增加了一個dnssec類別，可以在/etc/named.conf配置日志如下：配置權(quán)威服務器

生成簽名密鑰對

首先為你的區(qū)（zone）文件生成密鑰簽名密鑰KSK：

然后生成區(qū)簽名密鑰ZSK：

其中的-a 參數(shù)是簽名算法，-b是密鑰長度。上述命令共產(chǎn)生兩對DNSKEY密鑰（共四個文件），分別以.key和.private結(jié)尾，表明這個文件存儲的是公開密鑰或私有密鑰。

簽名

簽名之前，你需要把上面的兩個DNSKEY寫入到區(qū)文件中

然后執(zhí)行簽名操作：

上面的-o選項指定代簽名區(qū)的名字。生成的db.test.net.signed

然后修改/etc/named.conf如下：

記住，你每次修改區(qū)中的數(shù)據(jù)時，都要重新簽名：

發(fā)布公鑰

要讓其他人驗證你的數(shù)字簽名，其他人必須有一個可靠的途徑獲得你的公開密鑰。DNSSEC通過上一級域名服務器數(shù)字簽名的方式簽發(fā)你的公鑰。

用dnssec-signzone時，會自動生成keyset-文件和dsset-開頭的兩個文件，分別存儲著KSK的DNSKEY記錄和DS記錄。作為test.net區(qū)的管理員，你需要把這兩個文件發(fā)送給.net的管理員，.net的管理員需要把這兩條記錄增加到.net區(qū)中，并且用.net的密鑰重新簽名。

如果你的上一級域名服務器還沒有配置DNSSEC，你不得不另找其他方式了，比如，把上述兩個文件提交到一些公開的trust anchor數(shù)據(jù)庫中發(fā)布(如上面介紹過的secspider)，或者直接交給愿意相信你的解析服務器的管理員，配置到他們的trust anchor文件中。

DNSSEC的部署

互聯(lián)網(wǎng)工程技術(shù)領域普遍認為DNSSEC是增強互聯(lián)網(wǎng)基礎設施安全非常關(guān)鍵的一步，比如，美國國土安全部發(fā)起了DNSSEC部署計劃，美國網(wǎng)絡空間國家戰(zhàn)略安全明確要求部署DNSSEC。DNSSEC的大規(guī)模部署還可能解決其他的安全問題，比如密鑰的分發(fā)和安全的電子郵件。

盡管互聯(lián)網(wǎng)工程界認為DNSSEC非常重要，但是大規(guī)模的部署仍然非常謹慎。巴西 (.br)、保加利亞 (.bg)、捷克 (.cz)、波多黎各 (.pr) 和瑞典 (.se), 很早就開始在他們國家的頂級域名上部署DNSSEC，IANA在2007年開始在一個根域名服務器上進行簽名試驗。許多機構(gòu)在DNSSEC的部署上付出了巨大的努力。

在ICANN和VeriSign的推動下，2010年7月，所有13個根域名服務器都對根域簽名完畢且投入運營。頂級域名（如.org, .net等）也在計劃之中，有些國家級的頂級域名服務器（如.cz、.jp、.us、.fr等）已經(jīng)完成了這一任務。

國際上一些大的ISP已經(jīng)開始部署支持DNSSEC的解析服務器，以保護他們接入用戶的安全，美國Comcast 公司是其中的先驅(qū)者之一。

作者認為如果DNSSEC能夠普遍部署，可能對互聯(lián)網(wǎng)的安全體系產(chǎn)生重大的影響；因為有了DNSSEC的數(shù)字簽名，把DNS作為密鑰分發(fā)的PKI在很多應用場合已經(jīng)具有了可行性。它不僅僅可以加強DNS系統(tǒng)本身的安全，作為網(wǎng)絡的基礎設施，還給其他的應用，特別是端到端的移動通信、IPv6網(wǎng)絡環(huán)境的安全問題提供新的解決辦法。

但是作者也認為，離這一目標的實現(xiàn)還有很長的路要走。一方面DNSSEC自身的協(xié)議還在發(fā)展，另一方面其他的應用要想利用DNSSEC的機制還需要大規(guī)模的研究試驗和最后的標準化。另外，DNSSEC在某些國家是否會遭遇政策性的阻礙，也是個未知數(shù)。

盡管如此，因為DNS對互聯(lián)網(wǎng)實在太重要了，如果DNSSEC是通往一個安全可靠的互聯(lián)網(wǎng)基礎設施的必由之路（目前作者還沒有看到可以替代DNSSEC的其他解決方案），為此付出代價，也是別無選擇的。

（作者單位為清華大學信息網(wǎng)絡工程研究中心）