DNS Record Types
Expert-defined terms from the Certified Professional in Domain Name System (DNS) course at London School of Business and Administration. Free to read, free to share, paired with a professional course.
A Record – The fundamental DNS record that maps a domain name to an IP… #
Related terms: AAAA Record, CNAME Record, PTR Record. Explanation: When a resolver queries for “example.Com”, the authoritative server returns an A record containing the 32‑bit address, such as 192.0.2.45. This address is then used by the client to establish a TCP or UDP connection. Practical application: Hosting a web site, email server, or any service that requires a direct IPv4 endpoint. Challenges: Managing large numbers of A records in dynamic environments; ensuring the TTL (Time‑to‑Live) balances between rapid updates and DNS cache efficiency.
AAAA Record – The DNS record that maps a domain name to an IPv6 ad… #
Related terms: A Record, IPv6, Dual‑Stack. Explanation: Similar to the A record but stores a 128‑bit address, for example 2001:0Db8:85A3::8A2e:0370:7334. The AAAA record enables clients that support IPv6 to reach the target host without translation. Practical application: Deploying services on IPv6‑only networks, future‑proofing web infrastructure, and complying with IPv6 adoption policies. Challenges: Ensuring that DNS resolvers and firewalls correctly handle AAAA responses; synchronizing A and AAAA records to avoid “IPv4‑only” or “IPv6‑only” outages.
CAA Record – Certification Authority Authorization record that restricts… #
Related terms: TLSA Record, DNSSEC, PKI. Explanation: A CAA record contains a tag (e.G., “Issue”, “iodef”) and a value (the CA domain). For example, “issue; letsencrypt.Org” tells resolvers that only Let’s Encrypt may issue certificates for the domain. If a CA ignores the CAA policy, the issuance will be flagged as non‑compliant. Practical application: Reducing the risk of unauthorized TLS certificate issuance, meeting compliance requirements such as PCI DSS. Challenges: Keeping CAA records up‑to‑date when multiple CAs are used; handling “iodef” reporting endpoints to receive violation alerts.
CNAME Record – Canonical Name record that creates an alias for another do… #
Related terms: A Record, AAAA Record, Alias. Explanation: When a resolver queries “www.Example.Com” and receives a CNAME pointing to “example.Com”, it must subsequently query for the target name’s A or AAAA records. This indirection allows administrators to point many services to a single target without updating each record individually. Practical application: Load‑balancing via DNS, pointing sub‑domains to cloud‑hosted services, simplifying domain migrations. Challenges: Avoiding CNAME chains that exceed the DNS specification limit of 10 hops; ensuring that CNAME records are not placed at the zone apex, which would break the existence of essential records like SOA and NS.
DS Record – Delegation Signer record used in DNSSEC to link a child zone’… #
Related terms: DNSKEY Record, RRSIG Record, Chain of Trust. Explanation: The DS record contains a hash of the child zone’s DNSKEY (typically using SHA‑256). The parent zone publishes the DS, allowing resolvers to verify that the child zone’s signed data originates from a trusted source. Without a matching DS, the child zone’s DNSSEC signatures will be considered invalid. Practical application: Enabling DNSSEC for delegated sub‑domains, securing public‑suffix lists, and maintaining a hierarchical trust model. Challenges: Managing key rollovers; updating DS records promptly after a DNSKEY change to avoid validation failures.
DNSKEY Record – Holds a public key used to verify DNSSEC signatures for a… #
Related terms: DS Record, RRSIG Record, Key Signing Key (KSK). Explanation: Two types of DNSKEYs are common: The Zone Signing Key (ZSK) signs most records, while the KSK signs the DNSKEY set itself. The DNSKEY record is published in the zone file, enabling resolvers to retrieve the key for signature verification. Practical application: Establishing a secure DNS infrastructure, protecting against cache poisoning, and enabling signed responses for critical services. Challenges: Secure key generation, storage, and rotation; balancing performance (larger keys increase packet size) against security (stronger algorithms).
MX Record – Mail Exchange record that directs email to the appropriate ma… #
Related terms: SMTP, Priority, SPF Record. Explanation: An MX record contains a priority value and a hostname, for example “10 mail.Example.Com”. Lower numbers indicate higher priority. Mail Transfer Agents (MTAs) query DNS for MX records, then attempt delivery to the highest‑priority server, falling back to lower‑priority servers if needed. Practical application: Configuring inbound email routing, implementing redundant mail servers for high availability, and separating inbound/outbound mail processing. Challenges: Maintaining correct priority ordering, handling DNS propagation delays after MX changes, and ensuring that the target host resolves to valid A/AAAA records.
NAPTR Record – Naming Authority Pointer record used for dynamic service d… #
Related terms: SRV Record, ENUM, URI. Explanation: A NAPTR record contains order, preference, flags, service, regexp, and replacement fields. It enables a client to transform a domain name into a URI or another domain name based on the service required. For example, a NAPTR entry may map “example.Com” to a SIP URI “sip:Service@example.Com”. Practical application: Voice over IP (VoIP) service location, telephone number mapping (ENUM), and protocol‑agnostic service discovery. Challenges: Proper ordering of NAPTR and SRV records, handling complex regular‑expression replacements, and ensuring that fallback mechanisms are defined.
NS Record – Name Server record that designates authoritative DNS servers… #
Related terms: SOA Record, Delegation, Glue Record. Explanation: Each zone must have at least two NS records, such as “ns1.Example.Net” and “ns2.Example.Net”. The NS records are stored both at the parent zone (to delegate authority) and within the child zone (to inform resolvers of the authoritative servers). Practical application: Delegating sub‑domains, load‑balancing queries across multiple name servers, and providing redundancy. Challenges: Keeping NS records synchronized between parent and child zones, handling “lame delegation” where a listed name server is not authoritative, and managing glue records for in‑zone name servers.
PTR Record – Pointer record used for reverse DNS lookups, mapping an IP a… #
Related terms: A Record, Reverse Zone, rDNS. Explanation: In the in‑addr.Arpa (IPv4) or ip6.Arpa (IPv6) namespace, a PTR record resolves an address like “45.2.0.192.In‑addr.Arpa” to “example.Com”. Reverse DNS is often used for spam filtering, network diagnostics, and compliance checks. Practical application: Verifying mail server legitimacy, troubleshooting connectivity issues, and enforcing security policies that require matching forward and reverse records. Challenges: Coordinating PTR entries across multiple ISPs, ensuring that forward and reverse mappings are consistent, and handling dynamic IP address allocations.
RRSIG Record – Resource Record Signature that provides a cryptographic si… #
Related terms: DNSKEY Record, DS Record, Signature Expiration. Explanation: Each signed RRSet (e.G., All A records for a name) is accompanied by an RRSIG containing the signing key tag, algorithm, validity period, and the actual signature. Validating resolvers retrieve the DNSKEY, compute the hash of the RRSet, and verify the signature. Practical application: Enabling DNSSEC validation, protecting against cache poisoning, and ensuring data integrity for critical zones. Challenges: Managing signature lifetimes to avoid expired signatures, handling key rollovers without service disruption, and dealing with larger packet sizes that may trigger UDP truncation.
SOA Record – Start of Authority record that defines zone‑wide parameters… #
Related terms: NS Record, Serial Number, Refresh Interval. Explanation: The SOA contains the primary master server’s hostname, the responsible party’s email (with “.” Replacing “@”), and several timers: Serial, refresh, retry, expire, and minimum TTL. The serial number is incremented with each change, enabling secondary servers to detect updates. Practical application: Controlling zone transfers, coordinating primary/secondary server synchronization, and setting default TTL values for the zone. Challenges: Properly incrementing the serial (e.G., Using YYYYMMDDnn format), selecting appropriate refresh/retry intervals to balance load and timeliness, and preventing “zone slip” where secondary servers fall out of sync.
SRV Record – Service record that specifies the location of servers for a… #
Related terms: NAPTR Record, Port Number, Priority. Explanation: An SRV entry includes service, protocol, priority, weight, port, and target. For example, “_sip._Tcp.Example.Com 10 60 5060 sipserver.Example.Com” directs SIP clients to connect via TCP to port 5060 on the specified host. The weight field enables load‑balancing among servers with the same priority. Practical application: Locating VoIP, XMPP, LDAP, and other service endpoints without hard‑coding hostnames or ports; supporting failover and weighted distribution. Challenges: Correctly configuring priority and weight to achieve desired load‑balancing, ensuring that target hosts have matching A/AAAA records, and handling client implementations that may ignore SRV data.
TLSA Record – Transport Layer Security Authentication record defined by D… #
Related terms: DNSSEC, DANE, Certificate Pinning. Explanation: The TLSA record contains usage, selector, matching type, and certificate association data. For instance, a TLSA with usage 3 (DANE‑EE) and selector 1 (SPKI) may store a SHA‑256 hash of a server’s public key. Resolvers that validate DNSSEC can then verify the TLS handshake against the TLSA data, providing end‑to‑end authentication without relying on third‑party CAs. Practical application: Securing mail (SMTP) with DANE, protecting web services against rogue certificates, and enabling zero‑trust architectures. Challenges: Deploying DNSSEC across the entire delegation chain, managing key rollovers for TLS certificates, and handling client compatibility with DANE.
TXT Record – Text record that stores arbitrary human‑readable or machine‑… #
Related terms: SPF Record, DKIM, DMARC. Explanation: TXT records are often used to publish policy information. For example, an SPF TXT entry like “v=spf1 ip4:192.0.2.0/24 -All” tells receiving mail servers which IP ranges are authorized to send mail for the domain. Multiple TXT strings can be concatenated by the resolver. Practical application: Email authentication (SPF, DKIM, DMARC), domain ownership verification for SSL/TLS certificates, and publishing miscellaneous configuration data. Challenges: Length limits (255 characters per string, up to 4 KB total), ensuring correct syntax for SPF/DKIM, and avoiding conflicts when multiple services require TXT records for the same sub‑domain.
NAPTR Record – (Repeated entry omitted; ensure each term appears only onc… #
)
AAAA Record – (Repeated entry omitted; ensure each term appears only once #
)
CAA Record – (Repeated entry omitted; ensure each term appears only once #
)
MX Record – (Repeated entry omitted; ensure each term appears only once #
)
NSEC Record – Negative Security record that proves the non‑existence of a… #
Related terms: DNSSEC, NSEC3 Record, Authenticated Denial of Existence. Explanation: When a resolver queries for a name that does not exist, the authoritative server returns an NSEC record that links the closest existing name to the next name in canonical order, covering the queried type. This allows the resolver to cryptographically confirm that the name truly does not exist. Practical application: Preventing zone walking attacks, providing proof of non‑existence for security policies, and supporting full DNSSEC validation. Challenges: Managing large zones where NSEC records can expose the entire zone’s name list; mitigating privacy concerns by using NSEC3 instead.
NSEC3 Record – Hashed version of NSEC that provides authenticated denial… #
Related terms: NSEC Record, Salt, Iterative Hashing. Explanation: NSEC3 hashes zone names using a salt and a configurable number of iterations, then publishes NSEC3 records linking hashed names. When a resolver receives a negative response, it hashes the queried name with the same parameters and verifies the proof. Practical application: Enhancing privacy for large zones (e.G., Top‑level domains), complying with best‑practice DNSSEC recommendations, and reducing exposure of internal naming structures. Challenges: Selecting appropriate iteration counts to balance security and performance, handling key rollovers that require re‑hashing, and ensuring resolvers support NSEC3 validation.
PTR Record – (Repeated entry omitted; ensure each term appears only once #
)
RRSIG Record – (Repeated entry omitted; ensure each term appears only onc… #
)
SOA Record – (Repeated entry omitted; ensure each term appears only once #
)
SRV Record – (Repeated entry omitted; ensure each term appears only once #
)
TXT Record – (Repeated entry omitted; ensure each term appears only once #
)
TTL – Time‑to‑Live, a field present in most DNS records that dictates how… #
Related terms: Cache, Refresh Interval, Negative Caching. Explanation: TTL is expressed in seconds; a typical value might be 3600 (one hour). When the TTL expires, the resolver discards the cached data and re‑queries the authoritative server. Short TTLs allow rapid updates but increase query load; long TTLs reduce traffic but may cause stale data to persist. Practical application: Tuning TTL for services that change IPs frequently (e.G., CDNs) versus static services (e.G., Corporate websites). Challenges: Balancing performance with agility, handling TTL mismatches across different record types, and dealing with “TTL creep” where administrators unintentionally set excessively high values.
Wildcard Record – A DNS record that uses an asterisk (*) as the left‑most… #
Related terms: CNAME Record, A Record, DNS Hijacking. Explanation: A wildcard such as “*.Example.Com A 203.0.113.10” Will cause queries for “foo.Example.Com” or “bar.Example.Com” to return the same address if no explicit record exists. This feature simplifies configuration for large numbers of sub‑domains. Practical application: Catch‑all web hosting, providing default services for unregistered sub‑domains, and reducing administrative overhead. Challenges: Unexpectedly serving traffic for typo‑domains, interfering with legitimate sub‑domain delegation, and ensuring that explicit records correctly override the wildcard.
Zone Transfer – The process by which a secondary DNS server obtains a cop… #
Related terms: AXFR, IXFR, Secondary Server. Explanation: A full zone transfer (AXFR) transmits the entire zone file, while an incremental transfer (IXFR) sends only the changes since the last known serial. Transfers are typically protected by IP‑based ACLs to prevent unauthorized data extraction. Practical application: Maintaining redundancy, distributing load across multiple authoritative servers, and enabling geographically dispersed name servers. Challenges: Securing transfers against zone‑enumeration attacks, handling large zones that exceed UDP packet limits (requiring TCP), and ensuring that serial numbers are correctly incremented for reliable synchronization.
AXFR – Full zone transfer protocol used by DNS to copy an entire zone fro… #
Related terms: IXFR, TCP Transport, Access Control List (ACL). Explanation: AXFR is invoked when a secondary server detects a serial number change and needs the complete data set. The transfer occurs over TCP to guarantee reliable delivery. Because the entire zone is exposed, AXFR is a valuable source of information for attackers if not properly restricted. Practical application: Initial provisioning of secondary servers, backup of zone data, and debugging zone consistency. Challenges: Configuring firewalls to allow TCP port 53 only from trusted secondary servers, limiting exposure of internal hostnames, and managing bandwidth consumption during large transfers.
IXFR – Incremental zone transfer protocol that sends only the differences… #
Related terms: AXFR, Serial Number, Delta Records. Explanation: IXFR reduces bandwidth by transmitting only added, modified, or removed records since the last known serial. The secondary server issues an IXFR request specifying the current serial; the master responds with one or more “diff” sections. Practical application: Efficiently updating secondary servers for high‑traffic zones, minimizing network impact, and supporting rapid roll‑outs of DNS changes. Challenges: Ensuring that both master and slave correctly track serial numbers, handling cases where the slave’s serial is too far behind (requiring fallback to AXFR), and dealing with implementation quirks in some DNS software.
DNSSEC – DNS Security Extensions that provide data integrity and authenti… #
Related terms: RRSIG Record, DS Record, Chain of Trust. Explanation: DNSSEC adds cryptographic signatures to DNS data, allowing resolvers to verify that responses have not been tampered with. It does not encrypt data; instead, it ensures authenticity via public‑key signatures. The trust chain starts at the root zone and extends through each delegated zone via DS records. Practical application: Preventing cache poisoning, securing critical infrastructure (e.G., Banking domains), and meeting regulatory mandates for DNS integrity. Challenges: Deploying DNSSEC across the entire delegation hierarchy, managing key rollovers without downtime, handling increased response size that may trigger fragmentation, and educating stakeholders about the benefits and limitations.
EDNS0 – Extension mechanisms for DNS that allow larger packet sizes and a… #
Related terms: UDP Payload Size, DNSSEC, OPT Record. Explanation: EDNS0 introduces the OPT pseudo‑record, which specifies the maximum UDP payload the client can accept (commonly 4096 bytes). This is essential for DNSSEC because signed responses often exceed the classic 512‑byte limit. EDNS0 also enables future extensions, such as client subnet information. Practical application: Supporting DNSSEC validation, enabling DNS‑based load‑balancing extensions, and providing a framework for upcoming protocol enhancements. Challenges: Ensuring that firewalls and middleboxes allow larger UDP packets, handling fallback to TCP when fragmentation occurs, and mitigating DNS amplification attacks that exploit oversized responses.
OPT Record – The pseudo‑record used by EDNS0 to convey extended DNS param… #
Related terms: EDNS0, UDP Payload Size, Extended Flags. Explanation: The OPT record appears at the end of a DNS message and contains fields for payload size, extended RCODE, version, and optional data. It does not carry a name or TTL and is ignored by legacy resolvers that do not understand EDNS0. Practical application: Negotiating larger response buffers, signaling support for DNSSEC, and transmitting client subnet data for geo‑targeted responses. Challenges: Detecting and handling malformed OPT records, preventing abuse in amplification attacks, and ensuring compatibility with older DNS implementations.
Glue Record – An A or AAAA record placed in the parent zone to resolve th… #
Related terms: NS Record, Delegation, In‑zone Name Server. Explanation: When “ns1.Example.Com” is an authoritative server for “example.Com”, the parent zone (e.G., “.Com”) must provide a glue A record for “ns1.Example.Com” so that resolvers can reach the server without needing an additional lookup. Without glue, a circular dependency would prevent resolution. Practical application: Hosting authoritative name servers on the same domain they serve, reducing lookup latency, and ensuring reliable bootstrapping of the DNS hierarchy. Challenges: Keeping glue records synchronized with the actual A/AAAA records, handling changes to IP addresses of in‑zone name servers, and avoiding stale glue that leads to resolution failures.
Negative Caching – The practice of storing the results of a DNS query tha… #
Related terms: TTL, NSEC Record, Cache Poisoning. Explanation: When a resolver receives a response indicating that a name does not exist, it caches this negative result for the duration specified by the SOA’s minimum TTL (or the “negative TTL” field in newer RFCs). This reduces unnecessary traffic for repeated queries of nonexistent names. Practical application: Improving resolver efficiency, reducing load on authoritative servers, and limiting the impact of typographical errors. Challenges: Ensuring that legitimate changes (e.G., Newly created sub‑domains) propagate promptly despite cached negative entries, and protecting against malicious manipulation of negative caching to cause denial of service.
Forwarding – A DNS server configuration where queries are sent to another… #
Related terms: Recursive Resolver, Stub Resolver, Cache. Explanation: A forwarding server receives a query, forwards it to the designated upstream server, receives the answer, caches it, and returns it to the client. Forwarding can be unconditional (all queries) or conditional (specific domains). Practical application: Centralizing DNS policy enforcement, reducing external traffic, and providing a single point for DNS logging and security controls. Challenges: Managing latency introduced by additional hops, ensuring that forwarders support DNSSEC validation if required, and handling loops where forwarders inadvertently send queries back to the original server.
Recursive Resolver – A DNS server that performs the full lookup process o… #
Related terms: Stub Resolver, Cache, Iterative Query. Explanation: Upon receiving a query, the recursive resolver checks its cache; if the answer is absent, it queries the root servers, then follows NS records down the hierarchy until it obtains the final answer. The resolver may employ parallel queries and prefetching to improve performance. Practical application: ISP DNS services, corporate DNS infrastructure, and public resolvers like Google Public DNS. Challenges: Scaling to handle millions of queries per second, protecting against cache poisoning, implementing rate limiting to mitigate DDoS attacks, and supporting DNSSEC validation.
Stub Resolver – A minimal DNS client that forwards queries to a recursive… #
Related terms: Recursive Resolver, Resolver Library, System DNS Settings. Explanation: The stub resolver typically resides on end‑user devices (e.G., Computers, smartphones). It constructs a DNS query packet, sends it to the configured recursive server (often via UDP port 53), and displays the received answer to the application. Practical application: Operating system DNS configuration, application‑level DNS lookups, and embedded device networking. Challenges: Handling network failures gracefully, supporting IPv6 transport, and ensuring that the stub does not bypass security policies enforced by the recursive resolver.
TTL – (Repeated entry omitted; ensure each term appears only once #
)
Wildcard Record – (Repeated entry omitted; ensure each term appears only… #
)
Zone – A distinct portion of the DNS namespace administered as a single e… #
Related terms: SOA Record, NS Record, Authority. Explanation: A zone begins at a domain name (the zone apex) and includes all child domains unless a delegation (NS record) delegates authority elsewhere. Zones are stored in zone files, which define the resource records and their TTLs. Practical application: Partitioning DNS management responsibilities, isolating administrative domains, and enabling distributed control across different organizations. Challenges: Avoiding “lame delegation” where a parent NS points to a server that is not authoritative, handling zone cuts that create separate zones, and coordinating serial number updates across multiple administrators.
Zone Apex – The topmost name in a DNS zone, often identical to the domain… #
G., “Example.Com”). Related terms: SOA Record, NS Record, Wildcard Record. Explanation: At the zone apex, essential records such as SOA and NS must exist. Certain record types (e.G., CNAME) are prohibited at the apex because they would conflict with the required records. The apex serves as the anchor point for the zone’s authority. Practical application: Defining the primary point of delegation for a domain, configuring DNS hosting services that provide apex support for cloud load balancers, and establishing DNSSEC signing keys. Challenges: Implementing aliasing at the apex using provider‑specific solutions (e.G., “ANAME” or “ALIAS” records) while respecting protocol restrictions, and ensuring that apex records are consistently replicated across all authoritative name servers.
Zone Transfer – (Repeated entry omitted; ensure each term appears only on… #
)
AXFR – (Repeated entry omitted; ensure each term appears only once #
)
IXFR – (Repeated entry omitted; ensure each term appears only only once #
)
EDNS0 – (Repeated entry omitted; ensure each term appears only once #
)
OPT Record – (Repeated entry omitted; ensure each term appears only once #
)
Glue Record – (Repeated entry omitted; ensure each term appears only once #
)
Negative Caching – (Repeated entry omitted; ensure each term appears only… #
)
Forwarding – (Repeated entry omitted; ensure each term appears only once #
)
Recursive Resolver – (Repeated entry omitted; ensure each term appears on… #
)
Stub Resolver – (Repeated entry omitted; ensure each term appears only on… #
)
Zone – (Repeated entry omitted; ensure each term appears only once #
)
Zone Apex – (Repeated entry omitted; ensure each term appears only once #
)