Domain names and DNS are big parts of what make the internet workable and usable by us humans. Domain names are the addresses we use to reach websites and send emails. Common examples of domains would be Google.com and WordPress.com. Those are root domain names, and if you go to them in a web browser you’ll see the corresponding website. However computers really work on IP Addresses, or Internet Protocol Addresses, not domain names. Each device connected to the internet has one of these addresses, and it is these that are really used to direct you to where you are looking to go. When you go to WordPress.com it is the DNS, or Domain Name System, which translates the name WordPress.com to the right IP address so your computer knows where to go.
My go-to analogy, back when these were more common, was that DNS was similar to looking up someone’s name in the phone book so you could call them. Now it would be more like the contact list in your phone. We don’t remember phone numbers anymore – just like we don’t know the IP address of a computer on the internet. We use the name to find and reach them. In this analogy the person’s name is the domain name and their phone number would be the IP address.
Now that we have a general idea of what is happening let’s take a closer look at how the pieces fit together.
The first step in working with a domain name is choosing the address you want. There are many different extensions for domains these days so there are lots of options to choose from. Most are familiar with .com, but there are so many others like .blog, .me, .ca, and so many more. Each of these extensions are controlled by a central Registry. So .com has one main Registry where every time a domain is registered using that extension this is where it happens. You can register a .com domain name from numerous different sources, like WordPress.com, Hover.com, or GoDaddy.com. These companies are called Registrars and when you use them to register a domain they are communicating with the Registry to make that happen.
So far I’ve mentioned two of the main three R’s associated with domain names –Registry and Registrar. The next R is the Registrant. This is considered the owner of the domain name for the time it is registered. When you register a domain you must provide your contact information, and this is stored as part of the registration. There are different sets of contact information which can be set but the Registrant (owner) and the Administrative contacts are the most important and in many cases the same. This contact information is added to a database called Whois which allows you to lookup information about the domain name. By doing a whois lookup you can find the Registrar, Registrant and much more information about the domain. Some companies offer a privacy service, which makes your contact information hidden and instead puts in proxy contact details. You can do a whois for many domains through https://whois.icann.org or https://whois.net/
Some other information which appears in whois look ups about a domain name are the expiry date, creation date, date the settings were last updated, and the current status of the domain. One of the more important pieces of information we will use are the Name Servers set for the domain.
When you register a domain name typically, as part of the registration process, the domain has Name Servers specified for it. These can be manually specified by you, or many times, if you are registering through a hosting company, they will automatically set them for you. The Name Servers store all the DNS records for your domain name. These records specify where your domain name will point on the internet. The Name Servers, specified with the company you register your domain through, are considered the authoritative spot for where this information is stored. This will become important as we look more in depth later on.
If you at some point change the company who hosts your website the typical way to point your domain name to the new location will be to use the new hosting provider’s Name Servers for your domain. To do that you would log in to your account with the company you purchased the domain name through and update the Name Servers to the new provider. This then allows the new provider to specify where your domain will point by controlling the DNS records and point to their servers.
DNS, or Domain Name System, are the records, stored in the Name Servers, which direct where to point requests which are made for your domain name. There are many different types of DNS records which can and are specified, but we’re just going to concentrate on a few of the main ones used.
The A in A Record stands for Address. These records are what point domains to a specific IP address. For example my domain,
mcfadden.blog, has an A Record which directs it to the severs here at WordPress.com. It looks like this:
mcfadden.blog A 184.108.40.206
This means that any requests for
mcfadden.blog will go to that IP Addresses.
You could also create sub domains by adding A Records and pointing them elsewhere. One common time this happens is when you have your website hosted on one server but your email hosted on another. The server your email is hosted on would have a different IP address so you could create a sub domain which can be used to direct email to that server. A common convention is to use a sub domain in the format of
mail.yourdomain.com, so in my example it would be
mail.mcfadden.blog. The A Record for this could look like this:
mail.mcfadden.blog A 192.168.0.230
This would cause any requests for
mail.mcfadden.blog be sent to that IP address.
MX Records or Mail Exchange Records are what email services use to know where email sent to a domain name should be processed. In our example above we created the sub domain
mail.mcfadden.blog and pointed it to the server that will handle the email, but how do other email services know to use
mail.mcfadden.blog? We tell them by setting the MX Records. While an A Record above has just two parts — the host name and the IP address — an MX Record has three parts. The host name, the address that will handle the mail, and the priority. For our example above it would look like this:
mcfadden.blog MX mail.mcfadden.blog 10
This tells us that all emails for the domain
mcfadden.blog will be handled by the server at
mail.mcfadden.blog. The priority number at the end, in this case 10, allows us to set multiple MX records for a domain as a fail safe. In case one server is down, or unavailable, you would then use the next in line of priority and that way you won’t miss any email. The lower the number the higher priority. So if there was also an MX Record which said
mcfadden.blog is handled by
backupmail.mcfadden.blog with priority 15 then any requests to send email would first be sent to
mail.mcfadden.blog because it has the lower priority number, but if it couldn’t be reached, the request would then be sent to
CNAME Record, or Canonical Name Record, allows you to create an alias from one name to another. There are a few common examples for this. The main one would be to create a CNAME Record for the www version of a domain name and point it to the same place as the root domain name. In the examples I’ve been using that would be to create a CNAME for
www.mcfadden.blog so that it aliases
mcfadden.blog. The Record would look like this:
www CNAME mcfadden.blog
This tells any request for
www.mcfadden.blog to go to the same place as
mcfadden.blog. This is useful so that you don’t have to maintain A Records for both of those addresses. In case you change where
mcfadden.blog points you don’t then need to also update A Records for
www.mcfadden.blog, it will just continue going to the same place
Another common practice is to create a wild card CNAME record and point it to the root domain as well. That way any sub domain tried will go to the same point as root domain. This record would look like this.
* CNAME mcfadden.blog
Meaning I can put
whatever.mcfadden.blog and it will go to the same place as
mcfadden.blog. This is over-ridden though if there are specific DNS records created for certain sub domains. For our example if we had both the
mail.mcfadden.blog A Record and the wild card CNAME record,
mail.mcfadden.blog would still use the A Record we set.
How It Works
Now that we have an idea of how domain names are registered, that their DNS Records are stored in the Name Servers specified, and what those DNS Records do, lets see how they all fit together. This will also bring to light some common issues we see so we can then look at how to troubleshoot or investigate them. A lot of this section I’ve adapted from the article DNS: Why it’s Important & How it Works. Highly recommend it.
These are the rough steps which happen when you try to visit a website in your browser:
Open up your browser and type in the address https://mcfadden.blog. Your browser will try to save time by looking in your device’s cache or memory. Have I been to this site recently? If so, I’ve already looked up the IP Address it should point to, so let’s just go there. If it hasn’t been there before it will move on to the next step.
Each internet provider has their own DNS servers which they use to do these look ups, so if your local device doesn’t know where the domain name points, it asks these servers. If these servers have looked up the domain recently they already know the IP Address and just send it back to your device. If they don’t know, then it continues on to the next step.
Your internet provider’s DNS servers will then ask the Root Name Servers where to look. I won’t go into a bunch of details about the root name servers, but they are an integral part of the DNS infrastructure as they contain information about all the domain extensions. We talked about the Registries up above. The root name servers contain information about each of these registries. So if they get a request for a .blog domain they know where to find the information about .blog domain names. The registry name servers know what the authoritative name servers are for the specific domain. These are the name servers which we specified when we registered the domain. They contain the DNS records which should be used for the domain.
Your internet providers servers then ask the authoritative name servers to find the right DNS Records and return that to your local device. Your device can then connect to the right server on the internet and get the information you were looking for. In this case the browser shows you the website for the domain.
As you can see from above there are a lot of parts that all work together to make what usually looks like a simple super fast thing like loading a website happen. This works pretty well, but there are issues and things which can come up and cause the process to break. In this section we’ll look at a few common scenarios and some tools and processes to figure out and fix what is happening.
The majority of the issues you run into come in two main categories. The domain expired and stopped working, or the you are moving hosting providers and can’t get everything to work.
For expired domains the solution is usually pretty easy. Look up the domain in a whois lookup. You can see the expiry date and the status of the domain name. These will tell you if the domain is expired and needs to be renewed. You can see where the domain is registered as well, so go there and go through the process to renew the domain. There are added complications here due to the expiration process and stages of a domain name, but this is the general idea. In most cases it is a matter of dealing with the company you registered the domain through.
This is where things can get challenging to figure out what is happening. There are typically three tools I use to help figure out what is going on.
- What’s My DNS
Whois: We’ve talked about this before. You can look up information about the domain name registration itself. The big thing here is to see what Name Servers are set for the domain. Are these set to the new hosting provider’s servers?
Dig: This is a command line tool that allows you to query name servers for a specific domain and get the DNS records which are set for it. There is also a great web based tool at http://digwebinterface.com.
What’s My DNS: Directly from their site. https://www.whatsmydns.net/ lets you instantly perform a DNS lookup to check a domain name’s current IP address and DNS record information against multiple name servers located in different parts of the world. This allows you to check the current state of DNS propagation after having made changes to your domains records.
What does propagation mean? When we looked at the how DNS works section above we saw that at a number of steps the local device, or different DNS servers would cache or save in their memory where a domain name should point. That means when you change where your domain name points, it will take time before all these devices and servers will know about the changes.
To explain the caching using the phone number analogy from the beginning, if you have a favorite pizza shop you order from regularly chances are you’ll remember the number. It is saved in your memory. You no longer have to look it up elsewhere you can just call. One day the pizza place moves and as a result their number changes. They announce and make the change, but you don’t check because you know the number already. You’ll be calling an old number and if it hasn’t been disconnected yet, you might still reach the old shop. So if the old website is still in the old location you might still see it while others who have never been to the site before will do a fresh lookup and see the new site.
Luckily caches are set to expire so they don’t hold onto the information forever. After a specified time, even if they have seen the domain name before, they’ll go check to see if there is a new location instead. This happens at all levels — your local device, your internet provider’s servers etc. so the propagation is the time it takes for all these devices to know about the new location. Generally this can take anywhere from 24-72 hours from when changes to name servers are made. Many times we see issues because it is just a matter of waiting for this propagation to finish.
Email stopped working
A common scenario is to have your website hosted with one company but email hosted through another. This is perfectly fine, but you’ll have to make sure the DNS records are set up properly. For an example, you have your domain name registered with Bluehost.com, a large common hosting provider, and they have been hosting your website and your email. You decide to move to WordPress.com to host your website, but you still want Bluehost to manage your email for you. To make this work you update the Name Servers for your domain name to point to WordPress.com. Your new website starts working pretty quickly, but all of a sudden you aren’t getting emails.
This could be because the new Name Servers for your domain don’t have the proper MX Records in place to point your email to Bluehost. You would then have to go into your settings at WordPress.com and add the proper records to get it working properly again. Bluehost would be able to give you the settings you need, and then you input them into your new Name Servers. In a simple form this would include two DNS Records, an MX Record and an A Record. Bluehost might say your email is being hosted on the server with IP address x.x.x.x. You could then create an A Record for mail.yourdomain.com to point to the IP address, and then an MX Record for yourdomain.com to be managed by mail.yourdomain.com. This is like the example above in the DNS records section.
This is a lot of information, and there are too many different scenarios which could come up to cover them all specifically. Having a good understanding of how domain names and DNS work and by using the tools above you can piece together and figure out what is happening in most of them.
If you have questions, thoughts, or additional resources you think would be useful here please feel free to comment here or contact me, and I’ll get back to you as soon as I can.
Featured image credit: Flickr user mookielove