How Domains Work

A domain name is the friendly, human-readable address you type into a browser to reach a website, like devcraftly.com. Computers do not actually talk to each other using these names; they use numbers called IP addresses. This page explains what a domain really is, who manages it, and the full journey a request takes from the moment you type a URL to the moment it lands on your Ubuntu server. Understanding this end to end makes everything else in DevOps (DNS, SSL, reverse proxies) much easier.

What a domain name actually is

A domain name is a label that points to a server somewhere on the internet. An IP address (a numeric address that identifies a machine on a network, like 203.0.113.10) is hard to remember, changes when you move servers, and looks unfriendly. A domain gives you a stable, memorable name that you control, while the IP underneath can change freely.

When you own a domain, what you really own is the right to decide what that name points to. You do not own the IP address; you own the mapping from the name to an address.

Let’s use a concrete example throughout this page: the domain shop.example.com.

The anatomy of a domain

A domain is read right to left, from the most general part to the most specific. Each dot-separated part is called a label.

Part	Example	What it is
Root	. (invisible)	The very top of the system, the starting point
TLD	com	Top-Level Domain — the category or country
Apex / second level	example	The name you register and own
Subdomain	shop	A prefix you create under your domain

So in shop.example.com:

• com is the TLD (Top-Level Domain) — the broad category. Examples include .com, .org, .io, and country codes like .uk or .in.
• example.com is the apex domain (also called the root or naked domain) — this is what you register and pay for.
• shop.example.com is a subdomain — you create these yourself for free, as many as you like, once you own the apex.

The part before the first slash in a URL is the domain (the “host”). In https://shop.example.com/cart?id=5, the host is shop.example.com, and everything after it (/cart?id=5) is handled by your server, not by DNS.

Registrars, registries, and ICANN

Three different organisations are involved in making a domain work. It helps to know who does what.

Player	Role	Example
ICANN	The non-profit that oversees the whole naming system	ICANN
Registry	The company that runs a specific TLD’s master database	Verisign runs .com
Registrar	The company you actually buy a domain from	Namecheap, Cloudflare, Porkbun

When you buy example.com, you pay a registrar (a company licensed to sell domains). The registrar records your ownership in the registry (the authoritative database for the .com TLD). ICANN (the Internet Corporation for Assigned Names and Numbers) is the body that coordinates this entire system so names stay unique worldwide.

When to use which registrar: pick a registrar that sells at the wholesale price with no markup on renewals (Cloudflare and Porkbun are popular for this in 2026) and that gives you free WHOIS privacy. Avoid registrars that offer a cheap first year but triple the renewal price.

The journey: from URL to your server

Here is what happens, step by step, when someone visits https://shop.example.com.

1. You type the URL. The browser needs the IP address for shop.example.com, but it only has the name.
2. DNS resolution begins. The browser asks a DNS resolver (usually run by your internet provider or a public one like 1.1.1.1) to translate the name into an IP. DNS (Domain Name System) is the internet’s phone book.
3. The resolver walks the tree. It asks the root servers “who handles .com?”, then asks the .com registry “who handles example.com?”, then asks your nameservers (the DNS servers responsible for your domain) for the IP of shop.
4. An IP comes back, for example 203.0.113.10 — the public IP of your Ubuntu server.
5. The browser connects to 203.0.113.10 on port 443 (HTTPS) and the request reaches your server.
6. Your web server responds. On Ubuntu this is usually Nginx or Apache, which serves the page or forwards the request to your application.

You can watch part of this yourself. Use dig, the standard DNS lookup tool. Install it first if needed.

sudo apt update
sudo apt install -y dnsutils
dig shop.example.com +short

Output:

203.0.113.10

To see the full resolution path, including which nameservers answered:

dig shop.example.com +trace

Output:

; <<>> DiG 9.18.30-0ubuntu0.24.04.1-Ubuntu <<>> shop.example.com +trace
.                       518400  IN      NS      a.root-servers.net.
com.                    172800  IN      NS      a.gtld-servers.net.
example.com.            172800  IN      NS      ns1.yourdns.net.
shop.example.com.       3600    IN      A       203.0.113.10

That final A line is the actual mapping from your subdomain to your server’s IP. (An A record is the DNS entry that links a name to an IPv4 address — covered in detail in the DNS records page.)

Why this matters for your server

Once the name resolves to your server’s IP, the rest is your job on Ubuntu. The domain is just the doorway. To actually serve traffic you will:

• Open the firewall for web traffic with ufw (Ubuntu’s firewall tool):

sudo ufw allow 'Nginx Full'
sudo ufw status

Output:

Status: active

To                         Action      From
--                         ------      ----
Nginx Full                 ALLOW       Anywhere

• Configure a web server (Nginx or Apache) to respond for that hostname, using files in /etc/nginx/sites-available/.
• Add SSL/TLS so the connection is encrypted (the padlock and https://).

A common beginner trap: a domain pointing to the wrong IP, or DNS not yet propagated, looks identical to a broken server. Always confirm the name resolves to your IP with dig before debugging Nginx.

DNS changes are not instant. Records are cached for a period called the TTL (Time To Live), measured in seconds. If you set a TTL of 3600, a change can take up to an hour to be seen everywhere. Lower the TTL before a planned migration so changes apply faster.

Best Practices

• Register your apex domain with a no-markup registrar and enable auto-renew so it never expires by accident — a lapsed domain can be lost.
• Turn on WHOIS privacy to keep your name, email, and address out of public records.
• Always verify resolution with dig <name> +short and confirm it returns your server’s IP before touching web server config.
• Lower a record’s TTL to 300 seconds a day before migrating to a new server, then raise it again afterward.
• Use subdomains (like api. or shop.) to organise services instead of buying separate domains for each.
• Keep a note of which registrar holds the domain and which nameservers it uses — this is the first thing you check when a site goes down.

Related Topics

• Registering a Domain
• DNS Records
• Pointing a Domain to Your Server
• Nameservers
• Subdomains