Understanding registrars, DNS records and hosts


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.

When do I need to pick a registrar?

New organizations purchasing their first domain will always need to pick a registrar. If your organization is unhappy with your current registrar for cost, technical, or ideological reasons then transferring your domain to a new registrar can be a great idea. Alternatively if your organization’s domains are currently registered with multiple vendors, consolidating onto a single registrar can significantly reduce management complexity. Finally, any time your organization needs to register a new domain, you’ll have the opportunity to reassess the choice.

Cornershop Creative’s registrar recommendations

Your current registrar

If you have existing domains with a registrar service and are happy with the vendor, continuing to purchase domains through them is a great idea. This ensures all payment, management, and domain notifications stay centralized on the same vendor.


Cloudflare began offering domain registrar services to all customers in 2018. Cornershop Creative strongly recommends CF for a few reasons:

At cost TLD pricing. Each TLD authority is allowed to charge registration fees, which most registrars inflate to make their own profit. Cloudflare has no markup, ensuring their pricing is as low as possible without taking a loss.

Technically reliable. Cloudflare consistently delivers robust and reliable services, from their Content Delivery Network (CDN) to their Web Application Firewall (WAF). This absolutely carries over to their domain registrar offerings.


Cornershop Creative has worked with most of the top 25 domain registrars and isn’t a huge fan of any of them. That said, if market share is a priority for your organization’s vendor selection process, we recommend Name.com. They are unquestionably one of the most popular registrars in the world, are easy for us to work with as your agency partner, are competitively priced, and provide access to a significant number of TLDs.

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, 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). 


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.


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 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.