1 Structure of a resource record

A DNS resource record is the basic unit of stored data in the Domain Name System. It associates a domain name with one or more pieces of information needed for name resolution or related functions. Although different record types carry different payloads, most share a common layout that makes them easy for DNS software to parse, cache, and transmit.

1.1 Owner name

The owner name identifies the domain name to which the record applies. It is the label or set of labels queried by a client, such as a host name, service name, or delegated zone name. In zone files, the owner name may be written in full or inherited from a preceding line through shorthand syntax.

1.2 Type field

The type field specifies the kind of data carried by the record. Common types include address mappings, mail routing entries, service location data, and delegation records. The type determines how the remaining data is interpreted and whether the record is usable in a given context.

1.3 Class field

The class field identifies the namespace or protocol family to which the record belongs. In practice, the Internet class is used for nearly all modern DNS records, while other classes are limited to specialized or historical uses. The class helps DNS distinguish ordinary Internet records from alternative naming systems.

1.4 Time to live

The time to live, often abbreviated TTL, indicates how long a resolver may cache the record before refreshing it. It is expressed in seconds and directly affects performance, traffic, and propagation timing. Short TTL values lead to more frequent lookups, while longer values reduce query load but delay updates.

1.5 RDATA field

The RDATA field contains the record’s type-specific content. For an address record, this may be an IP address; for a mail record, it may be a preference and target host; for a security record, it may contain cryptographic material. The meaning of RDATA is defined entirely by the record type.

1.5.1 Type-specific formats

Each DNS record type has its own format rules. Some use fixed-length binary fields, while others use domain names, text strings, or combinations of both. These type-specific formats allow DNS to represent a wide range of information without changing the overall record structure.

1.5.2 Encoding and length rules

RDATA is encoded according to DNS wire-format conventions, which are optimized for compact transmission. Length fields are used where needed, and domain names may be compressed in some message contexts. Parsers must obey the syntax of each record type, since malformed lengths or invalid encodings can cause lookup failures.

2 Common DNS resource record types

DNS defines many record types, but a relatively small set accounts for most everyday use. These records support address translation, mail delivery, delegation, aliasing, and service discovery. Their behavior shapes how most Internet applications locate servers and services.

2.1 Address records

Address records map names to IP addresses. They are among the most frequently queried DNS records and are central to connecting a readable domain name with a network endpoint.

2.1.1 A record

The A record maps a hostname to an IPv4 address. It is used when clients need to reach a server on the IPv4 Internet. A single name may have multiple A records to distribute traffic across several addresses.

2.1.2 AAAA record

The AAAA record maps a hostname to an IPv6 address. It serves the same basic purpose as an A record but for the IPv6 protocol. Many hosts publish both A and AAAA records to support dual-stack connectivity.

2.2 Mail exchange records

Mail-related DNS records direct message delivery to the correct server. They allow sending systems to determine where email for a domain should be routed.

2.2.1 MX record

The MX record identifies the mail server responsible for receiving email for a domain. It includes a preference value, where lower numbers generally indicate higher priority. If multiple MX records exist, mail systems can use them for redundancy and load distribution.

MX records are closely tied to SMTP, the protocol used for sending email between servers. A sending system queries DNS to find the MX targets for a recipient domain, then connects to one of those servers. If no MX record is present, some systems fall back to the domain’s address records, depending on protocol rules and local policy.

2.3 Name server and delegation records

Delegation records describe which servers are authoritative for a zone. They form the backbone of DNS hierarchy and enable responsibility for subdomains to be distributed across different operators.

2.3.1 NS record

The NS record identifies authoritative name servers for a zone. Delegating a domain or subdomain typically requires a set of NS records pointing to the servers that answer for that zone. Resolvers follow these referrals to continue the lookup process.

2.3.2 SOA record

The SOA record, or Start of Authority record, marks the top of a zone and supplies administrative and timing information. It includes fields such as the primary master server, a responsible mailbox, and serial and refresh parameters. The SOA record is also used in caching behavior and zone transfer management.

2.3.3 Glue records

Glue records are address records supplied in the parent zone to help resolvers reach delegated name servers whose names lie within the delegation itself. They prevent circular dependence during lookups. Glue is not a separate record type, but a practical use of A and AAAA data in delegation contexts.

2.4 Alias and canonical name records

Alias records let one domain name refer to another. They are useful when a service should be reachable under multiple names or when the true target may change over time.

2.4.1 CNAME record

The CNAME record declares one name as an alias for another canonical name. Queries to the alias are redirected to the target name, which then resolves normally. A CNAME cannot coexist with other data at the same owner name in standard DNS use.

2.4.2 DNAME record

The DNAME record aliases an entire subtree of the namespace to another location. Unlike CNAME, which affects one name, DNAME applies to all names beneath the owner name. It is used less often, but it can simplify large-scale renaming of domain structures.

2.5 Service discovery records

Service discovery records help clients locate specific services rather than just hosts. They are especially useful in environments where a service runs on a nonstandard port or on multiple endpoints.

2.5.1 SRV record

The SRV record identifies a service, protocol, target host, and port number. It also includes priority and weight values to guide selection among several candidates. Many application protocols use SRV to find servers dynamically without hard-coding ports.

2.5.2 URI record

The URI record provides a service location in the form of a Uniform Resource Identifier. It can indicate a named service endpoint and may include selection parameters. Though less widely deployed than SRV, it serves similar discovery purposes for some applications.

2.6 Text and policy records

Text-based records carry arbitrary or semi-structured information. They are often used for verification, policy signaling, and service metadata.

2.6.1 TXT record

