Domains & DNS Definitely Demystified

There is a lot of confusion about domain names and DNS. What they are, how they work, who does what, and how all the pieces fit together. I run into countless questions when I’m working with my clients on websites and other digital marketing systems, so this video aims to provide an overview of all those pieces and help clear up some of that confusion.

It’s more of a “how” and “what” than a “how to”, although there are a few step-by-step examples at the end. I strongly believe that learning the concepts and foundations of any topic will help you figure out how to do anything you need more than specific instructions, which may or may not apply to your situation.

---

Transcript Below:

There is a lot of confusion about domain names and DNS. What they are, how they work, who does what, and how all the pieces fit together. This video aims to provide an overview of all those pieces and help clear up some of that confusion.

Hi, I’m Adam with Peak Performance Digital. We are a web consulting firm that provides websites and digital marketing solutions to run, grow, and market your business.

Disclaimer

Let me just begin by saying that this is by no means a definitive guide on DNS. It’s a simplification aimed at teaching you the foundational concepts that anyone who registers a domain name or manages their own DNS should understand. Lots of books have been written about the topic of domain names and DNS, and I particularly like O’Reilly’s DNS and Bind. You can pick it up on Amazon for about $50 and be enthralled by 642 pages of geekery.

What is DNS?

DNS is like a phone book for the Internet. Each service out there has its own unique IP address, something like 142.251.35.174. You don’t want to remember all those numbers just to get to a website, instead you type something in like google.com to there. DNS is the thing that takes the name google.com and translates it to the IP address so that you can go where you want to go.

DNS Components

There are a lot of components and pieces for DNS. First of all, you have a domain name itself. That’s something like mycompany.com. Then there is the registrar, which is where you buy and register the domain name. The IP address is what your computer uses to find things on the internet. And of course there is the DNS server that does the translation between the domain name and the IP addresses. Lastly, you have the services themselves. Things like web servers, email servers, VPN servers. Basically anything out there that you want to reach by name.

Domain Names

Let’s start with domain names. That’s something like mycompany.com. It’s the thing that you pay for and that is unique to your business. It’s your business asset and your company is responsible for it. You buy, or rather rent it, from a service called a domain registrar. There are a lot of different registrars out there on the Internet, and they all pretty much do the same thing. When you’re registering your domain name, you want to use one of the more well established registrar’s out there. The last thing you want is for your registrar to go out of business and for you to have a problem with your domain name because of that.

Domain Registrars

Keep in mind that there is a governing body that determines the price that the registrars pay for domain registration, although you’ll find varying prices for each one. Just be sure to go with one of the more reputable ones that are known for providing good service without overcharging.

Domain Name Prices

Usually a registrars will only charge you a couple dollars more than they pay to register your domain name. Typically, a domain name costs anywhere between 10 to $14.00 per domain each year, although most registrars offer discounts for your first year or for registering multiple years in advance.

Privacy Protection

One of the services you want to look for is something called Privacy Protection. It’s a great service to have and it keeps the contact information for the person who registered the domain private. Most registrars will give it to you for free, although some companies such as Bluehost and GoDaddy charge upwards of $15 per month for it.

Bundled Services

You’ll find that a lot of companies provide more than one service as part of the packages they offer. Some companies will register your domain, provide a web server, provide your DNS service, and host your email all under one package. The fact is, each of these services really are separate things, and in a lot of cases they should be run by separate companies.

One benefit of having all the services bundled together is for ease of administration and billing. Rather than managing four vendors, each with their own billing cycles, credentials, and administrative tools, you can do it all in one place. Another benefit is that the services are likely pre-configured to work with each other. Technical support is also streamlined since the single vendor has a complete end-to-end view of any issues they are troubleshooting.

This all sounds pretty good, right?

Well, it is pretty great… until it isn’t. Then, it creates major hassles at best and impassible roadblocks at worst.

Issues with Bundling

Take email, for example. It’s not uncommon for web hosting companies to bundle email services along with the website hosting. Sometimes they do if by combining both services on a single server and other times they do it by reselling services like Google Workspace or Office 365. Part of the reason they do this is because they know that email is a “sticky” service that is extraordinarily difficult and expensive to move from one vendor to another. By bundling them together, they have a much better chance of keeping your business long-term than if they just sold the web services separately. Interestingly, you’ll notice that nearly none of the top-tier website hosting companies offer email services. Instead, they rely on their quality of their core services to keep their customers loyal.

