Getting Started

This page walks through the actual workflow: register a domain, point it at an authoritative DNS provider, add the records you need, and verify with dig.

Register a Domain

Two transactions, often at the same place but conceptually separate:

Registrar — sells you the domain name (Namecheap, Porkbun, Cloudflare Registrar, AWS Registrar...).
Authoritative DNS provider — answers DNS queries for that domain (often a different service from the registrar).

Cloudflare Registrar sells at cost (no markup). Porkbun's prices are competitive. Avoid GoDaddy unless you have an existing relationship; the upsells are aggressive.

Point the Domain at Your DNS Provider

The registrar lets you set the nameservers (NS records) for your domain. Set them to your chosen DNS provider:

example.com   NS   ns1.cloudflare.com
example.com   NS   ns2.cloudflare.com

This change can take 24-48h to propagate fully (registry-level changes). Once it does, your DNS provider is authoritative.

Add the Basic Records

A typical web app needs:

# Apex (root) record — A or ALIAS to your CDN/LB
example.com           A      203.0.113.10
example.com           AAAA   2001:db8::1

# www subdomain
www.example.com       CNAME  example.com.

# Mail
example.com           MX     10  inbound-mail.example.com.
example.com           TXT    "v=spf1 include:_spf.google.com ~all"

# Domain verification
example.com           TXT    "google-site-verification=abc..."

# Certificate authority authorization
example.com           CAA    0 issue "letsencrypt.org"
example.com           CAA    0 issue "amazon.com"

# Service-specific
api.example.com       A      203.0.113.20
*.staging.example.com CNAME  staging.example.com.

A Note on Apex Records

You can't put a CNAME on the apex (example.com itself), per DNS spec. Two workarounds:

A record pointing at a stable IP — fine if your CDN gives you one.
ALIAS / ANAME / flattened CNAME — provider-specific synthetic record (Cloudflare, Route 53, NS1 all support some form). The DNS provider resolves the CNAME target itself and returns A/AAAA records.

Cloudflare's free flattening at apex is one of the reasons they're popular.

Inspect with dig

dig is the standard tool for DNS lookups:

# What A record does example.com return?
dig example.com A +short
# 93.184.216.34

# Full answer including TTL
dig example.com A
# ;; ANSWER SECTION:
# example.com.    3565    IN    A    93.184.216.34

# Ask a specific resolver (bypass your default)
dig @1.1.1.1 example.com

# Trace the lookup from root
dig +trace example.com

# Reverse lookup
dig -x 93.184.216.34

# What nameservers does the domain use?
dig example.com NS +short

# MX records (mail)
dig example.com MX +short

# All record types you can think of
dig example.com ANY

The most useful flag: +short for parseable output, drop it for the full diagnostic view.

Propagation: What's Actually Happening

When you change a record, you're updating it at the authoritative server. The change is immediate there. But recursive resolvers globally still hold the old answer until their cached TTL expires.

A change with TTL 3600 takes up to 1 hour to propagate to most users. Some misbehaving resolvers ignore TTL and cache longer; a long tail can persist for days.

Lower TTLs before a planned change:

Day -3:  set TTL to 300 (5 min)
Day -2:  wait — by now caches everywhere honor 5-min TTL
Day 0:   make the change
Day +1:  raise TTL back to 3600

Tools to verify propagation:

dig @8.8.8.8 example.com — query a specific recursive
dnschecker.org — check from 30+ resolvers worldwide
intodns.com — full health check

Subdomain Delegation

You can give a third party authority over part of your zone:

# In your zone
status.example.com    NS    ns1.statuspage.io.
status.example.com    NS    ns2.statuspage.io.

Now queries for status.example.com are answered by Statuspage's nameservers, not yours. Useful when a SaaS provider needs full control of records under that subdomain.

Wildcards

*.app.example.com    A    203.0.113.30

Any subdomain of app.example.com that's not explicitly defined gets 203.0.113.30. Useful for per-tenant subdomains, dev preview environments.

Beware: a wildcard catches everything, including typos. noexist.app.example.com also resolves. Combine with checks at the HTTP layer.

Common First Day Records

# A / AAAA — IPv4 / IPv6 address
@                    A      203.0.113.10     TTL 300
@                    AAAA   2001:db8::1      TTL 300

# CNAME — alias another hostname
www                  CNAME  example.com.     TTL 300

# MX — mail routing (priority + host)
@                    MX     10 mail.example.com.  TTL 3600

# TXT — arbitrary text; SPF, DKIM, domain verification
@                    TXT    "v=spf1 include:_spf.google.com -all"

# CAA — which CAs can issue certs for your domain
@                    CAA    0 issue "letsencrypt.org"

# SRV — service discovery (e.g. SIP, XMPP)
_sip._tcp            SRV    0 5 5060 sipserver.example.com.

# PTR — reverse DNS (set by IP owner, not you)

The next page covers each record type in detail.

What's Next

You can register a domain and configure DNS competently. Next:

Records & Zones — every record type, apex CNAME flattening, delegation, DNSSEC
Best Practices — TTL strategy, redundancy, monitoring, pitfalls

Getting Started

On this page