DNS (Domain Name System) is the service that translates example.com into an IP address your browser can connect to. Every developer knows this much. What's less well understood is the full set of DNS record types, what each one does, and when you'd actually use one over another.
This guide covers every record type you'll encounter as a working developer, with practical examples.
How DNS Works (The Short Version)
When you type example.com into a browser:
- Your computer asks a recursive resolver (usually your ISP's DNS server or a public one like
1.1.1.1) - The resolver asks a root nameserver where
.comrecords live - The resolver asks the
.comTLD nameserver which nameserver is authoritative forexample.com - The resolver asks the authoritative nameserver for
example.comfor its records - The authoritative nameserver returns the answer
- Your browser connects to the IP in the answer
All of this happens in under 100ms, usually under 10ms if the answer is cached.
The records we're about to cover are what the authoritative nameserver stores and returns.
A Record: The Foundation
An A record maps a domain to an IPv4 address. This is the most fundamental DNS record.
example.com. A 93.184.216.34
When your browser requests example.com, it gets 93.184.216.34 back from DNS and connects there.
When to use it: Any time you need a domain to resolve to a specific server. Setting up a VPS for a project? Create an A record.
TTL matters here. TTL (Time to Live) controls how long resolvers cache the answer. High TTL = faster resolution (from cache), slower propagation when you change the IP. Low TTL = slower resolution, faster propagation. Changing a record with a 24-hour TTL will take up to 24 hours to propagate globally. Reduce TTL before a planned migration.
DomainDock creates A records automatically on Cloudflare when you add a domain. Because Cloudflare's API is used directly, propagation typically takes 30–60 seconds rather than hours.
AAAA Record: IPv6
Identical to an A record, but for IPv6 addresses.
example.com. AAAA 2606:2800:220:1:248:1893:25c8:1946
If your server has an IPv6 address and you want clients with IPv6 connectivity to use it (generally faster), add an AAAA record. Modern hosting platforms typically give you both an IPv4 and IPv6 address.
When to use it: Always add it if you have an IPv6 address. Browsers prefer IPv6 when available (Happy Eyeballs algorithm).
CNAME Record: Canonical Name (Alias)
A CNAME maps one domain name to another domain name instead of an IP address.
www.example.com. CNAME example.com.
When a resolver looks up www.example.com, it gets back example.com and then resolves that to an IP. The final answer is the same IP as example.com, but the indirection layer lets you change the underlying IP in one place.
Important restrictions:
- A CNAME cannot coexist with other records at the same domain.
example.comcan't have both a CNAME and an MX record. (This is why you can't CNAME your root domain to a CDN; use a flattened CNAME/"ALIAS" record instead, which Cloudflare supports.) - CNAMEs can chain, but circular chains (A → B → A) break resolution.
When to use it: Pointing a domain alias to another domain. www.example.com → example.com. cdn.example.com → yourcdn.provider.com.
Not for root domains. example.com can't be a CNAME because it needs to have MX records for email. Use an ALIAS record or a CDN's CNAME flattening feature (Cloudflare calls this "CNAME flattening").
TXT Record: Text and Verification
TXT records store arbitrary text strings. Originally designed for human-readable information, they became the standard way to prove domain ownership and configure email security.
example.com. TXT "v=spf1 include:_spf.google.com ~all"
Common TXT record uses:
Domain verification: Google, GitHub, Stripe, Cloudflare, and countless other services ask you to add a TXT record to prove you control a domain. You add the specific string they give you; their verification system checks for it.
SPF (Sender Policy Framework): Specifies which mail servers are allowed to send email for your domain. Helps prevent spoofing.
example.com. TXT "v=spf1 ip4:1.2.3.4 include:sendgrid.net -all"
DKIM (DomainKeys Identified Mail): Your mail server signs outgoing emails with a private key. The public key is published in a TXT record. Receiving servers use it to verify signatures.
mail._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0..."
DMARC: Policy that tells receiving servers what to do when SPF and DKIM fail (quarantine, reject, or do nothing) and where to send reports.
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
Let's Encrypt DNS-01 challenge: When issuing wildcard SSL certificates, Let's Encrypt requires a TXT record at _acme-challenge.example.com to prove domain ownership. Traefik automates this using the Cloudflare API.
MX Record: Mail Exchanger
MX records specify which mail servers handle email for a domain. They contain a priority value and a hostname (not an IP; MX records must point to A records).
example.com. MX 10 mail1.example.com.
example.com. MX 20 mail2.example.com.
Lower priority number = higher priority. mail1 is tried first; if it's unreachable, senders fall back to mail2.
When to use it: When you're setting up email for a domain. Most developers use Google Workspace, Fastmail, or similar; the provider gives you specific MX records to add.
No MX records = no email. If you have an A record for your domain but no MX records, email sent to you will bounce.
NS Record: Nameserver
NS records specify the authoritative nameservers for a domain. These are set at your domain registrar, not in your DNS zone itself.
example.com. NS ns1.cloudflare.com.
example.com. NS ns2.cloudflare.com.
When you transfer a domain to Cloudflare, you change your registrar's NS records to point to Cloudflare's nameservers. From that point, Cloudflare is authoritative; all DNS changes go through Cloudflare.
You don't manage NS records day-to-day. They're set once when you set up DNS hosting. The only time you change them is when switching DNS providers.
SOA Record: Start of Authority
The SOA record contains administrative information about a DNS zone: the primary nameserver, the email of the zone administrator (encoded as a domain), and various timing parameters.
example.com. SOA ns1.cloudflare.com. dns.cloudflare.com. 2024052601 10800 3600 604800 3600
The fields are: primary NS, admin email, serial number, refresh, retry, expire, minimum TTL.
You almost never manage this directly. DNS hosting providers create and update it automatically. The serial number is important; secondary nameservers use it to detect zone changes.
SRV Record: Service Locator
SRV records specify the host and port for a specific service, protocol, and domain. Format:
_service._proto.example.com. SRV priority weight port target
Example for SIP (VoIP):
_sip._tcp.example.com. SRV 10 60 5060 sip.example.com.
When to use it: SRV records are mostly found in corporate environments (SIP for VoIP, XMPP for messaging, sometimes internal service discovery). Web developers rarely interact with them directly, but if you're setting up internal microservices with DNS-based discovery, they're worth knowing.
PTR Record: Reverse DNS
PTR records are the reverse of A records: they map an IP address to a domain name. They live in the special in-addr.arpa. zone.
34.216.184.93.in-addr.arpa. PTR example.com.
When to use it: Reverse DNS is important for email deliverability; many mail servers check whether the sending IP has a matching PTR record and that it matches the domain in the email headers. If you're self-hosting email, set a PTR record for your mail server's IP with your VPS provider.
CAA Record: Certificate Authority Authorization
CAA records restrict which Certificate Authorities are allowed to issue SSL certificates for a domain.
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild "letsencrypt.org"
If a rogue CA tries to issue a certificate for example.com, compliant CAs will check the CAA record first and refuse. This prevents certificate mis-issuance.
When to use it: If you use Let's Encrypt, add a CAA record allowing letsencrypt.org. If you don't add any CAA record, all CAs are allowed, which is fine for most projects, but large or security-conscious deployments should lock this down.
The Practical Hierarchy
When you set up a project, here's the typical order of DNS operations:
- A record: point the domain to your server IP
- CNAME: point
www(and other aliases) to the root domain - TXT records: verify domain ownership with any services you use
- MX records: if you need email
- CAA: if you want to restrict certificate issuance
- AAAA: if your server has IPv6
DomainDock handles step 1 automatically. When you create a domain in the dashboard, DomainDock calls the Cloudflare API and creates the A record pointed at your server. No manual DNS management needed.
Ready to put this knowledge to use? Create your first domain on DomainDock, free, no credit card.