如果 DNS 服务器查找一条记录,但该记录缺失,它通常会“负面缓存”该记录缺失的事实,并在一段时间内不会尝试再次查找。我在请求函数关于负面缓存的 TTL 应该是,所以我猜这有点随意。在现实世界中,这些负面记录会保留多长时间?
答案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秒。
答案2
这取决于你对“否定查询”的确切定义,但无论哪种情况,这都记录在rfc2308«DNS 查询的负面缓存 (DNS NCACHE)»:
NXDOMAIN
- 如果解析成功,并且结果为
NXDOMAIN
,则响应将附带一条SOA
记录,其中包含NXDOMAIN
TTL(传统上称为MINIMUM
字段)。rfc2308#section-4
SERVFAIL
如果解析不成功,并导致超时(
SERVFAIL
),那么它可能根本不会被缓存,并且在任何情况下都不能缓存超过 5 分钟。rfc2308#section-7.1
请注意,在实践中,如果缓存服务器偶尔出现短暂的连接问题,则将这些结果缓存整整 5 分钟会大大降低客户端的体验(并且实际上很容易受到拒绝服务放大攻击,几秒钟的停机时间就会导致 DNS 的某些部分在整整五分钟内处于停机状态)。
在 BIND 9.9.6-S1(2014 年发布)之前,显然
SERVFAIL
根本没有缓存。a878301
(2014年9月4日)例如,在您提出问题时以及在 2014 年之前发布的所有 BIND 版本中,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年1月11日)
第二种策略是声称广泛使用的 DNS 客户端在无法访问所有 DNS 服务器时会做出特别邪恶的事情。这种说法的问题在于,这种说法是错误的。任何这样的客户端显然都是有缺陷的,无法在市场上生存:想想如果客户端的路由器短暂停机,或者客户端的网络暂时被淹没会发生什么。
总之,NXDOMAIN
响应将按照SOA
适用区域中指定的方式进行缓存,而SERVFAIL
不太可能被缓存,或者,如果被缓存,则最多需要两位数的秒数。
答案3
有一个 RFC 专门讨论这个主题:RFC 2308 - DNS 查询的负面缓存 (DNS NCACHE)。
相关阅读部分是5 - 缓存否定答案其中指出:
与正常答案一样,否定答案也具有生存时间 (TTL)。由于答案部分中没有可以应用此 TTL 的记录,因此必须通过其他方法承载 TTL。这是通过在答复的授权部分中包含来自区域的 SOA 记录来实现的。当授权服务器创建此记录时,其 TTL 取自 SOA.MINIMUM 字段和 SOA 的 TTL 中的最小值。此 TTL 以与正常缓存答案类似的方式递减,当达到零 (0) 时,表示缓存的否定答案不得再次使用。
首先让我们识别SOA.MINIMUM
RFC 中描述的 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
您可以看到,Google 名称服务器的 SOA TTL 和负 TTL 值都不同。在这种情况下,的负 TTL300
低于的 SOA TTL 。因此,Google 服务器在返回响应时应21600
使用 SOA 记录中的较低值:AUTHORITY SECTION
NXDOMAIN
$ 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
正如预期的那样,响应中的 SOA 记录的 TTLNXDOMAIN
为300
秒。
上述示例还表明,对同一查询很容易得到不同的答案。单个缓存解析器最终使用的答案取决于查询哪个权威域名服务器。
在我的测试中,我还发现一些递归(缓存)解析器不会返回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
。
词汇表: