第一次使用 ttl 1 天的负载均衡器源 DNS 名称创建 Route53 DNS 记录。
几天后，我们想将该值更改为另一个负载均衡器源 DNS 名称。我们是否需要先将目标 DNS 记录的 ttl 设置为较短的时间，例如 1 小时？然后在 1 小时后更改 DNS 值。它是否可以完美地刷新其 DNS 缓存并更新到新记录？
我有一个看起来像这样的 DNS 配置：
www.example.com 600 IN CNAME prod.myzone.l2.company.example
prod.myzone.l2.company.example 600 IN CNAME ssl-endpoint-12345.hostcorp.example
ssl-endpoint-12345.hostcorp.example 60 IN A 192.0.2.4
所以链中前两条 CNAME 记录的 TTL 为 10 分钟，最后一条 A 记录的 TTL 为 1 分钟
CNAME在prod.myzone.l2.company.example多个端点之间进行区域负载平衡，如果我的 DNS 提供商确定当前端点不健康，它会自动更新。出于这个原因，我想尽快将更改传播到prod.myzone.l2.company.exampleCNAME。
如果我想减少客户在prod.myzone.l2.company.example更改时看到的整体 TTL，仅减少prod.myzone.l2.company.example记录的 TTL 就足够了，还是我还需要减少www.example.com记录上的 TTL？
我以前没有在 Varnish 上尝试过这个。而且我必须承认，我上一次使用 Varnish 的经历要追溯到很久以前 - 版本 2.1.5 天！
我已将 varnish 6.x 设置为简单/基本的静态 http-cache。我已经从这个清漆中实现了我希望的大部分内容，然后我想到了将 cache-ttl 信息显示为响应标头。在这里，我遇到了障碍。我肯定做错了。可能 vcl_delivery 可能不会得到 beresp.ttl。我不知道。这是我添加到 vcl_deliver
set resp.http.X-TTL = "TTL (" + beresp.ttl +")";
我得到编译错误：
Mar 19 07:05:41 varnishd[55516]: Message from VCC-compiler:
Mar 19 07:05:41 varnishd[55516]: ('/etc/varnish/default.vcl' Line 97 Pos 40) -- (Pos 49)
Mar 19 07:05:41 varnishd[55516]: set resp.http.X-TTL = "TTL (" + beresp.ttl +")";
Mar 19 07:05:41 varnishd[55516]: ---------------------------------------##########------
Mar 19 07:05:41 varnishd[55516]: Not available in method 'vcl_deliver'.
我尝试将 beresp.ttl 分配为 vcl_backend_response 中的标头变量：
set beresp.http.x-ttl = beresp.ttl
那也没有用。
让我想知道，这是否可能？如果是这样，如何实现？
这是我的场景：
- 我有一个办公室，它通过 VPN 隧道连接到 AWS 以访问一些 EC2 实例。
- 办公室计算机通过 VPN 隧道使用 AWS Route 53 来解析私有托管区域。
- 私有托管区域包含位于办公室的资产的 A 记录。打印机、应用服务器等
- 办公室工作站配置为使用 AWS 的 DNS 服务器的内部地址（在具有 EC2 实例的子网中）。
一切都很好解决。
现在，为了应对 VPN 隧道故障以及 AWS DNS 服务器的可访问性故障，我将内部资产的 DNS 记录配置为具有 432,000 秒或 5 天的 TTL。基本上这给了我 5 天的时间在办公室工作站无法按名称解析内部资产之前重新建立 VPN 隧道。
但是，我注意到以下行为，想知道这对于解析器和（Windows 10）客户端是否“正常”？
- 查询权威服务器显示TTL为432,000
- 查询解析器显示 TTL 为 86,400
- 查询客户端（例如
ipconfig /displaydns）也显示 86,400（和减量，这是正常行为）。
我已尝试更改 TTL，看来 Windows 客户端将尊重任何小于或等于 86,400 的 TTL 值。
为什么权威服务器级别的记录的 TTL 432,000 没有传播到解析器，因此没有传播到客户端？我是否误解了 TTL 如何工作的基本原理？
先谢谢了！
总的来说，我对 DNS 的工作有些怀疑——即使我有理论基础。让我们考虑以下输出：
[user@host ~]$ dig google.com
[...]
;; ANSWER SECTION:
google.com. 102 IN A 172.217.3.174
[user@host ~]$ dig -x 172.217.3.174
[...]
;; ANSWER SECTION:
174.3.217.172.in-addr.arpa. 17514 IN PTR sea15s11-in-f14.1e100.net.
174.3.217.172.in-addr.arpa. 17514 IN PTR sea15s11-in-f174.1e100.net.
[user@host ~]$ dig -x 172.217.3.174
[...]
;; ANSWER SECTION:
174.3.217.172.in-addr.arpa. 299 IN PTR sea15s11-in-f14.1e100.net.
174.3.217.172.in-addr.arpa. 299 IN PTR sea15s11-in-f174.1e100.net.
[user@host ~]$ dig -x 172.217.3.174
[...]
;; ANSWER SECTION:
174.3.217.172.in-addr.arpa. 299 IN PTR sea15s11-in-f14.1e100.net.
174.3.217.172.in-addr.arpa. 299 IN PTR sea15s11-in-f174.1e100.net.
[user@host ~]$ dig -x 172.217.3.174
[...]
;; ANSWER SECTION:
174.3.217.172.in-addr.arpa. 298 IN PTR sea15s11-in-f14.1e100.net.
174.3.217.172.in-addr.arpa. 298 IN PTR sea15s11-in-f174.1e100.net.
[user@host ~]$ dig -x 172.217.3.174
[...]
;; ANSWER SECTION:
174.3.217.172.in-addr.arpa. 297 IN PTR sea15s11-in-f14.1e100.net.
174.3.217.172.in-addr.arpa. 297 IN PTR sea15s11-in-f174.1e100.net.
TTL字段到底是什么意思？
在第一个答案中是：17514，进一步的 299、298...
我知道定义，类似于：客户端应在缓存中保留答案多长时间（限制对 DNS 的查询）
但是，
1. 它只与应用程序客户端有关吗？毕竟，linux 不缓存 DNS 答案，所以这个字段无关紧要。
2. 它是否也与辅助 DNS 服务器有关（换句话说，要为该特定记录保留来自主 DNS 的信息多长时间？）？在 master 中刷新 SOA 字段呢？
3. 越来越小是怎么回事？谁对此负责？我的客户端（在 RHat 上挖掘）或 DNS 服务器？权威还是奴隶？/etc/resolv.conf?
顺便说一句：我认为 master 和 Authorative 与 slave=secondary=non-Authorative 相同
假设我的域 example.com 已将 TTL 设置为 86400。如果我通过注册商面板将其更改为 60，何时会发生此更改？它需要86400秒吗？或者它会是即时的吗？
我在网上找不到任何关于此的内容。
是否有任何方法可以返回陈旧的 DNS 结果？我所说的陈旧，是指 TTL 已过期，但无法获得新记录，可能是由于名称服务器不可用。
据我所知，至少 bind 9 没有任何机制。我也无法在绑定 10 中找到它的任何参考。对于我的生活，我不知道为什么。DNS 没有理由不能使用与 HTTP 相同的缓存规则和方法。站点可以选择禁用或调整其缓存首选项。
这对我来说似乎很简单，我希望我错过了一些可以与我分享的新发展:)
PS 我知道有一些最终用户工具可以做到这一点（opendns、dnsmasq 等），但这会剥夺域所有者的所有控制权，并迫使最终用户经常对区域文件应该如何做出错误的猜测缓存超出其 TTL。
对于正常的 DNS 查找，可以使用 Dig 获得答案，包括 DNS 记录的剩余 TTL。如果该答案来自缓存，则 TTL 将“倒计时”，直到下一个权威查询，以及该查询出现之前的剩余时间（如本问题所述：检查 nameserver 的剩余 TTL）。
如何获得负缓存记录的相应“剩余时间”？根据定义，答案是“NXDOMAIN”或不存在的域；除了 SOA 记录（最大可能时间值）之外，似乎没有与此答案相关联的 TTL。
我还可以直接访问 [BIND 9] 服务器，因此也欢迎直接从缓存中获取此信息的方法，尽管我希望有一种基于查询的方法来执行此操作。
我正在从 Rackspace ta 专用服务器的云服务器迁移我们的应用程序。
我想将应用程序关闭约 5 分钟以将数据从云服务器复制到专用服务器，因此我不希望在复制数据后请求转到旧服务器。
我想将我们的 DNS 记录指向新服务器，但 TTL 设置为 24 小时。我已将其更改为 300 秒。在更新域指向/复制数据的 ip 之前，我是否需要等待 24 小时？
在清除 DNS 缓存之前是否有一个标准的持续时间，以便如果分心的操作员或卡住的键将 TTL 86400 变为 864000000，您最终不会得到权威资源记录甚至整个 DNS 区域，其更改不会承认 27.397 年？
而且，如果没有针对此类错误的保护，那么允许 TTL 持续时间长达 68 年而不是最大值可能是一个月的原因是什么？