如果DNS服务器查找记录而丢失，则通常会“负缓存”该记录丢失的事实，而不是尝试再次查找它。我在RFC中没有看到关于负缓存上TTL的任何信息，因此我猜测它有些武断。在现实世界中，这些负面记录会持续多久？

用于负缓存的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秒。

这取决于您对“否定查询”的确切定义，但是无论哪种情况，这都在rfc2308 «DNS查询的负缓存（DNS NCACHE）»中记录：

NXDOMAIN

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

SERVFAIL

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

  请注意，实际上，在这样的情况下将其缓存整整5分钟是减少客户端体验的好方法，如果客户端的缓存服务器偶尔会遇到短暂的连接问题（并使其很容易受到拒绝服务放大的影响，几秒钟的停机时间将导致DNS的某些部分在整整五分钟内停机）。

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

  例如，在您提出问题时以及在2014年之前发布的所有BIND版本中SERVFAIL，如果可以相信上述提交和有关9.9.6-S1中的首次引入的文档，则BIND递归解析器DID 根本不会缓存。

  在最新的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不太可能被缓存，或者，如果被缓存，则最多为两位数秒。

有一个专用于该主题的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秒）。

现在，让我们使用Google名称服务器执行相同的步骤：

$ 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

您可以看到，谷歌名称服务器的SOA TTL和负TTL值都有不同的值。在这种情况下，的负TTL 300低于的SOA TTL 21600。因此，AUTHORITY SECTION当返回NXDOMAIN响应时，google服务器应在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
• 递归名称服务器
• 权威名称服务器