Bundling website hosting and DNS services seems like it would make sense, and of all the bundled combinations this is the least objectionable in my opinion. The main issue is that The architecture of DNS benefits from a large, fast infrastructure with lots of other DNS servers. Web hosting companies typically put the DNS services on their web servers, which aren’t optimized for fast lookups, and this can have catastrophic consequences for your website speed. Now, the reason why I said it’s the least objectionable is because DNS services are relatively easy to move in most circumstances. You just copy the records to the new DNS server, then tell your registrar to make the switch.

There are a lot of reasons why you would want to decouple your DNS management from your domain registrar. One reason would be to add advanced features like a web application firewall, content delivery network, or content optimization services.

Additionally, most registrars don’t allow you to delegate access to their control panel. This means that anyone who can login to change DNS records can also modify your domain registration. This is a major security risk. By splitting the services, you can allow your IT department or your vendors to manage DNS records without running the risk of something happening to your registration.

Cloudflare actually takes this one step farther, and lets you maintain the account for your DNS services while providing access to your vendors to manage them using their own company accounts.

Lastly, and most interestingly, some of the major email service providers such as Google and Microsoft bundle DNS services with their packages. The reason they do this is simply because it eases the support burden for them by pre-configuring everything with their settings. While not ideal, this configuration is fine if your IT vendor is also going to manage the DNS Server. If you prefer to have your digital marketing or website services provider manage DNS, then it’s a big problem.

DNS Record Types

When it comes to DNS records, there’s four main types that you need to be familiar with, although there are a lot more.

• First there is the A record, or Host Record, and that’s what translates domain names IP address.
• CNAMES, which are also known as canonical names or aliases, translates a one domain name to another name.
• An MX, or Mail Exchange record, says where to deliver email for a particular domain.
• And, a TXT or text record, delivers miscellaneous information to the internet.

How DNS Works When Browsing a Website

So how do all these pieces fit together and what do they do? Let’s take a simplified example of someone going to my website, peakperformancedigital.com in their web browser.

• First, you start by typing peakperformancedigital.com in the address bar and hitting the go button.
• Your computer then says “I don’t know anything about this domain name, let me check with the root servers.”. The 13 root servers don’t necessarily know where peakperformancedigital.com is, but they know which DNS servers do know.
• The root servers check their databases and say, “hey it looks like Hal and Nelly (yes, those are the names of my DNS servers) know about this domain. Why don’t you go ask them?”
• So then your computer reaches out to Hal and Nelly, which are the authoritative servers for peakperformancedigital.com, and ask “do you know anything about this domain?” They answer, “sure, it’s one of my favorites! What would you like to know?”
• Your computer then says, “I want to the website, peakperformancedigital.com, how do I get there.”
• Hal replies, “please wait… your call is important to us…” then digs into its database to find the answer. A few microseconds later Hal says “okay, I got it right here. The host record for peakperformancedigital.com is 172.67.198.72.”
• Your computer then thanks Hal, makes brunch plans with him for the weekend, then tells your browser the IP address they just received and pulls up the website.

Looking up Subdomains

This process works very much the same way for subdomains as well. For example, if someone typed in www.peakperformanceigital.com my DNS server would find a CNAME record for www that points to peakperformancedigital.com. From there, it looks up the IP address of that domain name and goes on its merry way.

DNS and Email

Email delivery also works similarly. When someone sends an email to [email protected], the same root servers are queried, and the sending mail server is told to get the records from my authoritative servers. The conversation from the sending email server goes a little something like this:

• “Hey Hal, I want to send an email to [email protected]. Where do I send it?”
• Hal responds, “here are the MX, or Mail Exchange records for the domain. First try ASPMX.L.GOOGLE.COM. If that one doesn’t respond, here are four more servers at Google that can accept mail for that domain.”
• Your mail server then reaches out to Google’s mail servers and says “I have an email for [email protected]. Can you deliver it?”
• Google’s server then responds, “Sorry… I’m a bit busy right now.”
• Now, your email server is pissed. It then says, “fine, I’ll just give it to ALT1.ASPMX.L.GOOGLE.COM instead.”
• ALT1 is excited that someone wants to send email through her and eagerly accept it.
• From there, Google’s email servers do their magic and deliver the message.

