BIND DNS域名更改问题的域名input

您不应该等待DNScaching刷新，而应该直接从授权服务器上进行查询。

dig它是这样做的：

 dig @ns1.example.com oldentry.example.com 

用nslookup就是这样做的：

 nslookup oldentry.example.com ns1.example.com 

至于试图解决你的问题，我们只能做出疯狂的猜测，因为你给我们的只是“我改变了，但没有改变”。

如果您将实际的configuration添加到问题中，我们可能有机会。 如果你不能这样做，绑定喜欢logging错误，并继续并尝试加载其余的区域文件或条目。 例如，从区域文件中删除ns2行会导致logging：

 Feb 18 18:47:34 dns01 named[22465]: zone example.com/IN: NS 'ns2.example.com' has no address records (A or AAAA) Feb 18 18:47:34 dns01 named[22465]: zone example.com/IN: not loaded due to errors. 

但绑定仍然会启动并加载所有其他区域文件。 我不确定它在不良语法上的performance如何，是否忽略该条目或整个区域文件。 查看你的日志（这是在daemon.log ）与named相关的任何事情。）

其他一些猜测：

1. 你重新绑定了吗？
2. 你忘了拖尾了吗？ 在CNAME条目上？
3. 你有没有仔细检查绑定是否使用你编辑的文件？
4. 你是否通过所有你的区域文件的IP地址grep？

原来提交者的问题似乎在这一点上消失了，但是为了同样情况下的其他人的利益，他们可能会偶然发现这个问题。

（注意：下面的列表不包括启用dynamic更新的区域，如果您需要冻结和解冻步骤是手动编辑区域主文件，而不是使用nsupdate进行更改）

1. 备份旧区域文件的副本，以防出现问题。
2. 对您的区域文件进行计划的更改，特别注意确保每个已编辑区域的SOAlogging中的序列号都已正确更新 。
3. 检查您对区域文件所做的更改。 在这个阶段运行named-checkzone并不会伤害到确保编辑没有语法错误。 此外， 在FQDN结束时 ， 为防止意外省略尾随句点 ，这是最常见的区域编辑错误types，它是合法的语法，因此named-checkzone和/或服务器将不会为您标记它。
4. 导致区域重新加载，使用“rndc reload”，“rndc reconfig”或重新启动命名似乎最适合您的情况。
5. 通过使用有针对性的挖掘（即“dig @ masternameserver.example.org zone.name。soa”）来检查主名称服务器提供的内容，以确保该区域已正确加载，并且所服务的版本具有新的序列号。
6. 查看主站和/或从站上的日志文件中是否有证据表明通知消息已发送到从站，并且从站已通过AXFR或IXFR启动了新区域内容的传输
7. 使用针对从属服务器的有针对性的挖掘来检查从属服务器现在是否提供区域数据的正确副本（检查SOA，并检查您添加或删除的logging）。
8. 等待区域数据完全传播。 未收到通知的从属服务器可能会等待$ refresh秒，然后再检查SOA以查看是否有新的区域数据可用。 超出你的控制范围的其他服务器可能会caching旧区域数据一段时间，直到为该区域设置的TTL值为止（而不合格名称服务器可能会设置一个底层值，表示它们将接受的TTL低于TTL你已经select了。）