主页 / server / 问题 / 674934
Accepted
s1lv3r
Asked: 2015-03-13 05:28:07 +0800 CST

从 host -a 输出正确计算 DNS TTL

  • 772

我试图弄清楚如何在 DNS 中处理 TTL（最后我试图找出切换域的最快方法），但不知何故我一直在解释 TTL 值。

例如，我今天移动了一个域，该域在将其移给我之前具有以下 DNS 记录：

主机-a example.com ns.old-provider.net

Trying "example.com"
Using domain server:
Name: ns.old-provider.net
Address: 0.0.0.0#53
Aliases: 

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45674
;; flags: qr aa rd; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 4

;; QUESTION SECTION:
;example.com.           IN  ANY

;; ANSWER SECTION:
example.com.        3600    IN  NS  ns9.old-provider.net.
example.com.        3600    IN  NS  ns.old-provider.net.
example.com.        180 IN  MX  10 mail.example.com.
example.com.        3600    IN  NS  ns8.old-provider.net.
example.com.        180 IN  A   0.0.0.0
example.com.        3600    IN  SOA ns.old-provider.net. info.old-provider.net. 2015012001 14400 3600 604800 3600

;; ADDITIONAL SECTION:
ns8.old-provider.net.   86400   IN  A   0.0.0.0
ns9.old-provider.net.   3600    IN  A   0.0.0.0
ns.old-provider.net.        86400   IN  A   0.0.0.0
mail.example.com.   180 IN  A   0.0.0.0

Received 258 bytes from 0.0.0.0#53 in 31 ms

我对上述输出的解释是，这个域应该在最多 3600 秒后解析到我的服务器（因为我同时更改了 NS 和 A 记录）。

正如我确实移动了上述域，在收到 TRANSFER ACK 3 小时后，它仍然解析到错误的 DNS 服务器：

host -a example.com 8.8.8.8
[...]

;; ANSWER SECTION:
example.com.        179 IN  A   0.0.0.0
example.com.        3599    IN  NS  ns9.old-provider.net.
example.com.        3599    IN  NS  ns.old-provider.net.
example.com.        179 IN  MX  10 mail.example.com
example.com.        3599    IN  NS  ns8.old-provider.net.
example.com.        3599    IN  SOA ns.old-provider.net. info.old-provider.net. 2015012001 14400 3600 604800 3600

如您所见，我正在使用 Google DNS 服务器进行检查，所以我想可以保存 TTL 得到尊重。

我肯定错过了什么。但我无法弄清楚 - 任何人都可以在这里给我一个提示吗？

问题是 SOA 记录的 TTL，所以在进行切换之前必须降低这个值？

编辑

挖掘 +trace +附加 example.com @8.8.8.8

; <<>> DiG 9.8.1-P1 <<>> +trace +additional example.com @8.8.8.8
;; global options: +cmd
.           1024    IN  NS  c.root-servers.net.
.           1024    IN  NS  i.root-servers.net.
.           1024    IN  NS  j.root-servers.net.
.           1024    IN  NS  d.root-servers.net.
.           1024    IN  NS  f.root-servers.net.
.           1024    IN  NS  g.root-servers.net.
.           1024    IN  NS  k.root-servers.net.
.           1024    IN  NS  a.root-servers.net.
.           1024    IN  NS  h.root-servers.net.
.           1024    IN  NS  l.root-servers.net.
.           1024    IN  NS  b.root-servers.net.
.           1024    IN  NS  e.root-servers.net.
.           1024    IN  NS  m.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 30 ms

de.         172800  IN  NS  z.nic.de.
de.         172800  IN  NS  f.nic.de.
de.         172800  IN  NS  a.nic.de.
de.         172800  IN  NS  l.de.net.
de.         172800  IN  NS  s.de.net.
de.         172800  IN  NS  n.de.net.
a.nic.de.       172800  IN  A   194.0.0.53
a.nic.de.       172800  IN  AAAA    2001:678:2::53
f.nic.de.       172800  IN  A   81.91.164.5
f.nic.de.       172800  IN  AAAA    2a02:568:0:2::53
l.de.net.       172800  IN  A   77.67.63.105
l.de.net.       172800  IN  AAAA    2001:668:1f:11::105
n.de.net.       172800  IN  A   194.146.107.6
n.de.net.       172800  IN  AAAA    2001:67c:1011:1::53
s.de.net.       172800  IN  A   195.243.137.26
z.nic.de.       172800  IN  A   194.246.96.1
;; Received 343 bytes from 2001:500:2f::f#53(2001:500:2f::f) in 179 ms

example.com.        86400   IN  NS  ns9.old-provider.net.
example.com.        86400   IN  NS  ns8.old-provider.net.
example.com.        86400   IN  NS  ns.old-provider.net.
;; Received 93 bytes from 0.0.0.0#53(0.0.0.0) in 39 ms

example.com.        180 IN  A   0.0.0.0
;; Received 45 bytes from 0.0.0.0#53(0.0.0.0) in 29 ms
domain-name-system

1 个回答

  1. Best Answer

    我无法确定答案，因为您使用的是混淆域，但是当您更改顶点NS记录时，验证引用NS记录和相应粘合记录的 TTL 也很重要。应该预期旧的名称服务器将在整个持续时间内继续查看查询。考虑到您正在运行的测试，这对我来说是最有可能出现的问题。

    作为背景，我将引导您了解我不久前所做的现有问答。接受的答案链接到 RFC2181（我经常使用它，因为它是为人类消费而设计的）：
    NS 记录在 DNS 域的顶点的作用是什么？

    我相信这里发生的事情是您的胶水记录被被动缓存。这在您的验证中不明显的原因是，如果尚未进行，对NSand记录的显式查询通常会触发权威查找。A基本上，胶水是被动地受到尊重，直到 TTL 过期或有人明确请求记录。

    最简单的确认方法是运行这个： dig +trace +additional example.com

    • 2

相关问题