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

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

 

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

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

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

1、開啟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ㄒ)/~~）。別看我，我也不知道這怎么解決。