Last week, as you know, Macfilos was offline for many readers for nearly three days. This was an unprecedented break in communications in the 18-year-life of the magazine. Instead of seeing the site, readers were warned that a site could be impersonating Macfilos to steal personal data.
We realised early on that the problem lay with certification. For some reason, the SSL certification wasn’t working, so we spent some time investigating that. We even changed to a new provider in the hope that it would cure the issue.
Our webmaster, Richard Watts, worked with the hosting company to try to get the site up and running again. We explored several causes for the no-access, and came to the conclusion that IPv6 (an internet protocol that officially is not required until 2030) had been creating a conflict in our system. We have gone back to the trusty previous version IPv4 in the belief that this will solve the problem.
So we are back on the road again, and the editorial team and I offer our sincere apologies to our readers who rely on their daily fix of Macfilos. We are especially sorry to our author Andrew Tobin, whose exceptional article on multi-exposure in London was denied to our readers.
Pay a visit to Andrew’s article now if you missed it last week. The imagery is absolutely wonderful.
Join the Macfilos subscriber mailing list
Our thrice-a-week email service has been polished up and improved. Why not subscribe, using the button below to add yourself to the mailing list? You will never miss a Macfilos post again. Emails are sent on Mondays, Wednesdays, and Fridays at 8 pm GMT. Macfilos is a non-commercial site and your address will be used only for communications from the editorial team. We will never sell or allow third parties to use the list. Furthermore, you can unsubscribe at any time simply by clicking a button on any email.
Thanks Mike. That looked like a lot of hassle for you all. No worries from my end, there are some lovely comments coming in on my latest article.
Glad to see them, Andrew. It’s always a good feeling to get a positive comment. Some readers probably don’t understand the time and effort we all put into our articles.
From reading your explanation and from my somewhat limited knowledge of IT, my guess is that the security certificate had simply expired and the IPv4/6 issue was a red herring.
Thanks Chris. We thought the same, although the certificate was current until September 5. But what we did discover was that we were using a free service. This had not been pointed out by the hosting company. However, we upgraded to a paid-for service (more money!) and this still didn’t solve the problem.
Eventually the hosting company discovered that IPv4 cause the site to crash every time it was enabled. They are checking this but, in the meantime, we are back on IPv4.
I am not an expert and we have to rely to an extent on what the hosting company is telling us.
Mike
You mean IPv6 was causing the crash, Mike.
It’s possible they did not configure their AAAA records correctly? A lot of setups will prefer ipv6 if it is available. If the AAAA record is screwy, I guess some users’ browsers might fall back on the A record, but then have a mismatch later? In the past, some certificate authorities have had problems with users (i.e. providers) misconfiguring their DNS records, so this class of problem has a precedent. You could say that both the browser and their configuration would be at fault if this is the case, but, I don’t know the details, and MacOS Safari was fine this whole time. I was able to see the article when it came out. So if that is the root cause, I think it’s a bit sloppy, but I’d imagine that the margins for hosting plain-old websites are pretty thin, so you know how it goes. From what it sounds like, they didn’t know the root cause when they reported back to you, so we can only speculate.
Thanks for this, Arthur. It’s way over my head, but our (volunteer) webmaster, Richard Watts, will know more. It sounds like you could be a useful advisor on these issues! Want to volunteer?
Mike
You could fire me an email and ask me to take a look from the outside looking in. I could certainly run a dig on the record or run openssl commands against the server.
For a change like ipv4 to ipv6, I’m not sure I would have known where to look since I never even reproduced the issue. You need to at least get a detailed technical error message or otherwise reproduce the issue before you can figure out where the problem is happening.
The main onus is still on the service provider because only they know what charges they made to their configuration that would’ve caused the problem.
Hi Arthur, thanks for the feedback, yes lots of changes to the DNS records were made by us before our hosting company discovered the issue. We control the DNS records, so they supply us all the information to populate them. They are continuing to investigate why the issue suddenly started.
I don’t understand a word of what was said about the issue — my web days are long over.
But I do understand that the MACFILOS team worked quickly to get the site back up, and I’m very grateful for that: morning tea just isn’t the same w/o MACFILOS and the wonderful articles.
Thanks, Kathy.
Welcome back! : )