Now, of course in reality there is a lot more going on than what I just outlined. At its essence though, this is the process. It doesn’t matter whether one company provides all these services, or if different companies perform each function. The process and the configuration are still the same regardless.

Propagation & TTL

In some of the previous examples, I used the words Propagation and Time to Live, or TTL. As you can imagine, all these record lookups would put a huge burden on the internet if each client had to check for the records each time they accessed something. To ease this strain, DNS takes advantage of a lot of caching, both on your computer and between DNS servers themselves.

The TTL, or Time to Live, setting for each domain zone and record is one of the things that helps dictate how long a particular entry can stay in cache without being considered “stale” and being re-fetched.

Contrary to my simplified DNS conversation earlier, your computer most likely doesn’t talk directly to the DNS server responsible for a particular domain. Instead, your computer is configured to talk to it’s own local DNS servers, which in turn do that talking for you. Since your DNS server is looking up countless records all the time, it can cache those lookups and deliver them quite quickly. The downside, of course, is that your DNS server’s cache might be slightly out of date until the domain’s TTL expires and the records are re-fetched.

When we talk about DNS settings taking a while to propagate across the internet, this is what we are talking about. It’s that time that it takes for all the various DNS servers across the internet to realize that they have stale records and re-fetch them with current records.

In practice, this means that, depending on your TTL settings, any change you make to your records will take some time before they are seeing everywhere. Even though you might have up-to-date records, another DNS server might not. That’s why you’ll usually hear people say that changes to DNS may take 24-72 hours to fully take effect.

Roles & Responsibilities

One challenge that comes up with nearly every company I work with is “who does what?” The two pieces involved here are 1) who is responsible for registering the domain and paying the annual registration fees, and 2) who is responsible for managing the DNS servers.

The answer to the first question is easy. The business that uses the domain name should be the ones to register and maintain it. Not your IT company, not your website company. In actuality, each domain registration can have up to three contacts listed, a registrant, an administrative contact, and a technical contact. It’s a good idea to review these contacts each year to make sure each contact is correct and current.

The Registrant contact has the highest level of authority and access for the domain name, and is considered the contact partner. The administrative contract also has full access rights to the domain and is typically in charge of billing and decision-making for the domain name. The admin contact also has rights to transfer the domain name to another registrant. The technical contact is actually the contact with the least control and responsibility for the domain. They carry no liability and have no control over domain name transfers, but they can assign and control the domain name server responsible for the domain.

To simplify things, I generally recommend that my clients keep all three contacts internal rather than assigning them to contractors or partners.

The responsibility for managing the DNS servers can get a little tricky, and here I often find friction between the internal IT department, any outsourced IT vendors, internal marketing departments, and contracted website management companies. Because both email and web services rely so heavily on DNS to function correctly there really is no clear answer. Your best option is to make sure that the party responsible for DNS 1) knows what they are doing, 2) has good security and privacy policies in place, and 3) is responsive and cooperative with all other interested parties. Unfortunately, I find all too often that either IT service providers and website service providers lack the skills to correctly manage DNS.

I may be biased, but in my opinion the responsibility for DNS management should be on the digital marketing vendor or website service provider since they are generally the ones who need to make the most frequent changes and updates. I explain it like this: IT Services are responsible for communications systems and the systems that keep your business running. Digital marketing and website service companies are responsible for the systems that get your business found by customers and prospects.

As far as records are concerned, I typically find that the IT service providers generally just need the proper records for email delivery and authentication. Those records don’t change often and, when they do it’s usually scheduled well in advance. Digital marketing and website service providers, on the other hand, typically maintain a whole host of records for things like website access, website caching and security systems, identity verification for 3rd party services like Facebook, google business, Bing, and for verifying 3rd party email marketing companies. And, unlike the MX records, we don’t have the luxury of fallback records in case a service goes down or needs to be moved to a different host.

Now, before you correct me, I do know that there are ways to provide some of this flexibility using CNAME flattening or ANAME records. Both of those methods work well, but neither is supported by every DNS provider and interoperability between DNS hosts can sometimes be problematic.

