/etc/resolv.conf ordem não respeitada por 'ping'

Question

CentOS 7. Meu problema é um problema aparentemente comum em que nslookup pode resolver um host, mas ping não pode. No entanto, as respostas comuns como mexer com avahi ou /etc/nsswitch.conf não ajuda, porque o meu VPS não está executando o Avahi nem o NetworkManager. (em outras palavras, eu posso quebrar /etc/nsswitch.conf definindo hosts: files e ping continua a funcionar)

/etc/resolv.conf é o seguinte:

nameserver 10.44.13.246
nameserver 10.32.72.88
nameserver 10.32.72.86

Onde o primeiro servidor de nomes aponta para uma instância de dnsmasq em execução em outro dos meus VPSes e os dois últimos são os servidores DNS do provedor de hospedagem. Espero que eles sejam consultados em ordem (os dois últimos são simplesmente fallbacks de último recurso).

Agora, para qualquer um dos hosts definidos nessa dnsmasq instance, nslookup sempre funciona e ping funciona algum tempo - um host será resolvido corretamente e, em seguida, será interrompido , alguns minutos depois, tudo ficará bem novamente. No entanto, se eu remover os servidores DNS upstream em etc/resolv.conf desta forma,

nameserver 10.44.13.246
#nameserver 10.32.72.88
#nameserver 10.32.72.86

então ping começa imediatamente a funcionar 100% do tempo . Isso contradiz diretamente os documentos resolv.conf, que dizem que, na ausência de uma diretiva option rotate , os servidores são consultados em ordem até que alguém envie uma resposta.

nscd está sendo executado e está sendo atingido, porque eu posso ver os contadores de acertos / erros do cache sendo usados para essas consultas problemáticas.

Como posso resolver isso?

    

Answer 1

Eu não tenho uma resposta direta para a pergunta maior, mas respostas para algumas partes distintas dela.

Em relação a ping vs nslookup

Vale a pena notar que ping é apenas um exemplo de um programa comum que usa a biblioteca de resolução de SO ( getaddrinfo / gethostbyname calls) enquanto nslookup (bem como dig , etc) são programas cliente DNS fazendo consultas DNS próprias, em vez de usar a biblioteca de resolução, eles simplesmente pegam seu servidor padrão a partir do arquivo de configuração para o resolvedor de sistema como uma questão de conveniência.

O que isto significa é que nslookup é ruim para testar como o resolvedor do sistema se comporta (ex. resolv.conf , nsswitch.conf , etc), enquanto, por exemplo, ping é ruim para testar DNS.

Pode-se notar que no Linux-terra eu consideraria getent ahosts (ex. getent ahosts www.example.com ) uma escolha melhor para testar o comportamento do resolvedor, e dig seria muito preferível sobre nslookup para testar DNS. / p>

Com relação ao que você pode fazer para ver o que está acontecendo

Como foi sugerido por Hangin em desespero silencioso , você pode usar strace (talvez também ltrace para uma visualização de nível mais alto) e sugiro usá-lo com getent ahosts em vez de ping para não obter todo o ruído da finalidade real do ping , enquanto você está tentando observar o que é apenas um efeito colateral. getent ahosts faz apenas isso que você está tentando investigar.

Sobre o que ter no resolv.conf

O que você está dizendo sobre as coisas "quebrando" quando o servidor "errado" é consultado me faz perguntar por que você está colocando todos esses servidores em resolv.conf em primeiro lugar. Geralmente, não é uma boa ideia colocar servidores com comportamento diferente (diferente de alguma forma que seja realmente significativo para o seu uso), tudo na lista.

    

Answer 2

Ping é antigo. Ele precede nsswitch e usa um arquivo /etc/host.conf (não tenho certeza se isso ainda é relevante para o RHEL7)

Além disso, você não estará consultando / etc / hosts: sugiro que você tente getent hosts name.example.com , que consultará / etc / hosts (conforme configurado pelo nsswitch.conf). Isso usa a funcionalidade de resolução de nomes padrão da biblioteca C, em que host (e dig ) são expressamente apenas sobre DNS, e só olham para /etc/resolv.conf para definir padrões para coisas como servidores de nomes e domínio de pesquisa use - mas de outra forma use parte do código do software DNS do BIND para consultar o DNS