在 BIND 上，我有一个指向旧服务器和 IP 的域条目。这台机器不再存在。当我进行更改以指向新服务器时，nslookup 仍显示前一个服务器的旧值。我上周四（下周二）更改了 www 条目，但该条目仍未缓存/传播，仍显示旧条目。我重建了域，删除了前一个，但我仍然看到 NSLOOKUP 上显示旧条目。我愿意等待一段时间让它缓存。有没有其他方法可以让它指向适当的工作地址，而不是仍然指向旧地址？
答案1
您应该直接从权威服务器进行查找，而不必等待 DNS 缓存刷新。
这样dig做是这样的：
dig @ns1.example.com oldentry.example.com
这样nslookup做是这样的：
nslookup oldentry.example.com ns1.example.com
至于尝试解决您的问题，我们只能进行大胆的猜测，因为您给我们的只是“我改变了它，但它没有改变”。
如果您将实际配置添加到问题中，我们可能会有机会。如果您不能这样做，Bind 会记录错误并继续尝试加载其余区域文件或条目。例如，从区域文件中删除 ns2 行会导致记录此信息：
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.
但 Bind 仍将启动并加载所有其他区域文件。我不确定它对错误语法的具体反应，是忽略该条目还是忽略整个区域文件。查看您的日志（位于 中daemon.log）以查找与 相关的任何内容named。）
其他一些猜测：
- 您重新启动了 Bind 吗？
- 您是否忘记了 CNAME 条目末尾的 .？
- 您是否仔细检查过 Bind 是否确实使用了您编辑的文件？
- 您是否在所有区域文件中查找 IP 地址？
答案2
此时，原始提交者的问题似乎已经消失，但这对于处于相同情况并可能偶然发现此问题的其他人是有益的。
更改名称服务并随后验证一切是否按计划进行的一般操作顺序如下所示（注意：以下列表不包括启用了动态更新的区域，如果您手动编辑区域主文件，则还需要冻结和解冻步骤，而不是使用 nsupdate 进行更改）
- 备份旧区域文件的副本，以防出现问题。
- 对区域文件进行计划内的更改，特别注意确保 SOA 记录中的序列号已正确更新对于每个被编辑的区域。
- 检查您对区域文件所做的更改。在此阶段运行 named-checkzone 以确保编辑没有语法错误是没有坏处的。此外，警惕无意中遗漏的 FQDN 末尾的尾随句点，这是最常见的区域编辑错误类型，并且它是合法的语法，因此 named-checkzone 和/或服务器不会为您标记它。
- 导致区域重新加载，使用“rndc reload”、“rndc reconfig”或重新启动命名中的任何一个似乎最适合您的情况。
- 使用有针对性的 dig（即“dig @masternameserver.example.org zone.name.soa”）检查主名称服务器提供的内容，以确保区域已正确加载并且所服务的版本具有新的序列号。
- 查看主服务器和/或从服务器的日志文件，查找已向从服务器发送通知消息以及从服务器已通过 AXFR 或 IXFR 启动新区域内容传输的证据
- 对从属服务器进行有针对性的挖掘，以检查从属服务器现在是否提供区域数据的正确副本（检查 SOA，并检查您添加或删除的记录。）
- 等待区域数据完全传播。未收到通知的从属服务器最多可能需要等待 $refresh 秒，然后才检查 SOA 以查看是否有新的区域数据。您无法控制的其他服务器可能会将旧区域数据缓存一段时间，最长可达为区域设置的 TTL 值（不符合要求的名称服务器可能会设置一个最低值，即它们将接受的 TTL 值高于您实际选择的 TTL）。