Understanding registrars, DNS records and hosts

Registrars

A registrar is the company that you buy your domain name from. Domains usually cost around $10-20 per year, though it depends on the suffix and how much the registrar chooses to charge. For example the .car and .dealer domains cost over $2,000 per year to register!

Once a domain is purchased with a particular registrar, it can be transferred to a new registrar if desired. In order to prevent fraud, however, changing registrars is a cumbersome process involving email approvals, transfer codes, paying the new registrar, etc — so it can be rather logistically inconvenient to do.

Getting registrar credentials gives us the ability to change a domain’s name servers. Content Delivery Network (CDN) providers like Cloudflare and Sucuri generally require doing so.

Name Servers

The Name Servers for a domain are the computers in charge of knowing (and telling other computers on the Internet) how that domain works, i.e. what computers on the Internet host the domain’s website, what computers on the Internet receive email sent to that domain, and what computers on the Internet are allowed to send email from that domain.

Domains always have at least two nameservers specified and sometimes several more. (This helps ensure that if one fails, there’s a backup to connect with for the answers). Typically, these name servers have names like ns1.someprovidername.com, ns2.someprovidername.com, ns3.someprovidername.com, etc.

Name Servers store this information in what are called “DNS records” or, more technically, a “zone file”. For this reason, the company providing the Name Servers is known as a domain’s “DNS Provider.”

Getting credentials to the DNS provider allows us to change a domain’s DNS records, for example to point the domain at your new website! Here’s how to add us.

DNS Records

A domain’s DNS records are the things that specifically tell the rest of the Internet how to treat that domain, such as where to route email messages intended for that domain and where to send requests for that domain’s website. Each record is like a row in a spreadsheet; the main columns are “type”, “name” and “value”

There are four main types of DNS records (and several less common ones):

  • A records: These link a domain name, including specific prefixes like “www.domain.com” or “intranet.domain.com”, to an IP address — that is, a specific device connected to the Internet somewhere.

  • CNAME records: These are like aliases, specifying that a certain domain name or prefix should actually send traffic to whatever the DNS record is of some other domain, e.g. calendar.cornershopcreative.com has a CNAME record of ghs.google.com. 

  • MX records: These link a domain to the names of servers that handle email sent to the domain. Often multiple MX records exist so that if one mail server is having problems emails can be routed to another server without disruption. 

  • TXT records: These are used for a variety of purposes, such as authorizing specific computers to send email on that domain’s behalf (called SPF).

DNS records are what specify what computer a website lives on, which means they specify a domain’s website host.

For example, for our site, there is an A record that "points" the domain cornershopcreative.com to the IP address 23.185.0.2, and there's a separate record just for email called an MX record that makes emails sent to someone@cornershopcreative.com get delivered to our email provider (Google Apps). 

Hosts

The host is the provider of the computing infrastructure that powers the website.

Every website must be “hosted” on at least one computer (often called a server) – the machine in charge of sending the data for the website to a site visitor’s browser. While sometimes we use the word “host” to refer to the specific computer the website lives on, more commonly the word “host” refers to the company that owns and maintains that computer and its connection to the internet (as well as likely thousands of other such computers!).

Different hosts use different computers and different technologies to provide the computing resources necessary to power a website. Some hosts use really powerful computers, give those computers really good internet connections, and put very few websites on each computer; others don’t. (And sometimes the “computer” hosting a website isn’t actually a single computer at all, but a complicated system of stuff that all together functions like one computer.)

Some hosting companies do a good job and others don’t. But since every host does things a little differently — sort of like how everyone’s phone has a unique combination of wallpaper, apps, and so on — it can be challenging to know how to best work with all the possible hosts. For that reason, we focus on Kinsta and Pantheon to insure deep familiarity with a few great hosts. This is not to say these are the only acceptable hosts in the world! They’re just the ones we know are good and the ones that we have learned our way around the best.

Bundling

It’s very common for one company to provide all three of these separate services — domain registration, name servers, and hosting — as it can be convenient and simple (especially for non-techies) to not have to worry about keeping this stuff in order across different vendors. But they are, in fact, distinct services and don’t need to be done by the same company.

