奇怪。 即使我configuration它，我的绑定不validationdnssec。 根据named -V是BIND 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.2 ，它具有内置的DLV密钥。 在named.conf中的选项下 dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto; 但是，当我查询一个已知的不良区域时，就像在dig www.dnssec-failed.org @localhost我得到了IP地址，而不是像我期待的那样失败。 有什么想法吗？
我听到http://www.isoc.org/在其DNSlogging上有域名系统安全扩展 。 如何使用工具dig来查看和validationDNS？
我正在为我们的内部HPC群集环境设置一个新的DNS基础结构。 这涉及到从我们现有的DNS权威和域提供迁移path。 为了举例，假设我们有一个example.edu的机构域。 （我们实际上有一个真正的.edu域。）我们组使用子域rc.example.edu 。 我在ns1.rc.example.edu为这个域build立了一个新的内部权限，并且从我们的内部parsing器转发给这个权限。 zone "rc.example.edu" IN { type forward; forward only; forwarders { 10.225.160.10; }; # ip address of ns1.rc.example.edu }; 这按预期工作。 我可以查询我的resolver1.rc.example.edu并获取该域名称的地址。 [root@resolver1 ~]# host -t A ns1.rc.colorado.edu ns1.rc.colorado.edu has address 10.225.160.10 但我们在xcatmn.rc.local中有一个传统的名称服务器，我希望在迁移期间也能解决这个问题。 所以我把这个添加到resolver1的named.conf来镜像以前的转发configuration： zone "rc.local" IN { type forward; forward only; forwarders { 10.16.0.5; }; # ip address of xcatmn.rc.local […]
在RHEL 6.5上使用bind 9.8.2，运行chroot'd。 我有一个区域文件，其中包括其他文件（这是一个区域，在不同的数据中心有大量的服务器，每个数据中心有一个包含的文件）。 区域文件和包含的文件在 /var/named/chroot/var/named/zones/master/example.com /var/named/chroot/var/named/zones/master/lax01 包含文件在区域文件中相对于chroot'd目录被引用： $INCLUDE zones/master/lax01 当试图使用dnssec-signzone签署区域时，出现错误，因为它似乎无法加载包含的文件。 # cd /var/named/chroot/var/named/zones/master # dnssec-signzone -A -3 $(head -c 1000 /dev/random | sha1sum | cut -b 1-16) \ -N INCREMENT -o example.com -t example.com dnssec-signzone: error: dns_master_load: example.com:287: zones/master/lax01: file not found dnssec-signzone: fatal: failed loading zone from 'example.com': file not found 有没有更好的方法来引用INCLUDE指令的path？ 我没有看到指示dnssec-signzone将chroot指令考虑在内的方法。 […]
我们运行一个私人CA，同时使用DNSSEC和DANE。 最近我们决定重新颁发我们的CA根和颁发者密钥，因为当我们的PKI在2008年build立时，这些密钥是在1024位生成的。我们原来的TLSA RR指向颁发CA作为信任锚。 然而，重新阅读RFC和各种与DANE有关的评论提出了是否应该使用ROOT公钥的问题。 我们目前正在试图将这个想法平行于我们现有的DANElogging。 当我们使用https://dane.sys4.de/smtp/进行validation时，我们现有的服务器密钥会检出，但即使我们尚未将服务器密钥切换到新的证书链，也会报告新的ROOT TLSAlogging。 此外，新的信任锚点TLSA RR因此被报告： 可用的TLSAlogging 2, 1, 2 c26e0ec16a46a973[…]ce60eabc5adba90e – self signed certificate in certificate chain: (19) 而同一个主机的当前TLSA RR是这样报告的： 2, 0, 2 67274b3554289058[…]5fd3917510e6722a 报告的第一个logging是指新的根CA. 第二个是指原始颁发的CA（由原始根CA签名）。 当我self signed certificate in certificate chain: (19)检查消息self signed certificate in certificate chain: (19)我形成的印象是这是一个错误。 但是，如果这是一个错误，那么CA Root公钥在什么地方适合DANEscheme呢？
我即将为我的部分域名部署DNSSEC，而且在准备就绪时，我对这个主题进行了一些阅读。 我遇到了一些Microsoft Technet文章中讨论的名称parsing策略表 ，它允许在与DNS服务器通信时使用IPSec来configurationWindows DNS客户端以提供完整性和（可选）身份validation。 从我所坐的位置看，这似乎是一个非常好的主意，但唉，NRPT只是一个Windows。 在Linux / OpenBSD世界有没有相同的东西？ 将DNSSEC和IPSec组合在一起似乎是安全性明确的服务器pipe理员的完美解决scheme。
我想知道如何validationparsing器处理多个DSlogging。 假设我们有一个带有一个KSK和一个ZSK的区域，但是在一些关键的翻转恶意软件之后，在父区域中有两个DSlogging，一个指向当前的KSK，一个指向一个更老的KSK。 parsing器是否会忽略旧的DSlogging并validation该区域，只要DNSKEY RRset由至less一个父logging中的DSlogging指向的密钥签名？
我在Debian Jessie上运行一个权威的BIND 9.9.5-9 + deb8u8-Debian。 我有一个工作区robin.info正常工作（各种testing报告成功，如pingdom.com的DNS检查工具） 我正试图用dnssec来保护它。 我按照“ BIND DNSSEC指南”第4章给出的指示轻松启动。 我成功地生成了ZSK和KSK，并更新了我的区域，将粗体添加为粗体： 区域“robin.info”{ 型主人; 文件“/etc/bind/zones/robin.info”; 包括“/ etc / bind / include-zones / acls”; key-directory“/etc/bind/dnssec/robin.info/2016”; 内联签署是; auto-dnssec维护; }; 我确定没有.jnl ， .jbk ， .signed和.signed.jnl文件出现在区域文件中，然后重新启动与rndc reload绑定，并确认该区域已加载，并有DNSKEY条目，虽然我有一些错误在日志中： 11-Dec-2016 13:54:20.742 zone robin.info/IN/internal (signed): loaded serial 2016121111 11-Dec-2016 13:54:20.742 zone robin.info/IN/external (signed): loaded serial 2016121111 11-Dec-2016 13:54:20.750 zone robin.info/IN/external (signed): receive_secure_serial: unchanged […]
从版本9.9开始，绑定支持内联签名 ，但是我没有find任何有关如何使它与NSEC3一起工作的信息。 我不能添加nsupdate NSEC3PARAM RR：我认为这是正常的，因为内联签名，但我不能参数为内联签名。 有人设置和testing它，或一个想法？ 感谢您的回答。
我已经开始在个人域名上使用DNSSEC，并使用OpenDNSSEC进行签名和密钥维护; 我只有一个静态区域，所以OpenDNSSEC很容易。 为了玩弄东西，我决定为我的KSK和ZSK做一个手动键盘翻转。 ZSK从退休到死亡的过渡需要两周的时间。 考虑到大多数TTL小于48小时，并且传播延迟不超过24小时，这是一个非常大的时间，而且看起来完全没有必要。 我一直在阅读文档“ 部署DNSSEC的良好实践指南 ”，他们推荐这两个星期的延迟，但似乎没有给出延迟的理由。 是什么赋予了？ 从论文： 从一个状态转换到下一个状态的持续时间取决于区域中logging的使用期限，将区域传送到外部服务器所需的时间以及时钟抖动时间（Internet-Draft，DNSSEC Key Timing Considerations）。 和 KSK退休前的build议时间（退休时间）为四周。 对于ZSK，推荐的介绍时间是四天，退休时间是两周。