Github.com resolves but times out
For some reason I'm unable to reach github.com, the connection just times out; I've been having this issue consistently for the past few days. I don't have this problem with any other website.
I'm running macOS 10.15.5.
Running traceroute I see the DNS resolves but then gets lost (edit: answers pointed out that this is expected for github):
$ traceroute github.com
traceroute to github.com (192.30.253.113), 64 hops max, 72 byte packets
1 10.0.0.1 (10.0.0.1) 5.508 ms 1.134 ms 1.275 ms
2 192.168.1.1 (192.168.1.1) 3.066 ms 2.711 ms 2.658 ms
3 80.10.124.196 (80.10.124.196) 69.645 ms 53.357 ms 55.386 ms
4 10.125.222.74 (10.125.222.74) 54.702 ms 61.938 ms 38.273 ms
5 ae44-0.niidf202.paris15earrondissement.francetelecom.net (193.252.98.246) 108.873 ms 32.476 ms 102.200 ms
6 193.252.137.74 (193.252.137.74) 55.651 ms 82.649 ms 70.433 ms
7 zayo-9.gw.opentransit.net (193.251.250.188) 38.020 ms 85.435 ms 91.153 ms
8 ae27.cs1.cdg11.fr.eth.zayo.com (64.125.29.4) 168.142 ms 220.846 ms 195.284 ms
9 ae0.cs1.cdg12.fr.eth.zayo.com (64.125.29.84) 180.439 ms 119.870 ms 108.460 ms
10 ae2.cs3.lhr11.uk.eth.zayo.com (64.125.29.25) 114.051 ms * *
11 * * *
12 * * *
13 * * *
14 209.66.120.181.ipyx-243981-004-zyo.zip.zayo.com (209.66.120.181) 112.761 ms 120.212 ms 113.661 ms
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
...
Using host confirms that DNS resolves
$ host github.com
github.com has address 140.82.113.4
github.com mail is handled by 5 ALT1.ASPMX.L.GOOGLE.com.
github.com mail is handled by 5 ALT2.ASPMX.L.GOOGLE.com.
github.com mail is handled by 10 ALT3.ASPMX.L.GOOGLE.com.
github.com mail is handled by 10 ALT4.ASPMX.L.GOOGLE.com.
github.com mail is handled by 1 ASPMX.L.GOOGLE.com.
Running curl on the IP from host I can see the connection timing out trying to reach 192.30.253.113:
$ curl -v --insecure -L 140.82.113.4
* Trying 140.82.113.4...
* TCP_NODELAY set
* Connected to 140.82.113.4 (140.82.113.4) port 80 (#0)
> GET / HTTP/1.1
> Host: 140.82.113.4
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Content-length: 0
< Location: https://140.82.113.4/
<
* Connection #0 to host 140.82.113.4 left intact
* Issue another request to this URL: 'https://140.82.113.4/'
* Trying 140.82.113.4...
* TCP_NODELAY set
* Connected to 140.82.113.4 (140.82.113.4) port 443 (#1)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: C=US; ST=California; L=San Francisco; O=GitHub, Inc.; CN=github.com
* start date: May 5 00:00:00 2020 GMT
* expire date: May 10 12:00:00 2022 GMT
* issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High Assurance Server CA
* SSL certificate verify ok.
> GET / HTTP/1.1
> Host: 140.82.113.4
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Content-length: 0
< Location: https://github.com/
<
* Connection #1 to host 140.82.113.4 left intact
* Issue another request to this URL: 'https://github.com/'
* Trying 192.30.253.113...
* TCP_NODELAY set
* Connection failed
* connect to 192.30.253.113 port 443 failed: Operation timed out
* Failed to connect to github.com port 443: Operation timed out
* Closing connection 2
curl: (7) Failed to connect to github.com port 443: Operation timed out
* Closing connection 0
* Closing connection 1
At this point I'd think that the issue is on github's side, however I'm the only one having this issue among all my colleagues.
Edit 2 I logged in with the macOS guest account, and was able to access github. The issue still shows on another regular user account though. So the issue comes from some user-specific config.
I've also run sudo killall -HUP mDNSResponder and sudo dscacheutil -flushcache; it didn't fix the issue.
Edit 3
If I call curl without -L (i.e. no redirects) the request succeeds, I get the HTML for GitHub back:
$ curl -H "Host: github.com" --insecure -v https://140.82.118.3/
* Trying 140.82.118.3...
* TCP_NODELAY set
* Connected to 140.82.118.3 (140.82.118.3) port 443 (#0)
[...]
* TLSv1.2 (IN), TLS handshake, Finished (20):
[...]
<!DOCTYPE html>
<html lang="en">
<head>
[...]
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
hostordigtools 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
hostcommand 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.