You just linked your domain name to your website, or a new email service, or something else that requires an update to your DNS zone file, but … it’s not working!?
Before you throw your computer out the window in frustration, take a deep breath and check this list of common reasons your DNS might not be working. Here are five reasons.
1. Caching
One of the most common, and most misunderstood, reasons you can make a DNS change and not see it reflected right away is caching.
Without going into too much detail about the nitty gritty of how the domain name system as a whole works, suffice it to say that it’s a distributed and hierarchical system, built to be tough and robust, where your computer asks a server called a resolver (often this resolver is operated by your ISP) for the response to a DNS query and, if the resolver already has the answer in its cache, it gives your computer that answer instead of going back all the way to the source for the answer — provided that the cache hasn’t yet “expired.”
What that means is that if you visited your domain name on your computer, updated the DNS records to point your domain to a new website with a different IP address, and then visited your domain name again on the same computer, you’re likely to see the old website due to this cache.
Once the cache expires, though, you’ll get the new website. Due to this expiring cache, there’s a perceived “delay” in how long it takes for the new DNS records to be visible.
There’s a widespread misconception that these delays are due to something people call “DNS propagation.” This is inaccurate and misleading at best, since it suggests that DNS updates are actively “pushed” to servers around the world.
The opposite is actually the case — DNS records wind up in resolvers’ caches from having been previously requested.
What you can do about DNS caching
1. Wait
If you have time, you can just wait for the cache to expire. It helps if you know one key piece of data about the old DNS record you replaced: it’s TTL. TTL means “time to live” and it indicates to DNS resolvers how long to keep the record in its cache. In a DNS record, a TTL is measured in seconds. BUT there’s a catch — resolvers won’t always honor the TTL. That means, even with a short TTL, it could take anywhere between 3 and 24 hours for you to see your update. If you don’t have time to wait, then you can …
2. Try from a different network
Since the DNS resolver you use is tied to your internet service provider, if you try your domain name from your smartphone with the WiFi turned off, you should be able to get the new DNS record (provided you haven’t recently navigated to your domain name on your smartphone)
3. Query the server directly from a terminal
If you know how to `dig` in a Terminal window, you can add `@` and the name of one of your nameservers to query the nameserver directly, for example:
$dig example.com @ns1.example.com
If you can rule out caching, though, the issue might be something else, like …
2. Multiple A type records
An A record is used to point to an IP address associated with your website. This is opposed to a CNAME record, which maps your domain name to another domain name. A quirk of this difference is that you can only have one CNAME record for particular subdomain (actually if you have a CNAME on a subdomain, you can’t have any other type of record for that subdomain either), but you can have multiple A records.
It’s possible, then, that if your DNS update involved updating an A record, you really just added a new A record and left the old one where it was.
What makes this error even harder to figure out is that sometimes your computer will get one response for an A record query, sometimes another. If the different IP addresses serve different websites, the result is that sometimes you’ll get one website, sometimes you’ll get another.
And there’s yet another twist: the system of IP addresses is in the process of transitioning from version 4 (v4) to version 6 (v6). The problem is that v4 IP addresses (aka IPv4) are too small and there are not enough of them. IPv6 addresses are much longer. The problem for DNS is that you can’t have a regular A record with an IPv6 address.
For that, you need a AAAA record.
And that’s what can make this problem hard to spot. If you update just the A record and not the AAAA record, your update will apparently not work either.
3. You updated the wrong DNS servers
Whether due to miscommunications on your infrastructure team, force of habit, or just plain forgetfulness, you might have made your DNS updates on the wrong DNS service.
It could be that you recently transferred your domain name and you either didn’t update your nameservers to your new registrar’s, or you did update them but didn’t mean to.
Or you could be using a DNS service like CloudFlare and make the update at your registrar or a different DNS provider you’ve used before, or vice versa.
This can result in your changes apparently disappearing into the internet ether.
Check what nameservers your domain name uses in your registrar’s domain dashboard to make sure you’re making the updates in the right place.
4. You forgot a dot
One subtly of DNS records is their particular syntax. A lot of the problems arising from this can be safely automated away, but one that can’t be is the necessity to put a dot at the end of a domain name that a CNAME record points to.
That’s because a CNAME record can be used to map your domain name either to an internal domain name (that is, one that’s also on your domain name) or an external domain name (or a completely different domain name).
To account for this, a domain name in the Value field of a CNAME record has to end in a dot if it’s external. Without a dot, the DNS system understands that the rest of your domain name is added to the end.
For example:
www 300 IN CNAME foo.example.net.
would point the domain example.com to foo.example.net.
But if you had this instead:
www 300 IN CNAME foo.example.net
The domain example.com would point to foo.example.net.example.com.
5. Domain expired or suspended
Finally, the last reason your DNS might not be working is if your domain name has expired. This would cause your domain name not to resolve at all (in other words, instead of an old website, you’d see an error message).
Another reason is if your domain has been suspended, for example, for a legal issue.
For an expired domain name, you would see that in your dashboard. As for a suspended domain name, the only way to tell whether that’s causing your DNS problem would be using the Whois. Check the “Domain Status” and if it says “clientHold” or “serverHold,” get in touch with your registrar to resolve the issue.
Conclusion
If you make a DNS update and it’s not working, don’t flip out before you check these five common DNS problems. And of course, if your domain name is at Dotifi, our Customer care team is available around the clock to help you figure out the problem. thanks !
more…
1. What is DNS propagation?
When you update the nameservers for a domain, it may take up to 24-48 hours for the change to take effect. This period is called DNS propagation.
In other words, it is a period of time ISP (Internet service provider) nodes across the world take to update their caches with the new DNS information of your domain.
Due to DNS caches of different levels, after the nameservers change, some of your visitors might still be directed to your old server for some time, whereas others can see the website from the new server shortly after the change.
2. Why does it take up to 72 hours?
Let’s imagine you live in Bari, Italy, and you just have changed the nameservers for your domain that is hosted in Phoenix, USA.
When you open your domain in a web browser, your request is not going to the hosting server directly, it has to pass through several ISP nodes first. So your computer starts by checking the local DNS cache, then the request is sent to your local Bari ISP. From there, the request goes to the upstream provider in Rome, Italy, then connects to the ISP in Hamburg, Germany. After that, the request is sent to the first receiving point in the USA – New York, NY and ultimately, to the ISP in Phoenix, AZ. Here is an example of the request trace – the number of ISP nodes and their location will vary in each particular case:
