我们在我们的networking上运行域名服务器。 我们使用bind / named。 让我们调用域example.com 。 有一件事我最近注意到,当我转到像http://network-tools.com这样的网站,并在我们的名字服务器上定义的URL上运行查询时,我立即看到了变化。
例如,如果我为url funny.example.com向DNS服务器添加一个条目,然后在http://network-tools.com上查找该URL,我会立即看到为其列出的正确的外部静态IP。
这就是说,任何与example.com相关的DNS请求都会直接进入我们的DNS服务器。
我们的怀疑在本周早些时候被证实,当时我们的DNS服务器在很短的时间内就停止了。 在这段时间内,如果我使用http://network-tools.com来查询example.com或其子域,我将得到零结果。 显然是因为DNS服务器closures了,无法连接。
所以这使我想到了我的问题。 我认为我们的DNS服务器的变化应该是传播到互联网上的其他DNS服务器。 这样,如果我们的DNS暂时closures,互联网上的其他服务器仍然知道example.com所指向的IP地址。
我误解了这个DNS的东西? 像我们这样的第三方控制的DNS服务器是否不允许将DNS信息传播到networking上的其他服务器?
我应该在哪里开始调查,为什么变化没有在那里? 我可以在我们的防火墙上看到,端口53的stream量正确地传送到我们的DNS服务器。
UPDATE
我知道你们都在说不可能即时发布你的DNS设置,但我所知道的是:如果我们在DNS服务器上进行DNS更改,然后立即在http:// network-tools上检查它。 com ,我立即看到变化。
如果我closures了我们的DNS服务器,然后尝试使用http://network-tools.com检查任何URL,则该站点找不到任何URL。 但是如果我把DNS服务器恢复到在线状态,突然间http://network-tools.com可以再次find这个URL …这告诉我服务器不会caching我们的DNS设置。 我错了吗? 此外,我们的TTL设置目前设置为900(15分钟),我们的DNS服务器已经运行了一年多。 所以它不像互联网上的DNS服务器还没有机会caching它。 是服务器没有caching设置的原因,因为目前的TTL是如此之低? 如果这就是原因,那还是有道理的。
是的,你误解了DNS的工作原理。 我将在这里使用一些重点,但请不要冒犯,因为没有人打算。
DNSlogging不会传播。 他们被caching。
话虽如此,下面是发生了什么简单的解释:
您创build一个新的DNSlogging(A,CNAME等)
远程用户(更具体地说是用户启动的进程\应用程序)尝试访问通过该DNSlogging访问的服务(例如,试图访问在funny.jokerville.com上运行的网站的networking浏览器)
用户DNS客户端向其DNS服务器发送DNS查询,然后DNS服务器(通常通过一系列recursionDNS查询)find您的名称服务器,并要求他们提供有关funny.jokerville.com的信息
你的名字服务器回答答案
然后,用户DNS服务器将此信息发送给用户(更具体地说是用户DNS客户端parsing器),然后将这些信息返回给进程\应用程序。 这些信息与所谓的TTL(生存时间)一起,告诉DNS客户端parsing器这个信息可能被保存在它的DNScaching(在内存中)多久,信息可以被认为是最新的和准确的
TTL过期后,用户的DNS客户端parsing程序将刷新此信息。 任何有关DNSlogging的新请求都需要进行新的DNS查询,并重复上述过程。
所以这个长短是这样的:
您的DNSlogging不会传播。 没有其他DNS服务器有您的DNSlogging或区域的副本。 DNS客户端或服务器可能会将有关您的DNSlogging或区域的信息(基于您的DNSlogging和区域的DNS查询)caching到其DNScaching中。 这些信息被临时caching,并在TTL过期时从DNScaching中删除。
如果您的名称服务器已closures,则只有那些在其caching中具有任何DNSlogging的DNS客户端才能parsing这些DNSlogging,直到TTL过期。 此外,当TTL过期(需要新的DNS lokkup)时,这些DNS客户端将不再能够parsing您的DNSlogging。
如果您告诉我们您的实际域名,这将有很大的帮助,那么我们可以参考您的实际设置来回答您的问题,并指出任何错误。
我倾向于信任http://dns.squish.net/用于快速诊断DNS问题。 这会告诉你在你做出改变后你的问题在哪里 – 基本上如果你的上游代表是正确的,你的2-3个名字服务器都给出相同的答案,并且有人没有看到新的logging,他们只需要等待他们的本地networking看到变化。 如果该检查器告诉你一个服务器没有给出与其他服务器相同的响应,则需要解决该问题。
您无法立即发布DNS更改 – 您可以立即发布它们,但根据每个logging的TTL设置,世界其他地方将会落后,例如,如果您设置了86400秒的TTLlogging(一天),你做了一个改变,其他人会看到一个长达一整天的旧logging,因为他们的本地caching不会问你,直到他们的logging副本到期。
我build议,在任何重大DNS更改之前,将TTL降低到600(10分钟)以鼓励互联网上的caching不要长时间保留旧的logging。 但是一些caching会忽略这个,或者假设1天,甚至1周。
一个漫不经心的答案,希望有一些有用的东西,虽然。
是的,老的谚语,“DNS更改可能需要24-48小时才能通过互联网传播”更准确地说,“在过去的86400秒内查询此logging的任何DNS服务器上可能会cachingDNS更改”。
如果你想在你的服务器下线时确保DNS的冗余,你应该查看备份DNS服务(比如在dyndns.com上)或者创build你自己的二级NS。
互联网上的所有DNS服务器都是“第三方控制的”(我想你可以认为根DNS服务器对互联网来说是“专有的”,但是没有技术上的原因可以build立你自己的私有根)。
您的DNS服务器在其提供的每个答案中提供build议的“生存时间”(TTL)。 远程parsing器(对客户端执行recursionparsing的其他DNS服务器,客户端parsing器库等)都应该caching高达TTL的答案,然后将其从caching中丢弃。
如果您没有看到对现有logging所做的更改反映在真实世界的查询中,则可能意味着您的TTL值足够高,以至于您没有足够长的时间来查看现有答案是否超出parsing器caching在“networking”周围。
服务器故障的一些背景: 为什么叫做DNS“传播”?
当互联网上的某个人(或某个计算机)出现在互联网上时,他们想要连接到其中一台机器,他们要求他们的本地域名服务器input一个与他们感兴趣的主机名匹配的IP地址。
所以如果你告诉某人“嗨,看看我的酷网站http://www.example.com ”,另一个人的电脑会询问它的本地域名服务器“嘿,什么是www.example.com的IP地址?”
假设本地名称服务器从来没有查询过这个问题的答案,它会要求根名称服务器找出哪个服务器处理“.com”的查找。 当它得到这个答案时,它会问那些服务器处理查找“example.com”的服务器。 当它得到这个答案时,如果问这些服务器的IP地址为“www.example.com”。
当example.com的服务器以www.example.com的IP地址回应时,他们也会给请求的域名服务器一个关于应该记住这个问题的答案的时间的提示。 这个提示被称为“TTL”,或“生存时间”,它是以秒为单位来衡量的。 不能保证任何服务器都会关注TTL,一些域名服务器可能被configuration为永远不会记住查询的答案,并且即使每秒被询问几次,也会一直重复这个过程。 其他名称服务器可能被configuration为长时间保持答案,即使您build议数据只保留一小段时间,也许是因为他们想要最小化networkingstream量。 TTL只是一个build议,不是要求或保证。
你的问题的文字回答 – 为什么不是你的DNSlogging传播到互联网 – 是他们不这样做,因为他们不应该这样做。
此外,如果您正在使用旨在研究或debuggingDNS信息的站点查看自己的DNS信息,那么不pipe您的TTLbuild议是什么,该站点都不会长时间caching数据,该网站的目标可能是提供关于DNS系统现在说什么的信息,而不是5或50或500秒之前。 这就是您的更改立即反映的原因,以及为什么服务在您断开名称服务器时立即停止工作。
我怀疑你的潜在问题可能是“我该如何设置,以便如果我的DNS服务器重新启动或其硬盘死亡,互联网上的其他人仍然能够看到我的网页?
这个问题的答案是为你的域名build立几个域名服务器,并让它们在不同的机器上运行 – 理想情况下,不仅仅是不同的物理计算机,而且具有不同的networking连接,甚至可能在不同的城市或州或国家或大陆。 这些名称服务器中的大多数将被设置为“奴隶”,这意味着他们寻找一个“主”名称服务器的信息,然后将这些信息重复给任何人谁要求他们的数据。
因此,在您的域名注册商的WHOIS数据中,您可以为您的域configuration四个域名服务器:
ns1.example.com ns2.example.com ns1.otherguy.com ns2.otherguy.com
其中ns1.example.com是您当前的DNS服务器。 ns2.example.com可能是您公司/组织中的另一台计算机,理想情况下不在ns1.example.com的相同子网和相同服务器机架上(或在同一个人的桌面下)。
ns1.example.com将被视为“主”服务器,当您想更改您的DNS时,您将在该机器上进行更改。
ns2.example.com将被configuration为“奴隶”服务器,它只是复制你在ns1.example.com上设置的任何数据 – 但是外部世界并不关心主/从区分,ns2.example .com将被视为与ns1.example.com一样“正式”。
ns1.otherguy.com和ns2.otherguy.com是设置在其他地方的机器 – 也许你与另一个组织的朋友/同事进行安排,为对方运行名称服务器,或者你可以设置dyndns.com或everydns.net或任何其他免费或商业的DNS提供商。 然而,你可以把这些机器configuration成从机,这样他们就可以从ns1.example.com(你的“主机”)上获取example.com的DNS信息,并且将这些DNS信息提供给互联网,要求它。
一旦你的域名注册商为你的域名发布了新的NSlogging(这应该大致是即时的),那么当互联网上有人问出哪个域名服务器处理“example.com”时,他们会得到四个答案 –
ns1.example.com,ns2.example.com,ns1.otherguy.com,ns2.otherguy.com
取决于其他人的域名服务器的设置,它可能会把这四个视为一个列表,并一次询问一个如何到达“www.example.com” – 或者可能要求他们所有四个人在同一个问题上同时,只要从任何一台机器先回答的答案。 无论哪种方式,如果ns1.example.com因为硬盘死亡或者您决定重新启动等而closures,那么其他3台机器将可以回答问题,而您的网站将继续可见。
解决这个问题的最简单的方法是注册一个DNS服务提供商,他将为您的域名处理DNS – 这个价格的范围从免费到数千美元(可能甚至几十或几十万美元)每个月,这取决于你想要的服务水平。 你可以得到相当可靠的服务,每年30美元左右。 免费的服务不是很糟糕,因此具有相当不错的促销比例,但是如果你依靠你的网站赚钱,那么你应该能够拿出30美元一年的DNS价值。
然后,按照DNS服务提供商的指示,在您的域名注册商处更改NSlogging,您将全部设置。
由他人完成的cachingDNS服务器依赖于分配给TTL的logging。 在你的情况下可能是TTL很低或者很高。 你能给我们更多的关于你的DNSconfiguration的信息吗?