Being one of the most fundamental services on the Internet, DNS can sometimes be a challenge
to configure or troubleshoot. This article focuses on some of the most common DNS issues and how to troubleshoot and resolve them.
The most common issue with DNS is propagation. Most commonly, you have made a change to your DNS configuration, but customers are not seeing the change at their location.
The key thing to realize is that there are countless DNS servers and intermediate DNS resolvers around the world. Even if you set your TTL to a short interval, it can take up to 48 hours for the changes to propagate around the world.
Another potential issue is cached DNS responses. DNS changes may be live and propagated, but the end users might still have old DNS responses in their local or intermediate caches. Setting low TTL values can help mitigate those scenarios in the future, but if DNS is being set for the first time, waiting for at least a few hours is usually the only solution. Another potential fix is flushing your local DNS cache.
There are many online tools that can give you an overview of the progress of the DNS
propagation. One such tool is "WhatsmyDNS", which can be used for querying various DNS record types across many DNS servers across the globe.
Misconfigured or nonexistent DNS entries
If DNS changes have propagated but traffic still isn’t routed as desired, the
DNS configuration might have a misconfiguration. For example, you might set a proper A record
for your apex domain (e.g. mywebsite.com) but you forgot to set the DNS record for your ‘www’
subdomain. If you try to reach your website through www.mywebsite.com, it will return a nasty error message. At this point, you need to verify the actual A or CNAME record for the
www subdomain is created and pointed to the correct IP address or hostname (in the case of a
CNAME record). Using popular DNS debug tools such as nslookup or dig can help a ton in
isolating these kinds of issues.
For example, in order to check if a particular A record exists for www.stackpath.com, you can use
the dig tool:
dig +short A www.mywebsite.com
If the above record didn’t exist, a dig tool would simply return an empty response. A similar query
can be made for a CNAME record type:
dig +short CNAME www.mywebsite.com
Email not routed properly after DNS changes
After creating a new DNS zone for a new domain or if you've switched to a different DNS
provider (hopefully StackPath) for your existing website and now you are unable to send or receive email. It’s likely your MX records are missing or not propagated. Depending on the email provider you use for your domain, you will need to have at least one MX record for your domain
pointed to the correct mail server. This is where nslookup and dig utilities come in handy. You
can use them to make a quick check whether proper MX records exist and where they point to.
For example, you can use the dig tool to check for any MX records for a given domain:
dig +short MX mywebsite.com
In the above case, the domain mywebsite.com uses Google’s mail servers to manage email.
It is possible you have set up DNS correctly in the StackPath Portal but you still need to update your domain registrar and point your domain name to StackPath. In general, it usually takes more time for the DNS changes to propagate. Depending on your domain registrar, you might need to double check your domain name is pointed to proper nameservers before the changes you made can start working.
To check the nameservers for a given domain, the dig tool can be used:
dig +short NS mywebsite.com
In the above example, the mywebsite.com domain uses SoftLayer’s nameservers to handle DNS for the domain name.