Commonly used DNS record types

What is DNS

DNS is a global system for translating IP addresses to human-readable domain names. When a user tries to access a web address like example.com, their web browser or application performs a DNS Query against a DNS server, supplying the hostname. The DNS server takes the hostname and resolves it into a numeric IP address, which the web browser can connect to.

What is record types

Before we dive into various types of DNS records, it is important to understand the distinction and concept of DNS Zones and DNS Records.

Zone DNS database is a collection of resource records and each of the records provides information about a specific object. A DNS Zone is like a container of all the DNS records for a specific domain and only that domain.

A DNS Record is a single entry that gives the zone instructions on how to handle any given request based on type.

DNS servers create a DNS record to provide important information about a domain or hostname, particularly its current IP address. Each individual DNS record is assigned a type and information needed for that type of record.

The most common DNS record types are:

Record A: Address Mapping record

The A-record is the most basic and the most commonly used DNS record type. It is also known as a DNS host record, stores a hostname and its corresponding IPv4 address.

It is used to translate human-friendly domain names such as www.example.com into IP-addresses such as 93.184.216.34 (machine friendly numbers).

A-records are the DNS server equivalent of the hosts' file - a simple domain name to IP-address mapping. A-records are not required for all computers, but are needed for any computer that provides shared resources on a network. Assigning a value to an A record is as simple as providing your DNS management panel with an IP address to where the domain or subdomain should point and a TTL.

You'll want to use an A Record for your DNS entry if you have an IP address that the domain/subdomain should point to or if you want to establish a domain/subdomain to be used as the place to point a CNAME.

This record type is defined in RFC1035.

Record AAAA: IP Version 6 Address record

The record AAAA (also quad-A record) specifies IPv6 address for a given host. So it works the same way as the A record and the difference is the type of IP address.

IPv6 is the future replacement for the current IP address system (also known as IPv4). The current IPv4 addresses are 32 bits long (xxx.xxx.xxx.xxx = 4 bytes), and therefore "only" support a total of 4,294,967,296 addresses - less than the global population. With this limitation, there is an increasing shortage of IPv4 addresses, and to solve the problem, the whole Internet will eventually be migrated to IPv6.

IPv6 addresses are 128 bits long and are written in hexadecimal numbers separated by colons (:) at every four digits (segment). A series of zero value segments can be shortened as "::", and leading zeros in a segment can be skipped. For example: 4C2F::1:2:3:4:567:89AB.

This record type is defined in RFC3596.

Record CNAME: Canonical Name record

The CNAME record specifies a domain name that has to be queried in order to resolve the original DNS query. Therefore CNAME records are used for creating aliases of domain names. CNAME records are truly useful when you want to alias a domain to an external domain.

When a DNS client requests a record that contains a CNAME, which points to another hostname, the DNS resolution process is repeated with the new hostname. In other cases, we can remove CNAME records and replace them with A records and even decrease performance overhead.

Computers on the Internet often perform multiple roles such as web-server, ftp-server, chat-server etc. To mask this, CNAME-records can be used to give a single computer multiple names (aliases).

For example, the computer "computer1.xyz.com" may be both a web-server and an ftp-server, so two CNAME-records are defined:

www.xyz.com = computer1.xyz.com and ftp.xyz.com = computer1.xyz.com.

Sometimes a single server computer hosts many different domain names (take ISPs), and so CNAME-records may be defined such as www.abc.com = www.xyz.com.

The most common use of the CNAME-record type is to provide access to a web-server using both the standard www.domain.com and domain.com (with and without the www prefix). This is usually done by creating an A-record for the short name (without www), and a CNAME-record for the www name pointing to the short name.

CNAME-records can also be used when a computer or service needs to be renamed, to temporarily allow access through both the old and new name.

A CNAME-record should always point to an A-record and never to itself or another CNAME-record to avoid circular references.

This record type is defined in RFC1035.

Record MX: Mail exchanger record

It specifies an SMTP email server for the domain a DNS domain name. The information is used by Simple Mail Transfer Protocol (SMTP) to route emails to proper hosts. Typically, there is more than one mail exchange server for a DNS domain and each of them has set priority.

Mail Exchanger (MX) records are used to help route email according to the domain owners preference. The MX record itself specifies which server(s) to attempt to use to deliver mail to when this type of request is made to the domain. They differ from A Records and CNAMEs in the way that they also require a "priority" value as a part of their entry. The priority number is used to indicate which of the servers listed as MX records it should attempt to use first.

