BIND簡易教程（3）：DNSSec配置

目錄：
BIND簡易教程（1）：安裝及基本配置
BIND簡易教程（2）：BIND視圖配置
BIND簡易教程（3）：DNSSec配置 （本篇）

 

DNSSec，有個半英半中的名字叫DNS安全擴展。說的好聽一點，它是對域名進行簽名認證，保證域名的完整性和正確性，不會被修改。DNSSec不能防護對DNS服務器的攻擊，也不會對請求和應答的數據進行加密，甚至若是你不知道DNSSec這個東西的話，域名是否是完整正確的你也不知道。

實際上，給個人感受就是，DNSSec是在花很大的力氣去配置一個不怎麼有用的東西。然並卵。該用仍是得用。固然，也有多是我才疏學淺，蜩與學鳩笑鵬起不知若何

好了不拽文了，仍是說正事。大概要分好幾步：

一、開啓DNSSec功能：

（1）要在options裏面添加幾個選項，開啓DNSSec功能：

options {
    dnssec-enable yes;
    dnssec-validation auto;
    dnssec-lookaside auto;
    notify yes;
    allow-transfer { none; };
};

以前有dnssec-enable no;這個選項，改成yes，其他4個是新增的。

（2）創建目錄留做生成key放置：

mkdir -p views/dnssec_keys

（3）zone中添加相關參數：

zone 「apple.tree」 IN {
    type master;
    auto-dnssec maintain;
    update-policy local;
    file 「/etc/bind/views/zones/dianxin.apple.tree.zone」;
    key-directory 「/etc/bind/views/dnssec_keys」;
};

其中type和file是原來就有的，其他幾個選項是新增的。可是，file後面的文件一會是要改的。暫時先不改放在這兒。

2，生成密鑰

在新增的dnssec_keys目錄中生成密鑰

sudo dnssec-keygen -f KSK -a RSASHA1 -r /dev/urandom -b 512 -n ZONE apple.tree.
sudo dnssec-keygen -a RSASHA1 -r /dev/urandom -b 512 -n ZONE apple.tree.

分別採用KSK和RSA加密。關於dnssec-keygen的使用方法，有時候須要百度查一下，或者用-h看看。好比-r /dev/urandom，這是隨機數生成器，若是不加的話，生成key的時候可能要等上好幾分鐘都沒結果。

以後在dnssec_keys目錄中能夠看到4個文件：

Kapple.tree.+005+54124.key
Kapple.tree.+005+54124.private
Kapple.tree.+005+61152.key
Kapple.tree.+005+61152.private

兩個公鑰和兩個私鑰，一會配置解析庫的時候會用到>

3，簽名

（1）將前面生成的兩個公鑰添加到區域配置文件末尾

$TTL 86400
@   IN  SOA apple.tree. apple.apple.tree. (
          2016090100     ; Serial
               28800     ; Refresh
                7200     ; Retry
              604800     ; Expire
               86400     ; Negative Cache TTL
)

@   IN  NS  apple.tree.
@   IN  A   192.168.4.135
aaa     IN      A       192.168.4.100
bbb     IN      A       192.168.4.101
ccc     IN      CNAME   bbb

$INCLUDE "/etc/bind/views/dnssec_keys/Kapple.tree.+005+54124.key" $INCLUDE "/etc/bind/views/dnssec_keys/Kapple.tree.+005+61152.key"

（2）對zone簽名

sudo dnssec-signzone -K /etc/bind/views/dnssec_keys -o apple.tree. /etc/bind/views/zones/dianxin.apple.tree.zone

會生成一個後綴爲.signed的文件，這個就是簽名後的zone。把這個zone文件的名字寫到前面zone一節的file選項中。zone變爲

zone "apple.tree" IN {
    type master;
    auto-dnssec maintain;
    update-policy local;
    file "/etc/bind/views/zones/dianxin.apple.tree.zone.signed";
    key-directory "/etc/bind/views/dnssec_keys";
};

4，生成信任錨

（1）生成信任錨文件：查看剛纔生成的兩個公鑰

$ ls
Kccgslb.bokecs.com.+005+54124.key
Kccgslb.bokecs.com.+005+54124.private
Kccgslb.bokecs.com.+005+61152.key
Kccgslb.bokecs.com.+005+61152.private

