这里有一个奇怪的问题，希望有人能帮助描述和/或修复我。 我们在一个/ 24networkingAAAA上 ，最近换成了BBBB 。 名称服务器全部与注册服务商一起更新，它们显示在根名称服务器和所有内容中 – 到目前为止非常好，对不对？ 我可以挖掘根服务器，并获得新的IP，whois是好的，所有的“是否插入？ 基础看起来不错。
我在BBB254的新networking和AAA254的旧networking上运行DNS，因为这些变化仍然在世界各地传播。 AAA254 DNS服务器实际上是向全世界提供BBBB的IP，以捕捉那些还没有看到上游变化的零星 ，正常的业务。 每个服务器也为它自己的IP范围运行反向DNS。
所以！ 在对旧的AAA254服务器的查询logging中，我看到来自BBB254的PTR区域对于它自己的反向IP Bnetworking的奇怪请求！ 而且，它始终是两个IP–我的防火墙（.4）和VPN服务器（.6） – 除了这两个以外别无其他。
04-Aug-2009 09：56：09.755 client BBB254＃37384：query：4.BBBin-addr.arpa IN PTR +
04-Aug-2009 10：00：05.380 client BBB254＃37385：query：6.BBBin-addr.arpa IN PTR +
为什么有这样的查询，要求BBB254已经托pipe的IP区域，去我的AAA254服务器？！ 我不应该看到从BBB254到AAA254的任何疑问，但我仍然得到这些奇怪的PTR工作，我不明白。 B的'dig -x'不会导致它到A，所以没有那么简单。 我查过B上的每个configuration文件（这是一个linux / bind9盒子），对Anetworking的任何引用，找不到任何东西。
任何人都有线索这里发生了什么，我怎么能解决它？ 为什么新的服务器B向A申请这个PTR，当它知道它自己承载了这个范围？
我已经跟踪了各种各样的小径，如：
挖+ norecurse 4.BBBin-addr.arpa PTR @ x.arin.net
…然后…
dig + norecurse 4.BBBin-addr.arpa PTR @a。[权限服务器名称]
这一切看起来都是正确的。 任何想法欢迎哪里进一步寻找跟踪什么是导致这个请求循环，我有点损失接下来看什么。
这些日志摘录是否与IP地址逐字分开？
如果是这样的话，似乎令人惊讶的是，在4分钟的时间间隔内，显然没有其他的IPstream量，这些查询的源端口只显示了一个。
我build议你应该尝试确认它确实是BBB254发送这些查询（在发送主机上运行tcpdump ）。
如果你可以试着找出哪个进程正在造成他们。 如果在新服务器上named ，则启用更多日志logging以查明原因（ rndc trace和rndc querylog ）。
请注意，如果您已经重新编号了networking并重新configuration了您的机器，而且没有closures这些机器，那么任何长时间运行的守护进程都可能会将旧的/etc/resolv.confcaching在其中。
这是因为/etc/resolv.conf只有在程序第一次调用gethostbyname()或gethostbyaddr() res_init()从resolver库的res_init()函数中读取/etc/resolv.conf 。 parsing器库不会即时检测到configuration文件的更改。
BBB254 resolv.conf可能configuration为向旧的DNS服务器发送请求？ （不应该，因为recursion和权威不应该混合）。 另外， BBB254可能被configuration为RFC1918与NAT的默认网关？ 在这种情况下，该机器后面的东西可能会被错误地configuration成recursion的解决scheme。
另外，具有实际的IP范围可能会有所帮助，因此人们可以实际检查您的代表团。
我很高兴（狂喜！）报告它已经被解决了 – 问题的孩子实际上是在bbb254 syslogd！ Alnitak在bbb254机器上多次运行tcpdump捕获并将其命名为debugging级别5之后，让我走上了正确的道路。我偶然发现DNS查询正在进行，但不是来自命名的进程。
我不是syslogd的主要专家，但它与这个syslogd运行在远程日志logging模式，并接受有问题的设备（.4，.6）日志有关。 即使它正在新networking上正常工作，它的小守护进程大脑仍然caching了旧networking的信息（尽pipe我不太清楚），正是这个过程对旧的DNS服务器进行了PTR请求新的反向IP范围。 一个简单的“/etc/init.d/syslogd restart”清除了错误的请求，现在一切正常。
最后总是简单的事情，只需要8个小时的debugging即可到达目的地。 🙂
在黑暗中拍摄：你确定你已经得到了所有的DNScaching刷新？ 我已经看到了这样的奇怪的东西，因为某些caching中的某些旧DNS过时的视图，因为某种原因没有被刷新。