Are DNS and a domain the same thing?

No. The domain is the name you register (example.com). DNS is the system that publishes and resolves the data for that name, such as the site's IP and the mail servers.

What port does DNS use?

Port 53. Regular queries use UDP, and TCP is used when the answer is large or UDP is not enough. DNS over TLS uses port 853 and DNS over HTTPS uses 443.

I changed my DNS and the site did not update. Why?

Resolvers cache answers for the duration of the TTL. Until it expires, some users still get the old value. Lowering the TTL before a planned change shortens the wait.

What is the difference between 1.1.1.1 and 8.8.8.8?

They are public resolvers run by different companies (Cloudflare and Google). Both answer the same queries, but they differ in speed on your network, privacy policy and optional filtering.

What is DNS and how does it work?

Computers find each other on a network by IP addresses, like 203.0.113.10 or 2001:db8::10. People remember names. DNS bridges the two: you type example.com and, in milliseconds, a server answers with the IP that belongs to that name.

Almost everything you do online starts with a DNS query: opening a site, calling an API, connecting a bot to the Discord Gateway, sending an email. When DNS fails, a service looks down even if the server is perfectly healthy.

What is DNS?#

DNS (Domain Name System) is a distributed, hierarchical database that maps names to data, mainly IP addresses. It was defined in RFCs 1034 and 1035 and is still one of the foundations of the internet.

Two ideas explain the design:

Distributed: no single machine stores every name. Each organization maintains the data for its own domain, and the system knows who to ask.
Hierarchical: the name api.example.com reads right to left: root (an implicit trailing dot), com, example, api. Each level delegates the next one to other servers.

Who takes part in a DNS query?#

Role	What it does
Client (stub resolver)	The operating system or browser. Asks the resolver and caches the answer.
Recursive resolver	Does the heavy lifting: queries other servers until it finds the answer. Usually your ISP's, or a public one like `1.1.1.1` (Cloudflare) or `8.8.8.8` (Google).
Root server	Knows which servers handle each TLD (`.com`, `.org`, `.br`). There are 13 named root servers, from `a.root-servers.net` to `m.root-servers.net`, each with an IPv4 and an IPv6 address, replicated across thousands of instances worldwide (root-servers.org keeps the current map).
TLD server	Knows which servers answer for each domain inside the TLD.
Authoritative server	Holds the domain's zone and gives the final answer: the DNS records.

How does DNS find an IP, step by step?#

Say your browser needs www.example.com and nothing is cached:

The browser and the operating system check their local caches. With no answer, they ask the recursive resolver.
The resolver asks a root server. The root does not know the IP, but points to the .com servers.
The resolver asks the .com servers, which point to the authoritative servers for example.com.
The authoritative server answers with the record, for example A 203.0.113.10.
The resolver returns the answer to the client and caches it for the TTL.

Each step is a referral: the server points to whoever knows more. In practice caching skips most of this. Queries to the root are rare, because resolvers already remember who handles .com.

Queries travel over UDP on port 53, falling back to TCP when the answer does not fit in a packet (RFC 7766 requires TCP support).

What are caching and TTL?#

Every DNS answer carries a TTL (time to live): how many seconds it can be reused without a new query. A TTL of 3600 means the resolver may serve the same answer for up to one hour.

Caching makes DNS fast and cheap, but it has a cost: when you change a record, anyone who already cached the answer keeps seeing the old value until the TTL runs out. That is the "I changed it and nothing updated" effect. Before a migration, lower the TTL (for example to 300) a few hours ahead and raise it again afterward.

How do you query DNS with dig?#

dig (Linux and macOS; on Windows, use nslookup or WSL) shows what DNS answers, and @ picks the resolver. In order, the four commands below show the IP according to Google's resolver, the value only, the authoritative servers, and the full path (root, TLD, authoritative).

bash

dig @8.8.8.8 example.com A +noall +answer

dig +short example.com A

dig example.com NS +short

dig +trace www.example.com

The answer line looks like this (documentation IP, not a real record):

text

example.com.   3600   IN   A   203.0.113.10

The fields are name, remaining TTL, class, type and value. Run it again and the TTL counts down: that is the cache at work. If dig +short prints nothing, the name does not exist or has no record of that type.

Is DNS secure and private?#

Not by default. Classic DNS travels unencrypted, so the network sees which names you look up, and an answer can be forged. Two separate protections exist:

DNSSEC (RFC 4033 and related) signs the zone's answers. The resolver validates the signature and detects tampering. It protects integrity, not the privacy of the query.
DNS over TLS (DoT, RFC 7858, port 853) and DNS over HTTPS (DoH, RFC 8484) encrypt the hop between client and resolver. They protect privacy from anyone watching the network, but the resolver still sees your queries.

What does DNS not do?#

It does not register domains. Registering the name happens at a registrar. DNS publishes the data afterward.
It does not carry traffic. It only tells you the IP. The server at that address delivers the page.
It does not change instantly. Caching and TTL impose a wait, often called propagation.
It does not fix server failures. Correct DNS pointing to an application that is down still returns an error.

Related terms: zone (a domain's set of records), NS (the record saying who is authoritative), registrar (the company where you buy the domain), hosts file (a local file the system checks before DNS).

How to do this on Square Cloud#

Every web application on Square Cloud gets a *.squareweb.app subdomain with HTTPS, on every plan, with no DNS work on your side. To use your own domain, from the Standard plan, you create the DNS records the dashboard shows at your registrar and follow the validation status in real time. TLS is automatic and domains with accents (Punycode) are supported.

The domain stays registered in your name, at your registrar, and that is where you control the records. The steps are in how to point a domain to your app and how to use a custom domain.

The feature details are on the custom domains page.