这是一个创建于 3702 天前的主题，其中的信息可能已经有所发展或是发生改变。
Setup Hign-Availability DNSSEC Authoritative Only BIND DNS Server
本文的目的在于分享最近业余一直在研究的DNSSEC相关内容以及相关服务器的设置过程。
来V2EX没几个月，作者小狼是学生党，总之属于新人啦~ 所以肯定有不足的地方，大家多多包涵~
本文可以随意转载，但是一定要署名。<del>其实还有个重要的目的，由于博客还没有搭建好所以先找个地方存放供以后参考。</del>
关于DNSSEC的介绍：
请大家参阅ICANN的官方介绍： https://www.icann.org/resources/pages/dnssec-qaa-2014-01-29-zh （有中文翻译，大赞！）
台湾地区从2012年开始进行了大规模的DNSSEC部署，并开设了相关的教学网站： http://dnssec.tanet.edu.tw/
懂日语的同学还可以参考JPNIC的十分钟讲座https://www.nic.ad.jp/ja/newsletter/No43/0800.html
关于DNSSEC目前的普及情况(2014年10月)：
所有的根域名()和大部分的顶级域名服务器(超过70%)都部署了DNSSEC。
738 TLDs in the root zone in total
556 TLDs are signed;
546 TLDs have trust anchors published as DS records in the root zone;
6 TLDs have trust anchors published in the ISC DLV Repository.
想了解自己注册的顶级域名是否支持DNSSEC可以参考ICANN的TLD DNSSEC Report：
http://stats.research.icann.org/dns/tld_report/
想了解自己域名的注册商是否支持DNSSEC可以参考：
https://www.icann.org/resources/pages/deployment-2012-02-25-en
完成自己域名的DNSSEC权威服务器的部署需要以下前提条件：
1. YOUR TOP-LEVEL DOMAIN (TLD) MUST BE SIGNED (目前有73%左右的顶级域名达到条件)
2. YOUR DOMAIN REGISTRAR MUST SUPPORT DNSSEC （悲剧的是大部分人都卡在了这一步，目前支持DNSSEC的域名注册商太少，而且大部分支持DNSSEC的注册商只提供部分域名的支持，详情可以参考上面的链接。目前对DNSSEC支持比较好的知名域名注册商有Godaddy和GANDI以及Name.com）
3. YOUR DNS HOSTING PROVIDER MUST SUPPORT DNSSEC （这一步也有很多人卡住，部署了DNSSEC的DNS会比没有部署之前消耗更多的资源，所以大部分DNS服务商也都没有提供DNSSEC的支持。Godaddy和DYN的付费DNS提供的DNSSEC的支持。）
关于DNSSEC在递归DNS服务器上的普及情况：
目前国内的大部分运营商的递归服务器还不能支持DNSSEC，不过互联网企业的公共DNS基本已经完成了DNSSEC的支持，以下是小狼目前测试到支持DNSSEC DS记录的DNS：(有待补充)
阿里 AliDNS 223.5.5.5 223.6.6.6
CNNIC SDNS 1.2.4.8 210.2.4.8
114 DNS 114.114.114.114 114.114.115.115
oneDNS 112.124.47.27 114.215.126.16
DNS 派 101.226.4.6 218.30.118.6
123.125.81.6 140.207.198.6
Google DNS 8.8.8.8 8.8.4.4
OpenDNS 208.67.222.222 208.67.220.220
北京电信 219.141.136.10 219.141.140.10
北京联通 202.106.196.115 202.106.46.151 202.106.0.20
黑龙江联通 202.97.224.69
江苏电信 218.2.2.2 218.4.4.4
61.147.37.1 218.2.135.1 (几乎全线支持)
其他很多地区的递归服务器小狼还没有测试，希望各位V友能帮忙测试一下0.0
检查方法很简单:dig +noadditional DS icann.org. @DNS 的IP | grep DS
如果有DS记录返回则说明该服务器支持DNSSEC,如：
[root@0w0 ~]# dig +noadditional DS icann.org. @114 .114.114.114 | grep DS
; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> +noadditional DS icann.org. @114 .114.114.114
;icann.org. IN DS
icann.org. 86400 IN DS 41643 7 1 93358DB22E956A451EB5AE8D2EC39526CA6A87B9
icann.org. 86400 IN DS 41643 7 2 B8AB67D895E62087F0C5FC5A1A941C67A18E4B096F6C622AEFAE30DD 7B1EA199
关于DNSSEC在DNS服务器软件上的普及情况：
目前的BIND、PowerDNS、NSD等主流的DNS服务器软件都已无缝支持DNSSEC，并且经过一段时间的技术演进性能已趋于稳定。但是部署DNSSEC后会加重服务器的负载也成为不争的事实。这也在一定程度上减缓了DNSSEC的普及速度。
所以，虽然DNSSEC的普及还有很长的一段路要走，但是目前的情况已经比之前好很多，如果找到一家靠谱的支持DNSSEC的域名注册商，完全可以通过自己搭建DNS仅权威服务器的方式使自己的域名支持DNSSEC。
DNSSEC部署方面的相关分享(属于纯粹的实验总结分享，并不是严肃的教程=_=，所以不能保证客观正确性)：
小狼这次是用肉身做实验了，申请了域名(wolflab.net感觉这个域名不错^_^)并亲自搭建了DNS仅权威服务器。
部署完成后的图形化检测结果(检测地址http://dnsviz.net/)：
同时使用KSK和ZSK签署
http://wolfmoe.qiniudn.com/wolflab.net-2014-10-31-03-30-11-UTC.png
仅使用KSK签署
http://wolfmoe.qiniudn.com/wolflab.net-2014-10-31-09-56-49-UTC.png
关于域名的申请：
在看到ICANN提供的那份表单之前，小狼的域名是在Name.com注册的，他家也为域名提供了DNSSEC的管理界面(在国内加载特别慢...)，但是增加DS的时候总是提示参数错误，后来给客服发了个Ticket客服回复说让我联系DNS的管理员(我才不会说DNS的管理员就是自己呢o(╯□╰)o)。然后就是各种谷歌，然后，搜到了ICANN的那个页面(https://www.icann.org/resources/pages/deployment-2012-02-25-en)，然后，就没有然后了QAQ
/* 此处省略一大段废话 */
最后，小狼选择了TransIP B.V.这家注册商<del>前阵子搞活动.net一年4.75欧，官网也挺高端的-_+</del>
以下分享一下在CentOS 7和BIND9(yum安装)环境下配置DNSSEC的过程：
相关教程的链接(强烈推荐阅读)：
DNS搭建相关：
业界良心DigitalOcean的系列文章 An Introduction to Managing DNS： https://www.digitalocean.com/community/tutorial_series/an-introduction-to-managing-dns(包含DNS的相关介绍和Debian系的安装教程)
https://www.digitalocean.com/community/tutorials/how-to-install-the-bind-dns-server-on-centos-6(RedHat系的安装教程 CentOS6 CentOS 7通用)
当然RedHat的官方指南中对BIND也有详细的教程，大家可以参考
DNSSEC部署相关：
https://www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server--2 (RH系)
Debian系的强烈建议参考台湾交大资通安全研究与教学中心的DNSSEC部署SOP
http://dnssec.tanet.edu.tw/index.php/sop
以下是小狼自己的部署过程分享(欢迎各位批评与指正，鞠躬~)：
环境：CentOS 7 + BIND 9.9.4
为了增强高可用性(其实是偷懒=_=),此处小狼只使用4096bits的KSK密钥签署整个网域并且不设定密钥的期限。这样做的优点是管理十分方便，每次修改DNS记录后只需要重新签署网域即可，不需要进行复杂的密钥管理。 [而在安全的强度方面，根据＂European Network of Excellence in Cryptology II“于2010年3月的报告指出，破解 RSA 2048bits 约需要三亿美金的预算，使用 ASIC 花费 10 年来运算。也就是说，本文所建议的方式，仍然是需要非常高的代价才可被破解，而破解后的收获仅是获得 DNSSEC 的金钥，可用来仿冒 Resource Record。我们认为，除非管理者所管理的相关系统，价值超过数亿美金，否则本文所建议的方式已经提供足够的安全性。——摘自http://dnssec.tanet.edu.tw/images/DNSSEC/DNSSEC_Authoritative_ServerSOPLite_v2.12.pdf]
安装BIND9过程及初始化设置过程略...
[root@sg tw]# nano /etc/named.conf
# 检查以下设置的状态
recursion no;
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
zone "wolflab.net" IN {
type master;
# 修改文件名
file "wolflab.net.zone.signed";
allow-transfer { 1.1.1.1; 2.2.2.2; };
};
进入 /var/named/
[root@sg named]# ls -al
total 47
drwxr-x--- 6 root named 4096 Oct 31 09:35 .
drwxr-xr-x. 22 root root 4096 Oct 30 18:32 ..
drwxr-x--- 7 root named 4096 Oct 27 23:10 chroot
drwxrwx--- 2 named named 4096 Oct 29 13:12 data
drwxrwx--- 2 named named 4096 Oct 31 09:33 dynamic
-rw-r----- 1 root named 2166 Oct 28 22:19 named.ca
-rw-r----- 1 root named 152 Dec 15 2009 named.empty
-rw-r----- 1 root named 152 Jun 21 2007 named.localhost
-rw-r----- 1 root named 168 Dec 15 2009 named.loopback
drwxrwx--- 2 named named 4096 Jun 10 16:13 slaves
-rw-r--r-- 1 root named 533 Oct 30 14:15 wolflab.net.zone
首先确保zone文件格式正确，BIND9能够正常运行。
修改一下Serial，方便同步从服务器
然后安装haveged (目的是加快密钥生成速度)
[root@sg named]# yum -y install haveged
[root@sg named]# chkconfig haveged on
[root@sg named]# service haveged start
生成KSK密钥
[root@sg named]# dnssec-keygen -f KSK -a NSEC3RSASHA1 -b 4096 -r /dev/urandom -K /var/named wolflab.net
Generating key pair...........++ ...............................................................................................................................++
Kwolflab.net.+007+38406
以下是相关参数的说明：
-f 密钥的flag
-a 密钥的算法
-b 密钥的长度
-r 乱数来源
-K 密钥文件产生后存放的目录(默认为当前目录)
Zone name
将密钥添加到zone文件中
[root@sg named]# for key in `ls Kwolflab.net*.key`
> do
> echo "\$INCLUDE $key">> wolflab.net.zone
> done
wolflab.net.zone 中的最后一行会包含以下字样：
$INCLUDE Kwolflab.net.+007+38406.key
签署网域
[root@sg named]# dnssec-signzone -3 7aa7c4b1300f4915 -H 100 -K /var/named -o wolflab.net -S -u -z wolflab.net.zone
Verifying the zone using the following algorithms: NSEC3RSASHA1.
Zone fully signed:
Algorithm: NSEC3RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 0 active, 0 stand-by, 0 revoked
wolflab.net.zone.signed
以下是相关参数的说明：
-3 NSEC3使用的salt值，可在Debian系统中使用
head -c 1000 /dev/random | sha1sum | cut -b 1-16
命令随机生成，也可以使用SOP教程中的值61
-H NSEC3 使用的 Iteration 值，默认为10
-K 密钥文件产生后存放的目录(默认为当前目录)
-o 网域名称
-S 智能签署
-u 更新NSEC/NSEC3
-z 使用KSK签署整个zone file
Zone name
权限设置(其实这步可以省略 644权限是不是named组都无所谓啦)
[root@sg named]# chown root:named K*
[root@sg named]# chown root:named *.signed
[root@sg named]# ls -al
drwxr-x--- 6 root named 4096 Oct 31 17:01 .
drwxr-xr-x. 22 root root 4096 Oct 30 18:32 ..
drwxr-x--- 7 root named 4096 Oct 27 23:10 chroot
drwxrwx--- 2 named named 4096 Oct 29 13:12 data
-rw-r--r-- 1 root root 167 Oct 31 17:01 dsset-wolflab.net.
drwxrwx--- 2 named named 4096 Oct 31 17:14 dynamic
-rw-r--r-- 1 root named 951 Oct 31 16:40 Kwolflab.net.+007+38406.key
-rw------- 1 root named 3319 Oct 31 16:40 Kwolflab.net.+007+38406.private
-rw-r----- 1 root named 2166 Oct 28 22:19 named.ca
-rw-r----- 1 root named 152 Dec 15 2009 named.empty
-rw-r----- 1 root named 152 Jun 21 2007 named.localhost
-rw-r----- 1 root named 168 Dec 15 2009 named.loopback
drwxrwx--- 2 named named 4096 Jun 10 16:13 slaves
-rw-r--r-- 1 root named 587 Oct 31 16:52 wolflab.net.zone
-rw-r--r-- 1 root named 22437 Oct 31 17:01 wolflab.net.zone.signed
重启BIND9
[root@sg named]# systemctl restart named-chroot
结果验证
[root@0w0 ~]# dig DNSKEY wolflab.net. @0w0 .moe(DNS地址) +multiline
root@debian:~# dig A wolflab.net. @0w0 .moe(DNS地址) +noadditional +dnssec +multiline
如果出现一大堆排列很整齐的乱码=_=，恭喜，设置成功~
dsset-wolflab.net.中记录着签署时生成的DS记录
[root@sg named]# cat dsset-wolflab.net.
wolflab.net. IN DS 42945 7 1 EBE05D35D18466A4013B953E51AA1049CB7CB63F
wolflab.net. IN DS 42945 7 2 5F953F58484289F3D886AD8E8F604A7365A4DE9E7FE8B5ACC598023A C0998F62
此记录用来提交给域名注册商
有些域名注册商并不使用DS记录，而是直接提交DNSSEC KEY(比如TransIP),使用dig DNSKEY wolflab.net. @DNS 的IP 即可直接查看
最后再次声明，本文可以随意转载，但是一定要署名，首发于V2EX。
本文的目的在于分享最近业余一直在研究的DNSSEC相关内容以及相关服务器的设置过程。
来V2EX没几个月，作者小狼是学生党，总之属于新人啦~ 所以肯定有不足的地方，大家多多包涵~
本文可以随意转载，但是一定要署名。<del>其实还有个重要的目的，由于博客还没有搭建好所以先找个地方存放供以后参考。</del>
关于DNSSEC的介绍：
请大家参阅ICANN的官方介绍： https://www.icann.org/resources/pages/dnssec-qaa-2014-01-29-zh （有中文翻译，大赞！）
台湾地区从2012年开始进行了大规模的DNSSEC部署，并开设了相关的教学网站： http://dnssec.tanet.edu.tw/
懂日语的同学还可以参考JPNIC的十分钟讲座https://www.nic.ad.jp/ja/newsletter/No43/0800.html
关于DNSSEC目前的普及情况(2014年10月)：
所有的根域名()和大部分的顶级域名服务器(超过70%)都部署了DNSSEC。
738 TLDs in the root zone in total
556 TLDs are signed;
546 TLDs have trust anchors published as DS records in the root zone;
6 TLDs have trust anchors published in the ISC DLV Repository.
想了解自己注册的顶级域名是否支持DNSSEC可以参考ICANN的TLD DNSSEC Report：
http://stats.research.icann.org/dns/tld_report/
想了解自己域名的注册商是否支持DNSSEC可以参考：
https://www.icann.org/resources/pages/deployment-2012-02-25-en
完成自己域名的DNSSEC权威服务器的部署需要以下前提条件：
1. YOUR TOP-LEVEL DOMAIN (TLD) MUST BE SIGNED (目前有73%左右的顶级域名达到条件)
2. YOUR DOMAIN REGISTRAR MUST SUPPORT DNSSEC （悲剧的是大部分人都卡在了这一步，目前支持DNSSEC的域名注册商太少，而且大部分支持DNSSEC的注册商只提供部分域名的支持，详情可以参考上面的链接。目前对DNSSEC支持比较好的知名域名注册商有Godaddy和GANDI以及Name.com）
3. YOUR DNS HOSTING PROVIDER MUST SUPPORT DNSSEC （这一步也有很多人卡住，部署了DNSSEC的DNS会比没有部署之前消耗更多的资源，所以大部分DNS服务商也都没有提供DNSSEC的支持。Godaddy和DYN的付费DNS提供的DNSSEC的支持。）
关于DNSSEC在递归DNS服务器上的普及情况：
目前国内的大部分运营商的递归服务器还不能支持DNSSEC，不过互联网企业的公共DNS基本已经完成了DNSSEC的支持，以下是小狼目前测试到支持DNSSEC DS记录的DNS：(有待补充)
阿里 AliDNS 223.5.5.5 223.6.6.6
CNNIC SDNS 1.2.4.8 210.2.4.8
114 DNS 114.114.114.114 114.114.115.115
oneDNS 112.124.47.27 114.215.126.16
DNS 派 101.226.4.6 218.30.118.6
123.125.81.6 140.207.198.6
Google DNS 8.8.8.8 8.8.4.4
OpenDNS 208.67.222.222 208.67.220.220
北京电信 219.141.136.10 219.141.140.10
北京联通 202.106.196.115 202.106.46.151 202.106.0.20
黑龙江联通 202.97.224.69
江苏电信 218.2.2.2 218.4.4.4
61.147.37.1 218.2.135.1 (几乎全线支持)
其他很多地区的递归服务器小狼还没有测试，希望各位V友能帮忙测试一下0.0
检查方法很简单:dig +noadditional DS icann.org. @DNS 的IP | grep DS
如果有DS记录返回则说明该服务器支持DNSSEC,如：
[root@0w0 ~]# dig +noadditional DS icann.org. @114 .114.114.114 | grep DS
; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> +noadditional DS icann.org. @114 .114.114.114
;icann.org. IN DS
icann.org. 86400 IN DS 41643 7 1 93358DB22E956A451EB5AE8D2EC39526CA6A87B9
icann.org. 86400 IN DS 41643 7 2 B8AB67D895E62087F0C5FC5A1A941C67A18E4B096F6C622AEFAE30DD 7B1EA199
关于DNSSEC在DNS服务器软件上的普及情况：
目前的BIND、PowerDNS、NSD等主流的DNS服务器软件都已无缝支持DNSSEC，并且经过一段时间的技术演进性能已趋于稳定。但是部署DNSSEC后会加重服务器的负载也成为不争的事实。这也在一定程度上减缓了DNSSEC的普及速度。
所以，虽然DNSSEC的普及还有很长的一段路要走，但是目前的情况已经比之前好很多，如果找到一家靠谱的支持DNSSEC的域名注册商，完全可以通过自己搭建DNS仅权威服务器的方式使自己的域名支持DNSSEC。
DNSSEC部署方面的相关分享(属于纯粹的实验总结分享，并不是严肃的教程=_=，所以不能保证客观正确性)：
小狼这次是用肉身做实验了，申请了域名(wolflab.net感觉这个域名不错^_^)并亲自搭建了DNS仅权威服务器。
部署完成后的图形化检测结果(检测地址http://dnsviz.net/)：
同时使用KSK和ZSK签署
http://wolfmoe.qiniudn.com/wolflab.net-2014-10-31-03-30-11-UTC.png
仅使用KSK签署
http://wolfmoe.qiniudn.com/wolflab.net-2014-10-31-09-56-49-UTC.png
关于域名的申请：
在看到ICANN提供的那份表单之前，小狼的域名是在Name.com注册的，他家也为域名提供了DNSSEC的管理界面(在国内加载特别慢...)，但是增加DS的时候总是提示参数错误，后来给客服发了个Ticket客服回复说让我联系DNS的管理员(我才不会说DNS的管理员就是自己呢o(╯□╰)o)。然后就是各种谷歌，然后，搜到了ICANN的那个页面(https://www.icann.org/resources/pages/deployment-2012-02-25-en)，然后，就没有然后了QAQ
/* 此处省略一大段废话 */
最后，小狼选择了TransIP B.V.这家注册商<del>前阵子搞活动.net一年4.75欧，官网也挺高端的-_+</del>
以下分享一下在CentOS 7和BIND9(yum安装)环境下配置DNSSEC的过程：
相关教程的链接(强烈推荐阅读)：
DNS搭建相关：
业界良心DigitalOcean的系列文章 An Introduction to Managing DNS： https://www.digitalocean.com/community/tutorial_series/an-introduction-to-managing-dns(包含DNS的相关介绍和Debian系的安装教程)
https://www.digitalocean.com/community/tutorials/how-to-install-the-bind-dns-server-on-centos-6(RedHat系的安装教程 CentOS6 CentOS 7通用)
当然RedHat的官方指南中对BIND也有详细的教程，大家可以参考
DNSSEC部署相关：
https://www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server--2 (RH系)
Debian系的强烈建议参考台湾交大资通安全研究与教学中心的DNSSEC部署SOP
http://dnssec.tanet.edu.tw/index.php/sop
以下是小狼自己的部署过程分享(欢迎各位批评与指正，鞠躬~)：
环境：CentOS 7 + BIND 9.9.4
为了增强高可用性(其实是偷懒=_=),此处小狼只使用4096bits的KSK密钥签署整个网域并且不设定密钥的期限。这样做的优点是管理十分方便，每次修改DNS记录后只需要重新签署网域即可，不需要进行复杂的密钥管理。 [而在安全的强度方面，根据＂European Network of Excellence in Cryptology II“于2010年3月的报告指出，破解 RSA 2048bits 约需要三亿美金的预算，使用 ASIC 花费 10 年来运算。也就是说，本文所建议的方式，仍然是需要非常高的代价才可被破解，而破解后的收获仅是获得 DNSSEC 的金钥，可用来仿冒 Resource Record。我们认为，除非管理者所管理的相关系统，价值超过数亿美金，否则本文所建议的方式已经提供足够的安全性。——摘自http://dnssec.tanet.edu.tw/images/DNSSEC/DNSSEC_Authoritative_ServerSOPLite_v2.12.pdf]
安装BIND9过程及初始化设置过程略...
[root@sg tw]# nano /etc/named.conf
# 检查以下设置的状态
recursion no;
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
zone "wolflab.net" IN {
type master;
# 修改文件名
file "wolflab.net.zone.signed";
allow-transfer { 1.1.1.1; 2.2.2.2; };
};
进入 /var/named/
[root@sg named]# ls -al
total 47
drwxr-x--- 6 root named 4096 Oct 31 09:35 .
drwxr-xr-x. 22 root root 4096 Oct 30 18:32 ..
drwxr-x--- 7 root named 4096 Oct 27 23:10 chroot
drwxrwx--- 2 named named 4096 Oct 29 13:12 data
drwxrwx--- 2 named named 4096 Oct 31 09:33 dynamic
-rw-r----- 1 root named 2166 Oct 28 22:19 named.ca
-rw-r----- 1 root named 152 Dec 15 2009 named.empty
-rw-r----- 1 root named 152 Jun 21 2007 named.localhost
-rw-r----- 1 root named 168 Dec 15 2009 named.loopback
drwxrwx--- 2 named named 4096 Jun 10 16:13 slaves
-rw-r--r-- 1 root named 533 Oct 30 14:15 wolflab.net.zone
首先确保zone文件格式正确，BIND9能够正常运行。
修改一下Serial，方便同步从服务器
然后安装haveged (目的是加快密钥生成速度)
[root@sg named]# yum -y install haveged
[root@sg named]# chkconfig haveged on
[root@sg named]# service haveged start
生成KSK密钥
[root@sg named]# dnssec-keygen -f KSK -a NSEC3RSASHA1 -b 4096 -r /dev/urandom -K /var/named wolflab.net
Generating key pair...........++ ...............................................................................................................................++
Kwolflab.net.+007+38406
以下是相关参数的说明：
-f 密钥的flag
-a 密钥的算法
-b 密钥的长度
-r 乱数来源
-K 密钥文件产生后存放的目录(默认为当前目录)
Zone name
将密钥添加到zone文件中
[root@sg named]# for key in `ls Kwolflab.net*.key`
> do
> echo "\$INCLUDE $key">> wolflab.net.zone
> done
wolflab.net.zone 中的最后一行会包含以下字样：
$INCLUDE Kwolflab.net.+007+38406.key
签署网域
[root@sg named]# dnssec-signzone -3 7aa7c4b1300f4915 -H 100 -K /var/named -o wolflab.net -S -u -z wolflab.net.zone
Verifying the zone using the following algorithms: NSEC3RSASHA1.
Zone fully signed:
Algorithm: NSEC3RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 0 active, 0 stand-by, 0 revoked
wolflab.net.zone.signed
以下是相关参数的说明：
-3 NSEC3使用的salt值，可在Debian系统中使用
head -c 1000 /dev/random | sha1sum | cut -b 1-16
命令随机生成，也可以使用SOP教程中的值61
-H NSEC3 使用的 Iteration 值，默认为10
-K 密钥文件产生后存放的目录(默认为当前目录)
-o 网域名称
-S 智能签署
-u 更新NSEC/NSEC3
-z 使用KSK签署整个zone file
Zone name
权限设置(其实这步可以省略 644权限是不是named组都无所谓啦)
[root@sg named]# chown root:named K*
[root@sg named]# chown root:named *.signed
[root@sg named]# ls -al
drwxr-x--- 6 root named 4096 Oct 31 17:01 .
drwxr-xr-x. 22 root root 4096 Oct 30 18:32 ..
drwxr-x--- 7 root named 4096 Oct 27 23:10 chroot
drwxrwx--- 2 named named 4096 Oct 29 13:12 data
-rw-r--r-- 1 root root 167 Oct 31 17:01 dsset-wolflab.net.
drwxrwx--- 2 named named 4096 Oct 31 17:14 dynamic
-rw-r--r-- 1 root named 951 Oct 31 16:40 Kwolflab.net.+007+38406.key
-rw------- 1 root named 3319 Oct 31 16:40 Kwolflab.net.+007+38406.private
-rw-r----- 1 root named 2166 Oct 28 22:19 named.ca
-rw-r----- 1 root named 152 Dec 15 2009 named.empty
-rw-r----- 1 root named 152 Jun 21 2007 named.localhost
-rw-r----- 1 root named 168 Dec 15 2009 named.loopback
drwxrwx--- 2 named named 4096 Jun 10 16:13 slaves
-rw-r--r-- 1 root named 587 Oct 31 16:52 wolflab.net.zone
-rw-r--r-- 1 root named 22437 Oct 31 17:01 wolflab.net.zone.signed
重启BIND9
[root@sg named]# systemctl restart named-chroot
结果验证
[root@0w0 ~]# dig DNSKEY wolflab.net. @0w0 .moe(DNS地址) +multiline
root@debian:~# dig A wolflab.net. @0w0 .moe(DNS地址) +noadditional +dnssec +multiline
如果出现一大堆排列很整齐的乱码=_=，恭喜，设置成功~
dsset-wolflab.net.中记录着签署时生成的DS记录
[root@sg named]# cat dsset-wolflab.net.
wolflab.net. IN DS 42945 7 1 EBE05D35D18466A4013B953E51AA1049CB7CB63F
wolflab.net. IN DS 42945 7 2 5F953F58484289F3D886AD8E8F604A7365A4DE9E7FE8B5ACC598023A C0998F62
此记录用来提交给域名注册商
有些域名注册商并不使用DS记录，而是直接提交DNSSEC KEY(比如TransIP),使用dig DNSKEY wolflab.net. @DNS 的IP 即可直接查看
最后再次声明，本文可以随意转载，但是一定要署名，首发于V2EX。
第 1 条附言 · 2014-11-05 22:36:02 +08:00
20141105补充：
自己搭建的BIND已经运行五天，目前三个节点的情况都良好，国内外解析都比较正常。
但是今天在另一台虚拟机中使用dig +trace wolflab.net命令时发现会出现卡在最后一步的情况。
症状表现为最后一段记录无法显示，提示没有服务器响应或者超时。
小狼反复对比了相关的教程和自己的操作步骤，发现有一步存在问题，解决方案如下：
在编辑.zone文件(解析记录)时一定要在NS记录下添加这么一段记录：
@ IN NSEC3PARAM 1 0 100 61
其中100和61分别为iteration和salt值，具体解释摘录http://dnssec.tanet.edu.tw/中的原话：
'@ IN NSEC3PARAM 1 0 100 61' 用來設定NSEC3功能,
NSEC3為DNSSEC用來回應"不存在"(例如某個host/domain不存在),
且讓這個回答可受信任的方法,
請一定要加入這個設定.
管理者需知道的設定為iteration和salt,
iteration為執行hash的次數, 上述例子為100次, 此為我們的建議值, 不建議更改,
salt功能為在RR名稱追加自己定義的16進位字串(0-F,且長度為2的倍數), 使字典攻擊法的威脅降低,
上述例子為61, 可以自行改成例如FF / 8888 / 1234567890等等.
這裡補充一下,
NSEC3的iteration和salt設定除了在上述的NSEC3PARAM會用到之外,
做zone簽署(dnssec-signzone)時也會用到,
這兩個地方的iteration和salt值一定要相同.
假設在NSEC3PARAM設定 iteration=100 salt=61
在zone簽署時一定要設定 iteration=100 salt=61
按照此步骤修改.zone后重新签署域名，问题很快解决。
自己搭建的BIND已经运行五天，目前三个节点的情况都良好，国内外解析都比较正常。
但是今天在另一台虚拟机中使用dig +trace wolflab.net命令时发现会出现卡在最后一步的情况。
症状表现为最后一段记录无法显示，提示没有服务器响应或者超时。
小狼反复对比了相关的教程和自己的操作步骤，发现有一步存在问题，解决方案如下：
在编辑.zone文件(解析记录)时一定要在NS记录下添加这么一段记录：
@ IN NSEC3PARAM 1 0 100 61
其中100和61分别为iteration和salt值，具体解释摘录http://dnssec.tanet.edu.tw/中的原话：
'@ IN NSEC3PARAM 1 0 100 61' 用來設定NSEC3功能,
NSEC3為DNSSEC用來回應"不存在"(例如某個host/domain不存在),
且讓這個回答可受信任的方法,
請一定要加入這個設定.
管理者需知道的設定為iteration和salt,
iteration為執行hash的次數, 上述例子為100次, 此為我們的建議值, 不建議更改,
salt功能為在RR名稱追加自己定義的16進位字串(0-F,且長度為2的倍數), 使字典攻擊法的威脅降低,
上述例子為61, 可以自行改成例如FF / 8888 / 1234567890等等.
這裡補充一下,
NSEC3的iteration和salt設定除了在上述的NSEC3PARAM會用到之外,
做zone簽署(dnssec-signzone)時也會用到,
這兩個地方的iteration和salt值一定要相同.
假設在NSEC3PARAM設定 iteration=100 salt=61
在zone簽署時一定要設定 iteration=100 salt=61
按照此步骤修改.zone后重新签署域名，问题很快解决。
 |
1
TrustyWolf OP 再补充一些DNSSEC测试的网站：
http://dnsviz.net/ http://dnssec-debugger.verisignlabs.com/ 以及浏览器插件： https://www.dnssec-validator.cz/ 之前的排版废了QAQ... |
 |
2
wwqgtxx 2014-10-31 19:20:27 +08:00 via Android
可以用markdown排班一下可能看着更舒服
|
 |
3
panzhc 2014-10-31 22:10:26 +08:00
这个赞
|
|
4
TrustyWolf OP |
|
5
wwqgtxx 2014-11-01 07:14:05 +08:00 via Android  1
@TrustyWolf 建议使用v2ex notes的发布功能在发这种技术文章，就像L大大的官方文档一样
https://www.v2ex.com/p/7v9TEc53 因为notes发布的内容可以修改^ω^ |
 |
6
0w0 2015-02-04 00:07:59 +08:00
有人 @ 我 冒泡
|
|
7
0w0 2015-02-04 00:09:43 +08:00
我靠 这…… 94天前的帖子 我怎么才收到 @ 的提示 ……
管理管给沉了吧…… 我不是故意挖坟的orz |
 |
8
roxhaiy 2015-07-28 13:24:03 +08:00
虽然略显混乱，但是参考了文中提到的台湾交大DNSSEC部署SOP的pdf，应该说基本搞懂了，谢谢！
|
|
9
TrustyWolf OP 新发布了 2016 版，请大家移步：/t/266750
|
 |
10
bclerdx 2016-08-03 23:20:35 +08:00
顶起来~
|
Select Language