如何测试DNS信息是否已传播？

16

我为我的一个子域设置了一个新的DNS条目（我尚未设置任何Apache虚拟主机或类似的东西）。如何检查DNS信息已传播？

我假设我可以简单地ping my.subdomain.com假设，如果可以解决，它将显示我在A记录中指定的IP地址。但是，我不知道我是否假设正确。检查此信息的最佳方法是什么？

domain-name-system 
— 安德鲁
source
3
不是愚蠢的问题。找出这种事情并不是那么简单。
— aseq 2012年
1
我同意@aseq的观点，这不是一个愚蠢的问题，但是“尝试一下然后看看”也会为您提供答案。这也是Google只需付出最少的努力即可轻松回答的问题（搜索How to test if DNS information has propagated-血腥的标题会产生良好的Google结果）。
— voretaq7 2012年
4
我不认为您在浪费人们的时间。您的问题引起了一些宝贵的反响。您永远不会知道一个看似简单的问题，可能只是“用谷歌搜索”。该论坛的价值之一就是可以很容易地扩展答案和问题。
— aseq 2012年
1
@andrew问我们很多人认为简单的问题没有错-由于网站如何被索引/排名，这可能是几天后该字符串在Google上排名最高的结果。总的来说，尽管Google是一个更好（更快）的地方：如果Google不知道，那么请在这里询问（Google将会学习）:-)
— voretaq7
1
我想出了为什么我没有尝试的方法。显然，我们的网络配置方式也必须在本地DNS中添加新的子域。因此可以从外部访问子域，而不能在我正在测试的网络中访问。= [但是在指定外部服务器时使用nslookup和dig使其成功，因此我可以验证外部DNS信息。
— Andrew

Answers:

15

您可以使用dig或nslookup，将您的（或如果您自己运行的话，请与提供商联系）名称服务器为ns1.example.com。

使用nslookup：

nslookup - ns1.example.com

在提示符下键入：

my.example.com

如果它解决了您的期望，那么它将起作用。它应该给你类似的东西：

Name:   example.com
Address: 192.0.43.10

传播到互联网的其他地方可能还需要一段时间，这是您无法控制的。

使用挖：

dig@ns1.example.com my.example.com

您应该看到类似以下内容：

;; ANSWER SECTION:
example.com.        172800  IN  A   192.0.43.10

仅使用ping可能会给您一个想法，但只有在ping传播后（由远程名称服务器缓存可能是描述它的更好方法），并且可能需要刷新本地dns缓存。尽管在您的情况下这并不适用，因为这是新记录。在这种情况下，它应该立即可用。上面的方法在给您一个想法而不是ping它时更为精确。

如果使用Windows，则命令和语法可能会略有不同，但是非常相似。

— 平等
source
3
+1如果您要对DNS进行任何操作，请获取的副本dig（* nix系统已经拥有它，有适用于Windows的各种版本）。
— 克里斯·S
3
-1。对不起。我确实是，但是这个答案“传播”了DNS记录传播的神话，但他们肯定不会传播。您要查找的术语是“缓存”，这是DNS记录根据记录的TTL发生的情况。由于OP指的是新的DNS记录，因此不会发生缓存，因此，任何要解析有问题的记录的DNS客户端都将得到答案...立即...因为该客户端无法对其进行缓存...或该客户端DNS服务器...或任何其他DNS服务器。DNS记录不会传播到“互联网的其余部分”。
— joeqwerty
1
joeqwerty是完全正确的。dns服务器将在预定时间内缓存肯定或否定命中。但是，除了原始帖子外，您还可以检查一些公共名称服务器，包括旧的GTE（4.2.2.1、4.2.2.2、4.2.2.3和4.2.2.4）和google（8.8.8.8、8.8）。 4.4）。简单的经验法则，对于正面或负面的打击，新更改可能要持续ttl的时间。但是，在某些情况下，应用程序会执行错误的逻辑并长时间缓存答案。
— bangdang 2012年
2
我认为您确实不必坚持确切的定义来阐明观点。此外，我认为传播不是一个坏词。从DNS记录的缓存确实扩展到更广泛的服务器的意义上讲，它确实涵盖了该主题。传播是指传播。我更新了答案，以反映新记录可立即使用的事实。
— aseq 2012年
1
@aseq，这是一个误导性术语。大多数情况下，认为/谈论DNS有点“传播”的ppl不知道DNS的工作原理。他们通常说一句废话，例如“ DNS信息在Internet /地球上传播需要2-3天”，依此类推。
— 12
7

您无法测试DNS记录传播，因为不会发生DNS传播。您可以测试的是DNS客户端或服务器是否缓存了特定的DNS记录。

由于这是新的DNS记录，因此不会发生缓存。假设您的名称服务器已在父服务器上正确注册，并且您的名称服务器正常运行，则此DNS记录应立即可用于所有DNS客户端或服务器。

— 乔伊维蒂
source
很高兴为您提供帮助
— joeqwerty 2012年
有什么方法可以检查我是否输入了有效的IP？我只是想确保我使用的IP地址正确。我与之交谈的人似乎认为，如果我还没有设置Apache VHost，则ping操作将失败。
— Andrew
Ping不是DNS测试工具。Dig和Nslookup是DNS测试工具。使用Dig或Nslookup测试新的DNS记录。根据您的名称服务器查询记录，然后针对其他名称服务器查询记录，以确保它们找到了您的名称服务器，并且您的名称服务器以正确的答案响应。
— joeqwerty
1
“传播”是在人们无法理解实际情况（即缓存老化和过期）的情况下制定的概念。DNS提供商需要说的是“您的数据要等到XX小时后才能看到”。为何需要这样的解释，以致看起来DNS提供程序看起来像是延迟。太多的人“无法处理真相”。编造的“传播”是一个有效的封面故事。真正的DNS怪才知道真正发生了什么，因为他们阅读了技术细节。
— Skaperen
确实如此……我只是讨厌使用一个“传播”​​对DNS工作原理的误解的术语。
— joeqwerty
5

尽管其他答案都不错，但请记住，传播给您的内容可能不会传播给我。我通常使用http://www.whatsmydns.net/来查看传播的过程，而不是使用DIG或NSlookup并花一个小时检查世界各地的DNS服务器。

— 吉姆·B
source
DNS没有传播，这个术语对所有不会读RFC的Lamer都具有误导性，所以请不要<strike> propagate </ strike>使用此术语。;-D
— poige
1
当然，DNS会以RFC的形式传播，前提是读者理解信息可以随着服务器执行查找和缓存而传播。当lamers阅读RFC然后想知道为什么服务器上的记录与来自其他服务器的查询结果不匹配时，这一点尤其明显。他们发现，传播具有“广泛传播”的定义（这正是需要检查的内容-更新记录的分布）
— Jim B
既不分发也不传播（主机到从机除外）。
— poige
从有时花将近一天的时间来获取在根域名服务器上加载的.com域中所做的更改（可能追溯到.com在根目录上！）可能是一个遗物
— Cakemox 2012年
@ poige-感谢您验证您对DNS缓存工作原理的了解。我建议阅读有关DNS如何工作的RFC，并可能检查我链接到的网站以获得真实示例。
— Jim B
3

确保您的授权路径中的权威DNS服务器正确回答的最简单方法是使用dig +trace：

; <<>> DiG 9.7.3 <<>> +trace www.google.com a
;; global options: +cmd
.           80050   IN  NS  m.root-servers.net.
.           80050   IN  NS  f.root-servers.net.
.           80050   IN  NS  i.root-servers.net.
.           80050   IN  NS  h.root-servers.net.
.           80050   IN  NS  c.root-servers.net.
.           80050   IN  NS  k.root-servers.net.
.           80050   IN  NS  d.root-servers.net.
.           80050   IN  NS  g.root-servers.net.
.           80050   IN  NS  a.root-servers.net.
.           80050   IN  NS  b.root-servers.net.
.           80050   IN  NS  e.root-servers.net.
.           80050   IN  NS  l.root-servers.net.
.           80050   IN  NS  j.root-servers.net.
;; Received 509 bytes from 192.168.1.1#53(192.168.1.1) in 0 ms

com.            172800  IN  NS  c.gtld-servers.net.
com.            172800  IN  NS  k.gtld-servers.net.
com.            172800  IN  NS  g.gtld-servers.net.
com.            172800  IN  NS  d.gtld-servers.net.
com.            172800  IN  NS  j.gtld-servers.net.
com.            172800  IN  NS  f.gtld-servers.net.
com.            172800  IN  NS  i.gtld-servers.net.
com.            172800  IN  NS  m.gtld-servers.net.
com.            172800  IN  NS  e.gtld-servers.net.
com.            172800  IN  NS  a.gtld-servers.net.
com.            172800  IN  NS  l.gtld-servers.net.
com.            172800  IN  NS  h.gtld-servers.net.
com.            172800  IN  NS  b.gtld-servers.net.
;; Received 504 bytes from 198.41.0.4#53(a.root-servers.net) in 127 ms

google.com.     172800  IN  NS  ns2.google.com.
google.com.     172800  IN  NS  ns1.google.com.
google.com.     172800  IN  NS  ns3.google.com.
google.com.     172800  IN  NS  ns4.google.com.
;; Received 168 bytes from 192.43.172.30#53(i.gtld-servers.net) in 20 ms

www.google.com.     604800  IN  CNAME   www.l.google.com.
www.l.google.com.   300 IN  A   173.194.35.180
www.l.google.com.   300 IN  A   173.194.35.178
www.l.google.com.   300 IN  A   173.194.35.176
www.l.google.com.   300 IN  A   173.194.35.177
www.l.google.com.   300 IN  A   173.194.35.179
;; Received 132 bytes from 216.239.34.10#53(ns2.google.com) in 27 ms

这将跟随对您的查询具有权威性的名称服务器的委派。最后一个答案通常是您最关心的答案，但是该跟踪很有帮助，因为它将显示谁在为每个代表团回答。但是，如果要更改名称服务器，这将非常有用。

请记住，跟踪将直接查询权威服务器，因此没有缓存。这是最佳答案，表明已按预期返回了答案，但是，这并不是最终用户可能会遇到的好迹象。但是，由于您无论如何都不经常控制其他人的缓存名称服务器（除了有远见的降低您的TTL之外，请等待原始TTL，进行更改，然后再恢复TTL），因此通常不值得事后检查。

— Cakemox
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.