DNS does more than translate hostnames into IP addresses. It stores typed information about names: addresses, aliases, mail destinations, authoritative servers, service endpoints, certificate-issuance policy, and other data used by applications and infrastructure.

Each piece of typed information is a resource record, or RR. A client does not simply ask, “What is example.com?” It asks for a particular kind of data associated with that name.

For example:

asks for mail-routing information, while:

asks for IPv6 addresses. The name can be identical while the requested record type and returned data are completely different.

This chapter explains the record types engineers encounter most often and the constraints that make them work correctly.

A node in the DNS namespace can hold several kinds of records at once.

This is not a complete list of what example.com can contain. It illustrates that DNS records attach typed facts to names.

The meaning of the data depends on the type:

DNS itself stores and transports these values. The application using a record decides how to interpret it.

Every resource record has the same outer structure:

NAME is the owner name to which the record belongs.

TYPE identifies how to interpret the data, such as A, MX, or TXT.

CLASS identifies the protocol family. Almost all public DNS data uses the Internet class, written as IN.

TTL is the maximum time, in seconds, for which the record may be reused from a DNS cache. It is part of every resource record even though many zone-file examples inherit it from a default.

RDLENGTH is the size of the type-specific data in the DNS message. It appears in the wire format rather than ordinary zone-file text.

RDATA is the value whose structure depends on TYPE.

A zone-file line commonly uses this presentation format:

For example:

This record belongs to api.example.com, is in the Internet class, has type A, and contains the IPv4 address 192.0.2.10.

The examples in the rest of this chapter omit the TTL when it is not important:

An actual zone still supplies a TTL explicitly or through inherited zone-file configuration.

DNS commonly works with resource record sets, or RRsets, rather than isolated records.

An RRset contains records with the same:

Consider:

These two records form one A RRset for api.example.com. An A query normally returns the applicable RRset, not one permanently designated “primary” address.

RRsets are unordered. A server can present members in different orders, and clients must not assume that the first record is always preferred. Publishing several addresses can distribute some client traffic, but DNS does not automatically check endpoint health or guarantee equal load distribution.

An AAAA record at the same name belongs to a different RRset because its type differs:

A client normally asks for the record types it understands. A query for A does not mean “return every record attached to this name.” An ANY query also should not be treated as a reliable way to fetch all records; servers are allowed to return limited responses to it.

An A record stores one 32-bit IPv4 address:

The mapping reads:

Several A records can exist in the same RRset:

A client can try one of the returned addresses. The DNS data does not state which server is healthy, which is geographically closest, or which currently has spare capacity.

An A record stores only an IPv4 address. It does not contain:

If a service moves from port 443 to port 8443, changing its A record cannot tell a generic client to use the new port.

The letter A historically means address. It does not mean “alias”; DNS aliases use a different record type.

An AAAA record stores one 128-bit IPv6 address:

The name is read as “quad A.” It reflects that an IPv6 address is four times the size of an IPv4 address, not that the record contains four separate A records.

A dual-stack service can publish both address families:

The A and AAAA records remain separate RRsets. A client can query both and choose an address according to its network support and connection strategy.

The IP version used to transport the DNS query is independent of the requested record type. A client can ask for an AAAA record over IPv4 or ask for an A record over IPv6.

Like an A record, an AAAA record contains an address only. It carries no port, protocol, or URL information.

A CNAME record declares that its owner name is an alias for another DNS name:

Here:

If a client requests address information for shop.example.com, resolution follows the alias and obtains the address records for stores.platform.example.net.

The CNAME target must be a domain name, not an IP address:

A CNAME Owns the Entire Name

In ordinary DNS data, a name that owns a CNAME record cannot also own other record types.

This is invalid:

The alias applies to the name as a whole, not only to address queries. Allowing unrelated data at the alias would make it unclear whether clients should use the alias target or the local records.

This restriction is why a standard CNAME normally cannot be placed at a zone apex such as example.com. The apex must already contain SOA and NS records, so it cannot simultaneously be a CNAME owner.

CNAME Chains and Loops

A CNAME target can itself be an alias:

Resolvers can follow such a chain, but each extra step creates more work and another opportunity for failure. A loop can never produce a final result:

CNAME Is Not an Application Redirect

A CNAME changes DNS resolution; it does not send an HTTP redirect or rewrite a URL.

If a user visits https://shop.example.com, a CNAME can help locate the network endpoint, but the browser still treats shop.example.com as the requested hostname. The address bar does not automatically change to the CNAME target.

An MX record identifies a mail exchanger for a domain:

Each record contains:

A lower preference value is tried before a higher value. In the example, senders prefer mail1.example.com; mail2.example.com is a fallback.

Records with the same preference are peers:

The sending mail system chooses among equally preferred exchangers.

The MX target must be a hostname with its own address records:

An MX record must not point directly to an IP address or to a name that is a CNAME. Mail software needs a stable hostname whose addresses it can resolve.

MX records apply to the domain receiving the email. For alice@example.com, senders query MX records for example.com, not www.example.com.

A Domain That Accepts No Email

Merely omitting MX records does not unambiguously say that a domain rejects email. Mail systems can fall back to address records when no MX record exists.

