负 DNS 缓存通常持续多长时间？

Question

如果 DNS 服务器查找记录但它丢失了，它通常会“负面缓存”该记录丢失的事实，并且暂时不会再次尝试查找它。我在RFC 中没有看到关于负缓存的 TTL 应该是什么，所以我猜这有点武断。在现实世界中，这些负面记录会保留多久？

Answer 1

负缓存的 TTL 不是任意的。它取自位于请求记录所属区域顶部的 SOA 记录（如果它存在）。例如：

example.org.    IN      SOA     master-ns1.example.org. Hostmaster.example.org. (
            2012091201 43200 1800 1209600 86400 )

SOA 记录中的最后一个值（“86400”）是要求客户端在example.org..

如果客户端请求doesnotexist.example.org.，它将缓存结果 86400 秒。

Answer 2

这取决于您对“否定查询”的确切定义，但在任何一种情况下，这都记录在rfc2308 «DNS 查询的否定缓存 (DNS NCACHE)» 中：

NXDOMAIN

• 如果解析成功并且结果为NXDOMAIN，则响应将带有一个SOA记录，其中包含NXDOMAINTTL（传统上称为MINIMUM字段）。 rfc2308#section-4

SERVFAIL

• 如果解析不成功，并导致超时 ( SERVFAIL)，那么它也可能根本不缓存，并且在所有情况下都不得缓存超过 5 分钟。 rfc2308#section-7.1

  请注意，在实践中，如果他们的缓存服务器偶尔遇到短暂的连接问题（并有效地使其容易受到拒绝服务放大，其中几秒钟的停机时间将导致 DNS 的某些部分停机整整五分钟）。

  在 BIND 9.9.6-S1（2014 年发布）之前，显然SERVFAIL根本没有缓存。 a878301(2014-09-04)

  例如，在你的问题，并在BIND的所有版本的发布时间之前的2014年，BIND递归解析器没有缓存SERVFAIL可言，如果上述承诺和有关9.9.6-S1率先引进的文件是可以相信的.

  在最新的 BIND 中，默认servfail-ttl值为1s，并且设置被硬编码为上限30s（代替 RFC 规定的上限300s）。 90174e6(2015-10-17)

  此外，以下是有关此事的一些值得注意的引述：

  • https://kb.isc.org/article/AA-01178/ (2014/2016-01-07)

  缓存 SERVFAIL 响应的结果包括一些被认为对客户端体验有害的情况，特别是当向客户端呈现 SERVFAIL 的原因是暂时的并且来自立即重试查询将是更合适的动作。

  • http://cr.yp.to/djbdns/third-party.html (2003-01-11)

  第二种策略是声称广泛的 DNS 客户端在无法访问所有 DNS 服务器时会做一些特别邪恶的事情。这个论点的问题在于该主张是错误的。任何这样的客户端显然都是有问题的，将无法在市场上生存：考虑如果客户端的路由器短暂出现故障，或者客户端的网络暂时被淹没会发生什么。

总之，NXDOMAIN响应将按照SOA适用区域的指定进行缓存，而SERVFAIL不太可能被缓存，或者，如果被缓存，它最多是两位数的秒数。

Answer 3

有一个专门针对此主题的RFC：RFC 2308 - DNS 查询的负缓存 (DNS NCACHE)。

要阅读的相关部分是5 - 缓存否定答案，其中指出：

像正常答案一样，否定答案也有生存时间（TTL）。由于答案部分中没有可以应用此 TTL 的记录，因此必须通过其他方法携带 TTL。这是通过在回复的授权部分中包含来自区域的 SOA 记录来完成的。当权威服务器创建此记录时，其 TTL 取自 SOA.MINIMUM 字段和 SOA 的 TTL 中的最小值。此 TTL 以与正常缓存答案类似的方式递减，并且在达到零 (0) 时表示不得再次使用缓存的否定答案。

首先让我们确定SOA.MINIMUMRFC 中描述的 SOA TTL。TTL 是记录类型之前的数字IN（900下例中的秒数）。而最小值是记录中的最后一个字段（86400下例中的秒数）。

$ dig serverfault.com soa @ns-1135.awsdns-13.org +noall +answer +multiline

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> serverfault.com soa @ns-1135.awsdns-13.org +noall +answer +multiline
;; global options: +cmd
serverfault.com.    900 IN SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. (
                1          ; serial
                7200       ; refresh (2 hours)
                900        ; retry (15 minutes)
                1209600    ; expire (2 weeks)
                86400      ; minimum (1 day)
                )

现在让我们看一些示例，该serverfault.com区域是说明性的，因为它具有来自两个不同配置的不同提供商的权威服务器。

让我们找到区域的权威域名服务器serverfault.com：

$ host -t ns serverfault.com
serverfault.com name server ns-860.awsdns-43.net.
serverfault.com name server ns-1135.awsdns-13.org.
serverfault.com name server ns-cloud-c1.googledomains.com.
serverfault.com name server ns-cloud-c2.googledomains.com.

然后使用 aws 名称服务器检查 SOA 记录：

$ dig serverfault.com soa @ns-1135.awsdns-13.org | grep 'ANSWER SECTION' -A 1
;; ANSWER SECTION:
serverfault.com.    900 IN  SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

从中我们可以看出SOA记录的TTL是900秒，负的TTL值是86400秒。的 SOA TTL 值900较低，因此我们希望使用此值。

现在，如果我们查询一个不存在域的权威服务器，我们应该得到一个没有答案的响应，并且在权威部分有一个 SOA 记录：

$ dig nxdomain.serverfault.com @ns-1135.awsdns-13.org

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> nxdomain.serverfault.com @ns-1135.awsdns-13.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51948
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nxdomain.serverfault.com.  IN  A

;; AUTHORITY SECTION:
serverfault.com.    900 IN  SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

;; Query time: 125 msec
;; SERVER: 205.251.196.111#53(205.251.196.111)
;; WHEN: Tue Aug 20 15:49:47 NZST 2019
;; MSG SIZE  rcvd: 135

当递归（缓存）解析器收到此答案时，它将解析 中的 SOA 记录AUTHORITY SECTION并使用此记录的 TTL 来确定它应缓存否定结果的时间（在本例中为900秒）。

现在让我们对谷歌域名服务器执行相同的步骤：

$ dig serverfault.com soa @ns-cloud-c2.googledomains.com | grep 'ANSWER SECTION' -A 1
;; ANSWER SECTION:
serverfault.com.    21600   IN  SOA ns-cloud-c1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300

您可以看到 google 名称服务器对于 SOA TTL 和负 TTL 值具有不同的值。在这种情况下，负 TTL300低于 SOA TTL 21600。因此，谷歌服务器AUTHORITY SECTION在返回NXDOMAIN响应时应该使用SOA 记录中较低的值：

$ dig nxdomain.serverfault.com @ns-cloud-c2.googledomains.com

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> nxdomain.serverfault.com @ns-cloud-c2.googledomains.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 25920
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;nxdomain.serverfault.com.  IN  A

;; AUTHORITY SECTION:
serverfault.com.    300 IN  SOA ns-cloud-c1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300

;; Query time: 130 msec
;; SERVER: 216.239.34.108#53(216.239.34.108)
;; WHEN: Tue Aug 20 16:05:24 NZST 2019
;; MSG SIZE  rcvd: 143

正如预期的那样，NXDOMAIN响应中SOA 记录的 TTL是300秒。

上面的示例还演示了针对同一查询获得不同答案是多么容易。单个缓存解析器最终使用的答案取决于查询的权威 namserver。

在我的测试中，我还观察到一些递归（缓存）解析器不会AUTHORITY SECTION为后续请求返回带有递减 TTL 的 SOA 记录，而其他的会返回。

例如 cloudflare 解析器（注意递减的 TTL 值）：

$ dig nxdomain.serverfault.com @1.1.1.1 | grep 'AUTHORITY SECTION' -A 1
;; AUTHORITY SECTION:
serverfault.com.    674 IN  SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
$ dig nxdomain.serverfault.com @1.1.1.1 | grep 'AUTHORITY SECTION' -A 1
;; AUTHORITY SECTION:
serverfault.com.    668 IN  SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

虽然 AWS VPC 中的默认解析器只会在第一个请求时使用授权部分进行响应：

$ dig nxdomain.serverfault.com @169.254.169.253 | grep 'AUTHORITY SECTION' -A 1
;; AUTHORITY SECTION:
serverfault.com.    300 IN  SOA ns-cloud-c1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300
$ dig nxdomain.serverfault.com @169.254.169.253 | grep 'AUTHORITY SECTION' -A 1 | wc -l
0

注意：此答案解决了答案的行为NXDOMAIN。

词汇表：

• 区
• SOA
• TTL
• 递归名称服务器
• 权威域名服务器