看来pool.ntp.org的回复最近发生了变化。 这使我的CentosOS 6 ntp服务器不高兴。
$ host pool.ntp.org pool.ntp.org has address 0.0.0.2 pool.ntp.org has address 83.209.8.142 pool.ntp.org has address 130.236.254.17 pool.ntp.org has address 195.178.181.98 $ /usr/lib64/nagios/plugins/check_ntp_time -H pool.ntp.org can't create socket connection# $ strace -f /usr/lib64/nagios/plugins/check_ntp_time -H pool.ntp.org ... connect(3, {sa_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("83.209.8.142")}, 16) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3 connect(3, {sa_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("130.236.254.17")}, 16) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4 connect(4, {sa_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("195.178.181.98")}, 16) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 5 connect(5, {sa_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("83.209.8.142")}, 16) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 6 connect(6, {sa_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("0.0.0.2")}, 16) = -1 EINVAL (Invalid argument) fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6571c5b000 write(1, "can't create socket connection", 30can't create socket connection) = 30 exit_group(3) = ? +++ exited with 3 +++ 现在看来，就这个问题达成了一致，就像现代的Ubuntu说的那样：
$ ping 0.0.0.2 connect: Invalid argument
我以为0.0.0.2是一个有效的IP？
UPDATE
这个问题确实是周期性的，并且已经持续了好几天（根据我的nagios，从2015-12-20开始）：
[12:40] host pool.ntp.org pool.ntp.org has address 194.71.144.71 pool.ntp.org has address 79.136.86.176 pool.ntp.org has address 83.209.8.142 pool.ntp.org has address 178.73.198.130 [13:09] host pool.ntp.org pool.ntp.org has address 194.71.144.71 pool.ntp.org has address 0.0.0.2 pool.ntp.org has address 178.73.198.130 pool.ntp.org has address 192.36.143.130
我想有一个排名的战斗正在进行。
更新2
对于那些感兴趣的，这个问题发生在从瑞典查询pool.ntp.org的DNS RR时。
所有的0.0.0.0/8都是保留的，所以肯定不是ntp服务器的有效IP地址。 您可以查看IANA注册处以获取更多信息。
你应该提交一些错误报告。 一个针对pool.ntp.org ，因为他们应该在允许他们进入池之前validationIP地址的有效性。 还有一个针对check_ntp_time ，因为即使一个无效的地址出现，它也不会死。 相反，它应该尝试三个有效的IP地址。
在您列出的四台服务器中，有三台服务器位于池中，并具有有效的服务器监控页面：
http://www.pool.ntp.org/scores/83.209.8.142
http://www.pool.ntp.org/scores/130.236.254.17
http://www.pool.ntp.org/scores/195.178.181.98
另一个是非法的，一个不是：
http://www.pool.ntp.org/scores/0.0.0.2
正如kasperd所指出的那样，在Alogging上返回的RR是循环负载平衡的，所以我们不能判断你的上游DNS是否对你说谎，或者是非法的地址暂时把它放到了池中。 作为一个池pipe理员，我从经验中知道，一个人的服务器必须是高度可用的，并且因此被监视系统良好地评分，以被包括在池中。 所以我个人怀疑，一个无法访问的地址可以使它进入池，并怀疑这是一个上游DNS故障。 但是，除非你能够可靠地重现结果，否则我怀疑我们永远不会知道。
我发现，如果pool.ntp.org使用DNSSEC签名，我们将立即能够判断这是一个caching中毒问题，还是一个混乱的问题。 如果我有几分钟的时间，我可能会在池服务器的pipe理员列表中提出这个问题。
编辑 ：我已经提出了pipe理员名单上的问题，并已经有一个独立的确认，这个地址似乎确实进入了池，即使显然不应该。 看，我猜这个空间。
编辑2 ：显然， 这是一个真正的bug，现在已经修复 。 我同意kasperd认为值得追逐插件的作者，使插件更强大的垃圾池。
0.0.0.2本身是“有效”的，但是只能根据RFC1700作为源地址使用，所以你不能ping通它。