The TXT record stores one or more character strings. It is flexible enough to hold verification tokens, descriptive text, and application-specific metadata. Many services use TXT records for domain ownership checks and configuration hints.

TXT records were historically used to publish SPF data for mail authentication. SPF states which hosts are allowed to send mail on behalf of a domain. Modern practice prefers dedicated SPF processing rules while still relying on TXT storage in many deployments.

3 Resource record classes

DNS classes define the logical context in which records exist. Most records today use the Internet class, but the class field remains part of the protocol for completeness and compatibility.

3.1 IN class

The IN class, short for Internet, is the standard class for public DNS records. Nearly all common host, mail, service, and security records belong to this class. In ordinary use, “DNS record” usually implies an IN-class record.

3.2 CH class

The CH class, originally associated with the Chaos network class, is now mainly of historical or specialized interest. It is occasionally used for diagnostic or experimental purposes. Few modern applications rely on it.

3.3 HS class

The HS class, associated with Hesiod, is another legacy class with limited contemporary use. It was developed for an older distributed naming environment. In modern DNS operations, it is encountered far less often than the IN class.

4 DNS record processing

DNS software reads, stores, forwards, and caches records as part of query handling. Processing rules determine how records are represented in zone data, how answers are assembled, and how caches behave over time.

4.1 Zone files and master file syntax

Zone files, sometimes called master files, are human-readable text files used to define authoritative DNS data. They include directives, owner names, TTL values, classes, types, and RDATA content in a standardized format. Administrators use them to maintain zones before loading data into authoritative servers.

4.2 Answer, authority, and additional sections

DNS responses are divided into sections that separate the direct answer from supporting information. The answer section contains the requested records, the authority section may identify which zone or server is authoritative, and the additional section can include helpful companion records such as address data for name servers. This structure reduces follow-up queries.

4.3 Caching and TTL behavior

Resolvers store records in cache for the duration indicated by TTL. Caching improves performance and reduces repeated traffic to authoritative servers. When the TTL expires, the resolver must query again to obtain fresh data, which is especially important after configuration changes.

4.4 Negative caching

Negative caching stores the fact that a queried name or record type does not exist, rather than only caching positive answers. This avoids repeated lookups for missing data. The SOA record often governs how long a negative result may be cached.

5 Operational uses

Resource records are not just a technical abstraction; they support everyday Internet functions. Their arrangements determine how users reach web sites, send mail, and discover services.

5.1 Hostname resolution

Hostname resolution converts a domain name into an IP address. This is the most familiar DNS task and typically uses A or AAAA records. Without this mapping, users would need to remember numeric addresses rather than names.

5.2 Mail routing

Mail routing depends on MX records and related fallback behavior. A mail server consults DNS to determine where to deliver messages for a recipient domain. This indirection allows mail hosting to be separated from web hosting and makes infrastructure changes easier to manage.

5.3 Service location

Service location records help clients find the correct host and port for an application. SRV and related records support this by identifying endpoints in a flexible way. This can be useful for clustered services, directory protocols, and enterprise applications.

5.4 Domain delegation

Domain delegation divides authority across the DNS hierarchy. NS and SOA records identify the servers responsible for a zone and support administrative control over subdomains. Delegation is one of the core features that makes DNS scalable across the global namespace.

6 Extensions and protocol evolution

DNS has evolved beyond its original record set to support larger messages, stronger validation, and more complex operational needs. Extensions preserve compatibility while adding new capabilities.

6.1 EDNS and record handling

EDNS, or Extension Mechanisms for DNS, expands the practical limits of DNS messages and enables additional features. It allows larger payloads than the original protocol design and supports options that improve transport and negotiation. Although EDNS is not itself a record type, it affects how records are carried and processed.

DNSSEC adds cryptographic protection to DNS data. Its records support signing, key distribution, and authenticated denial of existence, helping resolvers verify that responses have not been altered in transit.

6.2.1 DNSKEY

The DNSKEY record stores public keys used in DNSSEC. These keys verify signatures over DNS data and form part of a zone’s trust chain. A zone may publish more than one DNSKEY for operational flexibility.

6.2.2 RRSIG

The RRSIG record contains a digital signature for a set of resource records. Validators use it to confirm that a signed RRset was produced by the legitimate zone holder. It is paired with DNSKEY records during verification.

6.2.3 DS

The DS record links a child zone to its parent in the DNSSEC chain of trust. It contains a digest of a DNSKEY from the child zone, allowing authenticated delegation. This record is crucial for secure validation across zone boundaries.

6.2.4 NSEC and NSEC3

NSEC and NSEC3 provide authenticated denial of existence, showing that a queried name or record type does not exist in a signed zone. NSEC lists the next existing name in canonical order, while NSEC3 uses hashed names to reduce easy zone enumeration. Both support secure negative responses.

7 Troubleshooting and diagnostics

DNS records are often examined when names fail to resolve, mail is rejected, or a service cannot be found. Diagnostic tools and response interpretation help administrators identify problems quickly.

7.1 Query tools

Common tools such as dig, nslookup, and host are used to query DNS records directly. They reveal returned data, TTL values, response codes, and delegation paths. Administrators rely on them to test zone changes and isolate configuration errors.

7.2 Common configuration issues

Typical DNS problems include missing records, incorrect targets, conflicting aliases, and stale cache data. Misplaced glue, wrong MX preferences, or inconsistent name server settings can also disrupt service. Careful comparison between zone files and live responses often exposes the fault.

7.3 Interpreting record responses

Interpreting DNS responses requires reading both the record data and the response metadata. A successful answer may still contain multiple records with different roles, while a referral or negative reply indicates a different path. Understanding sections, TTLs, and response codes helps distinguish authoritative data from cached or supplemental information.