中间名称服务器中的 DNS TTL 过期后发生了什么？
What happened after DNS TTL expired in intermediate Name Server?
我有一些问题想更好地理解 DNS 机制：
1) 我知道在客户端和权威 DNS 服务器之间有一些像 ISP 那样的中间 DNS 服务器。其他类型的它们是什么以及在哪里？
2)中间DNS服务器NS记录的TTL过期后，什么时候刷新域名地址？客户要求？或者在到期后立即刷新记录？
谢谢。
您的问题与编程无关，因此与主题无关。
但是：
I know between clients and authoritative DNS server there are some intermediate DNS servers like ISP's one. What and where are the other types of them?
只有两种类型的 DNS 服务器（我们暂时搁置存根案例）：它是 权威 名称服务器（保存有关某些域的信息并作为它的信任源）或附加到缓存的递归，它基本上从没有数据开始，然后将根据它获得的查询逐步执行各种查询以获取信息。
从技术上讲，单个服务器可以做到这两点，但至少出于缓存的原因和不同的客户端数量，这是一个坏主意：权威名称服务器通常对任何客户端开放，因为它需要 "broadcast" 它的数据无处不在，而递归名称服务器通常仅适用于选定的客户端列表（如 ISP 客户端）。
目前存在开放的 public 大型组织的递归名称服务器：CloudFlare、Google、Quad9 等。但是，他们拥有处理所有问题的硬件、链接和人力在 public 个递归名称服务器中，例如带有放大的 DDOS。
从技术上讲，您可以拥有一个递归名称服务器场，就像大型 ISP 需要做的（或上述大型 public 那样），因为任何单个实例都无法支持所有客户端查询，并且它们可以共享单个缓存或在层次结构中工作，底部的缓存将其数据发送到另一个上游递归名称服务器等。
After the TTL of an NS record is expired in intermediate DNS servers, when do they refresh the addresses of names? Clients request? or right after expiration, they refresh records?
这种历史性的天真方式可以概括为：请求到达，我的缓存中有它吗？如果不是，则在外部查询并缓存它。如果是，它在我的缓存中是否已过期？如果否，将其发送给客户端，但如果是，我们需要将其从缓存中删除，然后就像它从一开始就不在缓存中一样。
然后你有各种变化：
- 一些缓存并没有完全遵循 TTL：一些缓存根据它们自己的本地策略限制了太低或太高的值。对该规范最认同的读物是 TTL 指示将记录保存在缓存中的最长时间，这意味着客户端可以自由地放弃它。但是，如果它认为它太低，它不应该将其重写为更高的值。
- 缓存可以与 reboots/restarts 一起保存，并且可以预取，尤其是 "popular" 记录；在某种程度上，根 NS 的列表在启动时预取并与内部硬编码列表进行比较，以便更新它
- 缓存，尤其是 RAM 中的缓存，通常在 "oldest removed" 情况下可能需要修剪，以便为沿途出现的新记录找到位置。
- 因此，根据缓存的管理方式和请求它具有的功能，可能会有一个后台任务来监视过期和刷新记录。
我建议你看看 unbound 作为递归名称服务器，因为它有各种围绕 TTL 处理的设置，所以你可以学习东西，然后阅读代码本身（这让我们回到-主题类型）。
您还可以阅读此文档：https://www.ietf.org/archive/id/draft-wkumari-dnsop-hammer-03.txt IETF Internet-Draft 关于：
The principle is that popular RRset in the cache are fetched, that is
to say resolved before their TTL expires and flushed. By fetching
RRset before they are being queried by an end user, that is to say
prefetched, HAMMER is expected to improve the quality of experience
of the end users as well as to optimize the resources involved in
large DNSSEC resolving platforms.
确保阅读附录 A，其中包含许多有用的示例，例如：
Unbound already does this (they use a percentage of TTL, instead of a number
of seconds).
OpenDNS that they also implement something similar.
BIND as of 9.10, around Feb
2014 now implements something like this
(https://deepthought.isc.org/article/AA-01122/0/Early-refresh-of-cache-records-cache-prefetch-in-BIND-9.10.html), and enables it by
default.
A number of recursive resolvers implement techniques similar to the
techniques described in this document. This section documents some
of these and tradeoffs they make in picking their techniques.
举个例子，绑定一个，你可以阅读：
BIND 9.10 prefetch works as follows. There are two numbers that control it. The first number is the "eligibility". Only records that arrive with TTL values bigger than the configured elegibility will be considered for prefetch. The second number is the "trigger". If a query arrives asking for data that is cached with fewer than "trigger" seconds left before it expires, then in addition to returning that data as the reply to the query, BIND will also ask the authoritative server for a fresh copy. The intention is that the fresh copy would arrive before the existing copy expires, which ensures a uniform response time.
BIND 9.10 prefetch values are global options. You cannot ask for different prefetch behavior in different domains. Prefetch is enabled by default. To turn it off, specify a trigger value of 0. The following command specifies a trigger value of 2 seconds and an eligibility value of 9 seconds, which are the defaults.
我有一些问题想更好地理解 DNS 机制：
1) 我知道在客户端和权威 DNS 服务器之间有一些像 ISP 那样的中间 DNS 服务器。其他类型的它们是什么以及在哪里？
2)中间DNS服务器NS记录的TTL过期后，什么时候刷新域名地址？客户要求？或者在到期后立即刷新记录？
谢谢。
您的问题与编程无关，因此与主题无关。
但是：
I know between clients and authoritative DNS server there are some intermediate DNS servers like ISP's one. What and where are the other types of them?
只有两种类型的 DNS 服务器（我们暂时搁置存根案例）：它是 权威 名称服务器（保存有关某些域的信息并作为它的信任源）或附加到缓存的递归，它基本上从没有数据开始，然后将根据它获得的查询逐步执行各种查询以获取信息。
从技术上讲，单个服务器可以做到这两点，但至少出于缓存的原因和不同的客户端数量，这是一个坏主意：权威名称服务器通常对任何客户端开放，因为它需要 "broadcast" 它的数据无处不在，而递归名称服务器通常仅适用于选定的客户端列表（如 ISP 客户端）。
目前存在开放的 public 大型组织的递归名称服务器：CloudFlare、Google、Quad9 等。但是，他们拥有处理所有问题的硬件、链接和人力在 public 个递归名称服务器中，例如带有放大的 DDOS。
从技术上讲，您可以拥有一个递归名称服务器场，就像大型 ISP 需要做的（或上述大型 public 那样），因为任何单个实例都无法支持所有客户端查询，并且它们可以共享单个缓存或在层次结构中工作，底部的缓存将其数据发送到另一个上游递归名称服务器等。
After the TTL of an NS record is expired in intermediate DNS servers, when do they refresh the addresses of names? Clients request? or right after expiration, they refresh records?
这种历史性的天真方式可以概括为：请求到达，我的缓存中有它吗？如果不是，则在外部查询并缓存它。如果是，它在我的缓存中是否已过期？如果否，将其发送给客户端，但如果是，我们需要将其从缓存中删除，然后就像它从一开始就不在缓存中一样。
然后你有各种变化：
- 一些缓存并没有完全遵循 TTL：一些缓存根据它们自己的本地策略限制了太低或太高的值。对该规范最认同的读物是 TTL 指示将记录保存在缓存中的最长时间，这意味着客户端可以自由地放弃它。但是，如果它认为它太低，它不应该将其重写为更高的值。
- 缓存可以与 reboots/restarts 一起保存，并且可以预取，尤其是 "popular" 记录；在某种程度上，根 NS 的列表在启动时预取并与内部硬编码列表进行比较，以便更新它
- 缓存，尤其是 RAM 中的缓存，通常在 "oldest removed" 情况下可能需要修剪，以便为沿途出现的新记录找到位置。
- 因此，根据缓存的管理方式和请求它具有的功能，可能会有一个后台任务来监视过期和刷新记录。
我建议你看看 unbound 作为递归名称服务器，因为它有各种围绕 TTL 处理的设置，所以你可以学习东西，然后阅读代码本身（这让我们回到-主题类型）。
您还可以阅读此文档：https://www.ietf.org/archive/id/draft-wkumari-dnsop-hammer-03.txt IETF Internet-Draft 关于：
The principle is that popular RRset in the cache are fetched, that is to say resolved before their TTL expires and flushed. By fetching RRset before they are being queried by an end user, that is to say prefetched, HAMMER is expected to improve the quality of experience of the end users as well as to optimize the resources involved in large DNSSEC resolving platforms.
确保阅读附录 A，其中包含许多有用的示例，例如：
Unbound already does this (they use a percentage of TTL, instead of a number of seconds).
OpenDNS that they also implement something similar.
BIND as of 9.10, around Feb 2014 now implements something like this (https://deepthought.isc.org/article/AA-01122/0/Early-refresh-of-cache-records-cache-prefetch-in-BIND-9.10.html), and enables it by default.
A number of recursive resolvers implement techniques similar to the techniques described in this document. This section documents some of these and tradeoffs they make in picking their techniques.
举个例子，绑定一个，你可以阅读：
BIND 9.10 prefetch works as follows. There are two numbers that control it. The first number is the "eligibility". Only records that arrive with TTL values bigger than the configured elegibility will be considered for prefetch. The second number is the "trigger". If a query arrives asking for data that is cached with fewer than "trigger" seconds left before it expires, then in addition to returning that data as the reply to the query, BIND will also ask the authoritative server for a fresh copy. The intention is that the fresh copy would arrive before the existing copy expires, which ensures a uniform response time.
BIND 9.10 prefetch values are global options. You cannot ask for different prefetch behavior in different domains. Prefetch is enabled by default. To turn it off, specify a trigger value of 0. The following command specifies a trigger value of 2 seconds and an eligibility value of 9 seconds, which are the defaults.