Having your domain’s DNS properly functioning is essential for your domain to function, whether for your website, your email, or other services related to your domain name. None of it is possible if you don’t have control over your DNS.
But how do you check your domain’s DNS? What should you even check? Let’s find out.
What is DNS?
First, let’s get on the same page about what we’re talking about when we talk about checking DNS. The Domain Name System, usually abbreviated to DNS, is system that’s used to connect machine-readable network addresses (specifically, IP addresses, which consist only of a series of numbers) to easily remembered and communicated domain names. DNS is both hierarchical and decentralized. Both of these have an impact on what we mean when we talk about checking DNS and why we would want to check it.
How is DNS hierarchical?
DNS is hierarchical in that every domain name is defined in the “zone” of it’s “parent” domain, going all the way up to the root zone, which defines all the existing Top-Level domains, or TLDs, which we know as domain endings (sometimes called domain extensions) such as .com, .org, .net, etc. The zone of each top-level domain, then, defines all the domain names that end in that particular domain ending, and the zone of each domain name defines all the subdomains of that particular domain name.
How is DNS decentralized?
DNS is decentralized in that there is no master list of all domain names that currently exist, or at least if such a list does exist, it isn’t used by the DNS system. Instead, the owner of each domain is responsible for maintaining its own “zone file” that indicates all the domains defined in that zone. This is then made public on one more “name servers,” usually at least one authoritative name server and at least one backup name server.
So when you buy a domain name, you really are buying control over the at domain name’s zone, and the right to add any entry to it.
There are also a series of DNS resolvers, which are servers that are dedicated to the process of “resolving” a domain name, in other words, of translating a domain name into a network address, so that a computer given a domain name can make a connection to a specific machine identified by its IP address.
This system of resolvers is also distributed in the networks around the world that are connected into the internet.
When the Domain Name System is queried — for example when you navigate to a website in your browser — your network’s domain name resolver is actually where that query is first sent. Often times, this is your ISP’s DNS resolver, but it is possible to use third-party DNS resolvers, like Google’s public DNS, or if you’re connected to a VPN, it would probably be that network’s DNS resolver.
For high traffic websites, that resolver might already have the answer in its cache, in which case it will just send that answer to you from its cache without asking the rest of the internet. If not, it will ask the next resolver up the chain hierarchically from it.
This system makes DNS resolvers highly flexible and quick, since they don’t have to ask an authoritative name server every time you query a domain name, but it also might cause some small hiccups for you. But more on that later.
For now, suffice it to say that DNS is both hierarchical and decentralized, and that that hierarchy and decentralization mean that for every domain name at every level (whether the root, the top-level, or the domain name), the owner of that domain name needs to publish a list of correspondences between human-readable names and machine-readable addresses on a server called an authoritative name server, as well as on one or more secondary nameservers (basically backups). They also mean that to find a domain name, your computer has to ask a distributed network of special DNS servers called resolvers whose job it is to either provide a cached answer to a DNS query or go ask another DNS server.
Why would I need to check my domain’s DNS?
With us so far? Good. It’s a little tricky to wrap your brain around but it’s worth it in the end because now you’ll understand a couple of reasons you might need to check your domain’s DNS.
What’s my DNS?
The first reason you might want to check your DNS is to figure out where exactly you need to make changes to your domain’s zone file, or in other words, where you need to make changes to your domain’s configuration so that it points to a new server or a different server than it did before.
Say, for example, you build a new website on a new hosting service. You’ll need to update your DNS zone to point it to the new website hosting server. Or if you’re changing your email provider, you’ll also need to update your domain zone to point your domain to the new email servers.
Because, as we explained above, the nameserver is where the answer to DNS queries about a domain name are stored, knowing which nameserver is assigned to your domain name will tell you where you need to make this update.
Where’s my DNS update?
You might want to check the other side of your DNS, though. That is, you might check whether changes you made to your DNS zone file are available for everyone.
The problem is, for various reasons, you might not be able to see that update reflected immediately. As part of troubleshooting a potential problem, then, you might want to check your DNS, and particularly check whether the DNS update you made is available from different DNS resolvers.
Does my DNS have a propagation delay?
Related to this, you may have heard of a concept called “propagation delay,” or you may have heard of the idea that you have to wait up to 2 days for changes you make to your DNS to be reflected on the internet.
The good news is that “propagation delay” is a myth. The not-so-good news is that it’s been used to explain a problem that is indeed real, but, thankfully, is avoidable.
What is DNS propagation?
“Propagation,” is a term that tries to explain the mechanics of DNS. Like when you propagate plants or when you propagate information or ideas, a DNS update is said to “propagate” from the point of change outwards to the rest of the internet. According to the myth of DNS propagation, it takes a certain amount of time for new DNS records to reach every corner of the internet, so you might not see changes reflected immediately.
What really happens is that, as we described above, a given DNS resolver either has queried a particular domain name or it has not. And if it has queried a given domain name, it has either has the DNS answer stored in its cache or it does not.
So IF a particular DNS resolver has queried a domain name before AND it stored the answer in its cache, THEN even after you make an update to the DNS zone file, it MIGHT provide the old answer still. But it’s important to know that all DNS caches sooner or later expire, so ONLY IF the cache has not yet expired will the DNS resolver provide the old record.
If you’re updating the DNS records for a website, then, this delay is more likely to impact you if you’ve recently visited your old website on your web browser before you make a DNS update.
Because your local DNS resolver already has the old record in its cache, and that cache is not yet expired, you’ll still see the old website. But if someone who uses a DNS resolver that has never queried your domain’s zone visits your website, they’ll get the new website right away.
How long a record stays in cache is determined by the policies of the individual DNS resolvers, HOWEVER, you have a way of indicating how long resolvers should keep your DNS record in its cache right in the record itself. It’s called the Time-To-Live, or TTL. This is usually measured in seconds, and at one point or another the standard TTL used to be 10800 seconds, or 3 hours for regular resource records and up to 172800 seconds, or 48 hours, for NS records (the records used to indicate your domain name’s nameservers). Because these TTLs were relatively standard, it became “common sense” to wait between 3 and 48 hours for DNS updates to “propagate,” hence the origin of the “DNS propagation” myth.
N.B.: The TTL of a given DNS record cannot be shortened at the same time as you make a DNS update in order to avoid this delay. The old record will be retained in cache for as long as the original TTL indicates. So if you want to make an update quickly, you’ll need to update the TTL on the old record first.
How do I check my DNS?
There are various ways you can check your DNS, based on what about your DNS you want to check, and what tools are available to you or that you are comfortable with.
How do I check my DNS at my registrar?
Checking your nameservers
You should be able to check your nameservers with your registrar relatively easily. In fact, updating and managing nameservers is a basic function you can perform at any domain name registrar, so it’s generally very easy to find in your domain registrar’s interface.
In Gandi’s interface, you can check this from the Domain section of your dashboard, under the Nameservers tab.
How to update your nameservers at Gandi
Checking your DNS records
As for recent updates to your DNS zone, you can check that at the same place you would have made the changes. If you are using a third-party DNS provider, you wouldn’t be able to check them at your registrar, but would have to check in your DNS provider’s interface.
If your DNS nameservers are at your registrar, though, you can check your records from your registrar’s DNS interface.
How to check your DNS records at Gandi
If you’re not seeing these records reflected when you try to navigate to your website, be sure to pay attention to what the TTL is set for. This can give you a clue as to whether the problem is related to an old record still being stored in a cache.
How do I check my DNS on the web?
DNS lookup tools
When looking for options on the web for checking your website’s DNS, it’s important to distinguish between the two sides of the DNS coin — that is, the nameservers which hold the information about a domain’s DNS zone, and the “resolution” side, that queries and stores DNS records for use.
If you just do a search engine search for “What’s my DNS?” you might come up with the wrong one, depending on what you’re looking for. If you’re looking for what your domain name’s DNS is, don’t try to look that up with a tool that tells you the DNS your computer is using to access the internet.
Look for website tools like DNSchecker.org, that allow you to search for the nameservers or any type of record if you provide the domain name you want to look up.
You might have better luck looking for these services by looking for “DNS lookup” tools.
While it uses the term “propagation” to describe its tool, whatsmydns.net provides a useful tool for checking your DNS records against multiple DNS servers from various Internet service providers around the world.
You just need to enter your domain name, and indicate the record type you want to check. You’ll see a world map that shows which nameservers located around the world have your most up-to-date records as well as
WHOIS
Another way to look up specifically the nameservers used for a domain name is by using an online Whois lookup tool, like Gandi’s whois look up tool or ICANN’s lookup tool. ICANN, or the Internet Corporation for Assigned Names and Numbers, is the organization in charge of coordinating the entire Domain Name System, so they can be a trusted third-party source when in doubt.
How do I check my DNS from a terminal?
A final option for checking your DNS is in a Terminal window, or a command line.
There are three main DNS lookup commands you can use:
dighostnslookup
The most detailed and versatile of these is dig. With dig if you don’t just want to know where the domain itself points to (i.e. the IP address of the website), you should specify which record you want. For example, if you want to see the records used by the domain name example.com for email, you would type:
dig mx example.comSince MX records are the ones used for linking a domain name to an email service. That means, if you want to check a domain name’s nameservers you would need to add ‘ns’ to your query, like this:
dig ns example.comDig answers are long and sometimes intimidating to read, though, so if you want just a list of the nameservers, you can do this:
dig +short ns example.comSo with dig you can actually check whether a particular DNS record is available from the DNS resolver you’re using OR you can check what nameservers your domain uses.
You can use host to do what dig does by itself and by adding ‘mx,’ and get results like these:
$ host example.com example.com has address 93.184.216.34 example.com has IPv6 address 2606:2800:220:1:248:1893:25c8:1946 example.com mail is handled by 0 .
Which are a bit more readable than evendig +short results. You can’t however use host to look up the nameservers (or NS records). For that, you can use nslookup, though.
However, nslookup will only give you IP addresses, not the names of the namservers. That makes dig ns your best option, or dig +short ns if you want the most concise answer.
Checking your DNS
Knowing how to check your domain’s DNS is essential for being able to manage your domain name and the services that you associate to it. We’ve taken an in-depth look at how to check your domain’s DNS, but there is one other way in which to check your DNS which we haven’t covered: checking the DNS that your computer is using to reach the internet.
For this, we recommend checking your computer’s DNS settings (depending on your operating system, these are in the network settings for your computer). Otherwise, you can also use online tools or your command line to check.
DNS is a system at the center of the functioning of the internet, and so knowing how to know exactly where you or your domain is in that system is tremendously valuable.
Tagged in DNSNom de domaine
