☰

来自命名/绑定的 DNSsec 响应间歇性地缺少 RRSIG 记录

tag-icon • tag-icon linux domain-name-system bind
来自命名/绑定的 DNSsec 响应间歇性地缺少 RRSIG 记录

尽管请求了 RRSIG 记录，但来自我们名称服务器的响应仍会间歇性地丢失。所有其他相关记录（如 A 记录）均返回 OK。因此，dnsssec 验证失败。下面的示例适用于 paypal，但我相信这不是其名称服务器的问题，因为当直接查询其名称服务器时，我无法重现该问题。

    $ 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

RRSIG 记录丢失，但直接查询 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 分钟后，RRSIG 记录可以再次出现。这似乎是一个内部命名缓存问题，因为记录的每次“迭代”是否存在似乎与达到 TTL 相吻合。- 一旦它获得或未获得 RRSIG 记录，响应就会在记录的 TTL 生命周期内缓存 OK。

运行 bind 9.7.3

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

答案1

这是一个BIND 的常见问题，尽管确实令人困惑。

  • 在递归模式下，BIND可能返回它被动知道的额外记录，但不会主动尝试查找这些记录，除非相关标准要求它这样做。
  • 当在单个 DNS 服务器上遇到此行为时（即从单个服务器观察到不一致，而不是从负载平衡器前面观察到），应考虑缺少的 RR 不是必需的。一个简单的测试是明确请求您期望包含的记录，然后重复原始查询。如果现在包含该记录，则不需要执行额外的递归以将该答案包含在先前的响应中。包含额外的记录是纯属信息。

在这个特定情况下，您似乎希望将RRSIG记录呈现给存根解析器。但请仔细考虑一下。如果不知道中间签名，该签名有什么用呢？

在我们开始研究 DNSSEC RFC 之前，让我们快速回顾一下维基百科上可以轻松找到的内容：

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

存根解析器只会将请求转发到递归名称服务器，并使用响应中的已验证数据 (AD) 位作为“提示，以查明递归名称服务器是否能够验证响应的答案和授权部分中所有数据的签名”。

验证存根解析器还可以通过在其查询消息中设置检查禁用 (CD) 位来执行其自己的签名验证。验证存根解析器使用 CD 位来执行其自己的递归身份验证。使用这样的验证存根解析器可以为实现 DNSSEC 的域提供客户端端到端 DNS 安全性，即使 Internet 服务提供商或与它们的连接不受信任。

粗体部分是我加粗的。综合起来：

  • 非验证存根解析器只是AD在其响应中查找位，并相信递归服务器已对其进行了验证。它不会对RRSIG记录执行任何操作。想要根据该记录执行操作的应用程序RRSIG 应该直接请求该记录，并且不依赖于其包含在响应中。
  • 验证存根解析器必须执行自己的递归。这是验证从根服务器到与相关RRSIG记录关联的服务器是否具有有效签名的唯一方法。

了解了所有这些之后，我们需要确认设置标志dig时到底在做什么。我们可以从手册页中找到答案：+dnssec

   +[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不是作为验证存根解析器运行的（如果您愿意，可以通过数据包捕获进一步确认，因为它必须执行自己的递归），并且 BIND 服务器是不是代表其执行验证，因为响应没有返回ad答案的 OPT 伪部分中的位设置。（只是do，确认它do在原始查询中看到了）

相关内容