DNS Record Types – Complete Reference Guide

1. What Is a DNS Record?

A DNS record is an entry in a DNS zone file — the authoritative database for a domain — that maps a hostname to data of a specific type. When a DNS resolver queries for www.example.com, the authoritative nameserver returns the relevant record(s) from its zone file.

Every DNS record follows the same basic structure:

; DNS Zone File Record Format:
; <name>       <TTL>    <class>  <type>  <rdata>
example.com.    3600     IN       A       93.184.216.34
www             300      IN       CNAME   example.com.
example.com.    3600     IN       MX      10 mail.example.com.

; name   = the hostname or domain this record applies to
;          "@" means the apex (root) of the zone itself
; TTL    = Time To Live in seconds — how long resolvers cache this answer
; class  = always IN (Internet) for modern DNS
; type   = the record type (A, MX, TXT, etc.)
; rdata  = the record data — varies by type

FQDN vs relative names in zone files: A name ending with a dot (example.com.) is a fully qualified domain name (FQDN) — absolute. A name without a trailing dot (www) is relative and the zone's origin is appended automatically, making it www.example.com.

2. Quick Reference — All DNS Record Types

Type	Full Name	Purpose	dig Command
A	Address	Maps hostname → IPv4 address	`dig example.com A`
AAAA	IPv6 Address	Maps hostname → IPv6 address	`dig example.com AAAA`
CNAME	Canonical Name	Alias — maps one hostname to another hostname	`dig www.example.com CNAME`
MX	Mail Exchange	Specifies mail servers for a domain with priority	`dig example.com MX`
TXT	Text	Arbitrary text — SPF, DKIM, DMARC, site verification	`dig example.com TXT`
NS	Name Server	Delegates a zone to authoritative nameservers	`dig example.com NS`
PTR	Pointer	Reverse DNS — maps IP address → hostname	`dig -x 93.184.216.34`
SOA	Start of Authority	Zone metadata — primary NS, serial, refresh/retry timers	`dig example.com SOA`
SRV	Service Locator	Locates services by protocol and port (SIP, XMPP, AD)	`dig _sip._tcp.example.com SRV`
CAA	Certification Authority Authorisation	Restricts which CAs can issue SSL/TLS certificates	`dig example.com CAA`
DNSKEY	DNS Key	DNSSEC public key for signature verification	`dig example.com DNSKEY`
RRSIG	Resource Record Signature	DNSSEC cryptographic signature over a record set	`dig example.com A +dnssec`
DS	Delegation Signer	DNSSEC chain of trust from parent to child zone	`dig example.com DS`
NAPTR	Name Authority Pointer	Used in VoIP (SIP/ENUM) for phone number mapping	`dig example.com NAPTR`
ANY	All types	Request all record types (many servers restrict this)	`dig example.com ANY`

3. A Record — IPv4 Address Mapping

The A record (Address record) is the most fundamental DNS record type. It maps a fully qualified domain name to a 32-bit IPv4 address, enabling clients to find the IP of any named internet service.

; Zone file syntax:
; <name>           TTL    IN   A     <IPv4 address>
example.com.        3600   IN   A     93.184.216.34
www.example.com.    300    IN   A     93.184.216.34
mail.example.com.   3600   IN   A     93.184.216.40
api.example.com.    60     IN   A     93.184.216.50

; Multiple A records for the same name = round-robin load balancing
google.com.         60     IN   A     142.250.183.14
google.com.         60     IN   A     142.250.183.46
google.com.         60     IN   A     142.250.183.78

! Query with dig:
$ dig example.com A       ! or just: dig example.com
;; ANSWER SECTION:
example.com.  3600  IN  A  93.184.216.34

! Query with nslookup:
C:\> nslookup example.com
Name:    example.com
Address: 93.184.216.34

Key A Record Facts

Aspect	Detail
Address format	Dotted-decimal IPv4: 0.0.0.0 to 255.255.255.255
Multiple records	Multiple A records for the same name create round-robin load distribution. DNS returns all IPs; the client typically uses the first.
TTL impact	Short TTL (60s) = fast failover / CDN flexibility. Long TTL (86400s) = low query load but slow propagation on changes.
Apex domain	The bare domain (example.com without www) must use an A record directly — cannot use a CNAME at the apex.

4. AAAA Record — IPv6 Address Mapping

The AAAA record (Quad-A record) maps a hostname to a 128-bit IPv6 address. It is the IPv6 equivalent of the A record. Modern operating systems query for both A and AAAA simultaneously (Happy Eyeballs / RFC 6555) and use whichever responds first, preferring IPv6 when available.

; Zone file syntax:
example.com.     3600  IN  AAAA  2606:2800:220:1:248:1893:25c8:1946
www.example.com. 300   IN  AAAA  2606:2800:220:1:248:1893:25c8:1946

