Stackvora.tech

DNS Records Explained: A, AAAA, CNAME, MX, TXT, SRV

Domain Name System (DNS) records are fundamental to how the internet functions, translating human-readable domain names into machine-readable IP addresses…

Domain Name System (DNS) records are fundamental to how the internet functions, translating human-readable domain names into machine-readable IP addresses and providing other critical information about domains. Understanding the various record types and their appropriate use is essential for network engineers, sysadmins, and cloud architects managing internet-facing services. This guide details the most common and critical DNS record types, their structure, purpose, and practical application.

DNS operates primarily over UDP port 53 for queries and TCP port 53 for zone transfers. Records are stored in zone files on authoritative DNS servers, following a specific syntax defined in RFC 1035 and subsequent RFCs.

A Record (Address Record)

The A record maps a domain name to an IPv4 address. It is the most common and fundamental DNS record type, enabling web browsers, email clients, and other applications to connect to services hosted on specific IP addresses.

  • Purpose: Resolves a hostname to an IPv4 address.
  • Format: hostname IN A IPv4_address
  • Example: www.example.com. IN A 192.0.2.10
  • TTL (Time To Live): Specifies how long a recursive resolver should cache the record. Common values range from 300 seconds (5 minutes) to 3600 seconds (1 hour). Shorter TTLs are useful for services undergoing frequent IP changes or failover.

When configuring A records, ensure the specified IPv4 address is publicly routable if the service is internet-facing. For internal services, private IP addresses (RFC 1918) are used within private DNS zones.

AAAA Record (IPv6 Address Record)

The AAAA record, pronounced "quad-A," maps a domain name to an IPv6 address. As IPv6 adoption continues, AAAA records are becoming increasingly prevalent, often existing alongside A records for dual-stack environments.

  • Purpose: Resolves a hostname to an IPv6 address.
  • Format: hostname IN AAAA IPv6_address
  • Example: www.example.com. IN AAAA 2001:0db8:85a3:0000:0000:8a2e:0370:7334
  • Considerations: Services must be configured to listen on IPv6, and network infrastructure (routers, firewalls) must support IPv6 routing.

CNAME Record (Canonical Name Record)

A CNAME record creates an alias from one domain name to another canonical domain name. The aliased domain name then inherits the DNS records (A, AAAA, MX, etc.) of the canonical domain.

  • Purpose: Points one domain to another, making it an alias.
  • Format: alias.example.com. IN CNAME canonical.example.com.
  • Example: blog.example.com. IN CNAME pages.github.io.
  • Constraint: A CNAME record cannot coexist with other records for the same hostname. For instance, if example.com has a CNAME, it cannot also have an MX record or A record. This is why CNAMEs are typically not used at the zone apex (e.g., example.com itself), as the apex must have SOA and NS records. Some DNS providers offer ANAME or ALIAS records as proprietary workarounds to allow apex aliasing, which resolve the canonical name to an IP address at query time.

MX Record (Mail Exchange Record)

MX records specify the mail servers responsible for accepting email messages on behalf of a domain. They also include a preference value to prioritize multiple mail servers.

  • Purpose: Directs email to the correct mail server(s).
  • Format: domain.com. IN MX preference mail_server_hostname.
  • Example: 
    example.com. IN MX 10 mail.example.com.
example.com. IN MX 20 mail2.example.com.
  • Preference Value: Lower numbers indicate higher preference. If the server with preference 10 is unavailable, email clients will attempt to deliver to the server with preference 20.
  • Requirement: The mail_server_hostname specified in an MX record must resolve to an A or AAAA record. It cannot be a CNAME.

TXT Record (Text Record)

TXT records were originally designed for arbitrary human-readable text. Over time, their utility expanded significantly to include machine-readable data for various verification and security purposes, such as SPF, DKIM, and DMARC.

  • Purpose: Stores arbitrary text strings, often used for domain verification, email authentication, and service configuration.
  • Format: hostname. IN TXT "text_string_data"
  • Examples:
    • SPF (Sender Policy Framework): Helps prevent email spoofing by specifying which mail servers are authorized to send email for a domain. 
      example.com. IN TXT "v=spf1 include:_spf.google.com ~all"
      This SPF record indicates that Google's mail servers are authorized, and others should be treated with suspicion (~all means softfail).
    • DKIM (DomainKeys Identified Mail): Adds a digital signature to outbound emails, verifying the sender and ensuring message integrity. DKIM records are typically generated by email service providers. 
      selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn8/V3sL0..."
    • DMARC (Domain-based Message Authentication, Reporting, and Conformance): Builds upon SPF and DKIM, telling receiving mail servers how to handle messages that fail SPF or DKIM checks, and providing reporting mechanisms. 
      _dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"
      This DMARC record tells recipients to quarantine emails failing SPF/DKIM and send aggregate reports to the specified address.
    • Domain Verification: Many services (e.g., Google Workspace, Microsoft 365, various SSL certificate providers) require adding a specific TXT record to prove domain ownership. 
      example.com. IN TXT "google-site-verification=abc123def456"
  • Length Limits: TXT records can contain multiple strings, each up to 255 characters. If a TXT record needs to be longer, it can be broken into multiple quoted strings (e.g., "part1" "part2"), which are concatenated by the DNS resolver.

