Yes. In fact, I was just about to post this myself. It seemed to have started--i dunno--maybe a week ago? Ten days before? Just getting this message posted is becoming an ordeal because of this problem.
Yes !!! I'm having the same problem. Glad it's not just my computer.
I sent a PM yesterday to Cliff to see if it's something that he can fix.
The message I'm getting is as folllows,
Your connection to this site isn't secure This site does not have a certificate. Because this connection is not secure, information (such as passwords or credit cards) will not be securely sent to this site and may be intercepted or seen by others.
That's what I've been getting, intermittently. That same screen grab from maryjane, or something almost exactly like that. That's when my attempt to access the forum Times Out. But even it doesn't Time Out and cause that error diagnostic screen, there is a long delay before I get the expected response from the forum. That's been happening more often than not.
It is intermittent. Here, I ran traceroute on fiero.nl three times, one right after another and traced google.com once, as a sanity check. (Centurylink nameservers)
It also happens on my Verizon phone.
[This message has been edited by williegoat (edited 12-12-2021).]
Isn't just DNS and likely out of control for Cliff to fix... Ping times are very long and before Cliff's server.
Use Tracert to see Pings for many routers along the way to EU let alone NL.
fiero.nl and other ____.nl is nearly always ~ 15 - 20 hops for US and Canada users as going thru one or more Atlantic and other Undersea Cables. Right now Ping times in the middle of Tracert around 13 hops goes from ~ 20 ms to ~ 80 - 100 ms and everything after have 90 to 100 ms or more.
If was only DNS... Often change local DNS servers can help. Or add record to Host file in your machine so doesn't even go thru DNS.
But those won't work conentco.com etc have problems that runs undersea cables. Might have setting for the Browser to allow to wait longer to timeout a page that maybe help better here. You have to check your browser support doc's.
Example: Hope 1 is always your local router/gateway. Name is standard name for Netgear and other routers and always have Non-rout able IP for SOHO units. Hope 2 - 8 name/ip deleted by me. Ignore Hope 11. Timeout often means that router ignores all Pings.
Pinging www.fiero.nl [217.148.167.147] with 32 bytes of data: Reply from 217.148.167.147: bytes=32 time=103ms TTL=43 Reply from 217.148.167.147: bytes=32 time=100ms TTL=43 Reply from 217.148.167.147: bytes=32 time=99ms TTL=43 Reply from 217.148.167.147: bytes=32 time=98ms TTL=43
Ping statistics for 217.148.167.147: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 98ms, Maximum = 103ms, Average = 100ms
C:\Users\The Ogre>tracert 217.148.167.147
Tracing route to 217.148.167.147 over a maximum of 30 hops
1 2 ms 1 ms 1 ms routerlogin.net [192.168.0.1] 2 11 ms 10 ms 10 ms 3 9 ms 9 ms 11 ms 4 9 ms 9 ms 9 ms 5 10 ms 9 ms 9 ms 6 8 ms 10 ms 9 ms 7 9 ms 9 ms 9 ms 8 9 ms 10 ms 10 ms 9 13 ms 13 ms 16 ms be-31213-cs01.ashburn.va.ibone.comcast.net [96.110.42.97] 10 15 ms 13 ms 13 ms be-2111-pe11.ashburn.va.ibone.comcast.net [96.110.32.122] 11 * * * Request timed out. 12 40 ms * 22 ms be3084.ccr42.dca01.atlas.cogentco.com [154.54.30.65] 13 21 ms 18 ms 17 ms be2807.ccr42.jfk02.atlas.cogentco.com [154.54.40.109] 14 86 ms 88 ms 88 ms be2490.ccr42.lon13.atlas.cogentco.com [154.54.42.86] 15 98 ms 100 ms 98 ms be12488.ccr42.ams03.atlas.cogentco.com [130.117.51.42] 16 98 ms 98 ms 98 ms be3458.ccr21.ams04.atlas.cogentco.com [154.54.39.186] 17 97 ms 99 ms 98 ms be2514.rcr01.b015515-0.ams04.atlas.cogentco.com [130.117.0.130] 18 97 ms 96 ms 105 ms 149.11.39.250 19 108 ms 101 ms 100 ms 92.48.253.42 20 102 ms 103 ms 103 ms 84.244.189.118 21 101 ms 101 ms 100 ms www.fiero.nl [217.148.167.147]
Trace complete.
------------------ Dr. Ian Malcolm: Yeah, but your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should. (Jurassic Park)
traceroute to 217.148.167.147 (217.148.167.147), 30 hops max, 60 byte packets 1 gi0-5-0-10.3.rcr21.phl01.atlas.cogentco.com (66.250.250.105) 0.622 ms 0.664 ms 2 be2364.ccr41.jfk02.atlas.cogentco.com (154.54.3.141) 2.813 ms 2.820 ms 3 be2317.ccr41.lon13.atlas.cogentco.com (154.54.30.186) 70.917 ms 70.862 ms 4 be12194.ccr41.ams03.atlas.cogentco.com (154.54.56.94) 76.039 ms 77.701 ms 5 be3457.ccr21.ams04.atlas.cogentco.com (130.117.1.10) 78.328 ms 76.255 ms 6 be2514.rcr01.b015515-0.ams04.atlas.cogentco.com (130.117.0.130) 78.286 ms 76.728 ms 7 149.11.39.250 (149.11.39.250) 77.493 ms 77.500 ms 8 cr01nh-as01cpl.wd6.net (92.48.253.42) 78.935 ms 77.614 ms 9 as01cpl-as03cpl.wd6.net (84.244.189.118) 80.085 ms 80.094 ms 10 www.fiero.nl (217.148.167.147) 79.055 ms 78.976 ms
Note that This trace skips all hops from you and your local ISP to their fist hop listed.
[This message has been edited by theogre (edited 12-12-2021).]
Originally posted by Jake_Dragon: Its not just Fiero.nl I noticed that several sites are having DNS issue over the last couple of days. Its worse depending on where the host is.
I was blaming Spectrum but perhaps its something else.
Doesn't matter what local ISP is if all use Cogent Undersea Cables to reach Fiero.nl
Can see DNS fail or Connect Timeout depending on ISP and local OS. Change DNS to any others like Cloudflare 1.1.1.1 may stop DNS fail and still timeout connecting to Europe sites. Note that a Browser "Error" can say DNS fail but mean just can't connect to X.
Also All Local OS have DNS Caches that should resolve Recent Names First. Depending on settings, often will not bother DNS servers unless Cache Time to Live has ended. Unless you have DNS over HTTPS like FF and some others browsers use to hide DNS from ISP etc. Then the cache if any is in the browser.
Cogent router names that shows about where a problem is... 3rd section of name is "City"/location above traces first problem is at or in between JFK (as is JFK Airport area in NY) and London... Example:
code:
My Trace 13 21 ms 18 ms 17 ms be2807.ccr42.jfk02.atlas.cogentco.com [154.54.40.109] 14 86 ms 88 ms 88 ms be2490.ccr42.lon13.atlas.cogentco.com [154.54.42.86]
Looking Glass Trace 2 be2364.ccr41.jfk02.atlas.cogentco.com (154.54.3.141) 2.813 ms 2.820 ms 3 be2317.ccr41.lon13.atlas.cogentco.com (154.54.30.186) 70.917 ms 70.862 ms
Amsterdam routers doesn't look happy either. 1st of 2 "ams" names maybe really in Cambridge for Undersea cable link. (See https://www.cogentco.com/fi..._networkmap_page.jpg but that likely doesn't show all links for various reasons.)
Originally posted by Cliff Pennock: It's a DNS issue which is unfortunately out of my control. Hopefully they will solve it soon.
Even "going direct" w/ IP # is slow or no connect to your server(s).
IOW For browser, I get "can't find" or "can't connect" errors at random times trying to get PFF Page. Or PFF page may load but not pip/button pics. And use several DNS servers and IP # direct or in Host all w/ same results.
Cogent and maybe more have issues on US to EU cable(s) still today.
Any w/ slow connecting should run tracert to see if pings are high at some hops like examples above. High > 90 ms pushes many things to see connecting w/ many lost packets and slows down even more to resend, often several times, the lost data. Example Default setting of Ping and Tracert programs will often timeout a attempt a little above 100ms. To add time to them have to add command switches. (ping -v & -w, tracert -w, all w/ values before name/IP#.)
If one browser has problems dealing w/ slow connecting, try another or add a new profile w/ default setting and no plugins.
Even "going direct" w/ IP # is slow or no connect to your server(s).
If that is the case, then that is caused by something outside of my servers. I tested the connection with the server through its IP addresses and saw no issues.
quote
And use several DNS servers and IP # direct or in Host all w/ same results.
Yes, the problem was with the authorative DNS, not others.
It turned out there is a DDos attack going on directed at the authorative DNS servers. This causes between 80%-90% of the DNS requests to be dropped. I think they solved it for now by redirecting DNS requests to a backup server.
It turned out there is a DDos attack going on directed at the authorative DNS servers.
Why do people do stuff like that? Is it the same mindset as the trolls we see on some forums? Losers who want to spread the misery? Anti Capitalist troublemakers? People who drive Subarus?
Even when DNS is fixed, That may take many hours to propagate to users...
Just now I edit Host again and seems to stopped "Can't find" but not "Can't load" errors. quick just add 217.148.167.147 www.fiero.nl below 127.0.0.1 localhost didn't bother pip or other servers.
Windows... Hosts is in C:\Windows\System32\drivers\etc Other OS should have a Hosts but could be anywhere.
Hosts isn't = to Hosts.txt or any other extension.
Can use Notepad and likely others but may need to Run as Admin then open in notepad or Windows UAC etc block saving the file. Avoid using Wordpad or other full word processing because many try to change formatting w/o much or no notice.
Best if save but don't close Notepad so can edit again if want to remove or rem out the record. (anything starts w/ # doesn't work)
Hosts changes are instant on save file. Does not need reboot etc.
Even when DNS is fixed, That may take many hours to propagate to users...
Just now I edit Host again and seems to stopped "Can't find" but not "Can't load" errors. quick just add 217.148.167.147 www.fiero.nl below 127.0.0.1 localhost didn't bother pip or other servers.
Windows... Hosts is in C:\Windows\System32\drivers\etc Other OS should have a Hosts but could be anywhere.
Hosts isn't = to Hosts.txt or any other extension.
Can use Notepad and likely others but may need to Run as Admin then open in notepad or Windows UAC etc block saving the file. Avoid using Wordpad or other full word processing because many try to change formatting w/o much or no notice.
Best if save but don't close Notepad so can edit again if want to remove or rem out the record. (anything starts w/ # doesn't work)
Hosts changes are instant on save file. Does not need reboot etc.
Now why didn't I think of that? It worked for me. Thank you!
For many Linux users it is: /etc/hosts
code:
$ sudo nano /etc/hosts
[This message has been edited by williegoat (edited 12-13-2021).]