! Query:
$ dig example.com AAAA
;; ANSWER SECTION:
example.com.  3598  IN  AAAA  2606:2800:220:1:248:1893:25c8:1946

Dual-stack DNS: Most modern domains publish both A and AAAA records for the same hostname. Browsers and OS resolvers use Happy Eyeballs — they race IPv4 and IPv6 connections and use whichever connects faster. If no AAAA record exists for a domain, the client falls back to IPv4 transparently. A domain can have an A record without an AAAA record — this is common for services not yet IPv6-enabled.

5. CNAME Record — Canonical Name (Alias)

A CNAME record (Canonical Name) creates an alias — it maps one hostname to another hostname rather than directly to an IP address. The resolver follows the chain until it reaches a final A or AAAA record.

; Zone file syntax:
; <alias>          TTL   IN   CNAME  <canonical hostname>
www.example.com.    300   IN   CNAME  example.com.
ftp.example.com.    300   IN   CNAME  example.com.
blog.example.com.   300   IN   CNAME  mysite.wordpress.com.

; CDN use case — CNAME points to CDN edge hostname:
www.example.com.    300   IN   CNAME  example.cdn.cloudflare.net.

! Resolution chain:
! www.example.com → CNAME → example.com → A → 93.184.216.34

! dig shows the full chain:
$ dig www.example.com
;; ANSWER SECTION:
www.example.com.  300   IN  CNAME  example.com.
example.com.     3600   IN  A      93.184.216.34

Critical CNAME Restrictions

Rule	Explanation
Cannot exist at the apex domain	You cannot have a CNAME for `example.com.` (the bare domain with no subdomain). The apex must use an A or AAAA record directly. Some DNS providers (Cloudflare, Route 53) offer "CNAME flattening" or "ALIAS" pseudo-records that resolve this at query time.
Cannot coexist with other record types	A name that has a CNAME cannot also have an MX, TXT, or other record. If `www` is a CNAME, it cannot also have an MX record.
Chains are valid but should be short	CNAME → CNAME → A is valid but each hop adds a DNS lookup. Long chains increase resolution time. Maximum practical depth: 2–3 hops.
The target must resolve	A CNAME pointing to a hostname with no A/AAAA record results in NOERROR with an empty ANSWER — the original name resolves but the final target has no IP.

6. MX Record — Mail Exchange

MX records specify which mail servers accept email for a domain. When an SMTP server delivers email to [email protected], it first queries DNS for example.com's MX records, then connects to the returned mail server hostnames.

; Zone file syntax:
; <domain>      TTL   IN  MX   <priority>  <mail server hostname>
example.com.     3600  IN  MX   10  mail1.example.com.
example.com.     3600  IN  MX   20  mail2.example.com.
example.com.     3600  IN  MX   30  mail3.example.com.

; Each mail server hostname must also have an A record:
mail1.example.com.  3600  IN  A  93.184.216.40
mail2.example.com.  3600  IN  A  93.184.216.41

; Real-world example — Gmail's MX records:
gmail.com.  3599  IN  MX  5   gmail-smtp-in.l.google.com.
gmail.com.  3599  IN  MX  10  alt1.gmail-smtp-in.l.google.com.
gmail.com.  3599  IN  MX  20  alt2.gmail-smtp-in.l.google.com.
gmail.com.  3599  IN  MX  30  alt3.gmail-smtp-in.l.google.com.
gmail.com.  3599  IN  MX  40  alt4.gmail-smtp-in.l.google.com.

MX Priority Rules

Priority Value	Meaning	Behaviour
Lower number (e.g., 5)	Higher preference — tried first	Sending servers always attempt the lowest-priority-number server first
Higher number (e.g., 40)	Lower preference — fallback only	Only used if all lower-numbered servers are unreachable or return a temporary error (4xx)
Equal numbers (e.g., 10 and 10)	Same preference — load balancing	Sending servers randomly select between equal-priority entries, distributing load

Critical MX rules: MX records must point to a hostname (A record), never directly to an IP address. The MX target must have its own A/AAAA record. MX cannot point to a CNAME — the RFC explicitly prohibits this, although some implementations tolerate it. If no MX record exists for a domain, sending servers fall back to the domain's A record as the mail server.

7. TXT Record — Text (SPF, DKIM, DMARC, Verification)

TXT records hold arbitrary text data. Originally designed for human-readable information, they are now critical infrastructure for email authentication, domain ownership verification, and security policies.

; Zone file syntax:
; <name>       TTL   IN  TXT  "<text string>"
example.com.    3600  IN  TXT  "v=spf1 include:_spf.google.com ~all"
example.com.    3600  IN  TXT  "google-site-verification=abc123xyz"

TXT Record Use Cases

