Skip to content

Hosting

Domains and DNS for Hosting

A domain is the human-friendly name people type; DNS is the system that turns it into the IP address of your server and routes your email. This page explains domains and registrars, how a lookup resolves, every record type you will actually use, how to point a domain at a server, and the everyday DNS tasks of running a hosted site.

Tested on

Lookups use dig and host from bind-utils on AlmaLinux 9 / RHEL 9 (sudo dnf install -y bind-utils). On Debian/Ubuntu the package is dnsutils (sudo apt install -y dnsutils). Zone-file syntax is BIND-style but the concepts apply to any DNS panel.

Domains, registrars, and nameservers

  • Domain name - a name in the global namespace, e.g. example.com. The right-most label (.com, .org, .in) is the TLD.
  • Registrar - an ICANN-accredited company (Namecheap, GoDaddy, Cloudflare Registrar, etc.) where you register the domain. Registration is a yearly lease, not a purchase; let it lapse and it goes back on the market.
  • Registry - the operator of a TLD (Verisign runs .com). The registrar talks to the registry on your behalf.
  • Nameservers (NS) - the authoritative servers that answer DNS queries for your domain. At the registrar you set which nameservers your domain uses - these delegate control of your DNS. They might be your registrar's, your host's (e.g. ns1.yourhost.com), or a DNS provider's (e.g. Cloudflare).
  • WHOIS - the public registration record (registrant, dates, nameservers). WHOIS privacy replaces your personal contact details with the registrar's proxy so spammers do not harvest them - usually free and worth enabling.
whois example.com        # registrar, creation/expiry dates, nameservers
dig NS example.com +short # which nameservers are authoritative right now

Registration vs DNS hosting are two different things

You can register a domain at one company and host its DNS somewhere else. The link between them is the nameserver delegation you set at the registrar. Point the NS at the provider whose panel you want to edit your records in.

How DNS resolution works

When a resolver has nothing cached, it walks the hierarchy top-down. To resolve www.example.com:

Browser -> Recursive resolver (e.g. 1.1.1.1)
   1. resolver asks a ROOT server:        "where is .com?"
      root replies: "ask the .com TLD servers"
   2. resolver asks the .com TLD server:  "where is example.com?"
      TLD replies: "ask ns1.example-dns.com (the authoritative NS)"
   3. resolver asks the AUTHORITATIVE NS: "what is www.example.com?"
      authoritative replies: "A 203.0.113.10"
   4. resolver caches the answer for its TTL and returns it to the browser
  • Recursive resolver - does the legwork and caches results. Run by ISPs, or public ones like 1.1.1.1 (Cloudflare) and 8.8.8.8 (Google).
  • Root servers - the top of the tree; they delegate to TLD servers.
  • TLD servers - know which nameservers are authoritative for each domain in their TLD.
  • Authoritative nameservers - hold the real records for your domain. This is where your zone lives.

TTL and propagation

Every record has a TTL (time-to-live, in seconds) telling resolvers how long to cache it. A 3600 TTL means an answer can be cached for an hour. There is no "push" in DNS - so-called propagation is just old cached answers expiring across the world's resolvers. You cannot force a resolver to forget early; you can only wait out the TTL.

Lower the TTL before a migration

A day or two before changing an IP, set the record's TTL low (e.g. 300). Then when you flip the value, the world picks it up within ~5 minutes instead of hours. Raise it back afterwards to cut query load.

DNS record types

Type Purpose Value example
A Hostname -> IPv4 address 203.0.113.10
AAAA Hostname -> IPv6 address 2001:db8::10
CNAME Alias one name to another name www -> example.com.
MX Mail servers for the domain (with priority) 10 mail.example.com.
TXT Arbitrary text; used for SPF, DKIM, DMARC, verification "v=spf1 ..."
NS Delegates a zone to its authoritative nameservers ns1.example-dns.com.
SRV Locates a service (host + port), e.g. SIP, XMPP 10 5 5060 sip.example.com.
CAA Restricts which CAs may issue certs for the domain 0 issue "letsencrypt.org"

