Kubuntu (Ubuntu 14.04.2 LTS, kernel 3.13.0-48-generic) instalado há 2 meses (não instalado ainda as atualizações mais recentes).
Eu notei que meu resolvedor está falhando:
root@arrakis:~# telnet onet.pl
telnet: could not resolve onet.pl/telnet: No address associated with hostname
root@arrakis:~# ssh onet.pl
ssh: Could not resolve hostname onet.pl: No address associated with hostname
strace
e wireshark
confirmam que estou enviando duas consultas DNS: A e AAAA e recebem ambas as respostas - corrija A e AAAA vazia. Imediatamente após receber os aplicativos de segunda resposta ( telnet
/ ssh
) envia esse erro de resolução.
Tudo está funcionando bem ao usar o google dns (8.8.8.8) - mas não ao usar o DNS da minha empresa.
OK, executei solução de problemas adicionais e testei o google (8.8.8.8) e comparei com o DNS da minha empresa e os resultados são os seguintes: ao digitar telnet www.onet.pl
meu resolvedor local sempre envia consulta DNS para registros A e AAAA, e sempre ambas as respostas. Também cavar para ambos os retornos do servidor DNS semelhantes (registro A IN e registro AAAA IN vazio). Mas a diferença de trabalho (google DNS) vs não funciona (empresa DNS) cenário é: sinalizador recursivo: o google pode fazer recursiva e meu servidor DNS da empresa não pode. Esta é a única diferença. Por que meu resolvedor local não quer aceitar resposta com recursão desabilitada (ao ter um endereço IN já fornecido)?
Do cenário de trabalho do ponto de vista do usuário (google DNS):
root@arrakis:/tmp# telnet onet.pl 80
Trying 213.180.141.140...
Connected to onet.pl.
Escape character is '^]'.
Cenário não comercial (empresa DNS):
root@arrakis:/tmp# telnet onet.pl 80
telnet: could not resolve onet.pl/80: No address associated with hostname
Anexando capturas de tela para os dois cenários.
A única explicação razoável que eu veria é: se na consulta eu tenho "Recursão desejada" e em resposta eu vejo que não é suportado - então eu iria cair essa resposta? Alguém poderia confirmar? Isso seria um pouco louco já que todas as consultas DNS que estou enviando têm "recursão desejada" .... (conforme meu entendimento do rfc1035 é um comportamento incorreto e devemos aceitar resposta)
Há mais uma pequena diferença entre o cenário de trabalho e o de não trabalho. Para trabalhar (google DNS) Uma resposta inclui apenas A IN com endereço IP. Para não funcionar (empresa DNS) Uma resposta inclui o mesmo e, adicionalmente, vários servidores autoritativos adicionais. Eu acho que isso é normal, já que é uma resposta do servidor não recursivo e é apenas o resultado da diferença mencionada anteriormente. O fato de incluirmos o registro A IN também pode ser um pouco estranho (se retornarmos um registro IN provavelmente porque foi armazenado em cache antes de não precisarmos retornar registros de autoridade adicionais), mas acredito que ainda seja aceitável.
Apenas para confirmar, a resposta do DNS para A sempre retorna a entrada correta na seção de respostas:
root@arrakis:/tmp# dig @8.8.8.8 www.onet.pl -t A | grep "213"
www.onet.pl. 15 IN A 213.180.141.140
root@arrakis:/tmp# dig @173.38.200.100 www.onet.pl -t A | grep "213"
www.onet.pl. 60 IN A 213.180.141.140
Para o mesmo pedido, mas "-t AAAA", não temos a seção de resposta. Apenas autoridade.
Atualmente, estou usando uma solução muito boa. Tenho servidor de ligação no meu laptop com a recursão ativada e encaminhadores apontando para o DNS do Google e da empresa. E passando todo esse tráfego através do meu ligamento. E tudo está funcionando bem - como esperado.
Para resumir: um comportamento de bugs no linux na minha opinião.