Could it have been this issue? The timing is about right.

arstechnica.com/security/2024/05/dns-gli...use-remains-unclear/

I think you're right.

I posted about the issue on Cloudy Nights and in this link you can see cogent mentioned in the poster's output:

9.|-- be3043.ccr22.ymq01.atlas.cogentco.com 0.0% 10 85.0 85.1 84.8 85.5 0.2
10.|-- be3260.ccr32.yyz02.atlas.cogentco.com 0.0% 10 92.9 93.2 92.7 95.1 0.7
11.|-- be2994.ccr22.cle04.atlas.cogentco.com 0.0% 10 101.0 101.2 101.0 101.5 0.1

Odds are the issue lies with the provider at 198.207.200.70.
Every one of my traceroutes I ran ended there.
Cogent is apparently still having some issues as my hop between 173.246.243.5 and be2445.ccr41.dfw03.atlas.cogentco.com (154.54.46.125) hand a lengthy pause in it.
But the issue with using traceroute, they could have a firewall engaged at 198.207.200.70 blocking it (the most likely thing since others can reach indilib.org).

Something else I find interesting is this:
Even though, when I set my network to my IPhone's hotspot (as I am doing now), I successfully reach this site, traceroute still fails as soon as it hits 198.207.200.70.

$ traceroute -m25 indilib.org
traceroute to indilib.org (104.37.86.27), 25 hops max
1 172.20.10.1 6.000ms 1.778ms 1.555ms
2 172.26.96.169 79.567ms 72.676ms 65.588ms
3 107.72.233.4 72.314ms 69.980ms 77.937ms
4 12.83.188.161 154.624ms 84.241ms 223.053ms
5 * * *
6 * * *
7 * * *
8 * * *
9 154.54.3.69 214.815ms 220.188ms 83.413ms
10 154.54.45.161 310.007ms 308.636ms 90.874ms
11 154.54.26.54 214.880ms 307.451ms 204.224ms
12 154.54.87.22 204.761ms 204.757ms 168.109ms
13 154.54.31.90 241.293ms 204.739ms 204.958ms
14 154.54.42.166 204.561ms 204.892ms 204.572ms
15 154.54.6.222 204.779ms 204.678ms 204.817ms
16 154.54.0.146 307.118ms 307.495ms 208.502ms
17 154.54.82.138 200.622ms 204.882ms 204.545ms
18 38.142.133.98 204.696ms 164.440ms 347.967ms
19 198.207.200.70 204.271ms 204.807ms 204.587ms
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *

Why is traceroute getting stuck at 198.207.200.70, when the actual browser attempt apparently doesn' t even go there?
And of course, when I connect via my home wifi network, traceroute also fails by a completely different path at 198.27.200.70.

I now think you're right. Cogent is only involved in one of the two traceroute failure scenarios, whereas 198.207.200.70 is always where it dies.

While I am certain that the administrators of this site are doing whatever they can to resolve this situation, each day that it goes unresolved indicates to me a much more serious problem. For thirty years the whole fabric of our society has been dependent on a working Internet.

Given all the problems our society faces, the problems of a website catering to a small group of astronomy aficionados might seem like small potatoes. But the evidence presented so far here indicates that there is a broken path that is crucial not just to our little group but potentially many others as well.

It disturbs me that there is apparently little that we can do about this.

Hi Everybody

I also noticed the outage, and it (for me) took place only with indilib.org. I was not investigating, as servers sometimes go down. It might very much have been the mentioned root-server problem. DNS issues can be very strange and location/provider make a difference. Fact is, that the internet is very fragile. My strategy: not having control, I relax and wait for the issue to go away.

Cheers, Peter

"Fact is, that the internet is very fragile. My strategy: not having control, I relax and wait for the issue to go away."

