Github.com resolve, mas atinge o tempo limite

Eu também estava tendo esse problema, também por vários dias, e com o mesmo endereço de ipad que você! Apenas corrigi-lo esta manhã.

A maneira como consertei foi procurar em /etc/hosts e ver aquele ip listado para github.com e comentar essa linha.

uma explicação que alguém me deu para isso

libc (de maneiras que diferem em diferentes sistemas operacionais) usa /etc/hosts para substituir pesquisas de nome de host. isso às vezes pode ser útil ao testar coisas, mas muitas vezes eu simplesmente esqueço as coisas lá ...

192.30.253.113 é um endereço github, já que eles possuem 192.30.252.0/22. você pode executar whois 192.30.253.113 para confirmar. é provável que esse fosse um endereço de servidor válido para github.com em algum momento, mas foi desativado há alguns dias. não consigo nem pingar. eles o removeram de seus servidores DNS, mas, como está codificado no /etc/hosts do seu laptop, não percebe essa alteração!

Mas seu comando já mostra que o nome de domínio resolve (para o endereço IP 192.30.253.113 na linha #2). Caso contrário, o rastreamento não poderia nem começar.

O resto da sua saída de rastreamento não tem nada a ver com a resolução de nomes DNS - não é isso que o traceroute está verificando. (O nome de domínio não é resolvido novamente para cada pacote. Uma vez que o aplicativo conhece o endereço IP, ele usa diretamente esse endereço.) Em vez disso, o traceroute pode mostrar um problema com a conexão de rede real que segue.

Sua saída não significa necessariamente que há problemas em geral - apenas mostra que esses nós não parecem responder especificamente às sondagens traceroute. Na verdade, isso é normal nos sistemas do GitHub quando o traceroute é usado no modo UDP (já que eles têm apenas um firewall que bloqueia as investigações UDP desde o início). Provavelmente, você pode alterná-lo para sondas ICMP para obter resultados um pouco mais precisos:

sudo traceroute -I github.com
sudo traceroute -I 192.30.253.113

No entanto, no seu caso, o rastreamento não lhe dirá muito, pois é o próprio sistema final, o balanceador de carga 192.30.253.113, que não aceita suas conexões HTTPS. Mas normalmente as operações do GitHub teriam removido rapidamente um endereço inválido do DNS (e, como mostra o segundo comando, o endereço incorreto não está mais no DNS).

Em outras palavras, o problema é que o domínio resolve para o endereço errado sempre que curl ou traceroute usam os recursos de pesquisa de nomes fornecidos pelo sistema operacional.

Opções possíveis:

• Você acabou de resolver o nome de domínio quando ele ainda tinha esse endereço e será armazenado em cache pelo sistema operacional por alguns minutos (o GitHub especifica 60s, mas nem todos os sistemas honram TTLs tão baixos). Espere um pouco e tente novamente.

• Você tem o endereço inválido configurado como uma substituição em /etc/hosts (que traceroute e curl honram, mas as ferramentas hostou ignoram). digVerifique a partir de um dispositivo diferente.

• Seu servidor DNS estava mentindo no momento, por exemplo, talvez o administrador da rede tenha tentado substituir o nome de domínio por um endereço personalizado. (No entanto, seu segundo hostcomando mostra bons resultados.) Tente usar uma conexão diferente, como Wi-Fi público ou 4G móvel, para ignorar qualquer interceptação.

• Os servidores de nomes do GitHub eram inconsistentes e retornavam resultados diferentes em diferentes consultas. (O domínio é hospedado por AWS e Dyn, não é impossível que uma chamada de atualização tenha sido bem-sucedida, mas outra falhou.) Aguarde um pouco e tente novamente.

O Github.com resolve no seu computador, como evidenciado pelo fato de que o traceroute tem um endereço IP para trabalhar ( 192.30.253.113). Seu problema não é com a resolução de DNS.

Na verdade, o teste que você está tentando fazer tem muito pouco a ver com DNS. A resolução já foi feita antes mesmo do teste começar. Seu problema é que seus pacotes não chegam aos servidores do Github.

No entanto, o traceroute será inconclusivo para isso, pois parece que algumas partes no caminho para o Github.com desativaram o traceroute de alguma forma (veja abaixo). Github.com ainda funciona bem para mim, mesmo que eu veja as estrelas.

 mtak@dc4:~$ traceroute github.com
traceroute to github.com (140.82.118.4), 30 hops max, 60 byte packets
 1  * * *
 2  l6.f2.ams4.transip.net (77.72.151.70)  16.942 ms  16.917 ms l5.f1.ams4.transip.net (77.72.151.8)  15.319 ms
 3  f1.r2.ams0.transip.net (77.72.151.124)  0.261 ms f2.r1.ams0.transip.net (77.72.151.122)  0.594 ms  0.577 ms
 4  r1-a0.e1.ams7.transip.net (157.97.168.1)  0.407 ms  0.391 ms r2-a0.e1.ams8.transip.net (157.97.168.4)  0.407 ms
 5  transip.telecity2.openpeering.nl (82.150.159.226)  0.704 ms  1.247 ms 213.198.92.21 (213.198.92.21)  2.528 ms
 6  * * xe-0-2-1.er1.ams1.nl.zip.zayo.com (64.125.12.137)  0.879 ms
 7  ae9.cs1.ams17.nl.eth.zayo.com (64.125.31.10)  6.972 ms  7.191 ms  7.150 ms
 8  ae2.cs1.fra6.de.eth.zayo.com (64.125.29.58)  7.067 ms  6.956 ms  9.627 ms
 9  ae1.mcs1.fra6.de.eth.zayo.com (64.125.29.57)  6.791 ms  6.843 ms  6.911 ms
10  82.98.193.31.IPYX-270403-001-ZYO.zip.zayo.com (82.98.193.31)  7.432 ms  7.339 ms  7.291 ms
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Neste ponto, acho que não há muito o que fazer. A resolução funciona e você pode acessar a Internet. O resto é com outras partes.

Além das respostas fornecidas, tracerouteàs vezes pode ser um pouco enganador devido ao uso de pacotes ICMP ou UDP.

É mais provável que você obtenha informações melhores usando tcptraceroutea porta de destino 443. Talvez seu traceroute até suporte o -Tswitch.