DNS record types identify what information a name publishes. An A record associates a name with an IPv4 address, while an MX record at the same name describes where mail should be delivered. A DNS question specifies the name, type, and class, so changing the requested type can produce a different answer.

In a record listing, the owner name is the name to which the record belongs. Read that name together with the type before interpreting the value: a hostname in an MX record serves a different purpose from one in a CNAME record. The examples below use documentation names and addresses to illustrate the format.

Address and Alias Records

  • A maps a DNS name to one IPv4 address. A name may have several A records. The presence of an A record says nothing by itself about whether a web server is listening at that address.
  • AAAA maps a name to one IPv6 address. A and AAAA records belong to separate record sets, so a name may publish either family, both, or neither.
  • CNAME declares one name an alias of another name. A resolver follows the alias when looking for data such as an address at the target. A CNAME owner cannot also hold ordinary data of other types, although certain DNSSEC security records can coexist with it.
  • PTR points from one DNS name to another. In reverse DNS, it associates a name derived from an IP address with a hostname. A PTR answer is not proof that the forward name points back to the same address.

The zone apex is the highest name in a DNS zone, such as example.com in the example.com zone. Because that name must have SOA and NS records, it cannot also be an ordinary CNAME. This restriction applies to the record's owner name, not to a hostname merely mentioned inside another record.

Reverse DNS uses names under in-addr.arpa for IPv4 and ip6.arpa for IPv6. An address lookup for www.example.com and a reverse lookup for its address therefore query different names. Changing the website's A record does not automatically update the PTR record maintained in the reverse zone.

Mail, Service, and Text Records

  • MX normally names a mail exchanger for a domain and carries a preference value. Sending mail servers prefer exchangers with lower preference numbers. A null MX instead uses preference 0 and a single dot as its target to declare that the domain accepts no mail.
  • TXT stores one or more character strings as DNS data. The application using them determines their meaning: verification tokens, SPF email policies, and other protocols can all use TXT. A TXT record needs the syntax expected by its application to serve that purpose.
  • SRV identifies a service endpoint by hostname and port. Its query name identifies the service and transport protocol, while priority and weight guide endpoint selection. Clients prefer a reachable target with the lowest priority number, then use weights to select among targets at that priority.
  • HTTPS and SVCB provide service binding information to clients that support them. HTTPS is the type used for HTTP origins, allowing a supporting browser to discover connection parameters or an alternate endpoint. The records do not themselves establish that the endpoint has a valid certificate.

An MX or SRV record that identifies a server must point to a name with address records rather than a CNAME alias. A client still needs an address for the chosen target, and a successful DNS response does not establish that the mail or application service is running. An SRV target consisting of a single dot declares that the service is unavailable. SRV discovery applies when the application protocol specifies its use, so adding an SRV record does not make every client query it.

HTTPS and SVCB have two modes. AliasMode directs the client to another name for service binding information, while ServiceMode supplies connection parameters for an endpoint. AliasMode can be used at a zone apex because it aliases a service rather than making the entire owner name a CNAME.

Zone Authority and Security Records

  • NS names an authoritative nameserver for a zone or a delegation to a child zone. The server's address is separate from the NS record and may need its own A or AAAA lookup.
  • SOA contains administrative fields for a DNS zone, including a primary server name, an encoded contact mailbox, a serial number, and timers. The serial identifies a zone version, while refresh, retry, and expire values govern how secondary authoritative servers maintain their copies.
  • CAA lets a domain holder specify which certificate authorities may issue certificates under the applicable CAA policy. It does not issue or install a certificate, and browsers do not use it to validate the certificate a website presents.
  • DNSKEY, DS, and RRSIG support DNSSEC validation. DNSKEY publishes a public key, DS identifies a key using a digest and related fields, and RRSIG carries a digital signature covering a record set.

In a signed delegation, the DS record belongs to the parent zone, while the corresponding DNSKEY belongs to the child zone. A validating resolver checks the chain of trust and the signatures to authenticate DNS data. DNSSEC protects the authenticity and integrity of that data, but it does not encrypt an ordinary DNS query.

The SOA timers serve a different purpose from the cache lifetime of an A or MX answer. They help secondary authoritative servers check for zone updates and determine when an unrefreshed copy must expire. They do not set a universal schedule for recursive resolvers to refresh every cached record.

What an RRset Means

An RRset is the set of resource records sharing the same owner name, class, and type. For example, two A records for www.example.com in the Internet class belong to one A RRset. An AAAA record at that name is a different RRset, as is an A record at mail.example.com. Records within an RRset must have the same TTL.

RRSIG records are a special case: signatures at one name do not form an ordinary RRset of their own. Each signature's TTL follows the RRset it covers, so signatures for different types at one name can have different TTLs.

A complete response includes all members of the relevant RRset. If a required RRset will not fit in the response, the server must indicate truncation rather than silently present one member as the whole set. Several addresses in one A or AAAA RRset therefore do not, by themselves, indicate conflicting DNS data.

Multiple A records have no built-in preference order. Their displayed order does not carry the meaning that MX preference or SRV priority fields do. Application behavior and network conditions help determine which address a client uses.

In the example www.example.com. 3600 IN A 192.0.2.10, the fields show the owner name, TTL, Internet class, record type, and IPv4 address. The TTL value is in seconds, so 3600 allows an ordinary cache lifetime of up to one hour. It does not promise that every resolver will show a DNS change at the same instant. Compare the authoritative record with a cached answer's remaining TTL when investigating an old value.

URI, RP, and HINFO Records

  • URI publishes a uniform resource identifier, such as a service URL, with priority and weight fields. A client prefers a reachable target with the lowest priority number and uses weights among targets at that priority. An application must deliberately query and use this record, so publishing one does not automatically redirect a web browser.
  • RP identifies a responsible person's mailbox using a DNS name and can point to a name with TXT records containing further contact information. The mailbox uses the same encoding as the SOA contact field. RP provides an administrative contact rather than a route for delivering email.
  • HINFO carries strings describing a host's CPU and operating system. These are published DNS values, so an HINFO answer is not a live inspection of the host's current hardware or software.

A record type's definition does not establish how widely it is deployed. If a lookup finds no URI, RP, or HINFO record, that result applies to the requested name, type, resolver view, and time. It does not establish that the record type is obsolete or unsupported throughout DNS.

Read the Response for the Requested Type

A DNS response separates answer data from authority and additional information. For example, a response to an MX query can include the mail exchanger's address in the additional section. That address helps the client use the MX answer, but it is not another MX record.

When saving a lookup result, include the exact queried name and type, the responding server, the timestamp, and the complete response sections. Check the response status and flags as well as the displayed values. If a response is truncated, the client needs a complete answer, usually obtained by retrying over TCP. In a referral, the NS records identify other nameservers to ask rather than supply the requested record itself.