liminfo

DNS Record Reference

Free reference guide: DNS Record Reference

20 results

About DNS Record Reference

The DNS Record Reference is a comprehensive, searchable guide to all major DNS resource record types. It covers the five foundational categories: Basic records (A for IPv4, AAAA for IPv6, CNAME for aliases, NS for nameservers, SOA for zone authority, and PTR for reverse lookups), Mail records (MX for mail routing, TXT for SPF sender policy, DKIM public key signatures, and DMARC authentication policy), Security records (CAA to restrict certificate authorities, TLSA for DANE TLS certificate binding, DNSKEY for DNSSEC public keys, DS for delegation signer, and RRSIG for resource record signatures), Service records (SRV for protocol/port-based service discovery and NAPTR for URI/regex-based routing), and Other records (SSHFP for SSH host key fingerprints and LOC for geographic coordinates). Every entry includes the exact zone file syntax as a practical example.

Network administrators, DevOps engineers, security engineers, and web hosting professionals rely on this reference when configuring DNS zones, debugging mail delivery failures, implementing DNSSEC, or setting up DANE. It is also valuable for developers integrating email authentication (SPF, DKIM, DMARC) or restricting SSL/TLS issuance with CAA records. The reference answers the most common questions — such as whether to use an A or CNAME record at the zone apex, or how to structure a DMARC TXT record — with real-world zone file examples.

Records are organized into five filterable categories (Basic, Mail, Security, Service, Other) so you can quickly narrow down to the record type you need. The search bar matches against both record type names and descriptions, making it easy to find, for example, all mail-related record types by searching "mail" or locate SPF details by searching "sender policy". Everything runs client-side in your browser, with no data sent to external servers.

Key Features

  • Basic records: A (IPv4), AAAA (IPv6), CNAME (alias), NS (nameserver), SOA (zone authority), PTR (reverse lookup)
  • Mail authentication: MX routing records plus TXT-based SPF, DKIM public key, and DMARC policy records
  • DNSSEC suite: DNSKEY (public key), DS (delegation signer), RRSIG (record signature), and CAA (CA restriction)
  • DANE security: TLSA record for associating TLS certificates directly with DNS entries
  • Service discovery: SRV records with priority, weight, and port fields; NAPTR for URI-based routing
  • Miscellaneous: SSHFP for SSH key fingerprint verification and LOC for geographic coordinate encoding
  • Five filterable categories (Basic, Mail, Security, Service, Other) for targeted browsing
  • Real zone file syntax examples for every record type — copy-paste ready for bind or cloud DNS providers

Frequently Asked Questions

What is the difference between an A record and a CNAME record?

An A record maps a hostname directly to an IPv4 address (e.g., example.com → 93.184.216.34). A CNAME record creates an alias that points to another hostname rather than an IP address (e.g., www.example.com → example.com). You cannot use a CNAME at the zone apex (the bare domain) because it conflicts with NS and SOA records — use an A record or AAAA record there instead.

How do SPF, DKIM, and DMARC work together?

SPF (TXT record) lists the IP addresses authorized to send mail for your domain. DKIM (TXT record under a selector subdomain) provides a public key that receiving servers use to verify a cryptographic signature added to each email header. DMARC (TXT record at _dmarc.yourdomain) ties them together by specifying a policy (none/quarantine/reject) for messages that fail SPF or DKIM alignment, and an email address for aggregate reports.

What is DNSSEC and which record types does it use?

DNSSEC adds cryptographic authentication to DNS responses. It uses four record types: DNSKEY stores the zone's public signing key, RRSIG holds the digital signature for each resource record set, DS (Delegation Signer) is stored in the parent zone to create a chain of trust to the child zone, and NSEC/NSEC3 prove the non-existence of records. Together they allow resolvers to verify that DNS data has not been tampered with.

What is a CAA record and why is it important?

A CAA (Certification Authority Authorization) record specifies which certificate authorities are allowed to issue SSL/TLS certificates for your domain. For example, setting CAA 0 issue "letsencrypt.org" prevents any CA other than Let's Encrypt from issuing certificates. This mitigates mis-issuance risks from a compromised or rogue CA.

What is an SRV record used for?

SRV records advertise the hostname, port, priority, and weight of servers that provide a specific service and protocol. For example, _sip._tcp.example.com SRV 10 60 5060 sip.example.com tells SIP clients where to find the SIP server. SRV records are used by VoIP (SIP), XMPP chat, Microsoft services (Active Directory, Teams), and other protocols that need dynamic service discovery.

What is a PTR record and when do you need one?

A PTR record performs reverse DNS lookup — mapping an IP address back to a hostname. It lives in the in-addr.arpa. zone (for IPv4) or ip6.arpa. (for IPv6) and is typically managed by your ISP or hosting provider. PTR records are checked by mail servers as an anti-spam measure; missing or mismatched PTR records can cause legitimate email to be rejected.

What is a TLSA record (DANE)?

A TLSA record is part of the DANE (DNS-based Authentication of Named Entities) standard and pins a specific TLS certificate or public key to a service in DNS, protected by DNSSEC. For example, _443._tcp.example.com TLSA 3 1 1 <hash> tells browsers to only accept a certificate matching that hash for HTTPS connections, preventing certificate mis-issuance from a rogue CA.

Can I use this reference to look up record syntax while configuring DNS?

Yes, that is the primary use case. Each entry shows the exact zone file format for the record type so you can reference the correct field order (name, TTL, class, type, rdata) and data format. The examples use realistic values that can be adapted directly to bind-style zone files, AWS Route 53, Cloudflare, or other DNS providers.