Who is responsible for what?

So, the short answer to the question of who is responsible for what is: Your company should be responsible for the domain name, and the party responsible for managing your digital marketing and website services should be responsible for your DNS services.

So enough theory. How does it work in practice? Let’s run through a few scenarios…

Examples

Example 1: DNS For a Website

The first example is going to be a very simple one. We’ll take the domain name leaninginfallingover.com and we’ll attach it to a website. I’ve already registered the domain, leaninginfallingover.com, using Google domains and I’ve already used my website host, GridPane, to create the website leaninginfallingover.com. However, you’ll notice if we go to that URL, we don’t get anywhere. So, here’s what we need to do. In Google domains, this is my registrar, I come over to the DNS tab because Google domains is doing both the domain registration as well as the DNS hosting. And will keep them combine like this, just for this example.

So here on the DNS tab, I’m going to click in the host name box, and it automatically pre-populates with leaninginfallingover.com. I don’t need to put anything in there. The type of record that will create is an “A record”. And for the data, I’m going to come back here to my web host and grab the IP address for that server and just paste it right in here. When I hit save, it creates the record for me. This TTL of one hour, this is just saying how long the record stays in cache before our computer must go back out and re-fetch it.

Now you’ll notice when I go to leaninginfallingover.com I get the default WordPress website. Most of the time you want your website to answer on both the root of the domain as well as the WWW version of domain. If I come in here now and type in www.leaninginfallingover.com, you’ll see that, once again, I can’t reach that page. So how do we fix this?

We’ll come back to the DNS server where we’ve already created the A Record for leaninginfallingover.com and we’ll create a new record. This time, we’re going to create one called WWW and we’re going to change it to a CNAME Record. In there, we’re going to leave the TTL the same, and we’re going to type in leaninginfallingover.com for the data. So now we have an A record which is a host record that says leaninginfallingover.com goes to this IP address. Now we’ve created one that says www.leaninginfallingover.com goes to leaninginfallingover.com, which again resolves to that IP address. Once those records are saved and have a chance to propagate through the Internet, we’ll come back here to the website, go to www.leaninginfallingover.com, and you’ll see that it resolves.

You’ll also notice up here in the address bar it says not secure. The reason for this is because it’s using the HTTP version of the website, not the secure HTTPS version of the website because we haven’t issued an SSL certificate yet. That SSL certificate is usually something that’s issued by the web host (Actually it’s issued by a certificate authority, but the process is typically initiated by your web host). So, we’ll come back over here to GridPane, click into the domain, go over to domains, and we’re going to take this little box here that says, “Enable Primary Domain SSL”. It’s going to check to make sure everything is OK and it’s going to rewrite the website to use the SSL version for everything instead of the normal one. You’ll see that there’s a success, everything has been issued properly, and the database has been rewritten. Now, if I come back over here to the website and refresh, I’m now going to HTTPS leaninginfallingover.com. I now have SSL on my primary domain and if I go to www.leaninginfallingover.com it redirects back correctly. That’s all there is to getting a website connected to your DNS server.

Each Console is Unique

In the previous example, I used Google’s DNS console to manage the records. Each DNS server has their own console, and they all look slightly different. At its core though, the consoles are all just writing plain text files that are human readable. Here’s a simplified example of my domains DNS records.

We start off at the top with the SOA record. This store is important information about the domain in the zone. Then we had the A Record for peakperformancedigital.com pointing to 172.67.198.72. Below that, we have CNAME records for mail, schedule, and WWW. Then below that we have the MX records that show where to deliver mail for my domain. Below that is a text record. This one is an SPF record that says which mail servers are authorized to send mail from my domain.

Example 2: DNS For Email

Next, we’re going to set up the MX records for this domain so that it can receive email. We’ll come back over here to Google domains, and then we’re going to add a few additional records.

In this example, I’m going to pretend that we’re connecting the domain to Google Workspace. And if you look inside Google support, these are the records that it tells you to add. Now, come back into DNS, and we’re going to manage those custom records.

