DEV Community

Darragh O'Riordan
Darragh O'Riordan

Posted on • Originally published at darraghoriordan.com on

What are domain names, nameservers and IPs when setting up a Squarespace site

I recently helped a colleague setup a domain on SquareSpace. They asked me to explain why all the configuration was required and for a bit more info on what it was doing.

So here is my attempt to explain nameservers and DNS if you were wondering what all those settings are for.

Some notes up-front

  1. The point of this article is to learn why you have to perform the setup steps, I’m not trying to show you how to actually setup a domain on SquareSpace.

  2. SquareSpace has excellent step by step instructions on how to setup a domain on their platform if that’s why you came here!

  3. I’m going to gloss over some DNS stuff because these days most people mean DNS with IP on today’s internet when talking about DNS. I’ll leave out explaining virtual hosts and how important they are to modern web.

The SquareSpace configuration

This is what the SquareSpace instructions for configuration of a domain looks like

"SquareSpace dns configuration screen"
"SquareSpace dns configuration screen"

It mentions “DNS entries” and “domain providers”. There are “hosts”, “records”, “data” - and finally the status of your configuration. SquareSpace seems to be checking your configuration in close-to realtime.

At the end of this you should understand what these terms and settings are for.

Domains and IP Addresses

If you type a domain like google.com in your web browser and hit enter Google’s web page appears.

Your computer has reached out and asked a computer at Google for the website contents. Google sends back the website and your browser displays it.

The crucial thing to know here is that the internet doesn’t actually use the domain google.com underneath! The internet uses numbers to identify every computer or device on the internet.

You have seen examples of a number used to identify a computer in the SquareSpace settings above - 198.185.159.145.

We call these numbers IP Addresses. “IP” stands for internet protocol but that doesn’t matter too much here. Just remember the computers on the internet actually use numbers to identify each other.

Your phone has an IP address, your computer has an IP address. Even your telly probably has an IP address these days. If you have a smart fridge it has an IP address. Every device or computer on the internet needs an IP address number to work.

In fact a serious issue right now is that we’re running out of numbers for all the things as the internet keeps growing! Blocks of those numbers are like gold to companies like Google or Amazon.

Why use domains and numbers?

There are a few reasons to use domains instead of numbers.

  1. Domains are much easier for humans to remember. We’re terrible at remembering numbers and there are billions of devices on the internet.
  2. We can assign any computer to a domain at any time. For example this allows Google to replace one computer with another one without having to inform every user of google.com. If a computer broke and customers only used the number then google would have to email everyone that the new IP Address to use is 234.234.234.234 for example.
  3. IP addresses are owned by organisations. You cannot take the number with you if you want to host your website somewhere else. Mobile phone numbers used to be like this. If you changed phone provider you lost your old number. DNS was designed from the start to prevent this problem.

The Domain Name System

So how does your computer find a computer at google just from google.com?

You need a phone book.

When your computer is trying to find a computer at google.com it looks up the right IP Address using the Domain Name System (DNS).

These phone book entries are what SquareSpace need you to configure. You need to tell everyone who looks up the phone book that yourdomain.com should point to a computer at SquareSpace.

This phone book has some nice features that are suitable for a global internet. I’ll try to get to those. But ultimately it’s a list of domain names and the relevant IP addresses of computers.

We call these phone books a Name Server or just nameservers.

Summary of different DNS entry types

As the owner of the domain you get to decide what it points to. You set this up in on a website for your nameserver. As the owner of the domain you can define the nameservers it uses! We’ll talk about that later.

For now, if you bought a domain online it’s likely that the default name server is the same as the place you bought the domain from.

There are different records for different types of lookups that a computer might need.

A - An a record points a domain at an IP address. e.g. ”www.google.com” -> “123.123.123.123”

CNAME - a canonical name. This is for when you want one domain to point to another domain (not to another IP address). e.g. ”www.google.com” -> “google.com”

MX - a mail exchanger record. On the internet we don’t just have websites, we have email too! The MX record tells email services how to deliver email to people on the domain.

TXT - A text record can be any text. This is often used to store a code that shows you have ownership and control of the domain because only you would be able to set a record.

