I recently helped a colleague setup a domain on SquareSpace. They asked me to explain why the configuration was required and what it was doing.
So here is my attempt to briefly explain nameservers and DNS for anyone setting up a domain on a SquareSpace account.
Some notes up-front
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. SquareSpace has excellent step by step instructions on how to setup a domain on their platform if that’s why you came here!
For tech folks: I’m going to gloss over some DNS stuff. These days most people mean DNS with IP on today’s internet when talking about DNS. I’ll also leave out explaining virtual hosts but I acknowledge how important they are to the modern web. I won’t explain subnets and will generalise that every device has a unique IP.
The SquareSpace configuration
This is what the SquareSpace instructions for configuration of a domain looks like
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. 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 to talk to the computer! The internet uses numbers to identify every computer or device on the internet. I’ll explain how your computer turns
google.com into a number later on.
You have seen examples of a number used to identify a computer in the SquareSpace settings above -
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, not the domain.
Your phone has its own unique IP address, your computer has an IP address. Your telly probably has an IP address these days. If you have a smart fridge it also 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 on top of the numbers.
- Domains are much easier for humans to remember. We’re terrible at remembering numbers and there are billions of devices on the internet.
- 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 we only used the numbers and a computer broke then google would have to email everyone that the new IP Address to use is
- 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 your phone provider you lost your old number. DNS was designed from the start in a way that prevents this lock-in problem.
The Domain Name System
So how does your computer find a computer at google just from
You need a phone book.
When your computer is trying to find a computer at
google.com it looks up the correct
IP Address using the Domain Name System (DNS).
It’s these phone book entries that SquareSpace needs 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 so that other computers can look that information up.
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 on a website for your nameserver.
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. As the owner of the domain you can also change the nameservers the domain uses, but you probably don’t have to do that.
There are different DNS 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” -> “188.8.131.52”
CNAME - a Canonical Name. This is for when you want one domain to point to another domain (i.e. not to another IP address). e.g. ”www.googlemail.com” -> “gmail.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 (inboxes) on the domain.
TXT - A text record can be any text or meta information. 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
The first entry is
|Host||Record Type||Record Data|
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||Record Data|
Here SquareSpace needs you to point
ext-cust.squarespace.com. Squarespace will point anyone who goes to
www.yourdomain.com to your internal website on squarespace.
Finally there are a number of A records pointing to IP addresses at squarespace.
|Host||Record Type||Record Data|
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.
@ 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 “raw” domain. Think of
www.google.com - there the host is
www compared to
google.com - there the host is
@ (no host).
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!
So it’s important to remove old A and CNAME records that you don’t want.
How to store an internet-sized list of records
There are millions of DNS records for the internet and they change all the time. There’s too many for a single “phone book”.
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 and it would make the internet too slow.
There is another issue - we have to be able to trust the results! If I try to go to
google.com I have to know that i’ll actually go to a Google server and not some hacker’s computer.
DNS solves these problems 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
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
com nameservers for
google.com designated nameserver.
Finally it would ask google’s nameserver for the actual
CNAME record or whatever it needed! It seems like a lot of extra steps but it’s a brilliant solution really. It provides security because it’s all controlled from the root nameservers, redundancy is provided by having many copies of the phonebooks and solves the load problem by delegating more specific lookups down the chain.
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 of my lookup for
google.com available to the next person that looks up
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 DNS caching happens all over the internet to speed-up these 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 valid result is found it is cached at all lower levels.
Updating DNS records
Now there is a problem where a record for your domain changes because you just updated it. Suddenly all of those cached results all over the world are invalid! They still point to the old website!
DNS solves this by having a self-destruct time on each cached record. This is called
time to live or
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 for lookups for the next 30 minutes but I won’t get any updates for that time.
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.
That’s it. That’s a brief description of DNS as it applies to SquareSpace and the configuration screen you see there when configuring a domain.
Please let me know on Twitter if there’s anything I should go into more detail on!
Sources and further reading
The primary resource for any information on DNS is RFC 1035