服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 来自命名/绑定的DNSsec响应间歇性地丢失了RRSIGlogging
Intereting Posts
如何使用Augeas注释/取消注释configuration文件中的一行？ 将Nagios数据发送到中央监控服务器 DNS更新以parsing外部地址作为内部IP 基于Lighttpd的服务器问题在端口转发时出现 板载RAID和Ubuntu安装 – 为什么看到单独的磁盘？ 如何重写旧的备份副本Windows Server 2008 除了“Windows NT集成安全性”之外，不能访问SQL Server 2008 什么是在小环境中更新的最佳解决scheme 在Openshift WordPress中使用自定义域的SSL证书错误 SQL Server 2005：“链接的服务器上从registry”获取启用的协议列表出错 Linux服务器空间不足 Windows 7安装Adobe Reader和Flash更新的权限？ 连接到主机上的虚拟机 当木偶控制的文件将被yum改变时通知 什么是适合Windows的简单，开放的Web服务器？

来自命名/绑定的DNSsec响应间歇性地丢失了RRSIGlogging

尽pipe被请求，我们域名服务器的响应间歇性地丢失了RRSIGlogging。 所有其他相关logging（如Alogging）都会返回OK。 因此dnsssecvalidation失败。 下面的例子是贝宝，但我相信这是不是他们的名称服务器的问题，直接查询他们的名称服务器时，我不能重现这个问题。 

$ dig +dnssec api.paypal.com @internalnameserver Wed May 11 17:35:22 BST 2016 ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6 <<>> +dnssec api.paypal.com @internalnameserver ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9849 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;api.paypal.com. IN A ;; ANSWER SECTION: api.paypal.com. 47 INA 173.0.84.98 api.paypal.com. 47 INA 173.0.88.98 api.paypal.com. 47 INA 173.0.92.23 ;; AUTHORITY SECTION: paypal.com. 47IN NSns4.p57.dynect.net. paypal.com. 47IN NSns3.p57.dynect.net. paypal.com. 47IN NSns2.p57.dynect.net. paypal.com. 47IN NSns1.p57.dynect.net. ;; ADDITIONAL SECTION: ns1.p57.dynect.net. 83856 INA 208.78.70.57 ns2.p57.dynect.net. 83856 INA 204.13.250.57 ns3.p57.dynect.net. 83856 INA 208.78.71.57 ns4.p57.dynect.net. 83856 INA 204.13.251.57 ;; Query time: 0 msec ;; SERVER: 172.16.0.2#53(172.16.0.2) ;; WHEN: Wed May 11 17:35:25 2016 ;; MSG SIZE rcvd: 241

RRSIGlogging丢失，但直接查询paypal NS，它们是存在的： 

 $ dig +dnssec api.paypal.com @ns1.p57.dynect.net ; <<>> DiG 9.5.1-P3 <<>> +dnssec api.paypal.com @ns1.p57.dynect.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33378 ;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 5, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;api.paypal.com. IN A ;; ANSWER SECTION: api.paypal.com. 300 IN A 173.0.88.98 api.paypal.com. 300 IN A 173.0.84.98 api.paypal.com. 300 IN A 66.211.168.91 api.paypal.com. 300 IN RRSIG A 5 3 300 20160617044014 20160518034014 11811 paypal.com. SnkboXg/S1uV0IzYhcaCIrq+YtH+z5vtQcgw2O3GnNPM/oQbNWFmDClq Jj7gRgjKNHLy7zH8BHk1p7QBUCJuhQK3ud02dc5IDBSupMSusMp8tay9 eSG6AJEwkNsed0ztuacJiUw2qYETbgnLQyywOAF97Q68m8210tPXHCE2 2qY= ;; AUTHORITY SECTION: paypal.com. 300 IN NS ns1.p57.dynect.net. paypal.com. 300 IN NS ns2.p57.dynect.net. paypal.com. 300 IN NS ns3.p57.dynect.net. paypal.com. 300 IN NS ns4.p57.dynect.net. paypal.com. 300 IN RRSIG NS 5 2 300 20160606184750 20160507180943 11811 paypal.com. rV5WaDBF1SXjx9jSA0iom5+08dMja2aZIb4bqQhm3egqDAWku4+YXcCd rET1pxVQngIYpIPIF7eHheVSuPNd6mC63/U/1/Ph20Xm70OKL0EDjoVa +KgRT71J1X7Whs4oQ6df4L+E8lb8GspeHVyEGfuE00pZRbKt2ZevXZcu ZIk= ;; Query time: 10 msec ;; SERVER: 208.78.70.57#53(208.78.70.57) ;; WHEN: Wed May 18 10:31:17 2016 ;; MSG SIZE rcvd: 517

10分钟后，RRSIGlogging可以再次出现。 这似乎是一个内部的命名caching问题，因为每个“迭代”的logging存在与否似乎与达到的TTL一致。 – 一旦得到或没有得到RRSIGlogging，响应被caching在logging的TTL的有效期内。

运行绑定9.7.3

如果有什么不清楚或需要更多信息，请告诉我。

这是BIND常见的非问题 ，虽然承认混淆。

  • 在recursion模式下，BIND 可能会返回被动意识到的额外logging，但不会主动尝试查找这些logging，除非相关标准要求这样做。
  • 当单个DNS服务器遇到这种行为时（即从单个服务器而不是从负载均衡器前面观察到不一致），应该考虑不需要RR的可能性。 一个简单的testing是显式地请求一个你期望被包含的logging，并重复原来的查询。 如果现在包含logging，则不需要执行额外的recursion来在之前的响应中包括该答案。 包括额外的logging是纯粹的信息 。

在这种特殊情况下，看起来您期待RRSIGlogging被呈现给存根parsing器。 想想看。 如果不知道中间签名，该签名如何有用？

在我们追踪DNSSEC RFC之前，让我们快速回顾一下维基百科很容易获得的内容：

https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Stub_resolvers

存根parsing器将简单地将请求转发给recursion名称服务器，并在响应中使用authentication数据（AD）位作为“提示，以确定recursion名称服务器是否能够validation所有数据的签名答复的答案和授权部分“。

validation存根parsing程序还可以通过在其查询消息中设置检查禁用（CD）位来执行自己的签名validation。 validation存根parsing程序使用CD位执行自己的recursion身份validation。 即使互联网服务提供商或其连接不可信，使用这种validation存根parsing程序也可为实施DNSSEC的域提供客户端端对端DNS安全性。

大胆的重点是我的。 把它们放在一起：

  • 一个非validation的存根parsing器只是在它的响应中查找AD位，并且相信recursion服务器已经对它进行了validation。 它与RRSIGlogging没有任何关系。 希望根据该RRSIG执行操作的应用程序应该直接请求该logging ，而不是依靠其包含在响应中。
  • validation存根parsing器必须执行自己的recursion。 这是validation从根服务器到与RRSIG涉及的logging相关的RRSIG有效签名的唯一方式。

知道了所有这些，我们需要确认当+dnssec标志被设置的时候正在做什么。 我们可以从manpage中获得： 

  +[no]dnssec Requests DNSSEC records be sent by setting the DNSSEC OK bit (DO) in the OPT record in the additional section of the query.

从这里我们可以推断出dig不是作为一个validation的stubparsing器运行的（如果你愿意的话，可以进一步用数据包捕获确认，因为它必须执行自己的recursion），并且BIND服务器没有执行validation代表它的回应没有回到OPT伪部分设置的ad位作为答案。 （只要do ，在原始查询中看到的确认）