Use Case	Format	Purpose
SPF (Sender Policy Framework)	`"v=spf1 include:_spf.google.com ~all"`	Lists IP addresses and servers authorised to send email for the domain. Receiving servers check SPF to verify the sender is legitimate.
DKIM (DomainKeys Identified Mail)	`selector._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0..."`	Publishes the public key that receiving servers use to verify the cryptographic signature on outgoing emails. Confirms the email body hasn't been modified in transit.
DMARC (Domain-based Message Authentication)	`_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"`	Defines what to do when SPF/DKIM checks fail: none (monitor), quarantine (spam folder), or reject. Also specifies where to send aggregate reports.
Domain verification	`"google-site-verification=abc123"`	Google, Microsoft, and other services require adding a specific TXT record to prove you control the domain before granting access to their services.
BIMI (Brand Indicators for Message Identification)	`default._bimi.example.com TXT "v=BIMI1; l=https://...logo.svg"`	Associates a brand logo with authenticated email — displayed in email clients that support BIMI (Gmail, Apple Mail, Yahoo).

SPF Mechanisms Reference

; Full SPF TXT record example with common mechanisms:
example.com.  IN  TXT  "v=spf1 ip4:203.0.113.0/24 include:_spf.google.com a mx ~all"

; v=spf1         = SPF version — must always be present first
; ip4:x.x.x.x/nn = Authorise specific IPv4 range to send email
; ip6:            = Authorise IPv6 range
; include:domain  = Also check SPF of this other domain (e.g., your ESP)
; a               = Authorise the IP(s) in the domain's A record
; mx              = Authorise the IP(s) in the domain's MX records
; ~all            = Soft fail — mark as spam if no mechanism matched
; -all            = Hard fail — reject if no mechanism matched (strictest)
; ?all            = Neutral — no policy (essentially no SPF enforcement)

8. NS Record — Name Server

NS records identify the authoritative nameservers for a domain or zone. They are the delegation mechanism of DNS — the TLD nameservers hold NS records for every registered domain, telling the world which nameservers are authoritative for that domain's DNS zone.

; Zone file syntax:
; <domain>      TTL    IN   NS   <nameserver hostname>
example.com.     86400  IN   NS   ns1.example.com.
example.com.     86400  IN   NS   ns2.example.com.

; The NS records are also held at the TLD level (com.) pointing to the same servers:
; This is the delegation — without it, no one can find the zone

; Glue records — A records for the NS hostnames (needed when NS is IN the zone)
; These must be provided to the TLD servers to avoid a circular lookup:
ns1.example.com.  86400  IN  A  198.51.100.1
ns2.example.com.  86400  IN  A  198.51.100.2

Glue records explained: If your nameserver is ns1.example.com and you need to look up example.com, you need to know ns1.example.com's IP first — but that IP is in the example.com zone, which you can't get without knowing ns1's IP. This circular dependency is broken by glue records — the parent TLD zone also stores the A records for the NS hostnames, allowing the chain to resolve.

! Query NS records:
$ dig example.com NS
;; ANSWER SECTION:
example.com.  86400  IN  NS  ns1.example.com.
example.com.  86400  IN  NS  ns2.example.com.

;; ADDITIONAL SECTION:   ← Glue records
ns1.example.com.  86400  IN  A  198.51.100.1
ns2.example.com.  86400  IN  A  198.51.100.2

9. PTR Record — Pointer (Reverse DNS)

PTR records are the inverse of A records — they map an IP address back to a hostname. They live in special reverse DNS zones under .in-addr.arpa. (IPv4) or .ip6.arpa. (IPv6), not in the domain's forward zone.

; PTR records live in the reverse zone, NOT the domain's forward zone
; IPv4 reverse zone: octets reversed + .in-addr.arpa.
; For IP 93.184.216.34 → reverse zone: 216.184.93.in-addr.arpa.

; Zone file for 216.184.93.in-addr.arpa.:
34   86400  IN  PTR  example.com.

; This means: 93.184.216.34 → example.com

; Real-world examples (Google DNS):
8.8.8.8.in-addr.arpa.    86399  IN  PTR  dns.google.
8.8.4.4.in-addr.arpa.    21599  IN  PTR  dns.google.

! Query reverse DNS:
$ dig -x 8.8.8.8
;; QUESTION SECTION:
;8.8.8.8.in-addr.arpa.    IN   PTR

;; ANSWER SECTION:
8.8.8.8.in-addr.arpa.  86399  IN  PTR  dns.google.

Who controls PTR records? PTR records must be created by the owner of the IP address block — the ISP or hosting provider — not the domain owner. If your mail server is at 198.51.100.25 (owned by your ISP), you must ask your ISP to set a PTR record for that IP. A missing PTR record for a mail server IP is one of the most common causes of email being rejected or marked as spam.

10. SOA Record — Start of Authority

The SOA record (Start of Authority) is mandatory in every DNS zone. It identifies the primary authoritative nameserver for the zone and contains timing parameters that control how secondary nameservers synchronise with the primary and how resolvers handle negative responses.