• If a domain name is handled by multiple e-mail servers (for backup/redundancy), a separate MX-record is used for each e-mail server, and the preference numbers then determine in which order (lower numbers first) these servers should be used by other e-mail servers.
• If a domain name is handled by a single e-mail server, only one MX-record is needed and the preference number does not matter.

Some email providers have only one MX record and some have well over two. The number of MX entries you will need to create depends largely on the mail provider and how they expect the load on these email servers to be handled.

When sending an e-mail to "user@example.com", your e-mail server must first lookup any MX-records for "example.com" to see which e-mail servers handle incoming e-mail for "example.com". This could be "mail.example.com" or someone else's mail server like "mail.larapulse.com". After this, it looks up the A-record for that e-mail server name to connect to its IP-address.

Important:
An MX-record must point to the name of a mail server - not directly to the IP-address.
Because of this, it is very important that an A-record for the referenced mail server name exists (not necessarily on your DNS server, but wherever it belongs), otherwise there may not be any way to connect to that e-mail server.

Do not point an MX-record to a CNAME-record. Many e-mail servers don't understand this. Add another A-record instead.

This record type is defined in RFC1035.

Record NS: Name Server records

It specifies that a DNS Zone, such as “example.com” is delegated to a specific Authoritative Name Server, and provides the address of the name server.

A zone should contain one NS-record for each of its own DNS servers (primary and secondaries). This is mostly used for zone transfer purposes (notify messages). These NS-records have the same name as the zone in which they are located.

The more important function of the NS-record is delegation. Delegation means that part of a domain is delegated to other DNS servers.

For example, all ".com" sub-names (such as "example.com") are delegated from the "com" zone. The "com" zone contains NS-records for all ".com" sub-names (a lot!).

You can delegate sub-names of your own domain name (such as "subname.example.com") to other DNS servers the same way. To delegate "subname.example.com", create NS-records for "subname.example.com" in the "example.com" zone. These NS-records must point to the DNS server responsible for "subname.example.com", for example, "ns1.subname.example.com" - or a DNS server somewhere else like "ns1.othername.net".

An NS-record identifies the name of a DNS server - not the IP-address. Because of this, it is important that an A-record for the referenced DNS server exists (not necessarily on your DNS server, but wherever it belongs), otherwise there may not be any way to connect with that DNS server.

