7

It appears the reply for pool.ntp.org changed recently. This is making my CentosOS 6 ntp servers unhappy. 

$ 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 +++

It appears that there is general agreement on this, as modern Ubuntu says:

$ ping 0.0.0.2
connect: Invalid argument

I thought 0.0.0.2 is a valid IP?

UPDATE

The issue is indeed periodic and has been going on for several days (since 2015-12-20 according to my nagios):

[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

I suppose there is a ranking battle of some sort going on.

UPDATE 2

For those interested, this issue occurs when DNS RRs for pool.ntp.org is queried from Sweden.

Bittrance
  • 3,070
  • 3
  • 24
  • 27
  • maybe just a DNS hick-up. After entering *pool.ntp.org* in a browser I landed here: [sim720.co.uk](http://www.sim720.co.uk/#!menu). The address bar has shown http://pool.ntp.org/#!menu though. – klanomath Dec 23 '15 at 13:36
  • @klanomath `pool.ntp.org` is only for NTP. If some of the servers in the pool happen to also be hosting HTTP, it is likely to be totally unrelated to NTP. And it is a reasonable practice to configure an HTTP server to redirect requests for unexpected domain names to a domain name which is supposed to be used with HTTP. So when things are behaving properly you can expect `http://pool.ntp.org/` to give you an error or send you to a more or less random site. – kasperd Dec 23 '15 at 14:13

3 Answers3

12

All of 0.0.0.0/8 is reserved, so that definitely isn't a valid IP for an ntp server. You can check the IANA registry for more information.

You should file a few bug reports. One against pool.ntp.org, because they should be verifying the validity of IP addresses before allowing them into the pool. And one against check_ntp_time, because it shouldn't die even if an invalid address shows up. Instead it should try the three valid IP addresses it got.

kasperd
  • 30,455
  • 17
  • 76
  • 124
10

Of the four servers you list, three are in the pool and have valid server monitoring pages:

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

The other, illegal, one, does not:

http://www.pool.ntp.org/scores/0.0.0.2

As kasperd notes, the RRs returned on that A record are round-robin load-balanced, so we cannot tell whether your upstream DNS was lying to you, or an illegal address temporarily made it into the pool. I know from experience as a pool admin that one's server has to be highly-available, and thus well-scored by the monitoring system, to be included in the pool. So I personally doubt that an unreachable address could make it into the pool, and suspect that this was an upstream DNS glitch. But unless you can reliably reproduce the result, I doubt we'll ever know.

It occurs to me that if pool.ntp.org used DNSSEC signatures, we would immediately be able to tell if this was a cache poisoning issue, or a crap-in-the-pool issue. If I have a few spare minutes, I might raise the issue on the pool servers' admins' list.

Edit: I have raised the issue on the admins list, and have already had one independent confirmation that this address does seem to be making it into the pool, even though it clearly shouldn't. Watch this space, I guess.

Edit 2: apparently, this was a genuine bug and it has now been fixed. I agree with kasperd that it's worth chasing the plugin's authors to make the plugin more robust to crap in the pool.

MadHatter
  • 79,770
  • 20
  • 184
  • 232
  • 1
    Connecting to `0.0.0.0` on a Linux machine will connect you to localhost. So if you did monitor the availability of an NTP server on `0.0.0.0` it would probably appear to be highly available. There could be OS where this would be the case for any address in `0.0.0.0/8`. It would be a flawed design to rely on the availability monitoring to filter out invalid IP addresses. Those have to be filtered out before handing them to the monitoring. – kasperd Dec 23 '15 at 12:36
  • That is also true of `127.0.0.1`, so I'm sure there is some filtering other than availability checking. But even if there **weren't**, `0.0.0.2` isn't reachable the same way, so wouldn't pass the availability test. I agree there could be an OS that violated the RFCs and handled `0.0.0.2` as you describe. But there could equally be an OS that ignored all RFCs and passed any combination of characters as a valid IP address - and it probably wouldn't get used as the basis of an internet infrastructural service. – MadHatter Dec 23 '15 at 12:39
1

0.0.0.2 is "valid" per se but may only be used as a source address according to RFC1700 hence you cannot ping it.

Community
  • 1
Mintra
  • 561
  • 3
  • 7