; SOA record syntax:
; <zone>   TTL   IN  SOA  <primary NS>  <admin email>  (
;                                                          serial
;                                                          refresh
;                                                          retry
;                                                          expire
;                                                          negative TTL )

example.com.  3600  IN  SOA  ns1.example.com.  admin.example.com. (
                               2024041501   ; Serial   — zone version number
                               7200         ; Refresh  — how often secondaries check for updates (secs)
                               3600         ; Retry    — how long to wait before retrying failed refresh
                               1209600      ; Expire   — after this many seconds, secondary stops serving
                               3600         ; Negative TTL — how long to cache NXDOMAIN responses
                             )

SOA Field Explanations

Field	Typical Value	Meaning
Serial	2024041501	Zone version number — must be incremented every time the zone is changed. Secondary nameservers compare their serial to the primary; if the primary's serial is higher, they initiate a zone transfer. Common format: YYYYMMDDNN (date + daily change sequence number).
Refresh	7200 (2 hours)	How often (in seconds) secondary nameservers poll the primary to check if the serial has changed.
Retry	3600 (1 hour)	If the secondary's refresh attempt fails (primary unreachable), how long to wait before retrying.
Expire	1209600 (14 days)	If the secondary cannot contact the primary for this long, it stops serving the zone entirely — preventing stale data from being authoritative.
Negative TTL	3600 (1 hour)	How long resolvers cache negative answers (NXDOMAIN responses). Defined in RFC 2308. Prevents repeated queries for non-existent names.
Admin email	admin.example.com.	The zone administrator's email address — the first `.` replaces the `@`. So `admin.example.com.` means `[email protected]`.

11. SRV Record — Service Locator

SRV records allow a domain to publish the location (hostname and port) of specific network services. They are essential for VoIP, instant messaging, Microsoft Active Directory, and other services where clients need to discover the correct server and port programmatically without hardcoding them.

; SRV record syntax:
; _<service>._<protocol>.<domain>  TTL  IN  SRV  <priority>  <weight>  <port>  <hostname>

; SIP over TCP:
_sip._tcp.example.com.      3600  IN  SRV  10  20  5060  sip1.example.com.
_sip._tcp.example.com.      3600  IN  SRV  20  10  5060  sip2.example.com.

; Microsoft Active Directory (LDAP, Kerberos):
_ldap._tcp.example.com.     600   IN  SRV  0   100  389   dc1.example.com.
_kerberos._tcp.example.com. 600   IN  SRV  0   100  88    dc1.example.com.

; XMPP (Jabber instant messaging):
_xmpp-client._tcp.example.com.  3600  IN  SRV  5  0  5222  xmpp.example.com.

SRV Field Reference

Field	Description
Service	Standardised service name, prefixed with underscore: `_sip`, `_ldap`, `_http`, `_xmpp-client`
Protocol	`_tcp` or `_udp`
Priority	Lower value = higher preference (same logic as MX). Clients try lower priority first, fall back on failure.
Weight	Load distribution among equal-priority records. Higher weight = more traffic. Weight 0 = no preference.
Port	TCP/UDP port number the service listens on. This allows non-standard ports without client configuration.
Target	Fully qualified hostname of the server. Must have its own A/AAAA record. A single dot (`.`) means the service is not available.

12. CAA Record — Certification Authority Authorisation

CAA records specify which Certificate Authorities (CAs) are permitted to issue SSL/TLS certificates for a domain. CAs are required (by the CA/Browser Forum) to check for CAA records before issuing a certificate. If a CA is not listed, it must refuse to issue.

; Zone file syntax:
; <domain>  TTL  IN  CAA  <flag>  <tag>  "<value>"

; Allow only Let's Encrypt to issue certificates:
example.com.  3600  IN  CAA  0  issue  "letsencrypt.org"

; Allow Let's Encrypt AND DigiCert:
example.com.  3600  IN  CAA  0  issue  "letsencrypt.org"
example.com.  3600  IN  CAA  0  issue  "digicert.com"

; Allow wildcard certificates from one specific CA:
example.com.  3600  IN  CAA  0  issuewild  "sectigo.com"

; Prohibit all CAs from issuing (no CA listed at all):
example.com.  3600  IN  CAA  0  issue  ";"

; Notification email for policy violations:
example.com.  3600  IN  CAA  0  iodef  "mailto:[email protected]"

Why CAA matters: Without CAA records, any of the hundreds of trusted CAs worldwide could issue a certificate for your domain. A rogue or compromised CA could issue a fraudulent certificate enabling man-in-the-middle attacks. CAA records limit this attack surface — only the CAs you explicitly allow can issue. Verify your CAA records with: dig example.com CAA.

13. DNSSEC Records — DNSKEY, RRSIG, DS, NSEC

DNSSEC (DNS Security Extensions) adds cryptographic authentication to DNS responses, preventing cache poisoning and data tampering. It uses four additional record types that work together as a chain of trust.

