Parte disso depende de qual resolvedor stub está em uso. Você também pode estar tendo problemas com o IPv6, por exemplo se os registros IPv6 AAAA forem retornados, mas não houver conectividade IPv6.
Assumindo que o software (erm, rsh ? realmente? essa resposta não é rsh specific) está usando o resolvedor do sistema (como ping ) e não sua própria implementação (como dig ou host ), então você pode usar getent para ver o que pode estar acontecendo:
$ time getent ahostsv4 www.google.com
$ time getent ahostsv6 www.google.com
O acima irá realizar uma pesquisa direta e inversa (embora você não possa forçar o getent a procurar um PTR reverso ou outros tipos, ele só se preocupa com os registros A / AAAA).
Existem alguns scripts úteis em esta resposta para link , permitem que você encaminhe as pesquisas reversas (somente IPv4) como getent hosts , mas em perl para que você possa mexer com eles.
As duas possibilidades acima usam o seu resolvedor de sistema, incluindo todas as oscilações e rotatórias envolvidas no nsswitch, então elas devem se comportar como a maioria das aplicações.
Não se esqueça de testar no cliente e o servidor, ou ambos farão pesquisas inversas.
Você também pode verificar seus solucionadores locais, um por um:
$ while read opt p1 ; do
[ "$opt" = "nameserver" ] && dig @$p1 www.google.com +short +identify;
done < /etc/resolv.conf
e para verificar DNS reverso:
$ dig www.google.com +short | xargs -n1 -i dig -x {} PTR +short +identify
Para depurar ainda mais isso, você precisará verificar:
-
/etc/host.conf(várias opções, incluindo verificação de falsificação via DNS reverso) -
/etc/resolv.conf(seus resolvedores) -
/etc/nsswitch.conf(quais bancos de dados devem ser verificados, por exemplo,/etc/hosts, DNS, LDAP, etc) - a saída de
dnstracee / oudig +trace -
/etc/gai.conf, se presente. Entre outras coisas, isso pode controlar se os registros IPV6 AAAA são classificados antes dos registros A. -
/etc/nscd.confsenscdestiver em uso
Se você tiver acesso ao wireshark e ao root, poderá assistir a solicitações de DNS no fio:
# tshark -w dns.cap "port 53"
# tshark -V -ta -n -r dns.cap
(A opção -V é excessivamente detalhada, no entanto, não ocorreu aos desenvolvedores colocar timestamps na saída de dissecação do protocolo com -O dns . Talvez isso tenha sido corrigido em uma versão mais recente.)
Mesmo que você não esteja usando nscd agora, poderá ver facilmente alguns o que está acontecendo se você iniciá-lo interativamente com a opção -dd ou -ddd . Observe que nscd armazena somente em cache os registros do host (A / AAAA), portanto, os registros PTR terminarão negativamente em cache com uma vida útil curta (padrão 20s).
O resolvedor glibc (e outros) suporta " options debug " em /etc/resolv.conf , bem como a variável de ambiente RES_OPTIONS , que pode ser usada para ativar a depuração. Infelizmente, essa funcionalidade útil requer que o DEBUG seja ativado quando o glibc for criado, então é improvável que você possa usá-lo ...
Para trabalhos pesados, o melhor candidato é ltrace , isso permite rastrear e marcar timestamp as chamadas da biblioteca, assim como a forma strace pode rastrear chamadas do sistema, por exemplo gethostbyname() ou gethostbyaddr() . A desvantagem: com as muitas camadas de indireção oferecidas por nsswitch , você provavelmente se perderá na produção volumosa. Uma simples execução no telnet me deu mais de 3.000 linhas de saída, dentro das quais estão enterradas duas chamadas para gethostbyname() .
$ ltrace -ttT -e "getaddr*+gethost*+getname*" getent ahosts www.google.com
13:42:06.118718 getent->getaddrinfo("www.google.com", nil, { 0x2a, 0, 0, 0, 0, nil,
nil, nil }, { 0x2a, 0x2, 0x3, 0, 16, { 2, 0, { 0x69187d4a } }, "www.google.com", {
0x2a, 0x2, 0x2, 0x11, 16, { 2, 0, { 0x93187d4a } }, nil, { 0x2a, 0x2, 0x3, 0, 16, {
2, 0, { 0x67187d4a } }, nil, { 0x2a, 0x2, 0x2, 0x11, 16, { 2, 0, { 0x68187d4a } },
nil, ... } } } }) = 0 <0.042561>
É um pouco mais difícil entender o que está acontecendo porque não produz endereços IP legíveis para humanos ( 0x69187d4a = 105,24,125,74 - > 74.125.24.105). É provavelmente o melhor método para rastrear problemas locais, como você pode ver todas as chamadas através do NSS.
Eu usei essas alterações no meu ~/.ltrace.conf para o acima, isso pode exigir mais algumas invasões:
typedef size_t = int;
typedef sockaddr = struct(short, short, in_addr);
typedef addrinfo = struct;
typedef addrinfo = struct(hex(int), hex(int), hex(int), hex(int), size_t, sockaddr*, string, addrinfo *);
int getaddrinfo(string, string, addrinfo *, +addrinfo**);
int getnameinfo(sockaddr*, uint, +string, +uint, +string, +uint, uint);