ntpd gets "connect: invalid argument" on 0.0.0.2

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.

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.