We have to create at least one of those records, but it’s best to create them all just in case, for some reason, one of them fails. So again, we’ll start off with the host. We’ll leave that blank because it’s going to be for leaninginfallingover.com. We’ll change the record type to MX. I would leave my time to live the same, and I’m going to type in here both the priority as well as the server that it needs to go to.

Priority one means that this is the first server that it’s going to try before any other mail server. I hit save. To add the rest of the email servers we’ll come back in to “manage custom records” and this time we’ll click on this little box right here that says, “add more to this record” and you’ll see it creates another line underneath of it where I can add in those additional servers.

We’ll start here and I’ll add one with the priority of five for ALT1. Another with a priority of five for ALT2. ALT3 gets a priority of 10, and ALT4 gets a priority of 10. What this means is that further domain leaninginfallingover.com we’ve got MX records each with a time to live of one hour. The first one that it’s going to check is Aspmx.l.google.com, if that one fails then it can use either one of these, ALT1 or ALT2 as a secondary. If both of these fails, then it will try ALT3 and ALT4.

And there it is. We save the records and now if we were to send an email to an address at leaninginfallingover.com, as long as that address existed inside the mail server, it would be delivered.

Example 3: Moving DNS Servers

In this next demonstration we’re going to keep the registration with Google, but we’re going to move the DNS server from Google to Cloudflare.

Starting off inside of Google domains, you can see it’s using the default name servers which are Google, and we want to transfer that over to Cloudflare. Over in Cloudflare, you can see I’m logged into my account already. You can just go to www.cloudflare.com and create a new account and it will walk you through a wizard.

I’m going to say, “add site”, put in leaninginfallingover.com, and it’s going to take me to a sales page. Believe it or not, this free plan is very, very good. It has most of the features that people need and I highly recommend it for almost anybody. If you do want some of these enhanced features, $20 a month is a small price to pay for it. But for now, I’m going to select the free plan.

Cloudflare is great and it’s going to scan for existing DNS records to try to create them for me automatically. It doesn’t always get it right, so it’s a good idea to go into your existing DNS server and make sure that everything that it sees is actually correct. In this case it looks like it grabbed everything. It got our A Records, it got this domain connect, and now it has CNAME for www.that points back to leaninginfallingover.com. It also grabbed all five of our MX Records. In this case I don’t need to make any changes. However, if I needed to, I could add records just by clicking this button and going through the menus. For now, I’m going to click the continue button and we’ll go on.

The next part of this wizard is saying to remove these following name servers and add the ones for Cloudflare. As I mentioned before, my servers are HAL and Nelly, so I’m going to click to copy this one, I’ll go back to Google domains, and this time I’m going to change this default nameserver over to a custom nameserver.

I want to tell it that I want to use HAL and Nelly. If I didn’t have these in already, I would just click manage nameservers and put them in, then hit save. And then we’ll say, “switch to these settings”. Now, sometime in the next hour or so, the DNS settings will take effect and instead of using Google to resolve names, it’ll use Cloudflare.

When I finished all of that, I click on this button here in Cloudflare that says, “check name servers” and it’ll walk you through another wizard to do more. So, we’ll apply some of these recommendations. Always use HTTPS. This is a good one to use. Always enable auto minify. I also like this one. And now we’re going to go to the overview page. Now that we’re on this screen, we’re going to tell Cloudflare to check the name servers and see whether it’s taken effect. Because DNS changes don’t always take effect right away, sometimes we have to check, and it’ll email us when it’s ready. But for now, we will explore the rest of the important parts of the Cloudflare dashboard as it pertains to DNS.

The things that you really care about here are right when this DNS tab. We’ll click on it, and here again we see the records that we have. One of the big features that Cloudflare has is called proxy. What it does, is it hides the IP addresses on the Internet, and it proxies that through its own systems. That’s got a couple advantages. One of them is that it lets you use the Web Application Firewall (WAF) that’s built into Cloudflare. Another one is that it lets you use some of the caching that’s built into part Cloudflare, and those are some of the big selling features of this service.

When we have the orange cloud icon enabled, it means that those records are proxied and it’s taking advantage of those things in Cloudflare. If we don’t want to use them, we can just say, “edit, uncheck” and save. You’ll also notice that the interface inside Cloudflare looks a little bit different than the one inside of Google domains. I personally think that Cloudflare’s interface makes more sense, but it’s really just personal preference.

