DNS Records Explained: A, AAAA, CNAME, MX, TXT, NS, PTR
DNS records are the entries in a zone file that tell the internet where your domain's website, mail, and other services live. To point a domain at your server, create an A record (IPv4) and an AAAA record (IPv6) that contain the server's IP address, then wait for the old TTL to expire.
This guide covers the seven record types you will use most: A, AAAA, CNAME, MX, TXT, NS, and PTR. It also explains TTL, why "propagation" is mostly caching, and the mistakes that cause most DNS outages. All example addresses use documentation ranges (192.0.2.0/24, 2001:db8::/32), so replace them with your own.
How DNS Resolution Works in 60 Seconds
A resolver (your ISP's, or 1.1.1.1, 8.8.8.8) asks the root servers who handles .com. It then asks the .com servers which name servers handle example.com. Finally it asks those authoritative name servers for the record you want. The answer is cached for the number of seconds in the record's TTL.
Two places matter:
- Registrar: holds the NS delegation for your domain (and glue records if your name servers are inside your own domain).
- Authoritative DNS host: holds the zone with all your other records. This can be your registrar, a DNS provider, or your own BIND/PowerDNS/Knot server.
Records only take effect if they are created at the DNS host that your NS records actually point to. Editing a zone at a provider that is not delegated does nothing. This is the most common beginner mistake.
The Core Record Types
A record: domain to IPv4
Maps a name to an IPv4 address.
example.com. 3600 IN A 192.0.2.10
www.example.com. 3600 IN A 192.0.2.10
AAAA record: domain to IPv6
Same as A, but for IPv6. If you publish an AAAA record, the service must actually listen on that IPv6 address. Browsers prefer IPv6 when it is available, so a broken AAAA record produces slow or failing connections for part of your audience.
example.com. 3600 IN AAAA 2001:db8:10::10
CNAME record: alias to another name
Says "this name is an alias for that name." The resolver then looks up the target.
blog.example.com. 3600 IN CNAME www.example.com.
Rules to remember:
- A CNAME cannot coexist with any other record at the same name. That means no CNAME at the zone apex (
example.com), because the apex must have SOA and NS records. - Do not point an MX or NS record at a CNAME. Mail servers and resolvers may reject it.
- Chains of CNAMEs add lookup latency. Keep them short.
MX record: where mail goes
Tells other mail servers where to deliver mail for your domain. The number is the priority (lower is tried first), and the target must be a hostname with an A/AAAA record, not an IP and not a CNAME.
example.com. 3600 IN MX 10 mail.example.com.
example.com. 3600 IN MX 20 mail2.example.com.
mail.example.com. 3600 IN A 192.0.2.25
TXT record: free-form text, used for policy
TXT records carry verification strings and email authentication policy.
example.com. 3600 IN TXT "v=spf1 ip4:192.0.2.25 -all"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
Common uses are SPF, DKIM public keys (at selector._domainkey), DMARC, and domain ownership verification for third-party services. Publish only one SPF record per name. Two v=spf1 records cause a permanent error. A single TXT string is limited to 255 characters, so long DKIM keys are split into multiple quoted strings within one record.
NS record: who is authoritative
Lists the name servers for a zone.
example.com. 86400 IN NS ns1.example.net.
example.com. 86400 IN NS ns2.example.net.
Always use at least two name servers on separate networks. If a name server lives inside the domain it serves (for example ns1.example.com), you must also create glue records at the registrar. Otherwise there is a circular dependency and resolution fails.
PTR record: IP back to name (reverse DNS)
PTR is the reverse of an A record. It lives in the special in-addr.arpa (IPv4) or ip6.arpa (IPv6) tree.
25.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.com.
You do not create PTR records in your domain's zone. The reverse zone belongs to whoever controls the IP block, which is usually your hosting provider or the owner of the IP space. If you rent a VDS, your provider sets or delegates the PTR. If you announce your own block, you can ask your RIR or upstream to delegate the reverse zone to your own name servers.
For mail servers, the PTR should match the hostname in your SMTP greeting, and that hostname should resolve forward to the same IP (forward-confirmed reverse DNS). Many receivers penalize mail from IPs without it.
Point a Domain to Your Server: Step by Step
Assume your server is 192.0.2.10 with IPv6 2001:db8:10::10.
- Confirm the delegation. Check which name servers the world sees:
dig NS example.com +shortEdit the zone at the provider those servers belong to. - Lower the TTL in advance if you are migrating an existing site (see below).
- Create the records:
example.com. 300 IN A 192.0.2.10 www.example.com. 300 IN CNAME example.com. example.com. 300 IN AAAA 2001:db8:10::10 - Verify at the authoritative server, bypassing caches:
dig @ns1.example.net example.com A +norecurse - Verify through a public resolver:
dig @1.1.1.1 example.com A +short dig @8.8.8.8 example.com AAAA +short - Test the service itself, even before DNS is updated, by forcing the IP:
curl -I --resolve example.com:443:192.0.2.10 https://example.com/ - Set up reverse DNS if the server sends mail, and make sure the web server has a virtual host (and TLS certificate) for the name.
TTL: What It Controls
TTL (time to live) is the number of seconds a resolver may cache an answer. It is the main lever you have over how fast changes spread.
| Situation | Suggested TTL |
|---|---|
| Stable records (MX, NS, TXT) | 3600 to 86400 |
| Normal web A/AAAA records | 1800 to 3600 |
| Before a planned migration | 300 |
| Failover records you change often | 60 to 300 |
Very low TTLs increase query volume and make you more dependent on your DNS host's uptime. Very high TTLs make mistakes last longer. A practical approach is to keep 3600 normally, drop to 300 at least one full old-TTL period before a change, then raise it again after things are stable.
Why "DNS Propagation" Is Really Caching
DNS does not push changes around the world. Authoritative servers answer with the new data immediately. What delays you is that resolvers and applications are holding the old answer until its TTL runs out.
Typical delays:
- Record change on same name: up to the old TTL. If it was 3600, expect up to an hour.
- New record that never existed: usually visible fast, but a previously cached "does not exist" answer (negative caching) can persist. Its duration is controlled by the SOA minimum/negative TTL field.
- NS change at the registrar: parent-zone NS and glue records often have TTLs of 24 to 48 hours, so full cutover can take that long.
- Local caches: browsers, operating systems, and some applications (Java is a known one) can cache beyond the TTL. Flush with
resolvectl flush-cacheson systemd-resolved,ipconfig /flushdnson Windows, or restart the browser.
Check the remaining TTL on a resolver by running the same query twice and watching the number count down:
dig @1.1.1.1 example.com A
Common Mistakes and Fixes
- Editing the wrong zone. Run
dig NSfirst. Fix the zone at the delegated provider or update NS at the registrar. - CNAME at the apex. Use an A/AAAA record instead, or an ALIAS/ANAME feature if your DNS host provides one (it is not standard DNS).
- MX pointing to an IP or CNAME. Point MX to a hostname with its own A/AAAA record.
- Missing trailing dot in a zone file.
mail.example.comwithout the dot becomesmail.example.com.example.com.. Use the full name with a dot, or a relative name. - Stale AAAA record. You moved IPv4 but forgot IPv6. Update or delete both.
- Multiple SPF records. Merge them into one.
- Lame delegation. One NS record points to a server that does not answer for the zone. Check each name server separately with
dig @nsX ... SOA. - Expecting instant changes with a 24-hour TTL. Plan ahead and lower the TTL first.
- No reverse DNS on a mail server. Request a PTR from the IP owner.
Quick Diagnostic Commands
dig example.com ANY +noall +answer # many servers limit ANY; query types individually
dig example.com MX +short
dig example.com TXT +short
dig -x 192.0.2.25 +short # PTR lookup
dig example.com +trace # follow delegation from the root
dig +trace is the best first step when something "does not resolve," because it shows exactly where the chain breaks.
Where Your Server and Network Fit In
DNS only tells clients where to connect. The server behind that IP still has to be reachable, correctly configured, and protected. If you are hosting a site, mail server, or game server on a BGP-enabled VDS, you can run your own authoritative DNS on separate hosts for redundancy, and use your own IP space for forward and reverse records if you announce it with your ASN. For public-facing services that attract attacks, remember that DNS records reveal your origin IP, so consider placing it behind DDoS protection and a firewall before you publish it.
Whatever setup you choose, keep a copy of your zone file in version control, use at least two name servers on different networks, and test changes with dig against the authoritative servers before and after you make them.
Frequently asked questions
How long does DNS propagation take?
It depends mainly on the old TTL. If the previous record had a TTL of 3600 seconds, most resolvers pick up the change within an hour. Changing NS records at the registrar can take 24 to 48 hours because of parent-zone caching.
Can I use a CNAME record on the root domain?
No. A CNAME cannot coexist with the SOA and NS records that must exist at the zone apex. Use A and AAAA records at the root, or an ALIAS/ANAME feature if your DNS provider offers it.
Who controls the PTR record for my server's IP?
The owner of the IP block, usually your hosting provider or the organization that holds the address space. You request it from them, or if you have your own block, you can have the reverse zone delegated to your own name servers.
What TTL should I use for my DNS records?
Use 3600 seconds for most records. Lower it to 300 at least one old-TTL period before a planned migration, then raise it again once the change is stable.