服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 什么可能导致DNS不传播？
Intereting Posts
推广新的Exchange服务器，解除旧的进程 ESXi 4.1中没有显示多个SSD 不同服务器中的两个网站具有相同的cookie_domain，但不共享会话 Nginx使用WordPressredirect循环 Active Directory跨域身份validation 起搏器未检测到节点断开 亚马逊EC2 DNS不能全球回答 在VirtualBoxnetworkingconfiguration中的PXE引导服务器 什么时候需要在日志旋转的PID？ 使用HTTPS-Enforcer Chrome扩展，正常的ping将由不同的站点回答 Dockerfiles组织 Suphp连接在错误日志中由同位体重置 在EC2中的Windows上“很好”的过程 “服务”命令和环境variables firewalld：麻烦转发端口25而其他端口转发就好，“富规则”日志显示NO条目

什么可能导致DNS不传播？

我在15个小时前将Godaddy域名（ihearthawaii.com）移到了数字海洋液滴中。 通过像（whatsmydns.net）这样的网站跟踪DNS传播，我注意到传播正在挣扎。 它会传播到某些服务器，但一个小时左右后，它们就会消失。 这一直在发生。 这几乎就像是同时撤消传播。 一个小时前，我有8个绿色的复选标记，现在只有5个。

有没有人见过这样的事情？ 有没有什么办法解决这一问题？

我使用digitalocean名称服务器，他们似乎是好的。 我也尝试intodns和dnscheck寻找configuration问题，但没有真正突出。

在DNS未能在全球范围内传播 ，似乎问题本身就消失了。 但我想知道如何找出这种情况的原因。

我的数字海洋的区域文件 

$TTL 1800 @ IN SOA NS1.DIGITALOCEAN.COM. hostmaster.ihearthawaii.com. ( 1398835453 ; last update: 2014-04-30 05:24:13 UTC 3600 ; refresh 900 ; retry 1209600 ; expire 1800 ; ttl ) IN NS NS1.DIGITALOCEAN.COM. NS NS2.DIGITALOCEAN.COM. NS NS3.DIGITALOCEAN.COM. @ IN A 128.199.249.146 www CNAME @

无论您在区域内的NSlogging中设置的TTL如何，注册商对DNS服务器的更改通常最多需要48小时才能传播。 

 dig +trace www.ihearthawaii.com

显示对于我来说，更新已正确传播，并且您的域按照您的预期解决。 

 ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> +trace www.ihearthawaii.com ;; global options: +cmd . 8843 IN NS a.root-servers.net. . 8843 IN NS b.root-servers.net. <snip> . 8843 IN NS m.root-servers.net. ;; Received 228 bytes from 8.8.4.4#53(8.8.4.4) in 145 ms com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. <snip> com. 172800 IN NS m.gtld-servers.net. ;; Received 510 bytes from 192.36.148.17#53(192.36.148.17) in 141 ms ihearthawaii.com. 172800 IN NS ns1.digitalocean.com. ihearthawaii.com. 172800 IN NS ns2.digitalocean.com. ihearthawaii.com. 172800 IN NS ns3.digitalocean.com. ;; Received 153 bytes from 192.48.79.30#53(192.48.79.30) in 295 ms www.ihearthawaii.com. 1800 IN CNAME ihearthawaii.com. ihearthawaii.com. 1800 IN A 128.199.249.146 ;; Received 68 bytes from 198.199.120.125#53(198.199.120.125) in 94 ms

此跟踪选项显示从根服务器到.com顶级域根服务器（其中ihearthawaii.com域委托给ns <1-3> .digitalocean.com的TTL为48小时，直到www.ihearthawaii.com解决。

您自己的区域中的DNSlogging的TTL较低可能会导致出现a.gtld-servers.net行为，因为某些根服务器（例如a.gtld-servers.net ）已经更新了您的新DNS服务器，而其他服务器例如m.gtld-servers.net ）可能不会。

所以，当cachingDNS服务器可能已经使用a.gtld-servers.net并且发现ns1.digitalocean.com作为权威的DNS服务器时，当30分钟的caching时间段到期时，它可能已经被引导到m.gtld服务器.net，并find旧的注册商NSlogging指向您的旧名称服务器。

您的地址较低的TTL会导致您的logging早在名称服务器logging更新之前超时。 您的TTL应该至less与您的NSlogging的TTL一样长。

如果你能保存你的logging在旧的服务器上，直到NSlogging超时，你应该没问题。 旧的NSlogging将在几天内超时，您的传播问题将自行解决。 事情应该在2天（172800秒）后清理。

在更改logging之前，最好缩短logging上的TTL。 我不确定您的提供者是否允许您更改NSlogging上的TTL。 在改变之前的两天，我会把NSlogging的TTL减less到大约一个小时（或者你的logging中使用的是1800）。

这是我遵循的过程：

  • 在更改之前，将logging更改的TTL降低到大约一个小时。 （至less1 TTL）
  • 在TTL提前至less1 TTL显着降低（下降到5分钟左右）。
  • 进行更改并validation传播。 做任何修复（应该在几分钟内传播）。
  • 将TTL增加到一两个小时，然后重新validation传播。
  • 一旦事情稳定，将TTL增加到几天或更长时间。

一些主要的DNS服务器将覆盖你的TTL，以避免支持快速通量的DNS服务器..你可能希望在一天左右的旧IP地址可达。