There was an outage on indilib.org on Saturday May 18. Since then, it has been impossible for me to access the site in my normal way, through my ISP(Cox Communications). Every attempt to access it has produced a 403 error. Originally, I assumed everyone would have this error. As I had no access to the site, I opened an issue on Cloudy Nights Is the INDI website server down? (5/18/2024) . While one or two users reported seeing the outage, it soon became clear that most if not all (other than myself) did not. I also found that the problem persisted in every machine in my home network: my Linux PC, my wife's Windows PC, my IPhone, my wife's Samsung.

My original suspicion was that not all of the INDI website servers were successfully brought back up. But after finding by Tuesday May 21 that there was no one other than me having the problem that I knew of, someone suggested that caching might be an issue. Of course, I had been frantically clearing my cache in browsers for days, but the idea of caching at my ISP had not occurred to me. In testing this hypothesis, I turned WiFi off on my IPhone, and then I could immediately reach the site, using cellular data rather than WiFi, through my network.

Thinking I had something, I called Cox, my ISP, and they didn't know how to check the hypothesis. They were able to reach the indilib.org site, though it isn't clear to me what that might mean. I then started investigating my Google Nest router, engaging with their tech support, but nothing they were able to suggest, first trying new DNS settings avoiding the ISP's DNS, then factory resetting the router, got me anywhere. More fruitless discussions with Cox ensued.

I am back to the hypothesis that somehow connections from my home network to indilib.org are being mangled, i.e. sent to a server that is not fully brought back up.

