DNS Record Types

Below is a summary of the major types of records within a DNS configuration, along with their purposes and examples of their content.

Summary of Major DNS Record Types

DNS configuration files contain various record types that direct internet traffic by mapping domain names to specific resources or data. Each type serves a unique function, ensuring websites, emails, and other services work correctly. Below are the primary DNS record types, their purposes, and examples of their content.

A (Address) Record

• Purpose: Maps a domain name to an IPv4 address, directing traffic to a specific server.
• Content: Contains the 32-bit IPv4 address of the host.
• Example: example.com. 3600 IN A 192.0.2.1
  • This points example.com to the IP address 192.0.2.1 with a TTL (time to live) of 3600 seconds.

AAAA (Quad-A) Record

• Purpose: Maps a domain name to an IPv6 address, supporting newer internet protocols.
• Content: Contains the 128-bit IPv6 address.
• Example: example.com. 3600 IN AAAA 2001:0db8:85a3:0000:0000:8a2e:0370:7334
  • This directs example.com to the IPv6 address shown.

CNAME (Canonical Name) Record

• Purpose: Aliases one domain name to another, pointing to the “true” domain name.
• Content: Specifies the target domain name (not an IP address).
• Example: www.example.com. 3600 IN CNAME example.com.
  • This makes www.example.com resolve to the same IP as example.com.

MX (Mail Exchange) Record

• Purpose: Directs email to the correct mail server for a domain.
• Content: Lists the mail server’s hostname and a priority number (lower means preferred).
• Example: example.com. 3600 IN MX 10 mail.example.com.
  • This routes email for example.com to mail.example.com with priority 10.

NS (Name Server) Record

• Purpose: Identifies the authoritative DNS servers for a domain.
• Content: Contains the hostname of the DNS server.
• Example: example.com. 3600 IN NS ns1.example.com.
  • This states that ns1.example.com is a name server for example.com.

TXT (Text) Record

• Purpose: Stores descriptive or verification data, often for security or configuration.
• Content: Holds arbitrary text, like verification codes or policy settings.
• Example: example.com. 3600 IN TXT "v=spf1 mx -all"
  • This defines an SPF (Sender Policy Framework) rule to prevent email spoofing.

SOA (Start of Authority) Record

• Purpose: Provides key details about the domain’s DNS zone, like the primary name server and admin contact.
• Content: Includes fields like the primary name server, admin email, serial number, and timers for refresh/retry/expire.
• Example: example.com. 3600 IN SOA ns1.example.com. admin.example.com. 2025082101 7200 3600 1209600 3600
  • This specifies ns1.example.com as the primary server, admin.example.com as the contact, with a serial number and timing values.

PTR (Pointer) Record

• Purpose: Maps an IP address back to a domain name, used for reverse DNS lookups.
• Content: Contains the domain name associated with the IP.
• Example: 1.2.0.192.in-addr.arpa. 3600 IN PTR example.com.
  • This links the IP 192.0.2.1 to example.com for reverse lookups.

SRV (Service) Record

• Purpose: Defines the location (host and port) of specific services, like VoIP or messaging.
• Content: Includes priority, weight, port, and target hostname.
• Example: _sip._tcp.example.com. 3600 IN SRV 10 60 5060 sipserver.example.com.
  • This directs SIP traffic for example.com to sipserver.example.com on port 5060.

NAPTR (Naming Authority Pointer) Record

• Purpose: Rewrites a domain into a new name or URI for protocols like SIP and ENUM (telephone-number-to-domain mapping).
• Content: Contains order, preference, flags, a service field, a regular expression, and a replacement domain.
• Example: example.com. 3600 IN NAPTR 100 10 "U" "E2U+sip" "!^.*$!sip:info@example.com!" .
  • This rewrites a query for example.com into a SIP URI for VoIP routing.

CAA (Certification Authority Authorization) Record

• Purpose: Specifies which certificate authorities can issue SSL/TLS certificates for the domain.
• Content: Lists the CA’s domain and flags for constraints.
• Example: example.com. 3600 IN CAA 0 issue "letsencrypt.org"
  • This allows only Let’s Encrypt to issue certificates for example.com.

DNAME (Delegation Name) Record

• Purpose: Creates an alias for an entire subdomain, redirecting all its queries to another domain.
• Content: Specifies the target domain name that the subdomain maps to.
• Example: sub.example.com. 3600 IN DNAME target.com.
  • This redirects all queries for sub.example.com and its subdomains (e.g., app.sub.example.com) to target.com equivalents.

DS (Delegation Signer) Record

• Purpose: Supports DNSSEC by linking a parent zone to a child zone’s cryptographic key, ensuring secure delegation.
• Content: Contains a key tag, algorithm number, digest type, and a hash of a DNSKEY record.
• Example: example.com. 3600 IN DS 12345 8 2 1A2B3C4D5E6F7A8B9C0D1E2F3A4B5C6D7E8F9A0B
  • This verifies the DNSKEY for example.com using algorithm 8 and SHA-256 digest.

DNSKEY (DNS Key) Record

• Purpose: Publishes the public key a resolver uses to verify DNSSEC signatures for the zone.
• Content: Contains flags, a protocol field, an algorithm number, and the public key itself.
• Example: example.com. 3600 IN DNSKEY 257 3 8 AwEAAagAIKlVZrpC6Ia7...
  • This is the zone’s public signing key; the matching DS record in the parent zone points to it.

RRSIG (Resource Record Signature) Record

• Purpose: Holds the DNSSEC digital signature for a set of records, so a resolver can confirm they haven’t been tampered with.
• Content: Contains the record type covered, the algorithm, a validity window, and the signature itself.
• Example: example.com. 3600 IN RRSIG A 8 2 3600 20260901000000 20260801000000 12345 example.com. <signature>
  • This signs the domain’s A record; a resolver checks it against the zone’s DNSKEY before trusting the result.

Notes

• TTL (Time to Live): Most records include a TTL (in seconds), indicating how long resolvers cache the data.
• Format: Records follow a standard structure: name TTL IN type data.
• Use Cases: These records support everything from website hosting (A, AAAA) to email delivery (MX) and security (TXT, CAA).
• Management: Proper change management ensures these records are updated accurately to avoid errors, and that a bad change can be traced and undone rather than tracked down by hand.

All of the record types above are defined in various Request for Comment (RFC) specifications, which set the standards for the Internet.

ResorsIT DNS/IP Management manages every record type on this page, across multiple providers, with full change history and easy Undo.