在我的一个FC10盒子里，我注意到，即使在我什么都不做的情况下，networking活动指示灯仍然闪烁，所以我拔掉了wireshark，看看是什么原因造成的。 它logging相同的查询xxx.1.168.192其中xxx是我的networking上目前还没有打开的另一台机器（winXP）。 Wireshark提供“查询”选项卡下“typesPTR，类别IN”的其他信息。 响应数据包是'没有这样的名字'，在'Authoratative nameservers'下面写着：“168.192.in-addr.arpa：type SOA，class IN，mname prisoner.iana.org”
每几分钟发生几分钟。
我不是（很多）系统pipe理员，但我做一些简单的任务来照顾networking，所以一些指针上a）如何找出是什么造成这一点和b）如何解决这将是巨大的。
细节：
Source 192.168.1.fc10 dest 192.168.1.1（dsl gateway）'PTR xxx.1.168.192.in-addr.arpa'
来源192.168.1.1 dest 192.168.1.fc10'没有这样的名字'[在40Hz重复]
编辑2：
另一个问题：同时有人试图指出我正确的方向，反正有防火墙closures这个特殊的要求，而不会干扰其他DNS请求？
编辑3：
试了tcpdump -i any -X nnv ip host 192.168.1.winxp制作：
捕获0个数据包
filter收到的0个数据包
内核丢弃了0个数据包
试图编辑主机文件'192.168.1.xxx winxp'（埃迪先把主机名，但我以为知识产权第一？我错过了什么？），但没有做任何事情仍然得到PTR查询。
find罪魁祸首。 由于它周期性地出现，我在预感上检查了crontab，发现每隔x分钟就有一个sarg（squid报告生成器）。 从大家的DNS查询等build议我检查了configuration中的细节，发现它被configuration为解决IP地址（错误），所以每一个请求从winXP框中logging，它试图解决它，似乎这样做是为了每在日志中请求洪水。
修复：closuresparsingIP地址。
感谢大家的想法，让我看着正确的方向。 张贴答案，如果它可以帮助别人。
我看到两个问题：
您的机器正在为另一台机器执行PTR查找。
您的内部DNS中没有针对您的子网的反向查找区域。 这就是为什么PTR查找要去prisoner.iana.org
查询的来源是什么？ 我想知道你的networking上是否有一个服务试图访问禁用的winxp框（networking共享也许），当它失败时，它会对IP进行反向DNS查询（因为我不知道为什么）。
你最近有没有改变你的IP？ 难道是其他一些机器认为它正在使用XP站的IP？ 通常只有当另一台机器试图连接到电台时才会询问PTRlogging。 在你的例子中，IP 192.168.1.xxx正试图连接到你的fc10盒子。 如果您的WinXP盒子closures，则不会注意到IP冲突。 除了winxp，fc10和dsl路由器，您的networking上还有其他的机器吗？
正如Eddy所build议的那样，我会在你的fc10盒子上运行一个sniff（tcpdump），并且找出那些PTRlogging是什么来响应的。
为了解决这个问题，在你的/ etc / hosts文件中input一个条目。 这是掩盖了这个问题，但是你不会在你的networking上看到更多的PTRstream量。
顺便说一句，除了为什么发生这种情况，我没有看到任何理由担心在您的networking上的数据stream量是一个微不足道的问题。