DNS records explained

What DNS records are#

DNS records are entries in a domain's zone file that instruct resolvers how to handle queries for that domain. Each record has a type, a name, a value, and a TTL (Time to Live) that controls how long resolvers may cache it. Different record types serve different functions, from mapping names to IP addresses to routing email and proving domain ownership. Understanding DNS records is essential for managing how DNS works and for identifying security issues in domain configurations.

A zone file may contain dozens of records across many types. The following sections cover each major DNS record type, how it's used, and what to watch for from a security perspective.

Address records (A and AAAA)#

An A record maps a domain name to an IPv4 address (e.g., 93.184.216.34). An AAAA record does the same for IPv6 (e.g., 2606:2800:220:1:248:1893:25c8:1946). Most domains have at least one A record, and many now publish both A and AAAA records to support dual-stack connectivity.

A records are the most fundamental DNS record type. They are the final answer to "where does this domain live?" Multiple A records at the same name provide round-robin load balancing, and CDN providers often return different A records based on the querying resolver's location.

A record changes are routine during infrastructure migrations, CDN onboarding, or failover events. A change becomes suspicious when it moves a domain to an IP in an unrelated autonomous system, appears outside a scheduled maintenance window, or coincides with expired domain credentials. In those contexts, the shift can indicate a hijack or infrastructure compromise rather than a planned update.

CNAME (alias)#

A CNAME record maps one domain name to another, creating an alias. For example, www.example.com might CNAME to example.com or to a CDN hostname like d1234.cloudfront.net. CNAMEs cannot coexist with other record types at the same name, and they must not appear at the zone apex (the bare domain).

Dangling CNAMEs, records pointing to deprovisioned services, are the root cause of subdomain takeover vulnerabilities. When an organization cancels a cloud service but leaves the CNAME in place, an attacker can claim the orphaned endpoint and serve content under the victim's subdomain.

MX (mail routing)#

MX records specify which servers accept email for a domain, each with a priority value where lower numbers take precedence. A domain with 10 mx1.example.com and 20 mx2.example.com routes mail to mx1 first, falling back to mx2 if it's unavailable.

MX records pointing to unexpected servers can indicate mail interception. A null MX record (0 .) explicitly declares that a domain does not accept email, which is useful for domains reserved purely for brand protection.

TXT (text)#

TXT records hold arbitrary text strings and are heavily used for authentication: SPF records authorize mail senders, DKIM public keys verify message signatures, and DMARC policies define how receivers should handle authentication failures. TXT records also serve domain verification for services like Google Workspace and cloud providers.

Their flexibility makes them one of the most examined record types in security assessments. A domain with fully configured SPF, DKIM, and DMARC TXT records is prepared to send authenticated email. On a suspicious domain, that same configuration signals phishing intent.

NS (delegation)#

NS records identify the authoritative name servers for a zone. They appear in both the parent zone (as a delegation) and the zone itself. Unauthorized changes to NS records redirect all resolution for the domain, effectively a full domain hijack. Monitoring NS record changes is one of the highest-signal alerts in domain security.

example.com.  NS  ns1.example.com.
example.com.  NS  ns2.example.com.

When name servers are within the delegated zone itself, the parent zone must also include glue records (A/AAAA records for the name servers) to avoid circular dependencies during resolution.

SOA (zone authority)#

The SOA record (Start of Authority) identifies the primary name server for the zone, the responsible party's email address, and five numeric parameters:

• Serial number. Incremented on each zone change; secondary servers use it to determine whether they need a zone transfer
• Refresh. How often secondary servers check for updates
• Retry. How long to wait before retrying a failed refresh
• Expire. How long a secondary server continues serving data without a successful refresh
• Minimum TTL. Used as the negative-caching TTL (how long resolvers cache NXDOMAIN responses)

Every zone has exactly one SOA record. It's rarely modified directly in day-to-day operations but is critical for zone transfer mechanics and negative caching behavior.

PTR (reverse DNS)#

PTR records map IP addresses back to domain names, used in reverse DNS lookups. While A records answer "what IP does this name resolve to?", PTR records answer "what name does this IP resolve to?" PTR records live in special zones under .in-addr.arpa (for IPv4) and .ip6.arpa (for IPv6).

Mail servers commonly check PTR records to verify that a sending IP resolves to a name consistent with the sender's domain. A missing or mismatched PTR record is a common cause of email deliverability issues and is used as a basic anti-spam signal. Many mail providers will reject or flag messages from IPs without valid reverse DNS.

SRV (service discovery)#

SRV records specify the priority, weight, port, and target host for specific services at a domain. The record name follows the format _service._protocol.name, for example, _sip._tcp.example.com or _ldap._tcp.dc.example.com.

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

SRV records enable service discovery without hardcoding ports and are used by protocols like SIP, XMPP, and Microsoft Active Directory (which relies heavily on SRV records for domain controller location). They support both priority (for failover) and weight (for load distribution among servers at the same priority level).

CAA (certificate authority authorization)#

CAA records declare which certificate authorities are permitted to issue TLS certificates for a domain. A CAA record like:

example.com.  CAA  0 issue "letsencrypt.org"

restricts certificate issuance to Let's Encrypt. Additional tags include issuewild (for wildcard certificates) and iodef (for reporting unauthorized issuance attempts).

Certificate authorities are expected to check CAA records before issuance, making CAA a meaningful control against unauthorized certificate issuance. However, it relies on CA compliance rather than cryptographic enforcement; a compromised or non-compliant CA could ignore CAA. Deploying CAA alongside DNSSEC ensures that the CAA records themselves cannot be spoofed during the CA's lookup.

Security implications across record types#

Every stage of a domain impersonation campaign leaves traces in DNS records. Monitoring A records, MX records, NS delegations, and TXT authentication policies on suspicious domains reveals how attackers configure infrastructure and whether they intend to host web content, send email, or both. Record-level visibility turns DNS from an abstract system into an actionable intelligence source. Unexpected changes across any record type can signal compromise, and the specific combination of records present on a newly registered domain reveals the registrant's operational intent.