If an NS-record delegates a sub-name ("subname.example.com") to a DNS server with a name in that sub-name ("ns1.subname.example.com"), an A-record for that server (""ns1.subname.example.com") must exist in the parent zone ("example.com"). This A-record is called a "glue record", because it doesn't really belong in the parent zone, but is necessary to locate the DNS server for the delegated sub-name.

This record type is defined in RFC1035.

Record SOA: Start of Authority

This record appears at the beginning of a DNS zone file and specifies core information about a DNS zone. A zone contains exactly one SOA-record, which holds the following properties for the zone:

• Name of primary DNS server. The hostname of the primary DNS server for the zone. The zone should contain a matching NS-record.

NOTE: For dynamic updates from Windows clients and Active Directory to work correctly, it is important that this contains the correct hostname for the primary DNS server for the zone, and also that an A-record exists for this name pointing to the correct IP address.

• E-mail address of responsible person. The e-mail address of the person responsible for the zone. The standard for this is the "hostmaster" alias - such as "hostmaster@example.com".

• Serial number. Used by secondary DNS servers to check if the zone has changed. If the serial number is higher than what the secondary server has, a zone transfer will be initiated. You should never decrease the serial number.

• Refresh Interval. How often secondary DNS servers should check if changes are made to the zone.

• Retry Interval. How often secondary DNS server should retry checking if changes are made - if the first refresh fails.

• Expire Interval. How long the zone will be valid after a refresh. Secondary servers will discard the zone if no refresh could be made within this interval.

• Minimum (default) TTL. Used by other DNS servers to cache negative responses (such as record does not exist etc.).

This record type is defined in RFC1035.

Record TXT: Text Record

A TXT record is used to store any text-based information that can be grabbed when necessary. We most commonly see TXT records used to hold SPF data and verify domain ownership. They are also often used to hold general information about a domain name such as who is hosting it, contact person, phone numbers, etc.

One common use of TXT-records is for SPF.

This record type is defined in RFC1035.

Record ALIAS: Auto resolved alias

ALIAS-records are virtual alias records resolved by DNS Provider at the time of each request - providing "flattened" (no CNAME-record chain) synthesized records with data from a hidden source name.

This can be used for different purposes - including solving the classic problem with CNAME-records at the domain apex (for the zone name / for "the naked domain").

Similar implementations of virtual alias records ("ANAME", "ALIAS", "CNAME flattening") are offered by various DNS service providers. There is no standard (RFC or similar) for this.

Record PTR: Reverse-lookup Pointer records

As opposed to forward DNS resolution (A and AAAA DNS records), the PTR record is used to look up domain names based on an IP address.

For a reverse IPv4 mapping, the name of the PTR-record is the IP address with the segments reversed and with "in-addr.arpa" appended to the end. As an example, looking up the domain name for IP address "12.23.34.45" is done with a query for the PTR-record for "45.34.23.12.in-addr.arpa".

For a reverse IPv6 mapping, the name of the PTR-record is each hex digit of the IP address in reverse order, with dots between each digit, and with "ip6.arpa" appended to the end. As an example, looking up the domain name for IPv6 address "1234:5678:90ab:cdef:1234:5678:90ab:cdef" is done with a query for the PTR-record for "f.e.d.c.b.a.0.9.8.7.6.5.4.3.2.1.f.e.d.c.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa".

This record type is defined in RFC1035.

Record CERT: Certificate record

CERT-records store certificates and related revocation lists (CRL) for cryptographic keys.

CERT-records have the following data elements (see RFC below for details):

• Type: the type of certificate/CRL stored. Select one of the predefined values, or enter a numeric value (0-65535).
• Key tag: A numeric value (0-65535) used the efficiently pick a CERT record.
• Algorithm: the algorithm used. Select one of the predefined values, or enter a numeric value (0-65535).
• Certificate or CRL: Base 64 encoded.

This record type is defined in RFC4398.

Record SRV: Service Location

SRV-records are used to specify the location of a service. They are used in connection with different directory servers such as LDAP (Lightweight Directory Access Protocol), and Windows Active Directory, and more recently with SIP servers.

They can also be used for advanced load balancing and to specify specific ports for services, for example, that a web-server is running on port 8080 instead of the usual port 80 (theoretical example - this is not yet supported by any major browsers). This record type is, however, NOT supported by most programs in use today, including web-browsers.

The SRV record identification (record name) is made of 3 parts:

• Service: Most internet services are defined in RFC1700 (page 15).
• Protocol: Generally TCP or UDP, but also values are also valid.
• Domain name.

The "service location" is specified through a priority, weight, port and target:

• Priority is a preference number used when more servers are providing the same service (lower numbers are tried first).
• Weight is used for advanced load balancing.
• Port is the TCP/UDP port number on the server that provides this service.
• Target is the domain name of the server (referencing an A-record or AAAA-record).

This record type is defined in RFC2782.

Record HINFO: Host Information records

HINFO records are used to acquire general information about a host. The record specifies a type of CPU and OS. The HINFO record data provides the possibility to use operating system specific protocols when two hosts want to communicate. For security reasons, the HINFO records are not typically used on public servers.

This information can be used by application protocols such as FTP, which use special procedures when communicating with computers of a known CPU and operating system type. Standard CPU and operating system types are defined in RFC1700 (Page 206 / 214). The standard for a Windows PC is "INTEL-386" / "WIN32".

This record type is defined in RFC1035.

Record ISDN: Integrated Services Digital Network records

The ISDN resource record specifies ISDN address for a host. An ISDN address is a telephone number that consists of a country code, a national destination code, an ISDN Subscriber number and, optionally, an ISDN subaddress.

The ISDN phone numbers / DDI (Direct Dial In) used should follow ITU-T E.163/E.164 international telephone numbering standards. The ISDN sub-address is an optional hexadecimal number.

The function of the record is the only variation of the A resource record function.

This record type is defined in RFC1183.

---

Managing your own DNS can be a tricky endeavour, especially if you haven't ever considered what this means or ever even seen a DNS record. The most important DNS record types you should know is A, CNAME, MX, NS and SOA.

---

Interesting in reading more about Networks? Follow this link to find more articles 😉