Record Type	Purpose	Where It Lives
DNSKEY	Publishes the zone's public signing key. Resolvers use this to verify RRSIG signatures.	In the zone being signed
RRSIG	A cryptographic signature over a specific record set. Every signed record set has a corresponding RRSIG.	Alongside every signed record in the zone
DS (Delegation Signer)	A hash of the child zone's DNSKEY, stored in the parent zone. Creates the chain of trust from parent to child (e.g., .com has DS for example.com).	In the parent zone
NSEC / NSEC3	Authenticated denial of existence — proves that a requested name or type does not exist. Prevents attackers from injecting fake NXDOMAIN responses. NSEC3 adds hashing to prevent zone enumeration.	In the zone being signed

! Query DNSSEC records:
$ dig example.com +dnssec A
;; ANSWER SECTION:
example.com.  3600  IN  A      93.184.216.34
example.com.  3600  IN  RRSIG  A 13 2 3600 20241101000000 ...

! The "ad" flag in the header means the resolver validated DNSSEC:
;; flags: qr rd ra ad;   ← "ad" = Authenticated Data

14. Common Misconceptions About DNS Records

"CNAME and A records do the same thing."
An A record maps directly to an IP address. A CNAME maps to another hostname which must itself be resolved. CNAME adds an extra lookup hop. A records are required at the apex domain — CNAMEs cannot be used there.
"MX records can point directly to an IP address."
The DNS specification (RFC 2821) requires MX records to point to a hostname, not an IP address. The hostname must have its own A/AAAA record. Similarly, MX records must not point to a CNAME target.
"Changing a DNS record takes effect immediately."
Changes are instant on the authoritative server but propagate based on the TTL. If the old record had TTL 86400 (24 hours), resolvers that cached it will continue returning the old value for up to 24 hours. Always lower TTL well before planned changes.
"You need separate TXT records for each email authentication method."
SPF, DKIM, and DMARC are actually stored at different DNS names. SPF is a TXT at the domain apex (example.com). DKIM uses a selector prefix (selector._domainkey.example.com). DMARC uses the _dmarc subdomain (_dmarc.example.com). They do not conflict with each other.
"NS records control which server hosts your website."
NS records only delegate DNS authority — they specify which servers are authoritative for your DNS zone. Website hosting is controlled by A/AAAA records. Changing NS records at your registrar transfers DNS management; it does not move your website.

15. Key Points & Exam Tips

A = hostname → IPv4 (32-bit). AAAA = hostname → IPv6 (128-bit).
CNAME = alias → another hostname. Cannot exist at apex domain. Cannot coexist with other record types at the same name.
MX = mail servers + priority. Lower number = higher preference. Must point to a hostname (A record), never an IP or CNAME.
TXT = arbitrary text. Key uses: SPF (email sender policy), DKIM (email signing keys), DMARC (email policy), domain ownership verification.
NS = authoritative nameservers for a zone. Present at TLD level (delegation) and in the zone itself. Glue records needed when NS is within the zone.
PTR = IP → hostname (reverse DNS). Lives in .in-addr.arpa. (IPv4) or .ip6.arpa. (IPv6) zones. Managed by IP block owner (ISP), not domain owner.
SOA = one per zone. Contains: primary NS, admin email (dot instead of @), serial, refresh, retry, expire, negative TTL.
SOA serial must be incremented on every zone change for secondary nameservers to detect and sync the update.
SRV = service discovery by protocol and port. Format: _service._proto.domain SRV priority weight port hostname.
CAA = restricts which CAs can issue SSL/TLS certs for the domain. CAs must check and respect CAA before issuing.
DNSSEC records: DNSKEY (public signing key), RRSIG (signature), DS (parent trust anchor), NSEC/NSEC3 (authenticated denial of existence).
TTL on any record controls how long resolvers cache it — low TTL = fast change propagation, high TTL = less query load.

16. DNS Record Types Quiz

1. A web developer wants to point `shop.example.com` to the same IP address as `example.com` so that both names reach the same website. The developer adds a CNAME record: `shop.example.com CNAME example.com.` They also want to add an MX record for `shop.example.com` so that `[email protected]` receives email. What problem will they encounter?

A. No problem — CNAME and MX records can coexist on the same hostname without any restriction B. A CNAME cannot coexist with any other record type at the same name — adding an MX to shop.example.com is invalid if a CNAME already exists there; use a separate A record instead C. MX records cannot be added to subdomains — only to the apex domain D. The CNAME chain is too long and will cause a resolution timeout

Correct answer is B. DNS specification prohibits a CNAME record from coexisting with any other record type at the same name. If shop.example.com has a CNAME, it cannot also have an MX, TXT, A, or any other record. The CNAME must stand alone. The fix: replace the CNAME with an A record pointing to the same IP as example.com. Then the MX record can be added freely. This restriction exists because a CNAME means "this name is really that other name" — having an MX alongside a CNAME would create an ambiguous and potentially dangerous situation for mail routing.

