首页 > 代码库 > BIND简易教程（3）：DNSSec配置

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

2024-08-13 16:45:26   226人阅读

目录：
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.keyKapple.tree.+005+54124.privateKapple.tree.+005+61152.keyKapple.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.135aaa     IN      A       192.168.4.100bbb     IN      A       192.168.4.101ccc     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）生成信任锚文件：查看刚才生成的两个公钥

$ lsKccgslb.bokecs.com.+005+54124.keyKccgslb.bokecs.com.+005+54124.privateKccgslb.bokecs.com.+005+61152.keyKccgslb.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.100aaa.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ㄒ)/~~）。别看我，我也不知道这怎么解决。

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


联系
我们