DNS Record Types

Reference for all common and specialized DNS resource record types, their purpose, syntax, and usage examples.

Table of Contents#

1. Overview
2. Common Record Types
3. Security Record Types
4. Service Discovery Records
5. DNSSEC Record Types
6. Specialized Record Types
7. Record Examples in Zone File Format
8. Troubleshooting
9. See Also
10. Sources

1. Overview#

DNS resource records (RRs) are entries in a DNS zone that map domain names to various types of data. Each record has a standard format:

<name>    <TTL>    <class>    <type>    <data>

• Name - The domain name (or @ for the zone apex)
• TTL - Time to live in seconds (how long resolvers may cache the record)
• Class - Almost always IN (Internet)
• Type - Record type (A, AAAA, MX, etc.)
• Data - Type-specific content (IP address, hostname, text, etc.)

2. Common Record Types#

A (Address)#

Maps a domain name to an IPv4 address.

example.com.    3600    IN    A    203.0.113.10

• Most fundamental record type
• Multiple A records for the same name provide round-robin load balancing
• Cannot coexist with a CNAME at the same name

AAAA (IPv6 Address)#

Maps a domain name to an IPv6 address.

example.com.    3600    IN    AAAA    2001:db8::10

• Functionally identical to A records but for IPv6
• Dual-stack hosts should have both A and AAAA records

CNAME (Canonical Name)#

Creates an alias that points one domain name to another.

www.example.com.    3600    IN    CNAME    example.com.

• Does not provide an IP address directly; resolvers follow the chain to the target's A/AAAA records
• Cannot coexist with any other record type at the same name (including MX, TXT, NS)
• Cannot be used at the zone apex (root domain) per RFC 1034; some providers offer "CNAME flattening" or "ALIAS" records as workarounds

MX (Mail Exchange)#

Directs email to the specified mail server(s) for the domain.

example.com.    3600    IN    MX    10    mail.example.com.
example.com.    3600    IN    MX    20    backup-mail.example.com.

• Priority (preference) value: lower numbers are tried first
• The target must be an A/AAAA record, not a CNAME
• Multiple MX records with the same priority enable load balancing

TXT (Text)#

Stores arbitrary text data, commonly used for domain verification and email security.

example.com.    3600    IN    TXT    "v=spf1 ip4:203.0.113.0/24 -all"

• Maximum 255 characters per string; longer values split into multiple strings concatenated by the resolver
• Common uses: SPF, DKIM, DMARC, domain verification (Google, Microsoft), ACME DNS-01 challenges

NS (Name Server)#

Delegates a domain or subdomain to the specified authoritative name servers.

example.com.    86400    IN    NS    ns1.example.com.
example.com.    86400    IN    NS    ns2.example.com.

• At least two NS records recommended for redundancy
• NS records at the zone apex define the authoritative servers for the zone
• NS records for subdomains delegate authority to a different zone

SOA (Start of Authority)#

Contains administrative information about the zone. Every zone must have exactly one SOA record.

example.com.    86400    IN    SOA    ns1.example.com. admin.example.com. (
    2026032201    ; Serial
    7200          ; Refresh
    1200          ; Retry
    2419200       ; Expire
    60            ; Minimum TTL (negative cache)
)

See the Bind9 documentation for detailed field descriptions.

PTR (Pointer)#

Maps an IP address back to a domain name (reverse DNS).

10.113.0.203.in-addr.arpa.    3600    IN    PTR    mail.example.com.

• Used for reverse lookups (IP to hostname)
• Essential for mail servers (receiving servers check rDNS)
• Managed by the IP address owner (hosting provider or ISP), not the domain owner

3. Security Record Types#

CAA (Certification Authority Authorization)#

Specifies which Certificate Authorities are permitted to issue certificates for the domain.

example.com.    3600    IN    CAA    0 issue "letsencrypt.org"
example.com.    3600    IN    CAA    0 issuewild "letsencrypt.org"
example.com.    3600    IN    CAA    0 iodef "mailto:security@example.com"

Usage scenarios:

• Restrict to a single CA: 0 issue "letsencrypt.org" (only Let's Encrypt may issue certs)
• Block all issuance: 0 issue ";" (no CA may issue certificates)
• Allow multiple CAs: Add separate issue records for each CA
• Wildcard restriction: 0 issuewild ";" blocks wildcard certs while issue allows regular certs
• CAA records are inherited by subdomains unless overridden

TLSA (Transport Layer Security Authentication / DANE)#

Binds a TLS certificate or public key to a domain name, enabling DNS-based authentication of TLS certificates without relying solely on public CAs. Part of DANE (DNS-based Authentication of Named Entities, RFC 6698).

_443._tcp.example.com.    3600    IN    TLSA    3 1 1 <sha256-hash-of-certificate-public-key>

Format: <usage> <selector> <matching-type> <certificate-data>

Generate a TLSA record:

# From a certificate file
openssl x509 -in server.crt -pubkey -noout \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256 -binary \
  | xxd -p -c 64

Note: TLSA requires DNSSEC on the zone to be effective. Without DNSSEC, an attacker who can spoof DNS can also spoof TLSA records.

SSHFP (SSH Fingerprint)#

Stores the fingerprint of an SSH server's public key, allowing SSH clients to verify the server's identity via DNS.

server.example.com.    3600    IN    SSHFP    4 2 <sha256-fingerprint>

Generate SSHFP records from a server's host keys:

ssh-keygen -r server.example.com

4. Service Discovery Records#

SRV (Service Locator)#

Specifies the host and port for a particular service.

_sip._tcp.example.com.    3600    IN    SRV    10 60 5060 sipserver.example.com.

Format: <priority> <weight> <port> <target>

Common SRV records:

; XMPP
_xmpp-client._tcp.example.com.    IN    SRV    5 0 5222 xmpp.example.com.
_xmpp-server._tcp.example.com.    IN    SRV    5 0 5269 xmpp.example.com.

; SIP
_sip._tcp.example.com.            IN    SRV    10 60 5060 sip.example.com.

; LDAP
_ldap._tcp.example.com.           IN    SRV    0 100 389 ldap.example.com.

; CalDAV / CardDAV (autodiscovery)
_caldavs._tcp.example.com.        IN    SRV    0 1 443 dav.example.com.
_carddavs._tcp.example.com.       IN    SRV    0 1 443 dav.example.com.

; Mail client autodiscovery (RFC 6186)
_submission._tcp.example.com.     IN    SRV    0 1 587 mail.example.com.
_imaps._tcp.example.com.          IN    SRV    0 1 993 mail.example.com.

NAPTR (Naming Authority Pointer)#

Maps domain names to URIs or service endpoints using regular expression rewriting. Often combined with SRV records for dynamic service discovery.

example.com.    IN    NAPTR    100 10 "u" "E2U+sip" "!^.*$!sip:info@example.com!" .
example.com.    IN    NAPTR    100 20 "s" "E2U+http" "" _http._tcp.example.com.

Format: <order> <preference> "<flags>" "<service>" "<regexp>" <replacement>

Common use case: ENUM (E.164 Number Mapping) for telephone number to SIP URI mapping:

; Map +1-555-0100 to a SIP URI
; Query: 0.0.1.0.5.5.5.1.e164.arpa
0.0.1.0.5.5.5.1.e164.arpa.    IN    NAPTR    100 10 "u" "E2U+sip" "!^.*$!sip:+15550100@example.com!" .

SVCB (Service Binding)#

General-purpose record for specifying alternative endpoints for a service, including priority and connection parameters (RFC 9460).

_foo._tcp.example.com.    IN    SVCB    1 svc.example.com. alpn="bar" port=8443
example.com.              IN    SVCB    0 svc.example.com.

• Priority 0 is "AliasMode" (acts like CNAME for the service)
• Priority 1+ is "ServiceMode" (specifies connection parameters)
• Parameters include: alpn, port, ipv4hint, ipv6hint, ech (Encrypted Client Hello)

HTTPS (HTTPS Service Binding)#

A specific form of SVCB for HTTPS services (type 65, RFC 9460). Tells clients how to connect via HTTPS, including protocol negotiation and IP hints.

example.com.    IN    HTTPS    1 . alpn="h2,h3" ipv4hint=203.0.113.10 ipv6hint=2001:db8::10

Key difference from SVCB: HTTPS records apply specifically to HTTPS connections and are queried automatically by supporting browsers and HTTP clients. SVCB is a general framework for any service type.

Practical benefits:

• HTTP/3 (QUIC) signaling - The alpn="h3" hint tells clients the server supports HTTP/3
• Encrypted Client Hello (ECH) - The ech parameter distributes ECH configuration
• IP hints - Reduce DNS round trips by providing IP addresses directly
• Port redirection - Serve HTTPS on non-standard ports without URL modification

5. DNSSEC Record Types#

6. Specialized Record Types#

7. Record Examples in Zone File Format#

$TTL 86400
$ORIGIN example.com.

; SOA
@           IN  SOA     ns1.example.com. admin.example.com. (
                        2026032201 7200 1200 2419200 60 )

; Name servers
@           IN  NS      ns1.example.com.
@           IN  NS      ns2.example.com.

; A and AAAA
@           IN  A       203.0.113.10
@           IN  AAAA    2001:db8::10
ns1         IN  A       203.0.113.10
ns2         IN  A       203.0.113.11
www         IN  A       203.0.113.10
mail        IN  A       203.0.113.20

; CNAME
blog        IN  CNAME   www.example.com.

; MX
@           IN  MX      10 mail.example.com.
@           IN  MX      20 backup.example.com.

; TXT (SPF, DKIM, DMARC, verification)
@                       IN  TXT     "v=spf1 ip4:203.0.113.0/24 -all"
default._domainkey      IN  TXT     "v=DKIM1; k=rsa; p=MIIBIjAN..."
_dmarc                  IN  TXT     "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

; SRV (mail autodiscovery)
_submission._tcp        IN  SRV     0 1 587 mail.example.com.
_imaps._tcp             IN  SRV     0 1 993 mail.example.com.

; CAA
@           IN  CAA     0 issue "letsencrypt.org"
@           IN  CAA     0 issuewild "letsencrypt.org"
@           IN  CAA     0 iodef "mailto:security@example.com"

; TLSA (DANE for HTTPS)
_443._tcp               IN  TLSA    3 1 1 a]b2c3d4e5f6...

; HTTPS
@           IN  HTTPS   1 . alpn="h2,h3" ipv4hint=203.0.113.10

; PTR (in reverse zone 113.0.203.in-addr.arpa)
; 10    IN  PTR     example.com.
; 20    IN  PTR     mail.example.com.

Troubleshooting#

See Also#

• BIND9
• Mail Server DNS Records
• DNS Encryption

Sources#

• IANA DNS Parameters
• RFC 1035 - Domain Names, Implementation and Specification
• RFC 6698 - DANE / TLSA
• RFC 8659 - CAA
• RFC 2782 - SRV Records
• RFC 9460 - SVCB and HTTPS Records
• RFC 3403 - NAPTR