DNS Resolution
Query Types
Read aloud is unavailable in this browser.
More Than Just IP Addresses
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.
Query Type Fundamentals
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:
- IN (1): Internet class — used in virtually all DNS queries
- CH (3): Chaos class — used for querying server metadata
- HS (4): Hesiod class — historical, rarely used
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 Record Types (A and AAAA)
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:
- Fixed 4-byte RDATA (the IPv4 address)
- Multiple A records allowed for same name (round-robin load balancing)
- TTL controls caching duration
- Most common query type
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:
- Fixed 16-byte RDATA (the IPv6 address)
- Often coexists with A records for dual-stack hosts
- Increasing deployment as IPv4 exhaustion continues
- •Web server address resolution
- •API endpoint resolution
- •Direct service access (SSH, FTP)
- •Load balancing via multiple A records
- •CDN edge server selection
- •Always publish alongside A records
- •Happy Eyeballs handles dual-stack fallback
- •Some regions/networks prefer IPv6
- •Mobile networks increasingly IPv6-only
- •AAAAs may resolve to different hosts than A
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.
Mail-Related Types (MX)
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:
- Sending server queries MX records for recipient domain
- Sort MX records by priority (lowest first)
- Attempt delivery to lowest-priority server
- If connection fails, try next priority level
- If all fail, queue for retry with exponential backoff
Important MX Considerations:
- •MX points to hostname, not IP — The RDATA is a domain name that must be resolved to an A/AAAA record
- •MX can't point to CNAME — Per RFC 2181, MX targets must resolve to A/AAAA directly (though this is sometimes violated)
- •No MX = fallback to A record — If no MX exists, senders should try the domain's A record directly (implicit MX)
- •Priority 0 is valid — Priority values range from 0-65535; 0 is the highest priority
- •Equal priorities — For same-priority MX records, senders should randomize selection
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.
Name Aliasing (CNAME and DNAME)
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.):
- Query:
www.example.com A - Response:
www.example.com CNAME cdn.example.net - Resolver automatically continues: Query
cdn.example.net A - Response:
cdn.example.net A 192.0.2.100 - Return both CNAME and A to client
| 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:
- Migrating services to new domain names
- Reverse DNS delegation for IPv6 nibble boundaries
- Organizational restructuring without broken links
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.
Reverse Lookup (PTR)
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:
- •Email spam filtering — Mail servers check PTR of connecting IP; mismatched or missing PTR often means spam
- •Logging and auditing — Convert IPs in logs to readable hostnames
- •SSH host display — SSH shows remote hostname from PTR in welcome messages
- •Network troubleshooting — Traceroute uses PTR to show router names
- •Security analysis — Identify hosts by name during incident investigation
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.
Service Discovery (SRV)
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:
- Query SRV records for
_service._protocol.domain - Sort by priority (lowest first)
- Within each priority level, select servers by weighted random:
- Sum all weights in the priority group
- Generate random number 0 to sum
- Select server where running sum exceeds random number
- Connect to selected server on specified port
- If connection fails, select next server by weight algorithm
- If all servers in priority group fail, move to next priority level
| 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.'
Text and Verification (TXT)
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.
KEEP LEARNING
There’s more to understand.
You’re reading the introduction. Create a free account to read the complete lesson, save notes and keep track of your progress.