关于域名服务器的问题

这取决于您的DNS服务器是否实际接pipe您的Internet域的任何实际的DNSconfiguration – 例如NS入口/function。 如果您的DNS服务器只是一个独立的内部服务器，并且不需要实际的Internet DNS条目/更新，则不会有任何影响。

如果它代替或被作为活动Internet DNS域configuration的附加NS放置，则将需要一些时间用于从实际的Internet DNS服务器传播/更新到其余部分的input互联网DNS服务器。 过去大概需要72小时，但现在可以在24小时内完成。

这取决于。

• 如果你甚至没有运行内容DNS服务器，那么没有任何东西需要caching或被其他人复制。 对于代理 DNS服务器， 您可以caching世界其他地方发布的内容，而不是相反。

• 如果没有人询问您现在发布DNS数据的域名，则没有人会caching任何内容。

• 如果以前人们从别的地方获得答案，那么他们被告知这些答案是否有效的时间（资源logging集上的TTL值）将决定它们被caching多久。

  user48838正在引导你在这一个花园path上。 TTL值没有通用设置长度 – 72小时，24小时或其他。 他们是人们select他们的东西。 就你而言，他们目前是那些迄今为止发布数据的人所select的。

• 如果没有人知道你的内容DNS服务器是存在的，因为你没有要求/告诉任何超级域名所有者将domans委托给你，那么你发布的内容将被世界所忽略，因为没有人会被引导到请求你。 安排代表团涉及与人交谈。

当人们谈论“DNS传播”时，人们会相信很多胡言乱语，这是基于对DNS如何运作的完全不正确的心理模型。

• 你的ISP不一定和事情有关。 你的ISP是谁在你和互联网的其余部分之间推送IP数据报。 您的ISP（ parsing代理 ）DNS服务器与您在机器上select使用DNS 内容服务器发布的内容无关。
• 只要TTL说，事情就会被caching。 互联网其余部分使用的parsing代理DNS服务器（实际上是您使用的）将caching数据，直到他们上一次从内容DNS服务器接收到这些数据为止的整个生存时间段。
• 通过parsing代理进行caching与数据库复制完全不同。 一套协同工作的内容DNS服务器复制一个数据库，其中包含所有即将发布的数据。 这个数据库复制可以使用不同的机制之一，从“区域转移”到简单的scp 。 他们都没有任何关于数据库资源logging上的TTL的事情 。 其中只有less数甚至与SOA资源logging中的各种复制字段有关 。 代理DNS服务器中的协作内容DNS服务器之间的数据库复制与响应caching无关。