我知道这只是缺乏我的理解，但这是问题。
我们最近将DNS服务器从192.168.1.1改为.2，所以我转到了所有8台Linux服务器，并更改了/etc/resolv.conf来反映这个改变。 请注意，它们都是静态的，不涉及DHCP。
在做出更改之后，我可以立即使用nslookuptesting结果并进行挖掘，这一切看起来都不错。 我做了一个/etc/init.d/networking重新启动 – 重新启动networking子系统 – 并重新启动每个服务器上的Apache和后缀，只是为了确保。
几天后，我收到一份报告，指出我们的网站不再发送电子邮件。 仔细查看日志，我发现mod_php进程无法parsingdns条目来发送邮件。 打了我的头大约30分钟后，我重新启动服务器，一切恢复正常。
第二天，在不同的服务器上（使用CentOS而不是我们普通的Ubuntu），我得到一个报告，指出电子邮件没有通过，而且看着日志显示Postfix无法parsing名称。 重新启动，它几乎立即提供所有排队的邮件。
那么我在这里错过了什么？ 这个过程的哪个部分我没有正确理解？
你可能被nscd咬了： http ： //linux.die.net/man/8/nscd
干杯
大多数应用程序在启动时（使用res_init ）初始化parsing器一次，之后不再执行。 对于像ping这样的短生命应用程序来说，这并不是一个问题，但对于长时间运行的守护进程而言则更为严重
Apache进程（运行mod_php）可能就是这种情况。 重新启动Apache就足够了。
resolv.conf指导parsing器在哪里查找名称。 在大多数情况下，这将是libcparsing器，但可能还有其他一些情况，例如使用Python DNSparsing器库进行SPF查找的vPostMaster。
所以，可能是parsing器正在caching长时间运行的进程的resolv.conf信息，但听起来像是重新启动了postfix，这应该导致它开始使用新的resolv.conf文件。
检查你的/etc/nsswitch.conf，看它是否指定了“主机”的特殊情况。 例如，我的笔记本上的默认Fedora 11行是：
hosts：files mdns4_minimal [NOTFOUND = return] dns
所以在这种情况下，它使用mdns以及/ etc / hosts和DNS。 在这种情况下，如果DNS更改没有被提取，我不知道是否是导致它的mdns。
肖恩
可能有些caching正在进行。 我们有一个与sendmail类似的问题，只是重新启动修复它的服务。
有时，重启服务器并清除系统中任何位置的所有caching比直接花费时间来确定哪个服务caching时间要长很多。 另一方面，当它再次发生时，它可能会变成投资，并且您知道要重新启动哪个服务。