A null MX explicitly declares that the domain accepts no email:

The root target . means that no mail exchanger exists. A null MX must be the domain's only MX record.

A TXT record stores one or more character strings:

TXT was designed as a general text mechanism. Applications now use it for many purposes, including:

DNS does not assign meaning to arbitrary TXT contents. The application looking up the record defines the format.

One Record Can Contain Multiple Strings

Each individual character-string inside a TXT record can contain at most 255 octets. A longer logical value can be split:

For protocols that define concatenation, the consuming application treats this as:

The split does not insert a space.

This is different from publishing two separate TXT records:

Those are two members of one TXT RRset. An application must not blindly concatenate separate records because each record can represent an independent value or protocol.

TXT is convenient, but its flexibility creates ambiguity. Operators must publish it at the exact owner name and in the exact syntax required by the consuming application.

An NS record names an authoritative server for a DNS zone:

The target is a hostname, not an IP address. That hostname must be resolvable through A, AAAA, or necessary glue data.

NS records appear in two closely related places:

For example.com, the parent-side NS RRset in .com directs resolvers toward the child. The child-side NS RRset appears at the example.com zone apex.

The target of an NS record must not be a CNAME alias. Resolvers need to obtain the name server's addresses directly and reliably.

Publishing multiple NS records provides authority through more than one server. All authoritative servers for the zone should serve consistent zone data.

An NS record does not identify a general recursive resolver for end-user devices. It identifies a server authoritative for a zone.

Every DNS zone begins with one Start of Authority, or SOA, record at its apex.

A zone-file representation can look like this:

The SOA contains seven ordered values.

MNAME

This names the zone's designated primary source. It does not mean that this is the zone's only authoritative server.

RNAME

This encodes the responsible party's mailbox. The first unescaped dot represents @, so the example corresponds to:

SERIAL

The serial is the zone version. Secondary authoritative servers compare it with their current copy to determine whether the zone changed.

The value must advance according to DNS serial-number rules. A date-based form such as YYYYMMDDNN is a human convention, not a required DNS format.

REFRESH

This tells secondary servers how often to check the primary source for a newer serial.

RETRY

This tells a secondary how long to wait before trying again after a refresh attempt fails.

EXPIRE

This limits how long a secondary can continue serving its copy when it cannot refresh from its source.

MINIMUM

Despite its historical name, this field is not the default TTL for every record in a modern zone. It participates in determining how long negative answers can be cached.

Most SOA fields coordinate authoritative zone maintenance. Applications resolving ordinary hostnames rarely consume them directly, but an incorrect SOA can disrupt replication or negative-response behavior across the entire zone.

A and AAAA records perform forward lookup:

A PTR record commonly supports reverse lookup:

DNS does not attach records directly to the textual IP address. It converts the address into a name under a dedicated reverse-DNS hierarchy.

For IPv4, the address octets are reversed beneath in-addr.arpa.

The reverse name for:

is:

Its PTR record can be:

IPv6 reverse DNS uses reversed hexadecimal nibbles under ip6.arpa. The representation is longer because all 32 hexadecimal digits of the 128-bit address participate.

Forward and reverse records are independent. Publishing:

does not automatically create the corresponding PTR record. The operator controlling the IP address's reverse zone must publish it separately.

PTR records are useful in logging, diagnostics, and mail-server reputation checks. A PTR result is descriptive DNS data, not cryptographic proof that a machine has a particular identity.

An SRV record publishes the hostname and port for a named service.

The owner name follows this pattern:

For an LDAP service over TCP:

Each record contains:

Priority controls failover. Lower values are preferred, so priority 10 targets are tried before priority 20.

Weight influences selection among records with the same priority. In the example, ldap1 has a larger relative selection weight than ldap2.

Port tells the client where the service listens.

Target is the service hostname. The client resolves its address separately. A target of . states that the service is not available at that name.

An ordinary SRV target must be a canonical hostname with address records rather than a CNAME alias.

SRV works only when the application protocol or client explicitly supports it. A generic TCP client does not automatically look up SRV records, and a web browser does not treat an arbitrary SRV record as permission to replace a URL's port.

SRV provides service discovery at the DNS level, but it does not perform health checks. Publishing a target that is offline can still direct clients toward it.

A Certification Authority Authorization, or CAA, record states which certificate authorities may issue certificates for a domain.

For example:

The record contains:

Flags control how an issuer handles unrecognized properties. A value of 0 is common.

Tag identifies the policy:

Value contains the issuer identifier or tag-specific data.

A domain can explicitly indicate that no certificate authority is authorized:

When no CAA policy exists at the exact name, an applicable policy may be found at an ancestor. This lets an organization place policy higher in its DNS tree.

CAA is an authorization signal used during certificate issuance. It is not a certificate, does not encrypt traffic, and does not tell clients which server address to contact.

Traditional A and AAAA records provide addresses but no connection parameters. SRV provides a port and targets, but applications must define an SRV naming convention and explicitly use it.

The SVCB and HTTPS record types provide a modern, extensible way to describe service endpoints and connection parameters.

An SVCB record has this general form:

For example:

