Everyone likes to meme on DNS but it’s literally designed to make these servers as unimportant as possible. It’s a really well designed system that will probably be around as long as humans exist.
The issue here is that they didn't notice until someone with a direct contact at Cogent emailed them to tell them.
A corollary to that issue is the fact that the last news item is the same thing: they failed to get updates and their monitoring failed to tell them. Supposedly their monitoring was fixed then, in 2019. Why should we believe it's any more fixed now?
https://www.indilib.org/forum/general/14691-indilib-org-site...
The glitch began on the 18th and is now in the situation where some users can and others cannot access the site. I, myself, cannot access the site six days later, when connected via my network wifi router (ISP is Cox Communications), but can, if instead I connect to the Hotspot on my IPhone(AT&T). Traceroutes fail in either case, continually, at the server 198.207.200.70 (which does not appear to be owned by cogent).
What, if anything, can an end-user such as myself do in such a situation. Where can such an end-user send a report that might lead to a fix? I assume the owners of the indilib.org site are trying whatever they can, but I have no idea what their reporting chain might be.
I know this similar scenario happened to our lab setup of root servers.
Huge oversight from ICAAN and ARIN. I know they are behind anycast, but each server must also have an unicast address for management.
"2024‑05‑23 - On May 21 at 15:30 UTC the c-root team at Cogent Communications was informed that the root zone as served by c-root had ceased to track changes from the root zone publication server after May 18. Analysis showed this to have been caused by an unrelated routing policy change whose side effect was to silence the relevant monitoring systems. No production DNS queries went unanswered by c-root as a result of this outage, and the only impact was on root zone freshness. Root zone freshness as served by c-root was fully restored on May 22 at 16:00 UTC."
Edit to add:
This was mentioned on Tuesday on the dns-operations list:
https://lists.dns-oarc.net/pipermail/dns-operations/2024-May...