2. An email administrator sets up a new mail server at IP 198.51.100.25 and creates an A record: `mail.example.com A 198.51.100.25`, and an MX record: `example.com MX 10 mail.example.com.` However, outgoing email from this server is being rejected by many receiving servers with "550 Host not found." What critical DNS record is missing?

A. A CNAME for mail.example.com pointing to the IP address B. A TXT record containing the SPF policy C. An additional MX record with a different priority for redundancy D. A PTR record mapping 198.51.100.25 back to mail.example.com — receiving mail servers perform reverse DNS lookups on connecting IPs; a missing PTR causes rejection as spam or fraud

Correct answer is D. The PTR record (reverse DNS) is the missing element. When Gmail, Outlook, or another receiving mail server gets an SMTP connection from 198.51.100.25, it performs a reverse DNS lookup (PTR query). If no PTR record exists — or the PTR hostname doesn't forward- resolve back to the same IP (FCrDNS) — the receiving server treats it as suspicious and rejects the connection. The PTR record for 198.51.100.25 must be created by the owner of the IP block (the ISP or hosting provider), not the domain owner. The domain owner must request: PTR for 198.51.100.25 → mail.example.com. Verify with: dig -x 198.51.100.25.

3. A DNS zone's SOA record has a serial number of 2024031501. The zone administrator makes multiple record changes (adds 3 A records, modifies 1 MX record, and deletes 1 TXT record) but forgets to increment the serial. Secondary nameservers were last synced at serial 2024031501. What happens when the secondary checks for updates?

A. The secondary detects the content changes and performs a zone transfer automatically B. The secondary immediately flags an error and sends an alert C. The secondary compares serials — primary = 2024031501, secondary = 2024031501 — no update needed, zone transfer skipped; the secondary continues serving stale data D. The secondary's Refresh timer resets and it waits the full Refresh interval before checking again

Correct answer is C. Secondary nameservers determine whether to perform a zone transfer solely by comparing serial numbers. If the primary's serial equals the secondary's serial, the secondary concludes there are no changes and skips the zone transfer. The secondary continues serving its cached (now stale) version of the zone. The actual record changes are invisible to the secondary until the serial is incremented. This is why incrementing the SOA serial on every zone change is a mandatory operational requirement. The conventional format YYYYMMDDNN (e.g., 2024031502 for the second change on March 15, 2024) makes it easy to track when changes were made.

4. A company's domain `example.com` has this SPF TXT record: `"v=spf1 ip4:203.0.113.0/24 include:_spf.mailprovider.com -all"` An employee configures a new email relay server at IP 10.20.30.40. Email from this new server to external recipients bounces with an SPF failure. What is the cause and fix?

A. The new server's IP (10.20.30.40) is not authorised in the SPF record — it is not in 203.0.113.0/24 and not included in the mail provider's SPF. Add ip4:10.20.30.40 to the SPF TXT record and increment the SOA serial. B. The -all at the end should be changed to ~all to fix the delivery issue C. A new MX record must be added for the relay server D. The DMARC policy is rejecting the email regardless of SPF

Correct answer is A. SPF works by listing every IP address authorised to send email for the domain. The existing record authorises only 203.0.113.0/24 and the mail provider's IPs. The new relay at 10.20.30.40 is not in either list. When receiving servers check SPF for email arriving from 10.20.30.40, no mechanism matches and the -all qualifier causes a hard fail (reject). Fix: add ip4:10.20.30.40 to the SPF TXT record:

"v=spf1 ip4:203.0.113.0/24 ip4:10.20.30.40
                  include:_spf.mailprovider.com -all"

. Note: changing -all to ~all (option B) would soften the policy from "reject" to "mark as spam" but would not fix the fundamental missing authorisation problem.

5. A network engineer runs `dig example.com NS` and sees the NS records in the ANSWER section plus A records for the nameservers in the ADDITIONAL section. What is the name for those A records in the ADDITIONAL section, and why are they necessary?

A. They are CNAME records that help resolvers find the IP addresses of the nameservers B. They are cache records — the resolver stored them from a previous query and included them for convenience C. They are glue records — when a nameserver's hostname is within the zone it serves, its IP must be provided in the parent zone to break the circular dependency of needing to query the zone to find the server that serves the zone D. They are SOA records embedded in the additional section for zone synchronisation

Correct answer is C. These are glue records. The circular dependency problem: to look up example.com, you need ns1.example.com's IP — but ns1.example.com is in the example.com zone, which you can't resolve without knowing ns1's IP first. Glue records break this loop by storing the IP addresses of authoritative nameservers in the parent zone (the .com TLD servers), alongside the NS delegation. When the TLD returns the NS records for example.com, it also returns the A records for ns1/ns2.example.com in the ADDITIONAL section — providing the IPs needed to query the zone directly. Glue is only required when the nameserver hostname is within the zone being delegated.