But the one useful thing I've learned from all this fruitless struggle is that I CAN reach the site as long as I don't go through my ISP. I have now connected my computer to my IPhone's Personal Hotspot, which is how I'm sending this to you now. (I could just have used the IPhone itself to connect without WiFi, but it's easier to type on my laptop).

Is there a description of this outage anywhere, and are the administrators of indilib.org aware of any ongoing issues connected to this outage?

I would be happy to be in put in contact with this site's network engineers to further debug this situation.

Thank you.

I also had a site outage for several days until yesterday morning. It happened on both computers I tried it on. Everything seems to work for me now.

Have you tried clearing the DNS cache on your computer?
If not and running Windows, open an CMD prompt as an administrator and enter
ipconfig /flushdns
and hit enter then try to see if you can connect.

If using a Mac, open a terminal client and enter
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
it will then prompt you for your password, enter that and then hit enter then exit out of the terminal and see if it works.

Have you tried clearing the DNS cache on your computer?
No, I haven't, because as I said in my original post, the problem is seen on four devices in my home, two of which have never accessed INDI before as they belong to my wife, who has no interest in such things.

However, it costs me nothing to try.

In my version of Ubuntu Linux, the command is:
sudo resolvectl flush-caches
As I am now accessing the site through my IPhone hotspot, my next reply will indicate how it worked.

Uh, no, it didn't work but it was worth a try. I had to switch to my IPhone hotspot to post this. Thanks.

I have a similar issue with the ZWO site when I am on home ISP. When going to their dl.zwoastro.com it times out. I figured out it was in the Phillipines that the issue resided after running a traceroute to that domain.
If you have tracert installed on your Linux computer, try running a tracert indilib.org. You may find the same issue I noticed with them... the traceroute times out along the path.

root@Z103-NUC:/home/stellarmate# traceroute indilib.org
traceroute to indilib.org (104.37.86.27), 30 hops max, 60 byte packets
1 _gateway (10.10.10.253) 1.272 ms 2.718 ms 2.986 ms
2 64.188.192.1 (64.188.192.1) 11.702 ms 44.019 ms 45.838 ms
3 173.246.243.5 (173.246.243.5) 46.742 ms 48.476 ms 47.962 ms
4 * * *
5 be2445.ccr41.dfw03.atlas.cogentco.com (154.54.46.125) 50.506 ms 50.490 ms 50.477 ms
6 be2763.ccr31.dfw01.atlas.cogentco.com (154.54.28.73) 48.351 ms 12.571 ms be2764.ccr32.dfw01.atlas.cogentco.com (154.54.47.213) 10.854 ms
7 be2432.ccr21.mci01.atlas.cogentco.com (154.54.3.134) 36.732 ms 36.716 ms 36.701 ms
8 be2831.ccr41.ord01.atlas.cogentco.com (154.54.42.166) 58.381 ms be2832.ccr42.ord01.atlas.cogentco.com (154.54.44.170) 58.741 ms be2831.ccr41.ord01.atlas.cogentco.com (154.54.42.166) 60.867 ms
9 be2717.ccr21.cle04.atlas.cogentco.com (154.54.6.222) 60.852 ms be2718.ccr22.cle04.atlas.cogentco.com (154.54.7.130) 55.669 ms be2717.ccr21.cle04.atlas.cogentco.com (154.54.6.222) 58.304 ms
10 be3744.rcr51.tol01.atlas.cogentco.com (154.54.0.146) 60.815 ms 61.213 ms 60.768 ms
11 be2123.rcr21.dtw04.atlas.cogentco.com (154.54.82.138) 66.204 ms 55.745 ms 56.138 ms
12 38.142.133.98 (38.142.133.98) 52.355 ms 52.270 ms 61.438 ms
13 198.207.200.70 (198.207.200.70) 67.299 ms 68.613 ms 68.704 ms
14 * * *
15 * * *
<deleted>
29 * * *
30 * * *


198.207.200.70 is registered to ManagedWay in Troy Michigan. Indilib.org IP is in Traverse City, Michigan, so I wonder if they have some issues present on that leg of the journey.
The traceroute should have stopped at the Indilib.org IP address and not on step 13 of the routing path.

This is good stuff, thank you, Tracy for the detective work. I do have traceroute on linux and when I ran it, while connected to my ISP, my experience was similar:

1 192.168.86.1 5.028ms 4.330ms 2.357ms
2 10.101.56.1 13.972ms 11.684ms 11.736ms
3 100.127.77.68 12.677ms 14.555ms 13.491ms
4 100.120.100.36 19.758ms 17.847ms 17.918ms
5 213.248.104.26 19.037ms 17.602ms 16.647ms
6 62.115.125.53 17.909ms * *
7 * * *
8 62.115.139.131 39.531ms 39.519ms 42.631ms
9 62.115.136.118 39.916ms * *
10 * * *
11 * * *
12 62.115.115.71 130.241ms 62.211ms 141.420ms
13 * 62.115.126.158 66.798ms *
14 62.115.137.141 69.973ms 68.515ms 69.068ms
15 213.248.100.195 75.794ms 75.992ms 74.160ms
16 192.111.55.146 81.374ms 78.892ms 78.194ms
17 192.111.55.146 77.702ms 79.937ms 79.670ms
18 198.207.200.70 81.993ms 79.134ms 81.192ms
19 * * *
20 * * *
21 * * *

Mine crapped out at the same place yours did, 198.207.200.70.

Oddly, though, when I switched my computer to use my IPhone's hotspot, from which I CAN access the site, it crapped out at the same place as when I used my WiFi, even though the path it took to get there was different:

1 172.20.10.1 31.539ms 4.231ms 4.892ms
2 172.26.96.169 91.755ms 70.751ms 69.333ms
3 107.72.233.4 72.292ms 68.863ms 78.574ms
4 12.83.188.161 85.226ms 93.729ms 73.261ms
5 * * *
6 * * *
7 * * *
8 * 32.130.90.123 89.354ms *
9 * * *
10 154.54.27.117 139.040ms 78.875ms 71.747ms
11 154.54.44.85 258.855ms 307.660ms 204.183ms
12 154.54.5.218 307.068ms 204.817ms 204.664ms
13 154.54.87.30 174.389ms 116.706ms 220.795ms
14 154.54.31.90 307.200ms 415.590ms 198.556ms
15 154.54.42.166 307.292ms 307.500ms 306.712ms
16 154.54.7.130 306.953ms 204.894ms 186.695ms
17 154.54.30.130 222.639ms 204.901ms 306.995ms
18 154.54.82.138 204.738ms 139.594ms 167.707ms
19 38.142.133.98 204.584ms 204.629ms 330.329ms
20 198.207.200.70 283.974ms 153.681ms 134.261ms

I don't know how closely traceroute follows the path used by actual clients like browsers.

traceroute is the usually the same path. It's how the traffic is told to get to from point A to point B.
There is something within either the hosting for the indilib.org domain or a step above them. The site admins should be able to get with their hosting provider to have them start researching.

I don't know the details, but my understanding is that there was a bot-based denial of service attack on the indilib.org site starting Friday or Saturday that brought the site down for several days until Jasem worked with the hosting provider to bring the site back up, I believe sometime yesterday.

No, turned out it was not DDoS but some internal error loading a template (this is what the hosting providing did). At any rate, we're migrating to a new website now and hopefully should be ready in about 4-6 weeks.

I’ll be happy to see this improvement!

Hi
It could be a routing problem between ISP, it usually happens to me that some client does not access a particular page but from another ISP yes, some route is down in the middle, generally in a few days they are reconfigured
Best regards
Osvaldo