The record can direct a supporting client toward service.example.net, advertise an application protocol, and specify a port.

HTTPS uses the same basic structure with behavior defined for HTTP origins:

Here, target . means to use the owner name, example.com, while applying the supplied service parameters.

Priority 0 selects alias mode, which points toward another service name. A nonzero priority selects service mode, in which the record describes an endpoint. Lower nonzero priorities are preferred.

Possible parameters include supported application protocols, an alternative port, and IPv4 or IPv6 address hints. Address hints are optimization inputs rather than permanent replacements for authoritative A and AAAA data.

Clients must explicitly support SVCB-compatible records. Operators generally retain ordinary address records so clients without support can still connect.

An HTTPS record is not a TLS certificate and does not itself encrypt DNS traffic. Its name describes the service for which the record format is specialized.

DNS providers sometimes offer record-like features named ALIAS, ANAME, or “CNAME flattening.” These are useful, especially when pointing a zone apex toward hosted infrastructure, but they are not standard DNS resource record types sent to clients under those names.

The provider usually resolves the configured target and synthesizes standard address responses:

This avoids placing a forbidden CNAME at a zone apex, but it also means the exact update behavior is provider-specific.

Engineers should distinguish the control-plane feature configured in a provider dashboard from the standard record type visible on the DNS wire.

Start with the information the consuming application needs.

Use A when a name should return an IPv4 address.

Use AAAA when a name should return an IPv6 address.

Use CNAME when one non-apex DNS name should behave as an alias for another name.

Use MX to publish mail exchangers for an email domain.

Use TXT when an application specification requires text at a particular DNS name.

Use NS to name a zone's authoritative servers or establish a delegation.

Use SOA to define the identity and maintenance metadata of a zone.

Use PTR to publish a reverse mapping from an address-derived DNS name to a domain name.

Use SRV when a supporting application needs service targets, ports, priority, and weight.

Use CAA to publish certificate-authority issuance policy.

Use SVCB or HTTPS when a supporting client needs modern service-binding information and connection parameters.

The record must match the behavior of the client that reads it. Publishing a valid record is not useful if the application never queries or understands that type.

Pointing a CNAME directly to an IP address. A CNAME target must be another DNS name.

Combining a CNAME with other data at the same owner. The alias owns the name and cannot coexist with ordinary A, MX, TXT, NS, or similar records there.

Placing a standard CNAME at the zone apex. The apex already requires SOA and NS records.

Pointing MX or NS records at a CNAME. Their targets must be canonical hostnames with address records.

Treating multiple A or AAAA records as a health-aware load balancer. DNS returns addresses but does not inherently remove a failed endpoint.

Assuming a missing MX means no email. A null MX is the explicit no-mail signal.

Concatenating separate TXT records. Only character-string chunks within one TXT record are joined when the consuming protocol defines that behavior.

Forgetting the trailing dot on a target in a zone file. A relative target can have the zone origin appended unexpectedly. mail.example.net inside the example.com zone may become mail.example.net.example.com. unless written as mail.example.net..

Assuming an A record creates a PTR record. Forward and reverse zones are administered independently.

Publishing SRV, SVCB, or HTTPS data for a client that does not support it. DNS cannot make an application consume an unfamiliar record type.

Treating provider-specific ALIAS or ANAME features as standard records. Clients receive the standard records synthesized by the provider, not a portable ALIAS or ANAME RR.

DNS is not only a name-to-IP database. Address records are just two types among many.

A query asks for a name and a type. The same name can return different data for A, MX, TXT, or another requested type.

RRsets are unordered. Record position does not create priority unless the record type defines an explicit priority field.

A means IPv4 address, while AAAA means IPv6 address. Neither contains a port.

CNAME aliases names, not URLs. It does not change an address bar or create an application-layer redirect.

MX preference and SRV priority prefer lower numbers. SRV weight is a separate relative-selection value among equal priorities.

TXT is application-defined. DNS does not understand the semantics of arbitrary TXT content.

NS identifies authoritative servers, not the recursive resolver a laptop should use.

SOA MINIMUM is not a universal default TTL. Its modern role is associated with negative responses.

PTR is not the inverse half of an automatically synchronized mapping. It lives in separately controlled reverse DNS.

CAA does not issue or install a certificate. It constrains which issuers are authorized.

HTTPS is the name of a DNS record type as well as a URL scheme. The record provides service-binding information; it is not an HTTPS response or a certificate.

DNS resource records attach typed data to owner names. Records sharing an owner, class, and type form an unordered RRset.

A and AAAA publish IP addresses. CNAME creates an alias and cannot coexist with ordinary data at its owner. MX identifies prioritized mail exchangers, with null MX rejecting delivery; TXT carries application-defined strings. NS names authoritative servers, SOA defines zone identity and maintenance values, and PTR provides reverse mappings under in-addr.arpa or ip6.arpa.

SRV publishes service targets, ports, priorities, and weights. CAA restricts certificate issuers, while SVCB and HTTPS provide extensible service-binding parameters. Provider features such as ALIAS and ANAME usually synthesize standard records rather than defining portable types.

Choose a record by the question the client needs answered, and ensure the client understands its semantics.