Much to be said for that, Peter. I started obsessing about it a few days ago as I kept getting emails about replies to posts I'd made that I couldn't access. I bothered my ISP and Google Tech support about a supposed "cache issue" that someone, somewhere suggested. It was all BS. Then at least I discovered the possibility of connecting by going through my cel phone service rather than my ISP and that is how I'm talking to you now. Using traceroute, I can now see where the Internet has broken, but there isn't a damned thing I can do about it except wait. Oh well, there are worse situations to be in. First-world problem and all that.

DNS caching/caching issues are not BS. They do occur, they do require action. It is ONE of the things that could have affected your traffic.
When trying to resolve issues like this, you start at the beginning and then work forward. You don't immediately pull out the sledge hammers to fix it, as usually they aren't required.
Generally the issue you are running into does involve DNS issues.
Have you tried changing the DNS servers on your computer to something else, especially if you are using your routers or ISP defaults. It is not unusual for an ISP to have DNS issues, especially after a backbone issue, they may be slow to resolve. I think I remember you saying you were using a Google Nest for routing?
Try using any of the following. You can take one a primary from CloudFlare and a secondary from Google if you want, but I generally just choose one (usually CloudFlare).
CloudFlare Primary: 1.1.1.1 Secondary:1.0.0.1
Google Primary: 8.8.8.8 Secondary: 8.8.4.4
OpenDNS Primary: 208.67.222.222 Secondary: 208.67.220.220

If you are stuck using IPv6 on your home network, try these for your IPv6 DNS servers
CloudFlare Primary: 2606:4700:4700::1111 Secondary: 2606:4700:4700::1001
Google Primary: 2001:4860:4860::8888 Secondary: 2001:4860:4860::8844
OpenDNS Primary: 2620:119:35::35 Secondary: 2620:119:53::53

I don't know if you have a cable/fiber/dsl modem hooked up above your NEST router. I do with my setup at the house, but I also have my modem (a cable modem) configured for pass-through mode, so all it does is send the signals directly to my router (a TP Link) and the router does registration with the ISP using the static IP info I pay for, and also uses my custom DNS settings. If your system is set up with a modem that connects to your ISP and it pulls it's own information (IP address, DNS servers) from the ISP via DHCP and then your NEST router connects to it and pulls an IP address from it but then runs its own DHCP server to issue addresses to the other devices you connect to, you have added a link in there that may be introducing issues.

>> DNS caching/caching issues are not BS. They do occur, they do require action. It is ONE of the things that could have affected your traffic.

You are correct, caching issues may be a possibility but I think it was a dead end in this case. They were not the reason for the issue in this case, as my contacts with Cox and Google strongly suggested. The issue was a blockage somewhere along the way as the traceroute results shown above showed. The Google people had me try substituting the 8.8.8.8 DNS for my ISP's, which did not help. And I tried it at both my router level and my individual device level. On your suggestion, I just tried the OpenDNS ip's you provided and they did not help the situation. Again, the fatal 198.207.200.70 appeared in the traceroute I did and it ended there.

>>I don't know if you have a cable/fiber/dsl modem hooked up above your NEST router. I do with my setup at the house, but I also have my modem (a cable modem) configured for pass-through mode, so all it does is send the signals directly to my router (a TP Link) and the router does registration with the ISP using the static IP info I pay for, and also uses my custom DNS settings. If your system is set up with a modem that connects to your ISP and it pulls it's own information (IP address, DNS servers) from the ISP via DHCP and then your NEST router connects to it and pulls an IP address from it but then runs its own DHCP server to issue addresses to the other devices you connect to, you have added a link in there that may be introducing issues.

I have a cable Modem (Motorola MB8611 DOCSIS3.1) between my ISP and my router. I don't have this pass-through mode enabled, if indeed it's supported on the modem, which I've not messed with, and in any case I am not paying Cox for a static IP, so my system is using ordinary DHCP. My current hypothesis is that some sysadmin somewhere, on May 18. probably in response to the Cogent outage, made changes to routing that caused a hop to the fatal address 198.207.200.70 where good packets go to die these days. Since the system is working for you, perhaps you could try a traceroute to indilib.org and see if 198.207.200.70 does or does not appear in the results.

Thanks.