Applying all of this to SquareSpace instructions

Here is the image again, let’s go through them one by one

"SquareSpace dns configuration screen"
"SquareSpace dns configuration screen"

The first entry is

Host Record Type Reqcord Data
sdf89s9dfsdflkjjs CNAME verify.squarespace.com

SquareSpace want sdf89s9dfsdflkjjs.yourdomain.com to point to verify.squarespace.com. They will try to follow this record from your domain to their verify site to show that you were able to set the record. This is used to prove you own the domain.

Next up is another CNAME

Host Record Type Reqcord Data
www CNAME ext-cust.squarespace.com

Here SquareSpace needs you to point www.yourdomain.com to ext-cust.squarespace.com. Squarespace will point anyone who goes to www.yourdomain.com to your internal website on squarespace. They have hundreds of thousands of websites so they have an internal addressing system they use. It would be too expensive for them to have a separate IP Address for every site.

Finally there are a number of A records pointing to IP addresses at squarespace.

Host Record Type Reqcord Data
@ A 123.123.123.123
@ A 345.345.345.345

The @ symbol is a special entry that means the “root” domain i.e. yourdomain.com - notice there is no www or similar at the start. It is just the domain. This is called the root.

So here SquareSpace needs you to point yourdomain.com to some computers that they run. There are many records to provide redundancy. If you enter yourdomain.com into your browser, your browser will look up the first record and try to get the website from there. However if that computer is not available (it might be undergoing maintenance) the browser will try the next IP address and so on until one computer responds.

Removing conflicting entries

It’s important to note that the built in redundancy described above can also cause issues! If you forget to remove an old CNAME for www or an A record that points to something that isn’t on SquareSpace then some of your customers might be sent to the old website!

How to store an internet sized list of records

There are millions possibly billions of DNS records and they change all the time. There’s too many for a single “phone book”.

There is an issue where every time anyone on the internet opens a web page the phone book would have to be looked up. There’s no single computer that could host this lookup for the entire internet without crashing. It’s just too many requests to handle.

There is another issue - we have to be able to trust the results! If i try to go to google.com I hae to know that i’ll actually go to a Google server and not some hacker’s computer.

DNS solves this problem by using a hierarchy of responsibility and authority. There are root name servers run by an organisation called ICANN. These are the absolute authority on domains on the internet. ICANN store a relatively small list of domain records pointing the main roots at other nameservers. e.g. for com addresses you would go to some nameserver for all com records.

So if my computer needed to lookup google.com they might ask one of the root name servers for a list of nameservers that have authority for com domains. These nameservers are distributed globally. Then it would ask one of those nameservers for google.com designated nameserver. Finally it would ask google’s nameserver for the actual A record or whatever it needed! It seems like a lot of extra steps but it’s a brilliant solution really. It provides security, redundancy and solves the load problem.

The final piece here is that the results of the lookup(s) at each stage are cached for a short period of time. This makes the result available to the next person that looks up google.com. This hierarchy also works bottom up. When I look up google.com on my computer, my computer stores the result locally. So the next time I look up google.com it’s extremely fast because the record is on my computer.

This caching happens all over the internet to speed up lookups. Your computer has a file that will be checked for a record first. Then maybe your internet service provider will be checked. Then maybe a cloud provider like AWS or Azure. Then the request goes to a global name server and finally all the way up to a top level nameserver. When the result is found it is cached at all lower levels.

Updating DNS records

Now there is a problem where if a record for your domain changes then all of those cached results are invalid. DNS solves this by having a self-destruct time on each cached record. This is called time to live or TTL.

If the TTL for a DNS record is 30 minutes then when I look up google.com my computer will store and use the resulting IP Address for 30 minutes. This is very fast.

After 30 minutes my computer will delete the local record and ask a higher authority nameserver for a new record.

This is why it says “It might take 24 hours for your DNS changes to be applied” when you make a change. All of the cached records must be purged from nameservers all around the world!

This is also why SquareSpace has the verification button and the checks. They can only confirm the changes you made when all the caches on their name servers have been purged of the old records and this will take some time.

Sources and further reading

The primary resource for any information on DNS is RFC 1035

Top comments (0)