$ sudo cat Kapple.tree.+005+54124.key
; This is a key-signing key, keyid 54124, for apple.tree.
; Created: 20160825061813 (Thu Aug 25 14:18:13 2016)
; Publish: 20160825061813 (Thu Aug 25 14:18:13 2016)
; Activate: 20160825061813 (Thu Aug 25 14:18:13 2016)
apple.tree. IN DNSKEY 257 3 5 AwEAAbfkw0jfR6MAIInduMR1WAj6XZIRj3Zso8xyiOSmeQRNVVyS9dOz tBemhoCWhOk5RnEZpu/ITJVEzSZHY3bA1Tc=

$ sudo cat Kapple.tree.+005+61152.key
; This is a zone-signing key, keyid 61152, for apple.tree.
; Created: 20160825062349 (Thu Aug 25 14:23:49 2016)
; Publish: 20160825062349 (Thu Aug 25 14:23:49 2016)
; Activate: 20160825062349 (Thu Aug 25 14:23:49 2016)
apple.tree. IN DNSKEY 256 3 5 AwEAAb8mO4dN8I1mCt/f575aACdeSr+Q0igouAWrJa5DGJNZfAoX39eW z3QfG6nmiDdgtT/CoPL+uqH46BERgqk9POc=

在 /etc/bind 目錄下生成文件 sec-trust-anchors.conf

trusted-keys {
    apple.tree. 257 3 5 "AwEAAbfkw0jfR6MAIInduMR1WAj6XZIRj3Zso8xyiOSmeQRNVVyS9dOz tBemhoCWhOk5RnEZpu/ITJVEzSZHY3bA1Tc=";
    apple.tree. 256 3 5 "AwEAAb8mO4dN8I1mCt/f575aACdeSr+Q0igouAWrJa5DGJNZfAoX39eW z3QfG6nmiDdgtT/CoPL+uqH46BERgqk9POc=";
};

這裏面的兩條內容是剛纔生成的兩個密鑰的內容。用公鑰比較方便（也就是.key的文件）。注意複製的時候去掉「IN」和「DNSKEY」這兩個詞，以及後面的key要加引號。

（2）在named.conf中添加
include "/etc/bind/sec-trust-anchors.conf";

5，重啓bind

sudo service bind9 restart

若是重啓成功，就能夠測試了

$ dig +dnssec aaa.apple.tree @192.168.4.43
; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> aaa.apple.tree @192.168.4.43
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53833
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;aaa.apple.tree. IN A
;; ANSWER SECTION:
aaa.apple.tree. 86400 IN A 192.168.4.100
aaa.apple.tree. 86400 IN RRSIG CNAME 5 6 86400 20160924084355 20160825075619 61152 apple.tree. PLHn/VCVSb6mcvYZgM66qH2/19gKxrrfogCDWMWj3n5ZU+iqpu4W5XoY 9osK/d9BM9LM3YfltEubmCDlFBrUKw==
;; Query time: 4 msec
;; SERVER: 192.168.4.43#53(192.168.4.43)
;; WHEN: Fri Jan 08 14:47:48 CST 2016
;; MSG SIZE rcvd: 59

咱們看到除了正常的一行解析到192.168.4.100以外，還有一行亂七八糟的字符串，這個就是對aaa.apple.tree的簽名。出現這個就表明DNSSec配好了。OK，至此，三篇BIND的介紹就算完成了。其實對於整個BIND來講，這只是冰山一角。可是個人精力也有限，只能寫這麼點東西了。

 

題外話：

（1）開始覺得BIND的效率挺差的，可是後來真正用起來發現仍是至關快的，加上功能多，真不愧是當今世界上應用最普遍的DNS服務器。我關閉日誌，測試了一下QPS，有將近12萬的表現。比PowerDNS要高出一大截。並且，開啓DNSSec後效率並無下降，我估計是由於緩存的關係。

（2）DNS安全問題是個挺嚴肅的問題。我所知道的極少，又片面，因此不敢寫。前幾天跟羣裏的一位同窗談到了「分佈式放大攻擊」，簡直恐慌。簡單說下，好比有攻擊者A和受害者B，A將本身的IP地址假裝成B，而後向DNS服務器發送請求。請求是精心準備的，這個請求的應答要比請求自己要大上不少倍。以後，DNS服務器向B發送了應答包。從外部看起來，就是A利用DNS服務器做爲放大器，向B發動攻擊。固然，一個DNS包再大也不會有什麼問題。可是不少的DNS應答包就會出問題了——受害者的計算機畢竟不是服務器，能不能承受住如此大量的網絡數據包？這就是放大攻擊。而所謂的分佈式就是，A能夠向不少不少DNS服務器發送請求，這樣就會成爲N多服務器攻擊同一臺計算機（服務器：我是冤枉的/(ㄒoㄒ)/~~）。別看我，我也不知道這怎麼解決。