6. A security team discovers that a fraudulent SSL certificate was issued for their domain `example.com` by an unauthorised Certificate Authority. They want to prevent this from happening again. Which DNS record type should they add, and what should it contain?

A. A DNSKEY record containing their domain's public key to prove ownership to all CAs B. A CAA record specifying which CAs are authorised to issue certificates for example.com — CAs are required to check and respect CAA records before issuing C. A TXT record announcing their chosen CA to prevent others from issuing D. An SOA record update to invalidate all existing certificates

Correct answer is B. CAA (Certification Authority Authorisation) records are specifically designed to prevent unauthorised certificate issuance. The CA/Browser Forum requires all publicly trusted CAs to check for CAA records before issuing a certificate. If a CAA record exists and the CA is not listed, the CA must refuse to issue. Example: example.com. IN CAA 0 issue "letsencrypt.org" — only Let's Encrypt is permitted. Other CAs must refuse. Without any CAA record, any CA can issue — this is the attack vector that was exploited. Adding CAA records costs nothing and immediately restricts certificate issuance to your chosen CA(s). Verify with: dig example.com CAA.

7. What does the `-all` versus `~all` at the end of an SPF TXT record control, and which is stricter?

A. They both reject email from unauthorised senders — the difference is only cosmetic B. ~all is stricter — it permanently blocks all email from the domain C. -all allows all email; ~all quarantines email from unknown senders D. -all (hard fail) is stricter — instructs receiving servers to reject email from unlisted IPs. ~all (soft fail) marks email from unlisted IPs as suspicious/spam but still delivers it. ?all is neutral — no policy applied.

Correct answer is D. SPF qualifiers control what receiving servers do when an IP address doesn't match any SPF mechanism: -all = Hard Fail — the server should reject the email outright (return 550). This is the strictest option and correct for domains with known, stable sending infrastructure. ~all = Soft Fail — the server should accept the email but mark it as suspicious (typically adds a spam score or header). Good during transition/testing when not all sending IPs are confirmed. +all = Pass (never use — allows anyone to send). ?all = Neutral — no policy applied. For mature, well-understood email configurations, -all with DMARC p=reject provides the strongest anti-spoofing protection.

8. A Microsoft Active Directory domain controller at dc1.corp.example.com automatically publishes SRV records in DNS. A client machine queries `_ldap._tcp.corp.example.com SRV` and receives: `0 100 389 dc1.corp.example.com.` What does each field (0, 100, 389, dc1.corp.example.com.) represent?

A. Priority=0 (highest preference), Weight=100 (load share proportion), Port=389 (LDAP TCP port), Target=dc1.corp.example.com (hostname of the domain controller) B. TTL=0, Metric=100, Port=389, Hostname C. Hop count=0, Bandwidth=100 Mbps, Port=389, Target D. AD Site=0, Replica count=100, Port=389, Target

Correct answer is A. SRV record format is: priority weight port target. Priority 0 = highest preference (lower number = tried first, identical logic to MX). Weight 100 = when multiple SRV records have the same priority, traffic is distributed proportionally by weight (higher weight = more traffic). Port 389 = the standard LDAP TCP port — this tells the client which port to connect on, eliminating the need for hardcoded port configuration. Target dc1.corp.example.com = the hostname of the server providing the LDAP service, which must have its own A record. Active Directory relies heavily on SRV records — if AD SRV records are missing or incorrect, client machines cannot find domain controllers for login, authentication, or group policy.

9. A dig query returns this result:
`status: NOERROR, ANSWER: 0, AUTHORITY: 1`
The AUTHORITY section shows the SOA record for example.com. What does this response mean?

A. The domain example.com does not exist — this is the same as NXDOMAIN B. The DNS server is authoritative but the zone is temporarily unavailable C. The domain exists but has no record of the queried type. NOERROR with an SOA in AUTHORITY and empty ANSWER is a "negative response" — the zone is valid, but the specific record type doesn't exist D. The SOA record in AUTHORITY means the answer was returned by the primary nameserver directly

Correct answer is C. This is an important DNS distinction. NXDOMAIN means the domain name itself doesn't exist. NOERROR with an empty ANSWER means the domain exists, but no record of the queried type was found. The SOA record appearing in the AUTHORITY section is specifically how authoritative servers signal a "negative response" — they include the SOA to provide the Negative TTL (the minimum field in the SOA) which tells resolvers how long to cache this "record doesn't exist" answer. Example: querying AAAA for a domain that has only A records returns NOERROR, ANSWER=0, and the SOA in AUTHORITY — the domain is real and reachable over IPv4, but has no IPv6 address configured.

