Github.com resolves but times out

I was having this problem too, also for several days, and with the same ipaddress as you! Just fixed it this morning.

The way I fixed it was looking in my /etc/hosts and seeing that ip listed for github.com, and commenting out that line.

an explanation someone gave me for this

libc (in ways that differ in different operating systems) uses /etc/hosts to override hostname lookups. this can sometimes be useful when testing things but often i just forget stuff in there...

192.30.253.113 is a github address, since they own 192.30.252.0/22. you can run whois 192.30.253.113 to confirm. it's likely that that was a valid server address for github.com at some point, but was decommissioned at a few days ago. i can't even ping it. they'll have removed it from their dns servers, but since it's hardcoded in your laptop's /etc/hosts it's oblivious to that change!

But your command already shows that the domain name does resolve (to the IP address 192.30.253.113 in line #2). If it didn't, then the trace couldn't even start at all.

The rest of your trace output has nothing to do with resolving DNS names – that's not what traceroute is checking at all. (The domain name is not re-resolved for every single packet. Once the app knows the IP address, it directly uses that address.) Instead, traceroute can show a problem with the actual network connection that follows.

Your output doesn't necessarily mean that there are problems in general – it just shows that those nodes don't feel like responding to the traceroute probes specifically. This is actually normal with GitHub's systems when traceroute is used in UDP mode (as they just have a firewall that blocks the UDP probes early on). You can probably switch it to ICMP probes to get slightly more accurate results:

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

However, in your case the trace won't tell you much, as it's the final system itself, the 192.30.253.113 load-balancer, which fails to accept your HTTPS connections. But normally GitHub's ops would have quickly removed a bad address from DNS (and as your 2nd command shows, the bad address is actually no longer in DNS anymore).

In other words, the issue is that the domain resolves to the wrong address whenever curl or traceroute use the OS-provided name lookup facilities.

Possible options:

• You just happened to resolve the domain name when it still had that address, and it'll be cached by the OS for a few minutes (GitHub specifies 60s, but not all systems honor such low TTLs). Just wait a while and try again.

• You have the bad address set up as an override in /etc/hosts (which traceroute and curl honor, but the host or dig tools bypass). Check from a different device.

• Your DNS server was lying at the moment, e.g. maybe the network admin foolishly tried to override the domain name with a custom address. (Your 2nd host command shows good results though.) Try using a different connection such as public Wi-Fi or mobile 4G to bypass any interception.

• GitHub's nameservers were inconsistent and returned different results at different queries. (The domain is hosted by AWS and Dyn, it's not impossible that one update call succeeded but one failed.) Wait a while and try again.

Github.com does resolve on your computer, as evidenced by the fact that traceroute has an IP address to work with (192.30.253.113). Your problem is not with DNS resolving.

In fact, the test you are trying to do has very little to do with DNS. The resolving has already been done before the test even starts. Your problem is with your packets not arriving at Github's servers.

However, the traceroute will be inconclusive for this, as it seems that some parties on the path to Github.com, have disabled traceroute in some way (see below). Github.com still works fine for me, even though I see the stars.

 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  * * *

At this point, I think there isn't much you can do. Resolving works, and you can get to the internet. The rest is up to other parties.