ntpd obtém “connect: invalid argument” em 0.0.0.2

Question

Parece que a resposta para o pool.ntp.org foi alterada recentemente. Isso está deixando meus servidores ntp do CentosOS 6 infelizes.

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

Parece que há um consenso geral sobre isso, como o Ubuntu moderno diz:

$ ping 0.0.0.2
connect: Invalid argument

Eu achei que o 0.0.0.2 é um IP válido?

UPDATE

A questão é de fato periódica e já dura vários dias (desde 2015-12-20 de acordo com meus 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

Suponho que haja uma batalha de classificação de algum tipo acontecendo.

UPDATE 2

Para os interessados, esse problema ocorre quando os RRs DNS do pool.ntp.org são consultados na Suécia.

    

Answer 1

Todo 0.0.0.0/8 é reservado, então definitivamente não é um IP válido para um servidor ntp. Você pode verificar o registro da IANA para obter mais informações.

Você deve enviar alguns relatórios de bugs. Um contra pool.ntp.org , porque eles devem estar verificando a validade dos endereços IP antes de permitir que eles entrem no pool. E um contra check_ntp_time , porque não deve morrer mesmo se um endereço inválido aparecer. Em vez disso, deve tentar os três endereços IP válidos que obteve.

    

Answer 2

Dos quatro servidores listados, três estão no pool e possuem páginas de monitoramento de servidor válidas:

link

link

link

O outro, ilegal, não tem:

link

Como observa o kasperd, os RRs retornados nesse registro A são balanceados por carga round-robin, então não podemos dizer se o seu DNS upstream estava mentindo para você, ou um endereço ilegal temporariamente entrou no pool. Eu sei por experiência como administrador de pool que o servidor de alguém tem que estar altamente disponível e, portanto, bem pontuado pelo sistema de monitoramento, para ser incluído no pool. Então, eu pessoalmente duvido que um endereço inacessível poderia entrar no pool, e suspeito que isso seja uma falha de DNS upstream. Mas, a menos que você possa reproduzir o resultado de forma confiável, duvido que algum dia nos conheça.

Ocorre-me que, se pool.ntp.org usasse assinaturas DNSSEC, poderíamos dizer imediatamente se isso era um problema de envenenamento de cache ou um problema de porcaria no pool. Se eu tiver alguns minutos extras, posso levantar o problema na lista de administradores dos servidores do pool.

Editar : eu levantei o problema na lista de administradores , e já tiveram uma confirmação independente de que esse endereço faz parece estar entrando no pool, mesmo que claramente não devesse. Assista esse espaço, eu acho.

Editar 2 : aparentemente, este foi um bug genuíno e agora foi corrigido . Eu concordo com o kasperd que vale a pena perseguir os autores do plugin para tornar o plugin mais robusto para a porcaria no pool.

    

Answer 3

0.0.0.2 é "válido" em si, mas só pode ser usado como um endereço source de acordo com RFC1700 , portanto, você não pode fazer ping.