If you've ever worked with a software development firm to rebuild your website or app, you were likely asked a series of questions about your current domain registrar, hosting provider, email provider, and DNS host (among other things). Some of those things might seem pretty straightforward. Your website host... hosts your website, email hosts email, and so on. However, you may have wondered "What the heck even is DNS?"
Well I've put together a a very top-level guide in order to help you understand some of the basics of the domain name system, which is what the initialism actually stands for. It goes way deeper than I'm going to go in this guide, and some things may be a bit oversimplified, so any of you devs that might be reading this, keep your cool. This guide is most certainly not exhaustive and those oversimplifications I mentioned are meant to make the basic idea easier to understand.
WHAT IS A DOMAIN?
I'll start off the explanation of the domain name system by explaining briefly what a domain actually is, as it's essential to understanding the rest of this guide. In a very simple sense, a domain is what you type into your web browser's address bar to get to a website's homepage. In reality, it's much more than that, but that's most people's experience with it. I'll use "google.com" as an example for this. In a technical sense, it really starts with what is called a Top Level Domain (TLD). A TLD is the ".com" or ".org" part of a domain. There are actually a lot more of these, but I won't get into that now. The Second Level Domain (SLD) is the part that appears to the left of the TLD. It would be "google" in the case of "google.com". Both of these together make up what we know as a typical domain (or domain name).
To further illustrate this concept, have a look at this graphic, which breaks down the parts of a URL (Uniform Resource Locator). You know, that thing you see in your web browser's address bar.
DOMAIN NAME SYSTEM OVERVIEW
I'd like to use an analogy to describe this. I think it's pretty safe to assume you have a cell phone. Within that cell phone you have a list of contacts. When you want to dial up one of your friends, what do you do? You go into your contacts list, find their listing, and then press the "call" button. You were able to use a piece of information that was easy to remember (their name) to connect to your friend's phone number, which is typically much more difficult to remember. We all know that what really happened is that your phone automatically inserted their phone number and dialed that, so you could enjoy the convenience of not having to remember their actual phone number. The domain name system essentially functions the same way. Whereas your phone may keep a list of "person name" to "phone number" associations, the DNS keeps a similar list of associations. In this case, these associations are between domains and IP addresses or (Internet Protocol Addresses).
A domain is essentially just the text-based identifier for a website while an IP address is where the website actually lives in the vast network of computers we call the Internet. I'll use Google as an example. Type google.com into your address bar of your browser and you will actually get to Google's homepage. This is because your browser "looked up" google.com (like looking up your friend in your contacts list by name) and found that the number is actually 172.217.12.206, so it "dialed" that number. A moment later, you're connected to Google's homepage. If you actually type the number 172.217.12.206 into your address bar instead of google.com, you'll still get connected to Google's homepage (go ahead, open a new tab and try it). Without the Domain Name System, you would have no other way of connecting to Google's homepage than by actually typing 172.217.12.206 into your address bar. Not very user friendly, right? Please see the rudimentary graphic I've added to help explain this process. Follow along with steps 1-3.
For the sake of clarity, I've only included one domain name server. However, if the first DNS server your web browser "asks" doesn't know how to get to http://www.google.com, it calls in a lifeline (think "Phone a Friend" on Who Wants to be a Millionare) by asking another server the same question. Once it finds the right info it continues with step #2 so your web browser can proceed to step #3!
TYPES OF DNS RECORDS
I mentioned above that DNS records (known as Resource Records) are associations between domains and IP addresses. However, as you might have guessed, there's more to it than that. The domain/IP associations are just one type of record. These are known as A records. There are many records, of which I will only explain some of the most common ones.
A (ADDRESS)
This is the "where is my website hosted" record. Each domain typically only has one of these. Like I mentioned above, this is the domain and IP address association (google.com to 172.217.12.206) which is responsible for telling web browsers which computer the website is hosted on via it's IP address. This is why it is called the Address record, or A record, for short. If you migrate hosting to another provider you will have to update the A record.
MX (Mail Exchange)
This is the "where is my email hosted" record. A Mail Exchange record (or MX record) is responsible for making the association between the domain and an email server. An email server is just another type of computer, just like how your website is hosted on a computer. Domains typically have more than one MX record, but this is just for redundancy in case anything goes wrong. I'll use our own domain as an example. We use Google as our email host, so our MX records for the domain "vtdesignworks.com" point at Google's email servers. Other email providers use this information so they know where to route email. If you're sending email from, say, an outlook.com email address. Outlook.com would need to perform some DNS lookups. So if you had tried to send email to one of our staff, you would have to type something like "user@vtdesignworks.com" into the "To:" field. When you click "send", outlook.com looks up the MX record for vtdesignworks.com and uses that information to find out where on the Internet (which computer) to send your message. In this case, it would be one of Google's computers, which will take it from there and route it to the correct users inbox, which it knows because of the part of the email address that appears before the "@" sign.
CNAME RECORDS (Canonical Name)
Canonical Name Records (CNAME records) are records that function as aliases. It specifies that a domain name is an alias for another domain. Most websites at least have the "www" CNAME record, which is almost always aliased to the same domain. Using our website again as an example, "www.vtdesignworks.com" is an alias for "vtdesignworks.com". If you remember from my explanation of A records above, the bare domain is associated with an IP address, so the "www" version of the domain also points at that same IP address. So "www.vtdesignworks.com" points at "vtdesignworks.com" which points at an IP address. It's like a chain!
Another way that CNAME records can be used is if you have a blog that is not hosted on the same server (computer) as your website. This means that the blog is on another computer with a different IP address. You would create a CNAME record with an alias of "blog" that points to the other computer where the blog is hosted. This means that, while "domain.com" or "www.domain.com" would point at your website, "blog.domain.com" would point to the computer where your blog is hosted. So you've technically got a website on one machine and a blog on another, but both can be accessed by some variation of your domain.
OTHER RECORDS
There are a good number of other records such as TXT records (text), or SOA records (Start of Authority), etc. You may have heard, in the context of email, about SPF (Sender Policy Framework) records, or DKIM (DomainKeys Identified Mail) records. These are actually just TXT records with specific content and are used by email servers for verification to help prevent spam. They're outside of the scope of this guide, much like many of the other records that exist within the Domain Name System.
BUT WHERE ARE ALL THESE "RECORDS" MANAGED?
You might be asking yourself where all this stuff even happens. Where do these associations live? Surely they must be written down somewhere...
The actual question is "Where is DNS hosted, or managed?"
I'll start by saying that this can vary. If you've purchased (or registered) your domain through a domain registrar like GoDaddy or Network Solutions, then these associations are managed with those same registrars, by default. This can be changed though. In the same way that your website hosting can potentially be with GoDaddy, Network Solutions, or other providers, DNS management can also reside with these domain registrars or via other providers. We manage this for a good portion of our clients' websites at CloudFlare, while we manage the domains themselves at GoDaddy.
NS (NAMESERVERS)
The thing responsible for determining where your DNS is hosted and managed is known as a Nameserver. These are typically set up in pairs (for redundancy, like with MX records). These will always be managed at your domain registrar (GoDaddy, Network Solutions, wherever you currently manage your domain). If you want to set up your DNS management somewhere other than the registrar your domain was purchased at, you'll have to change the nameservers. If anything needs to look up some DNS records (like a web browser looking up the IP address of the domain so it can navigate to the homepage, or an email provider trying to find out where to route email messages), it will check the nameservers first, then go wherever those point to look up the individual resource records (A, MX, CNAME, etc).
WHAT DOES IT ALL MEAN?
If you take nothing else away from this guide than "this is really complicated", then I've still done my job. There's no reason why most people would even know about the existence of the Domain Name System, let alone its intricacies, but they use it every day nonetheless. Any time you type a domain into your address bar or send an email to literally anyone, that system is doing its job behind the scenes. Pay no attention to the man behind the curtain! At least just know he is there, and he is pulling some strings to make things happen and make your life easeir. A domain doesn't have to have email, nor does it have to have a website, but if it doesn't have any DNS records, it won't do anything for you. DNS is that connection to all of the other services. So hopefully I've been able to express the importance of it and maybe, just maybe, I've helped you understand a little bit about what it does... and maybe even how some of it works.
If you have any questions about how this is all set up for your domain, feel free to give us a call (802-383-7679) or contact us!