Domain Names

What is it? #

A domain name is a rented, human-readable label that points at your infrastructure.

Rented is the accurate word. You register it for a period and renew it; nobody owns a domain permanently.

The structure reads right to left. In shop.example.com, .com is the top-level domain, example is the registered part, and shop is a subdomain you control freely.

A registrar is the company you rent through. Their main job is maintaining your registration and letting you set nameservers, which decide who answers DNS queries for your domain.

Think of it like this #

A shop sign and a street address. The sign is the domain, the address is the server. Change premises and you update where the sign points — customers keep using the same name.

And like a shop lease, the sign stays yours only while you keep paying.

Simple example #

You own example.com. The marketing site is on the apex domain, the application is on app.example.com, the API on api.example.com, and documentation on docs.example.com served by a completely different provider.

Code #

Anatomy

        shop  .  example  .  com
         │         │         │
         │         │         └── top-level domain (TLD)
         │         └──────────── the part you register (second level)
         └────────────────────── subdomain, free for you to create

example.com          apex (or root) domain
www.example.com      a subdomain, conventionally an alias of the apex
api.example.com      a subdomain, often a separate service

A typical record set

Type    Name              Value                     TTL
A       @                 203.0.113.10              3600      apex → web server
CNAME   www               example.com               3600      www → apex
A       api               203.0.113.20              300       API on another server
CNAME   docs              hosted-docs.provider.io   3600      third-party service
MX      @                 10 mx.mailprovider.com    3600      email
TXT     @                 "v=spf1 include:..."      3600      mail authentication
CAA     @                 0 issue "letsencrypt.org" 3600      certificate policy

# Who is the domain registered with, and when does it expire?
whois example.com | grep -Ei "registrar|expiry|expiration"

# Which nameservers are in use?
dig +short example.com NS

# Does the subdomain resolve?
dig +short api.example.com

How it works #

The @ symbol in a DNS panel means the apex domain itself. Most providers use it as shorthand for example.com with nothing in front.

Subdomains cost nothing and need no registration. Creating staging.example.com is a single DNS record, which is why environments, services and third-party integrations usually get their own subdomain.

The www versus apex decision is worth making deliberately. Pick one as canonical and redirect the other, so search engines and analytics see one address rather than two.

Nameservers are the pivot point of control. Whoever the NS records point at answers all DNS queries for your domain. Moving to a new DNS provider means changing those records at the registrar, then recreating your records at the new provider — in that order, or the domain stops resolving.

The CAA record restricts which certificate authorities may issue certificates for your domain. It is a small, cheap security improvement that many domains still lack.

Different TTLs per record are normal. The API record has a short TTL because it may move; the mail records rarely change and can stay long.

Real-world use #

Domain decisions have long consequences. Changing the primary domain of a running product means redirects, re-issued certificates, updated email addresses, search ranking impact and confused users.

Subdomain versus path is a recurring choice. example.com/docs shares cookies, certificates and search authority with the main site; docs.example.com is easier to host separately. Neither is universally right, but the choice affects auth and analytics.

Expiry is a genuine operational risk. Domains have been lost by companies simply because a renewal email went to someone who had left. Auto-renew plus a calendar reminder plus registrar lock is the standard defence.

For anything customer-facing, also register the obvious misspellings and redirect them, and keep the registration details private through the registrar's privacy service where local rules allow it.

Common mistakes #

• Letting a domain expire because auto-renew was off or the contact email was stale.
• Serving the site at both www and apex without redirecting one to the other.
• Changing nameservers before recreating the records at the new provider.
• Using a personal account to register a company domain.
• Forgetting that a new subdomain also needs a certificate covering it.

Practice #

Sketch the DNS record set for a product with a marketing site, an app, an API, documentation hosted elsewhere, and email through a provider. Decide whether the canonical address is www or apex, and write down which records need short TTLs and why.