SRV Record (Service Record)

SRV records specify the location (hostname and port number) of services for a given domain. They are commonly used by VoIP (SIP), instant messaging (XMPP), and directory services (LDAP) to discover service endpoints.

  • Purpose: Locates specific services (e.g., SIP, XMPP, LDAP) on a domain by specifying hostname and port.
  • Format: _service._proto.name. TTL IN SRV priority weight port target.
  • Example (SIP): 
    _sip._tcp.example.com. IN SRV 10 100 5060 sipserver.example.com.
  • Fields:
    • _service: The symbolic name of the service (e.g., _sip, _xmpp-client).
    • _proto: The transport protocol (e.g., _tcp, _udp).
    • name: The domain name for which this record is valid.
    • priority: Similar to MX records, lower numbers are preferred.
    • weight: For records with the same priority, weight provides load balancing. Higher weight means a higher proportion of connections.
    • port: The TCP or UDP port on which the service is found.
    • target: The canonical hostname of the machine providing the service. This hostname must have an A or AAAA record.
  • Compliance: Many applications are now configured to automatically query SRV records for service discovery, simplifying client configuration.

PTR Record (Pointer Record)

PTR records perform reverse DNS lookups, mapping an IP address back to a domain name. They are crucial for email server validation, network troubleshooting, and some security applications.

  • Purpose: Resolves an IP address to a hostname (reverse DNS).
  • Format (IPv4): IP_address_in_reverse.in-addr.arpa. IN PTR hostname.
  • Format (IPv6): IPv6_address_in_reverse.ip6.arpa. IN PTR hostname.
  • Example (IPv4): For 192.0.2.10, the PTR record is 10.2.0.192.in-addr.arpa. IN PTR mail.example.com.
  • Management: PTR records are managed by the owner of the IP address block. For public IP addresses, this is typically your ISP or cloud provider, not your domain registrar. You must request that they create or update these records in their respective in-addr.arpa (for IPv4) or ip6.arpa (for IPv6) zones.
  • Significance: Many mail servers perform reverse DNS lookups on incoming connections. If the connecting IP's PTR record doesn't match the sender's domain, the email might be flagged as spam or rejected.

NS Record (Name Server Record)

NS records specify the authoritative DNS servers for a domain or subdomain. These are the servers that hold the actual zone files and respond to queries for that domain.

  • Purpose: Delegates a DNS zone to specific name servers.
  • Format: domain.com. IN NS ns1.nameserver.com.
  • Example: 
    example.com. IN NS ns1.registrar.com.
example.com. IN NS ns2.registrar.com.
  • Hierarchy: NS records are typically set at two levels:
    1. At the parent zone (e.g., the .com TLD servers tell resolvers where to find example.com's NS records).
    2. Within the domain's own zone file, listing the authoritative name servers for that domain. This forms the "glue records" essential for delegation.

SOA Record (Start of Authority Record)

Every DNS zone must have exactly one SOA record. It provides essential administrative information about the zone, including the primary name server, the email address of the administrator, and various timers.

  • Purpose: Defines the authoritative properties of a DNS zone.
  • Format: 
    domain.com. IN SOA ns1.nameserver.com. hostmaster.example.com. (
                                2023102701 ; Serial
                                7200       ; Refresh
                                3600       ; Retry
                                1209600    ; Expire
                                3600 )     ; Minimum TTL
  • Fields:
    • ns1.nameserver.com.: Primary name server for the zone.
    • hostmaster.example.com.: Email address of the zone administrator (@ is replaced with .).
    • Serial: A version number for the zone file. Incremented every time the zone file is updated, signaling secondary name servers to perform a zone transfer.
    • Refresh: How often secondary name servers should query the primary for SOA record updates (e.g., 7200 seconds = 2 hours).
    • Retry: If a secondary fails to refresh, how long it should wait before trying again (e.g., 3600 seconds = 1 hour).
    • Expire: If a secondary server fails to refresh for this duration, it should stop answering queries for the zone (e.g., 1209600 seconds = 2 weeks).
    • Minimum TTL: The default TTL for any resource record in the zone that doesn't specify its own TTL. Also used for negative caching (how long a resolver should cache that a record does not exist).

Common Pitfalls

  • CNAME at Apex: Attempting to create a CNAME record for the bare domain (e.g., example.com) is typically problematic as it conflicts with the required SOA and NS records. Use an A/AAAA record or an ALIAS/ANAME record if your DNS provider supports it.
  • Incorrect MX Target: MX records must point to a hostname that has an A or AAAA record, not directly to an IP address or a CNAME.
  • Stale PTR Records: For public IPs, forgetting to request PTR record updates from your ISP or cloud provider can lead to email delivery issues or service authentication failures.
  • Overly Short/Long TTLs: Very short TTLs (e.g., 60 seconds) can increase DNS query load on authoritative servers. Very long TTLs (e.g., 24 hours or more) can delay updates during IP address changes or failovers. Choose a TTL appropriate for the stability and criticality of the service.
  • Missing Trailing Dot: In zone files, hostnames that are not fully qualified (e.g., www instead of www.example.com.) are often appended with the zone origin. Explicitly using a trailing dot (e.g., www.example.com.) ensures the name is treated as fully qualified and prevents unintended appending.

Back to the knowledge base · Ask the AI assistant