I just received the email from Cloudflare saying that everything is set up and ready to go. I came back into leaninginfallingover.com and I get this screen that says “Great! Cloudflare is now protecting my site”, and now I can do everything that I want to with my DNS. We don’t have the messages in here saying that it’s in a pending state. We can go to overview, and we don’t have any more of the setup boxes.

At this point we have Google domains only managing the domain registration. We come over here to the DNS settings and is using custom nameservers, so any settings that we put inside of DNS here are not going to take effect because it’s saying do all the loops through Cloudflare. In Cloudflare we’ve got DNS setup so that these are the records that it uses.

If we needed to change the web server, we could just come right in here and update the A Record. If we needed to add any new MX records, we could do that. If we needed to put any other records in for any other reason, we could do that right through the Cloudflare interface. And one of the great things about Cloudflare is that these changes take effect very, very quickly, much faster than most other DNS servers.

Example 4: Transferring a Registrar

In this last demonstration, I’m going to show you how we can transfer registrars from one to another. Keep in mind that every register is going to be different, but again the process will be mostly the same.

We’ll start off inside of Google domains, which is our registrar, and we’ll come down to registration settings. In here, there’s two things that we need to think about. One is unlocking the domain, and then the second thing is getting an authorization code to transfer the domain out.

The first thing we need to do is make sure that this domain is unlocked. Some registrars will not immediately unlock the domain. If a change to the domain has happened recently, usually within about three days, it won’t unlock. If you just registered it, you typically won’t let you unlock the domain for a period of time. This is just a security feature on their part. Once the domain actually is unlocked, you’ll click on this button to say, “get an authorization code” and you want to copy that down and keep it in a secure place, at least until the domain transfer has taken effect.

Now that I have my domain unlocked and I have my authorization code, I can come over to the receiving registrar. In this case we’re going to use Namecheap com. I know it sounds like it’s a budget registrar, but it’s actually been around a long time and it’s very well respected. So here, right at the top, it says “transfer to us”. We’ll say, “transfer domains” and type in the domain name hit “transfer”. It’s going to do some checks and it says, “Great, the domain is unlocked”. I say, “yes, I do want this to be transferred”, type in that authorization code that we got before, and I verify it. It’s got a green check mark and now we are good to go. Next, I add to cart. We can see that’s going to cost me $9.36 to transfer it in. We’re going to “view cart” and here we have all the information about the transfer.

So, we’re going to transfer in leaningfallingover.com for one year, and not going to auto-renew. You can see right here that it’s a special rate of $9.18 for the first year and then it’s going to renew at $13.98 per year. Domain privacy is included for free, just as it should be now.

Down here, it’s going to try to sell us on some extra things. Most of the time you don’t need or want them. SSL, don’t pay for this. You can get it free from almost any webhost now. VPN, probably not worth the money. Most of the stuff I wouldn’t bother with. Even email and web hosting, those things are better done through companies that specialize in email hosting and web hosting. Premium DNS, if you want to spend an extra $5, you’re welcome to, otherwise use the free Cloudflare account and you’ll probably have better results with that.

Next, we’ll confirm the order and the last thing we do is create an account if you don’t already have one, pay the fee and then wait.

Registrar changes typically don’t take effect right away because there is a process that the receiving registrar needs to go through with sending registrar to make sure that everything is correct and that all the handshakes take place. With Google, for example, they’ll tell you right in the documentation that a domain transfer can take five to seven days to complete.

Once the transfer is complete, you’ll typically get an email confirmation from the receiving registrar. From there, you just log into that registrar to make any changes that need to be made.

Internal & External DNS

There is one other thing to be aware of. Just like the Internet, most internal company networks rely heavily on DNS because of a lack of understanding. It’s not unusual to see internal DNS systems configured improperly and causing issues with external name resolution. That topic is quite advanced and well beyond the scope of this high-level overview.

Wrap-Up

I know this was a lot to take in. As I mentioned earlier, this isn’t intended to be an exhaustive tutorial or step-by-step guide. But, if you understand these basic concepts you should have enough knowledge to ask the right questions or to apply what you learned here to your own situation.

If you want to learn more, you can visit us online at https://peakperformancedigital.com or email us at [email protected].