I hit the same dead spot at 198.207.200.70. All that means his that they are not passing the ICMP packets onward. It's probably their firewall configuration that is stopping it. At the same time, I CAN connect to indilib.org (doing so right now with this post that ran all those traceroutes from). So not being able to get beyond that one IP does not guarantee that is the issue. Odds are it's a strong player, but it is no guarantee.
From my understanding, you connect your computer to your phone hotspot and you can reach it. You connect to your WiFI hotspot (for your home ISP) and you cannot?
If so, have you checked in your router to make sure that either the domain or IP for indilib.org is not being blocked? I know some routers have the ability to block based upon various factors - some it's an additional cost and some have it built in. My TP Link system has one called HomeShield. And with being able to connect from the same computer via one access path and not the other, it puts more weight towards your ISP and/or router.
It has the ability to block based upon multiple factors, one being parental control. That got enabled some way on it and was blocking access to one of my old sites, which was not surprising since it is tobacco related. That software did give me an alert that it was blocking access though. Not all of them may do that.
So, check in your router to make sure that the domain or the IP for indlib.org (104.37.86.27) is not being blocked.

There is also the remote possibility that your ISP IP is being blocked itself. Have you tried to force getting a new IP from your ISP? Because of the various times of DHCP leases, this could mean that you have to leave your router off for an extended period of time and then hope that you pull a new IP address when it powers back up. Comcast seems to have various times... from 2 hours to 4 days, apparently depending on your location. You may be able to contact your ISP and see if they can force a new IP address for your router. If that resolves the issue, then it becomes your ISP problem to clear up as for some reason that IP got blocked further upstream.
There could even be the possibility for some reason your ISP IP is blocked at the indilib.org server itself. I block quite a few connections using CSF on my servers that I only know about because I do have email alerts enabled (most don't mess with them).
I don't block based upon any port 80/443 connections, but that can be done also.

I hit the same dead spot at 198.207.200.70. All that means his that they are not passing the ICMP packets onward. It's probably their firewall configuration that is stopping it. At the same time, I CAN connect to indilib.org (doing so right now with this post that ran all those traceroutes from). So not being able to get beyond that one IP does not guarantee that is the issue. Odds are it's a strong player, but it is no guarantee.

I agree. I also hit that deadspot when I am connected via the phone.

From my understanding, you connect your computer to your phone hotspot and you can reach it. You connect to your WiFI hotspot (for your home ISP) and you cannot?

Correct.

If so, have you checked in your router to make sure that either the domain or IP for indilib.org is not being blocked? I know some routers have the ability to block based upon various factors - some it's an additional cost and some have it built in. My TP Link system has one called HomeShield.


Google Nest has something similar called "Family WiFi". It isn't enabled. We have no kids to protect.

And with being able to connect from the same computer via one access path and not the other, it puts more weight towards your ISP and/or router.

The router looks clean of any such blocking. But then, I'm not sure how I could tell with certainty. The guts of the thing are completely invisible except by that $%^&* smartphone app. So I think the ISP is the likelier of these candidates.

There is also the remote possibility that your ISP IP is being blocked itself.

Blocked by whom? Cox (the ISP)?

Have you tried to force getting a new IP from your ISP? Because of the various times of DHCP leases, this could mean that you have to leave your router off for an extended period of time and then hope that you pull a new IP address when it powers back up. Comcast seems to have various times... from 2 hours to 4 days, apparently depending on your location. You may be able to contact your ISP and see if they can force a new IP address for your router. If that resolves the issue, then it becomes your ISP problem to clear up as for some reason that IP got blocked further upstream.

Leaving the router off for an extended length of time is a non-starter. That reminds me. I need to fix my wife's Alexa which stopped working at the router factory reset I did a few days ago.

There could even be the possibility for some reason your ISP IP is blocked at the indilib.org server itself. I block quite a few connections using CSF on my servers that I only know about because I do have email alerts enabled (most don't mess with them). I don't block based upon any port 80/443 connections, but that can be done also.

I suppose I could ask them ... if I could figure out who "them" is.