A few rules worth knowing:

  • A CNAME cannot coexist with other records on the same name, so you cannot put a CNAME on the zone apex (example.com itself) - the apex already has SOA/NS records. Use an A/AAAA record (or your provider's ALIAS/flattening) at the apex.
  • MX values point to hostnames, not IPs, and the hostname needs its own A/AAAA record. Lower priority number = preferred.
  • SPF, DKIM, and DMARC are all TXT records - they are formatting conventions inside TXT, not separate record types.

Example zone

A realistic BIND-style zone for example.com:

$TTL 3600
@       IN  SOA ns1.example-dns.com. admin.example.com. (
                2026060901 ; serial (bump on every edit)
                3600       ; refresh
                900        ; retry
                1209600    ; expire
                300 )      ; negative-cache TTL

; nameservers (delegation)
@               IN  NS    ns1.example-dns.com.
@               IN  NS    ns2.example-dns.com.

; web - apex and www
@               IN  A     203.0.113.10
@               IN  AAAA  2001:db8::10
www             IN  CNAME example.com.

; a subdomain on a different server
blog            IN  A     203.0.113.20

; mail
@               IN  MX    10 mail.example.com.
mail            IN  A     203.0.113.30

; email authentication (all TXT)
@               IN  TXT   "v=spf1 mx -all"
default._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQ..."
_dmarc          IN  TXT   "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

; only let Let's Encrypt issue certificates
@               IN  CAA   0 issue "letsencrypt.org"

Email records explained

  • SPF (v=spf1 mx -all) lists who may send mail as your domain; mx authorizes your MX hosts, -all rejects the rest.
  • DKIM publishes a public key (at a selector like default._domainkey) so receivers can verify your mail's signature.
  • DMARC (_dmarc) tells receivers what to do when SPF/DKIM fail (none/quarantine/reject) and where to send reports. See Email Hosting for generating these and How Web Hosting Works for where DNS sits in the stack.

Pointing a domain at a server

Two distinct knobs - know which one you are turning:

  1. Set the nameservers (at the registrar) - decides which provider's panel answers DNS for the domain. Do this once when you choose where to host DNS.
  2. Set the records (in that provider's zone) - the actual A/AAAA/MX/etc. that point traffic at servers. Day-to-day edits happen here.

To point example.com at a server on 203.0.113.10:

@     IN  A     203.0.113.10      ; apex
www   IN  CNAME example.com.      ; www follows the apex

If the server is dual-stack, also add the AAAA. After the edit (and once the old TTL expires), the site resolves to the new box - then issue TLS for it, see HTTPS with Let's Encrypt, and configure the vhost in nginx.

Managing a zone: common tasks

Add a subdomain on a separate server:

shop  IN  A  203.0.113.40

Add the email DNS records (MX + the three TXT records) as shown in the example zone above, matching the values your mail host/control panel gives you.

Lower TTL before a migration - edit the record (or the zone $TTL) to 300, wait for the old TTL to expire, then migrate, then raise it back to 3600.

Bump the serial

On a self-managed BIND zone, every edit must increment the SOA serial (e.g. 2026060901 -> 2026060902, the YYYYMMDDnn convention) or secondary nameservers will not pick up the change. Hosted DNS panels do this for you.

Verify your work

Use dig and host (see Networking Basics for more on these tools):

# A record (IPv4) and its TTL
dig A example.com

# AAAA, MX, NS, and TXT in turn
dig AAAA example.com +short
dig MX   example.com +short
dig NS   example.com +short
dig TXT  example.com +short

# Ask a specific resolver to bypass your local cache while testing changes
dig @1.1.1.1 example.com +short

# Trace the full delegation path root -> TLD -> authoritative
dig +trace example.com

# Quick lookups with host
host -t MX example.com
host www.example.com

You are done when the A/AAAA records show your server's IP, dig +trace ends at your authoritative nameservers, and MX/TXT return the mail records you set.

Summary

  • A registrar leases you the domain; the nameservers you set there delegate DNS to whichever provider hosts your zone. Registration and DNS hosting are separate.
  • Resolution walks recursive resolver -> root -> TLD -> authoritative, and answers are cached for the TTL. "Propagation" is just caches expiring - lower the TTL before a migration.
  • Core records: A/AAAA (addresses), CNAME (alias), MX (mail), TXT (incl. SPF/DKIM/DMARC), NS (delegation), SRV (services), CAA (cert issuance).
  • Pointing a domain = set nameservers at the registrar (once), then set records in the zone (ongoing). A CNAME cannot sit on the apex; MX points to hostnames.
  • Verify everything with dig (including +trace and @resolver) and host.

Test yourself