Introduction

The last thing any business owner wants is to find their website is offline and has been for a significant period of time. One of the potential causes of website downtime is DNS changes.

Domain Name System (DNS) records are the brains behind all digital aspects of your business. They tell a visitor to your business' website where to go to find the website's hosting. When someone sends you an email the DNS records tell the email where to go to find your email hosting. DNS records can also be used to validate or run things like email marketing accounts, Google Search Console, etc.

Your DNS records are such an important part of your business' online presence, that you really don't want them to suddenly change or be misconfigured. Whether by personal accident, malicious intent or third-party errors, DNS changes can bring your business to a halt. Plus, changing the records back can take sometimes as much as 24-48 hours!

In this post, we are going to explore three real-world examples that I was involved in to see why we offer DNS change monitoring. All names and business details have been changed, but the rest of the information is completely true.

Case study #1: Adam's coworking business

Adam reached out to me as he had acquired a coworking and office space provider. With a business partner, they had purchased a brand that offered virtual or physical office space, managed business phone numbers and other business resources.

After acquiring the business it was clear that the existing website was very outdated, often went offline and was not fit for purpose. Having previously worked with me to build a website for his main business, Adam asked me to help.

After a month of work designing the website, and developing the complex multi-step form and payment system, the new website was live. It was an excellent website, but one that provided lots of complex challenges.

As part of the launch, I needed to log into Adam's GoDaddy account to change the nameservers to point the domain towards Cloudflare. This allowed me then to update the A record of the DNS records to the new hosting and allow the website to go live.

The next day, I went to work on the website's performance optimisation and made some tweaks. When I entered the website's URL into my browser I was met by an error page. The website was not working!

It took me a while to work out why, as it was very unclear why suddenly it was offline when nothing should've changed. Eventually, I narrowed it down to the DNS records. Mainly, this was because Cloudflare no longer seemed to be connected.

When logging into Adam's GoDaddy account I discovered that overnight GoDaddy has reverted the change I had made. They had changed the nameservers back to the previous host and brought the website offline.

As pleased as I was that it was not my fault, I was very dismayed that a seemingly respected company had chosen to undo a critical change I had made. Luckily, I was able to change the nameservers again, restore the website and it never happened again.

There may have been at least 12 hours of downtime for the website. All due to a third-party arbitrarily deciding to undo something!

Case study #2: Tom's Consultancy

Tom had set up a consultancy company and experienced some issues with their first website. They had worked with a web agency that promised lots of excellent things but delivered something rather different.

Tom had reached out to me to help with their website. First to stabilise the website due to repeated downtime and then to rebuild it to fix the inherent issues the first company had created.

A new website was carefully worked on with multiple internal people contributing to the content. After many weeks of hard work, the website was ready to launch.

After again logging in to Tom's 123-Reg account and changing the nameservers, the website was launched. Alongside this, uptime monitoring was set up to catch any website downtime.

One evening, I was messaged with a screenshot of the website. It was the 123-Reg parked domain image. This is the image you see when you have bought a domain but not connected it to any hosting.

Why was the website suddenly showing this months after the website was launched?

I logged into the 123-Reg account and, again, the nameservers had changed. My initial thoughts were to the incident with Adam and a belief this was the same situation. Odd, though I thought, that this happened so long after my change when Adam's issue was fairly quickly after.

After discussing it with 123-Reg's customer service, I was left with a wholly different situation. I was presented with access logs that showed someone had logged into Tom's 123-Reg account that evening and changed the nameservers.

Was it a hack or did someone else with the login details do this? Tom was certain it was not him, as was I. There was one other person who had used the login details, so we were left assuming it was them. A malicious act of sabotage. How pathetic!

Leaving the malicious act to one side, why did I not know this had happened? I had uptime monitoring in place.

What I learnt was that the uptime monitoring could not catch this sort of incident. The monitor loads a website and looks for a 200 code, which says to it that, yes, there is a web page at that address. The 123-Reg parked domain page is a web page, so the uptime monitor did not realise it was anything different!

This is the incident where I first encountered visual change monitoring. I realised I now needed a service that would tell me if the website was still classed as 'up' but what was there was fundamentally different.

Case study #3: Jim's landing page

Jim had spent time purchasing a bunch of domains that would help him launch a sideline business. With experience in DevOps, he wanted to launch a business that helped him connect with DevOps professionals in his local area.

I helped him build and launch the website and it worked well for many months.

One evening (why is it always evenings?), I had an alert from one of the two uptime monitors that were checking this website to tell me there was an issue.

On checking the web address, I was this time met by the GoDaddy parked domain page. Had they reverted the nameservers? Had someone hacked in and changed the records? No.

Speaking to Jim, he had decided to move some of his domains from one domain provider to another. In moving this landing page's domain he had not realised that all DNS records had been wiped. Most domain and DNS providers will map the current records to prevent downtime.

This was simply a mistake to not check and update the records.

Weirdly, though, one uptime monitor had alerted me, the other one had not. The website stayed down for months after this incident and one monitor never alerted me. The other decided it was fixed and went back to tell me it was all ok when it clearly was not.

I had visual change monitoring, which also alerted me to the issue. However, I wondered if I needed a monitor to check for DNS record changes. Clearly, there was a potential issue here and I wanted to know if and when records were altered. Especially if uptime monitoring cannot catch these sorts of incidents.

How UpWatch can help prevent similar issues

I created UpWatch to share my knowledge of what it takes to comprehensively monitor a business website. These three incidents were some of the most instrumental in my path to forming UpWatch.

From my experiences, uptime monitoring is great, but it is not enough. On its own, it cannot catch these sorts of incidents. Visual change monitoring and DNS change monitoring as vital in providing a complete understanding of website issues.

Check out our pricing page to find out how you can get the most comprehensive website monitoring, built from experience. From only £5 per month, you can rest assured that your website is being properly monitored and protected.