Loading learning content...
When we think of DNS, we typically think of translating domain names to IP addresses. But DNS is far more versatile—it's a general-purpose distributed database capable of storing and retrieving many types of information.
From mail server locations to cryptographic keys, from service discovery to domain ownership verification, DNS query types enable a rich ecosystem of Internet services. Understanding these query types is essential for diagnosing DNS issues, configuring domains correctly, and leveraging DNS for modern applications.
In this page, we explore the full spectrum of DNS query types—what they retrieve, when they're used, and how resolvers handle them.
By the end of this page, you will understand: (1) The major DNS record types and their purposes, (2) Query type encoding and protocol details, (3) How resolvers handle queries for different types, (4) Modern record types for security and service discovery, and (5) Practical use cases and troubleshooting for each type.
Every DNS query includes a QTYPE field specifying what type of record the client seeks. The authoritative server returns records matching both the queried name (QNAME) and type (QTYPE).
DNS Question Section Structure:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
| QNAME | Variable length domain name
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QTYPE | 16-bit query type code
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QCLASS | 16-bit query class (usually IN)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Query Class:
While QTYPE specifies the record type, QCLASS specifies the data class:
QTYPE Categories:
| Category | Common Types | Purpose |
|---|---|---|
| Address | A, AAAA | IPv4 and IPv6 address resolution |
| MX, SPF (via TXT) | Email server discovery and verification | |
| Name Aliasing | CNAME, DNAME | Domain aliasing and redirection |
| Reverse Lookup | PTR | IP address to hostname mapping |
| Service Discovery | SRV, NAPTR | Locate services by protocol/service name |
| Text Data | TXT | Arbitrary text, verification, configuration |
| Zone Management | SOA, NS | Zone authority and delegation |
| Security | DNSKEY, RRSIG, DS, TLSA, CAA | DNSSEC, certificate pinning |
| Meta | ANY, AXFR, IXFR, OPT | Zone transfer, extension mechanisms |
DNS tools display type names (A, MX, TXT) but the wire protocol uses numeric codes: A=1, NS=2, CNAME=5, SOA=6, PTR=12, MX=15, TXT=16, AAAA=28, SRV=33, etc. IANA maintains the complete registry of DNS parameter type values.
Address records are the most fundamental DNS type—translating domain names to IP addresses.
A Record (Type 1) — IPv4 Address
The original address record type, mapping domain names to 32-bit IPv4 addresses:
; A record example
www.example.com. 86400 IN A 93.184.216.34
; Query
$ dig www.example.com A +short
93.184.216.34
Key characteristics:
AAAA Record (Type 28) — IPv6 Address
Maps domain names to 128-bit IPv6 addresses:
; AAAA record example
www.example.com. 86400 IN AAAA 2606:2800:220:1:248:1893:25c8:1946
; Query
$ dig www.example.com AAAA +short
2606:2800:220:1:248:1893:25c8:1946
Key characteristics:
123456789101112131415
# Query A records$ dig example.com A # Query AAAA records$ dig example.com AAAA # Query both (most applications do this)$ dig example.com A +short && dig example.com AAAA +short # Trace resolution path for A record$ dig example.com A +trace # Check for non-existence of AAAA$ dig ipv4only.example.com AAAA;; ANSWER SECTION: (empty - NODATA response)Modern applications implementing Happy Eyeballs (RFC 8305) query for both A and AAAA records simultaneously, then race connections to both address families. This ensures fast failover if one protocol path has issues while preferring IPv6 when available.
MX (Mail Exchanger) records direct email to the correct mail servers for a domain.
MX Record Structure (Type 15):
; MX record format
domain. TTL IN MX priority mail-server.
; Example with multiple MX records
example.com. 3600 IN MX 10 mail1.example.com.
example.com. 3600 IN MX 20 mail2.example.com.
example.com. 3600 IN MX 30 backup.example.com.
Components:
| Field | Description |
|---|---|
| Priority | 16-bit preference value; lower = higher priority |
| Mail Server | FQDN of the mail server to contact |
Mail Delivery Algorithm:
Important MX Considerations:
1234567891011121314151617
# Query MX records$ dig gmail.com MX +short5 gmail-smtp-in.l.google.com.10 alt1.gmail-smtp-in.l.google.com.20 alt2.gmail-smtp-in.l.google.com.30 alt3.gmail-smtp-in.l.google.com.40 alt4.gmail-smtp-in.l.google.com. # Query MX and resolve mail server addresses$ dig gmail.com MX +short | while read pri host; do echo "$pri $host -> $(dig $host A +short)"done # Check for missing/null MX$ dig no-mail-example.com MX# Empty answer = domain accepts mail at A record (fallback)# MX 0 . = domain explicitly doesn't accept mail (null MX, RFC 7505)To explicitly indicate a domain doesn't accept email, use a null MX: example.com. MX 0 . — This is cleaner than no MX record (which implies fallback to A record) and helps senders fail fast rather than attempting delivery.
Aliasing records redirect DNS queries from one name to another, enabling flexible domain architecture.
CNAME Record (Type 5) — Canonical Name
Creates an alias from one name to another (the canonical name):
; CNAME record format
alias.domain. TTL IN CNAME canonical.target.
; Example: www is an alias for the CDN
www.example.com. 3600 IN CNAME example.cdn.cloudflare.net.
; The resolver then queries the target
example.cdn.cloudflare.net. 60 IN A 104.16.132.229
CNAME Resolution Behavior:
When a resolver encounters a CNAME while querying for any type (A, MX, TXT, etc.):
www.example.com Awww.example.com CNAME cdn.example.netcdn.example.net Acdn.example.net A 192.0.2.100| Rule | Description | Rationale |
|---|---|---|
| No coexistence | CNAME can't exist with other records for same name | Ambiguity: which record to return? |
| No zone apex | CNAME can't be at zone apex (bare domain) | Zone apex requires SOA and NS, which can't coexist with CNAME |
| Chain limit | Resolvers limit CNAME chain depth (8-16 typically) | Prevent infinite loops and excessive queries |
| MX/NS target | MX and NS shouldn't point to CNAME targets (RFC violation) | Can cause resolution failures |
DNAME Record (Type 39) — Delegation Name
Similar to CNAME but applies to an entire subtree:
; DNAME record: redirect entire subtree
old-division.company.com. DNAME new-division.company.com.
; Effect: any query under old-division is rewritten
; Query: app.old-division.company.com
; Synthesized CNAME: app.old-division.company.com -> app.new-division.company.com
DNAME Use Cases:
1234567891011121314
# Query that follows CNAME chain$ dig www.linkedin.com A;; ANSWER SECTION:www.linkedin.com. 300 IN CNAME 2-01-2c3e-005a.cdx.cedexis.net.2-01-2c3e-005a.cdx.cedexis.net. 60 IN CNAME pop-sfo1.linkedin.com.pop-sfo1.linkedin.com. 60 IN A 108.174.10.10 # Query without following CNAME (just the CNAME record)$ dig www.linkedin.com CNAME +short2-01-2c3e-005a.cdx.cedexis.net. # Check if a name is a CNAME (no A record at that name)$ dig blog.example.com A +norecurse @ns1.example.com# If AUTHORITY section shows CNAME, it's an aliasYou cannot use CNAME at the zone apex (e.g., example.com without www). This caused issues for domains wanting to point to CDNs or cloud services. Solutions include: ALIAS records (Route53), CNAME flattening (Cloudflare), ANAME records (draft RFC)—all proprietary workarounds that resolve CNAME targets to A/AAAA and return those.
PTR (Pointer) records enable reverse DNS—mapping IP addresses back to domain names.
PTR Record Structure (Type 12):
PTR records are stored in special reverse zones:
; IPv4: Use in-addr.arpa zone (octets reversed)
; IP: 192.0.2.100 → Query: 100.2.0.192.in-addr.arpa
100.2.0.192.in-addr.arpa. 86400 IN PTR server.example.com.
; IPv6: Use ip6.arpa zone (nibbles reversed)
; IP: 2001:db8::1 → Fully expanded and reversed
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
86400 IN PTR server.example.com.
Why Reverse Zones Use This Format:
DNS names are hierarchical from right to left (more specific labels on the left). IP addresses are hierarchical from left to right (network portion on the left). Reversing IP octets aligns with DNS's delegation model, allowing /8, /16, /24 blocks to be delegated as subzones.
PTR Record Use Cases:
12345678910111213141516171819202122
# Query PTR for IPv4 address$ dig -x 8.8.8.8 +shortdns.google. # Query PTR manually (understanding the zone format)$ dig 8.8.8.8.in-addr.arpa PTR +shortdns.google. # Query PTR for IPv6 address$ dig -x 2001:4860:4860::8888 +shortdns.google. # Verify forward-reverse match (critical for email)$ dig google.com A +short142.250.189.46$ dig -x 142.250.189.46 +shortlax17s59-in-f14.1e100.net.# Note: PTR doesn't have to match forward A (but often should) # Check if PTR is missing (common for residential IPs)$ dig -x 192.168.1.1;; ANSWER SECTION: (empty or NXDOMAIN)PTR zones for your IP addresses are managed by your IP address provider (ISP, hosting provider, cloud provider). You typically need to request PTR record creation through their control panel or support. For large allocations (/24 or bigger), you may receive delegation of the entire reverse zone.
SRV (Service) records enable service discovery—locating servers for specific services within a domain.
SRV Record Structure (Type 33):
; SRV record format
_service._protocol.domain. TTL IN SRV priority weight port target.
; Example: LDAP server discovery
_ldap._tcp.example.com. 3600 IN SRV 10 60 389 ldap1.example.com.
_ldap._tcp.example.com. 3600 IN SRV 10 40 389 ldap2.example.com.
_ldap._tcp.example.com. 3600 IN SRV 20 0 389 backup.example.com.
SRV Fields:
| Field | Description |
|---|---|
| _service | Service name (e.g., _ldap, _xmpp-client, _sip) |
| _protocol | Transport protocol (_tcp or _udp) |
| Priority | Like MX priority; lower is preferred |
| Weight | For load distribution among same-priority servers |
| Port | TCP/UDP port the service listens on |
| Target | Hostname of the server providing the service |
SRV Selection Algorithm:
_service._protocol.domain| Service | SRV Name | Purpose |
|---|---|---|
| XMPP (Jabber) | _xmpp-client._tcp | Chat client connection discovery |
| SIP | _sip._tcp / _sip._udp | VoIP server discovery |
| LDAP | _ldap._tcp | Directory server discovery |
| Kerberos | _kerberos._tcp / _udp | Authentication server discovery |
| CalDAV | _caldavs._tcp | Calendar server discovery |
| CardDAV | _carddavs._tcp | Contact server discovery |
| Minecraft | _minecraft._tcp | Game server discovery |
123456789101112131415
# Query XMPP client servers for gmail.com$ dig _xmpp-client._tcp.gmail.com SRV +short5 0 5222 xmpp.l.google.com.20 0 5222 alt1.xmpp.l.google.com. # Query Microsoft 365 autodiscover$ dig _autodiscover._tcp.example.com SRV +short # Query for SIP service$ dig _sip._tcp.example.com SRV +short # Active Directory domain controller discovery$ dig _ldap._tcp.dc._msdcs.corp.example.com SRV +short0 100 389 dc1.corp.example.com.0 100 389 dc2.corp.example.com.Weight enables proportional load distribution. For 60/40 split: use weights 60 and 40. For equal distribution among 3 servers: use weight 33.33 approximated as 1,1,1 or 100,100,100. A weight of 0 means 'use only if no other servers available in this priority group.'
TXT (Text) records hold arbitrary text data. Despite their simplicity, they've become crucial for email security, domain verification, and configuration.
TXT Record Structure (Type 16):
; TXT record format
domain. TTL IN TXT "text string"
; Multiple strings in one record
example.com. 3600 IN TXT "v=spf1" " include:_spf.google.com" " ~all"
; Multiple TXT records for same name
example.com. TXT "v=spf1 include:_spf.google.com ~all"
example.com. TXT "google-site-verification=abc123..."
example.com. TXT "docusign=xyz789..."
Major TXT Record Uses:
| Application | Record Format | Purpose |
|---|---|---|
| SPF | v=spf1 ... | Email sender authorization (anti-spoofing) |
| DKIM | v=DKIM1; k=rsa; p=... | Email signature public key |
| DMARC | v=DMARC1; p=... | Email auth policy and reporting |
| Domain verification | google-site-verification=... | Prove domain ownership to services |
| ACME challenge | _acme-challenge.domain | Let's Encrypt domain validation |
| Security.txt | _security.domain | Security contact information |
Email Authentication Stack (SPF + DKIM + DMARC):
; SPF: Who can send email for this domain?
example.com. TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"
; DKIM: Public key for email signature verification
Selector._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..."
; DMARC: Policy for failed authentication
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
12345678910111213141516171819
# Query all TXT records for a domain$ dig example.com TXT +short"v=spf1 -all" # Query SPF specifically (may be at different location)$ dig example.com TXT | grep spf # Query DKIM (need the selector name, often in email headers)$ dig selector1._domainkey.example.com TXT +short # Query DMARC policy$ dig _dmarc.example.com TXT +short"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com" # Query domain verification$ dig example.com TXT | grep google-site-verification # Query ACME validation (Let's Encrypt)$ dig _acme-challenge.example.com TXT +shortEach TXT string is limited to 255 characters. Longer data must be split into multiple strings (concatenated by receiver). The total TXT record can be up to ~65535 bytes but UDP DNS responses may truncate large records. DKIM keys in particular often need string splitting.
Several record types manage zone operations and security. Understanding these is essential for DNS administration.
SOA Record (Type 6) — Start of Authority
Every zone requires exactly one SOA record at the apex:
example.com. 86400 IN SOA ns1.example.com. hostmaster.example.com. (
2024011701 ; Serial number (YYYYMMDDNN)
7200 ; Refresh: secondary checks primary
3600 ; Retry: time between failed refreshes
1209600 ; Expire: max time secondary serves stale
86400 ; Minimum: negative cache TTL
)
NS Record (Type 2) — Name Server
Delegates zone authority to nameservers:
example.com. 86400 IN NS ns1.example.com.
example.com. 86400 IN NS ns2.example.com.
DNSSEC Records:
| Type | Code | Purpose | Location |
|---|---|---|---|
| DNSKEY | 48 | Zone signing public keys | Zone apex |
| RRSIG | 46 | Signature over a record set | With each signed RRset |
| DS | 43 | Delegated signer (child zone key hash) | Parent zone |
| NSEC | 47 | Authenticated denial of existence | Inline with zone data |
| NSEC3 | 50 | Hashed denial of existence | Inline (prevents zone enumeration) |
CAA Record (Type 257) — Certification Authority Authorization
Controls which CAs can issue certificates for the domain:
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issue "digicert.com"
example.com. CAA 0 issuewild ";"
example.com. CAA 0 iodef "mailto:security@example.com"
CAA Properties:
issue: Allows CA to issue standard certificatesissuewild: Allows CA to issue wildcard certificates (; = none)iodef: Where to report policy violations123456789101112131415161718192021
# Query SOA record$ dig example.com SOA +shortns1.example.com. hostmaster.example.com. 2024011701 7200 3600 1209600 86400 # Query NS records$ dig example.com NS +shortns1.example.com.ns2.example.com. # Query DNSKEY (DNSSEC)$ dig example.com DNSKEY +dnssec # Query DS record (in parent zone)$ dig example.com DS @a.gtld-servers.net # Query CAA records$ dig example.com CAA +short0 issue "letsencrypt.org" # Check entire DNSSEC chain$ delv example.com +rtraceThe ANY query type (which requested all records for a name) is being deprecated due to amplification attack potential. RFC 8482 allows servers to return minimal or synthetic responses to ANY queries. For zone enumeration, use AXFR (zone transfer) if authorized, or query specific types individually.
We've explored the full spectrum of DNS query types. Let's consolidate the key concepts:
Module Complete:
With this page, we've completed our comprehensive exploration of DNS Resolution. You now understand recursive and iterative resolution, the complete resolution process, resolver roles and configuration, and the full spectrum of query types that make DNS a versatile Internet infrastructure service.
You now have comprehensive knowledge of DNS query types—from fundamental address records through mail routing, aliasing, service discovery, and security. Combined with your understanding of resolution mechanics, you can configure, troubleshoot, and optimize DNS for any scenario. Continue to the next module to explore DNS Caching in depth.