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

Published on December 12, 2021

Tagged: #no-code-explained

Follow me on twitter for more posts like this

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

  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. SquareSpace has excellent step by step instructions on how to setup a domain on their platform if that’s why you came here!

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

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

  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 we only used the numbers and a computer broke 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 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 google.com?

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” -> “123.123.123.123”

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

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

The first entry is

Host Record Type Record 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 Record 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.

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

Host Record Type Record Data
@ A 123.123.123.123
@ A 345.345.345.345

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.

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 “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 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 com nameservers for google.com designated nameserver.

Finally it would ask google’s nameserver for the actual A or 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 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 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 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 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.

The end

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

Darragh ORiordan

Hi! I'm Darragh ORiordan.

I live and work in Sydney, Australia building supporting happy teams that create high quality software for the web.

I also make tools for busy developers! Do you have a new M1 Mac to setup? Have you ever spent a week getting your dev environment just right?

My DevShell tooling will save you 30+ hours configuring your dev environment with all the best modern tools. Get it here

https://darraghoriordan.gumroad.com/l/devshell


Read more articles like this one...

List of article summaries

#frontend-development

Using no-code airtable and Netlify to quickly build a machine log application

A friend asked me to create a tool for logging when one of his staff enters a room to turn on and off machine jobs. It needed to be on the cloud and run on an ipad. He wanted it to be simple and have an MVP fast.

I wanted to see if I could build the tool using no-code or similar. I got it built in around 2 hours using airtable! Though I found that I needed a tiny bit of code to make it more professional by having it on its own url.