In fact, there are many companies that specialize in just one of these things. Kinsta, for example, just hosts websites — though they partner with Amazon to host DNS records through Amazon’s name servers if needed. As another example, Cloudflare just provides name servers to manage DNS records (because they do fancy stuff with those DNS records to allow them to provide caching and security). So sometimes figuring out what credentials you need to make a particular change can be confusing.

Sidenote: DNS “propagation”

Often when a DNS record is changed from pointing at one host to pointing at another, it can take a while before everyone sees the new website. Even more confusing, not everyone starts seeing the new website at the same time! This is due to DNS propagation, the phenomenon of spreading a DNS record throughout the Internet.

Imagine that any time you wanted to visit Google.com, your device had to lookup google.com’s name servers to find where the DNS records were stored, then go check the values of those DNS records to figure out what computers were actually hosting the google.com website. That would stink for two reasons: First, it’d be annoying and slow for YOU, because all of that would have to happen every single time you wanted to visit google.com. Second, it’d be terrible for the poor name servers, because billions of people would constantly be asking them the same damn question over and over and the name servers would likely get overwhelmed.

Fortunately, the answer to the question “what computers serve the website for google.com” doesn’t change very often, so to save time lots of computers and devices throughout the internet just remember the answer – which is to say, they can keep their own copy of the DNS records for google.com on hand. So instead of your device having to ask one of those original (called “authoritative”) name servers where google.com lives, your device may just remember the answer itself for a little while — and if it’s forgotten, it may just go ask a device more nearby on the internet (like your internet provider’s DNS servers).

Because all these devices all over the place are storing copies of the original DNS records, when changes to the original DNS records are made, it can take a while for those changes to take effect — the copies of those DNS records need to be “refreshed” with the latest information from the authoritative servers. And though DNS records can provide guidance on how long those cached copies of themselves should be kept before they expire and the original DNS records are re-checked (called “time to live”), it’s not an exact science.

How They All Fit Together

Let's say you're at home and want to use your Comcast connection to get to cornershopcreative.com. Conceptually, it goes down much like this:

  1. You type the domain into your browser.

  2. Your browser asks your device’s operating system "what computer has the content for cornershopcreative.com?"

  3. Your device’s OS to see if it has DNS records cached for the domain and how old the cache is.

  4. If it doesn't have the DNS records, or if they're too old, your device’s OS goes to your Internet Service Provider (e.g. Comcast) and asks the registrar "Who has the answer to where this domain goes?"

  5. Your device’s OS goes out to Comcast to ask "what computer has the content for cornershopcreative.com?"

  6. Comcast looks to see if it has DNS records cached for the domain and how old the cache is.

  7. If it doesn't have the DNS records, or if they're too old, Comcast goes to the cornershopcreative.com registrar and asks the registrar "Who has the answer to where this domain goes?"

  8. The registrar answers with the list of 2+ name servers.

  9. Comcast then goes to one of those name servers and asks it "what computer has the content for cornershopcreative.com?"

  10. The nameserver gives an answer. The nameserver also tells Comcast that it should remember the answer for a while.

  11. Comcast then stores the answer in its cache (so it can skip steps next time), and delivers the IP address in the answer to your device’s OS.

  12. Your device’s OS then stores the answer in its cache (so it can skip even more steps next time), and directs your browser to the IP address in the answer.

  13. Your browser goes to the server at that IP address and asks, "Can I please have the content of the webpage for cornershopcreative.com?"

  14. The hosting server responds with the website content for the site homepage.

The caches mentioned above are the reason why when you change a DNS record, it can take a day or two for everyone to see the "new" answer. Every step along the path will hold onto their last answer for minutes, hours, or even days! Asking the registrar and then the nameservers is much slower than looking in a local cache for the answer, so these systems try to avoid having to do so.

Did you find it helpful? Yes No

Send feedback
Sorry we couldn't be helpful. Help us improve this article with your feedback.