My website is down. Now what? Part 2 – DNS Issues

This is part of a series on diagnosing your website outage issues. This is part two; links to the other parts are here.

In Part 1 of this series I covered the fact that your web browser needs to know the IP address of your website which is done via a process called domain name resolution. This happens under the covers and is facilitated by your domain’s name servers which are part of the Domain Name System. This domain name to IP address resolution is absolutely fundamental to the functioning of the web and if there are issues with your domain’s DNS records, or your local computer’s DNS, you won’t be visiting your website today.

How to identify a DNS problem

Computers have local DNS caches and even networks sometimes cache DNS records. When those caches exist, your computer’s query for an IP address will never hit your actual name servers. That means if those caches are wrong, your computer will have no idea how to access your site. So, how do you test this out?

The first piece of information you need is the IP address that your website is supposed to point to. For most of us, that is the IP address your web hosting service provided to you when you signed up. If you have other layers (as described in Part 1 of this series) then the IP address would have been provided to you by that service provider. If you’ve lost that information, then you can open a support ticket with that provider and ask them what IP address your domain should be pointed to. Armed with that information, you can then compare that to the IP address your computer thinks your domain is at.

The easiest way to check what IP address your computer associates with your domain is to run a simple ping command. You can do this from the command prompt of any Windows, Linux or Mac computer like so:

Your output may look slightly different but the first line-ish will show you the IP address that your computer thinks your domain is at. In my case, this is 192.124.249.6 which is correct. I know that my DNS records are supposed to point to that IP address as that is my firewall IP address.

If my output contained some other IP address like so:

That’s a big red flag.

Is it just you?

Maybe its only your local computer or your office network that has bad DNS. You can use external tools such as the “DNS Propagation Checker” at ViewDNS. Put your domain name into that field and it will show you what IP address the global DNS system thinks belongs to your computer.

If ViewDNS (or any other external tool) has the correct IP address, then you can conclude that you have a local DNS problem. You can then Google methods on how to clear the DNS cache on your particular computer (Windows, Linux, Mac all have different methods) and re-do the ping test. If it still returns the incorrect IP address then you’ll have to move outward and restart your router or engage your local IT department to flush whatever cache they have on the network. This type of problem is not something that your web host or CDN or firewall provider can fix for you.

If ViewDNS shows the same incorrect IP address that you’re getting from your ping test, then you can conclude that the DNS records at your DNS provider are incorrect. You know who handles your DNS because we discussed that in Part 1 of this series under the Know Your Architecture section. But, if you’ve forgotten you can use the DNS Report section of the same ViewDNS website to determine where your nameservers are. If you’re command-line savvy, something like this will also tell you:

The remedy for this would be to contact the company listed here and get your DNS records updated to the correct IP address. In many cases, your DNS is also hosted by your web host but that may not be the case as there is no technical reason why your DNS has to be hosted by your web host.

For some reason, web hosts and other DNS providers seem unable to name their nameservers in a way that makes it easy to identify the operating company. For example, my DNS is hosted at Name Cheap, but the nameservers are named registrar-servers.com. No idea why they do this, but Marc Kranat maintains a very useful list named “Who’s DNS Nameservers Are These” which can help you figure out who actually runs the nameservers you see.

Do you have any DNS records at all?

Another possibility is that you have no DNS records which will cause your browser to display some kind of ‘cannot resolve’ error such as the one from Chrome in the screenshot below.

ERR_NAME_NOT_RESOLVED
Google Chrome showing a DNS error “ERR_NAME_NOT_RESOLVED”

This happens when the nameservers specified at your domain registrar do not contain records for your domain. You can find out what nameservers are specified at your domain registrar by running a whois command either on the command line or via, you guessed it, ViewDNS‘ “Domain / IP Whois” report. Look for the Name Server lines:

Note that these are the same nameservers that were returned in my dig command earlier which is good. You don’t want to see a mismatch between the results of a dig for your nameservers and the nameservers that are set at your registrar. You can then query those name servers to see if they have records for your domain:

That’s what you want to see. If your nameservers do not respond, then you have a problem. The solution depends on the problem. If the nameservers at your registrar are wrong, then log in to your domain registrar and correct them to point to your proper nameservers. If the nameservers at your registrar are correct, then log in to your name server provider and update your DNS records.

If your DNS looks fine, then the next step is to check how healthy the routes are from your computer to your website. That is the topic of Part 3!