10. A company's DNS zone has: `example.com. CNAME shop.platform.com.` A visitor's browser resolves example.com and connects successfully to the platform. However, they want to add HTTPS — but the SSL certificate issuer says the bare domain cannot use a CNAME and they must use an A record. Which DNS record restriction is causing this, and what is the recommended modern solution?

A. CNAME records cannot be used with HTTPS — they only work for HTTP; switch to an A record for SSL B. The DNS specification prohibits CNAME at the apex domain (bare domain with no subdomain). Modern DNS providers offer ALIAS, ANAME, or "CNAME flattening" pseudo-records that resolve the CNAME target at query time and return the resulting IP — combining CNAME flexibility with apex domain compatibility C. The CNAME chain is too long — add a shorter CNAME target D. This is a certificate authority policy limitation, not a DNS limitation — petition the CA to allow CNAME-based issuance

Correct answer is B. The DNS specification (RFC 1034) prohibits CNAME records at the zone apex (bare domain — example.com without www). This is because the apex must serve NS and SOA records, which cannot coexist with a CNAME. The problem: many SaaS platforms and CDNs want you to point your domain via CNAME (so they can return different IPs per region) but the apex restriction prevents this. Modern DNS providers solve this with proprietary ALIAS (Route 53), ANAME (DNS Made Easy), or CNAME flattening (Cloudflare) — these resolve the CNAME target's A record at query time and return the IP directly, behaving like an A record from the client's perspective while maintaining CNAME-like flexibility for the provider.

← Back to Home

DNS Record Types – Complete Reference Guide

1. What Is a DNS Record?

2. Quick Reference — All DNS Record Types

3. A Record — IPv4 Address Mapping

Key A Record Facts

4. AAAA Record — IPv6 Address Mapping

5. CNAME Record — Canonical Name (Alias)

Critical CNAME Restrictions

6. MX Record — Mail Exchange

MX Priority Rules

7. TXT Record — Text (SPF, DKIM, DMARC, Verification)

TXT Record Use Cases

SPF Mechanisms Reference

8. NS Record — Name Server

9. PTR Record — Pointer (Reverse DNS)

10. SOA Record — Start of Authority

SOA Field Explanations

11. SRV Record — Service Locator

SRV Field Reference

12. CAA Record — Certification Authority Authorisation

13. DNSSEC Records — DNSKEY, RRSIG, DS, NSEC

14. Common Misconceptions About DNS Records

15. Key Points & Exam Tips

16. DNS Record Types Quiz

4. A company's domain example.com has this SPF TXT record: "v=spf1 ip4:203.0.113.0/24 include:_spf.mailprovider.com -all" An employee configures a new email relay server at IP 10.20.30.40. Email from this new server to external recipients bounces with an SPF failure. What is the cause and fix?

5. A network engineer runs dig example.com NS and sees the NS records in the ANSWER section plus A records for the nameservers in the ADDITIONAL section. What is the name for those A records in the ADDITIONAL section, and why are they necessary?

6. A security team discovers that a fraudulent SSL certificate was issued for their domain example.com by an unauthorised Certificate Authority. They want to prevent this from happening again. Which DNS record type should they add, and what should it contain?

7. What does the -all versus ~all at the end of an SPF TXT record control, and which is stricter?

8. A Microsoft Active Directory domain controller at dc1.corp.example.com automatically publishes SRV records in DNS. A client machine queries _ldap._tcp.corp.example.com SRV and receives: 0 100 389 dc1.corp.example.com. What does each field (0, 100, 389, dc1.corp.example.com.) represent?

9. A dig query returns this result: status: NOERROR, ANSWER: 0, AUTHORITY: 1 The AUTHORITY section shows the SOA record for example.com. What does this response mean?

4. A company's domain `example.com` has this SPF TXT record: `"v=spf1 ip4:203.0.113.0/24 include:_spf.mailprovider.com -all"` An employee configures a new email relay server at IP 10.20.30.40. Email from this new server to external recipients bounces with an SPF failure. What is the cause and fix?

5. A network engineer runs `dig example.com NS` and sees the NS records in the ANSWER section plus A records for the nameservers in the ADDITIONAL section. What is the name for those A records in the ADDITIONAL section, and why are they necessary?

6. A security team discovers that a fraudulent SSL certificate was issued for their domain `example.com` by an unauthorised Certificate Authority. They want to prevent this from happening again. Which DNS record type should they add, and what should it contain?

7. What does the `-all` versus `~all` at the end of an SPF TXT record control, and which is stricter?

8. A Microsoft Active Directory domain controller at dc1.corp.example.com automatically publishes SRV records in DNS. A client machine queries `_ldap._tcp.corp.example.com SRV` and receives: `0 100 389 dc1.corp.example.com.` What does each field (0, 100, 389, dc1.corp.example.com.) represent?

9. A dig query returns this result:
`status: NOERROR, ANSWER: 0, AUTHORITY: 1`
The AUTHORITY section shows the SOA record for example.com. What does this response mean?