All domains are required to have at least a few essential DNS records for a user to be able to access their website using a domain name. The most common DNS records are described in detail in the RFC 1034 and RFC 1035. In a zone file, the first DNS record that needs to be included is the SOA record. In fact, a zone file is only valid if the SOA record is available. Without this, a zone file cannot function properly. Then it is followed by the NS records, and then the A and AAAA records. For convenience, we will briefly summarize the most common types of DNS records.
- A Record or AAAA Record (TYPE = 1 or 28)
A (Address) record is the most fundamental type of DNS record, it indicates the IPv4 address of a given domain name (IPv6 address for the case of AAAA Record). For example, if you pull the DNS records of mlytics.com, the A record will return an IP address of 104.26.10.143. The RDATA for A record is the IPv4 address (and 1Pv6 for the case of AAAA record). Check out this link for more information about IP address (link to IP address article).
- CNAME Record (TYPE = 5)
CNAME (Canonical Name) record, is a record that maps an alias domain name (can be a root domain or a subdomain), to the canonical domain name. Usually, the canonical name is the domain name that carries an A/AAAA record (or linked to the IP address). Though in some cases, the canonical name is a domain name that carries yet another CNAME record. This latter situation is usually applied in Multi CDNs.
The usual application of CNAME is when a website has several subdomains, and subdomains can have CNAME records that point to the root domain which carries the A (or AAAA) record. For this example, if the IP address of the host changes, only the A (or AAAA) record for the root domain needs to be updated, and there is no need to change any of the CNAME records of the subdomains. Each CNAME record will simply point to the root domain and will follow whatever updates made onto the A (or AAAA) record. The RDATA for the CNAME record is the canonical name.
Note: apex CNAME, or a CNAME record at the apex of a domain (root domain) is considered as a taboo practice.
- NS Record (TYPE = 2)
NS (NameServer) record, is a record that indicates which server serves as the authoritative nameserver for a given domain/subdomain (namespace), or which server contains all the DNS records or zone files of a particular domain. NS record is used to indicate which nameservers can answer lookups on a DNS Zone. In a more practical sense, NS records tell the internet which specific nameserver can provide the IP address or email server of a given domain. Without a properly configured NS record, users will be unable to load a website or application.
Almost all domains rely on multiple nameservers to increase reliability. Typically there is one primary nameserver and several secondary nameservers, which store exact copies of the DNS records found in the primary nameserver. If the primary nameserver goes down or is unavailable, DNS queries can go to any of the secondary nameservers for backup. Updating the primary nameserver will trigger an update of the secondary nameservers as well. The RDATA of NS record is the nameserver.
Note: NS record cannot point to an alias name (or domain name bearing a CNAME record).
- SOA Record (TYPE = 6)
SOA (Start of Authority) record, is a record that contains information about your domain or zone for managing traffic between nameservers (primary and secondary). In practice, zone files are mirrored to secondary servers in order to prevent failures. The process of distributing RRs (or zone files) between nameservers is called the zone transfer. During zone transfer, SOA record is of primary importance, since DNS needs to identify the source of the zone files (i.e. primary name server), and some parameters that can instruct the DNS on how the zone transfer is going to proceed.
Due to the function of SOA, SOA records also store additional information besides the typical fields found on most DNS records. These additional fields are: MNAME – name of the primary nameserver; RNAME – name-server administrator’s email account; SERIAL – nameserver serial number; REFRESH – zone file refresh interval (or the time interval the secondary nameserver checks the primary nameserver if the records are updated); RETRY – refresh retry interval (or the time interval for a secondary server to recheck an unresponsive primary nameserver); EXPIRE – no response expiry time (time that the secondary will stop checking the unresponsive primary nameserver). These “additional” fields are considered to be the SOA record’s “RDATA”.
- MX Record (TYPE = 15)
MX (Mail eXchange) record, is a record that specifies the email server that is used to handle emails for a domain name specified in an email address. This allows emails for that domain name to be directed to its corresponding email server in accordance with Simple Mail Transfer Protocol (SMTP – the standard protocol for all email). One or more email servers can be defined to handle email for a particular domain, each is assigned a priority number.
The priority number will let the DNS know in which sequence each email server should be contacted. The email server assigned with the lowest value will have the highest priority. Such that, the email server with a higher value (lower priority) will only be contacted if the one with a lower value (higher priority) has failed. In cases where several email servers are assigned with the same value (equal priority), then the DNS will balance the load between these email servers. The RDATA for the MX record is the email server and its assigned priority number.
Note: MX record cannot point to an alias name (or domain name bearing a CNAME record).
- SRV Record (TYPE = 33)
SRV (SeRVice) record, is a record that specifies a host server and its corresponding port for a specific service such as voice over IP (VoIP), instant messaging, HTTP, etc. SRV record helps with service discovery even without having to know which host the service is running on. An SRV record’s NAME field typically includes the service name and the transport protocol, together with the domain name, e.g. _http._tcp.mlytics.com (combination of web service: http, transport protocol: tcp, and domain name: mlytics.com). This allows the web service for that domain name to be directed to its corresponding host server in accordance with transmission control protocol. One or more host servers can be defined to handle the service for a particular domain, each is assigned with a port, priority number, and a weight. SRV record is similar to MX record, but for other services besides email.
In networking, a port is a communication endpoint. At the software level (within an operating system), a port is a logical construct that identifies a specific process or a type of network service. Ports allow computers to easily differentiate between different kinds of network traffic. For example, email messages go to a different port for website content, despite both reaching the computer over the same internet connection. A port is identified by the type of transport protocol used for network communication, and by its port number. The most common transport protocol that uses port numbers are the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP). Port number is used to identify specific type of services and/or specific type of host server. Port numbers lower than 1024 are called the well-known port numbers. Port 80 and 443 are the most common, and are used to identify HTTP and HTTPS web services. You may check this list for other most commonly used ports.
Just like in MX record, the priority number will let the DNS know in which sequence each host server should be contacted. The host server assigned with the lowest value, will have the highest priority. In cases where several host servers are assigned with the same priority value (equal priority), then the DNS will balance the load between these host servers depending on their weights. The server with higher weight value will receive more traffic than those which have less. The RDATA for SRV record is the host server, and its corresponding port, priority number, and weight.
Note: SRV record cannot point to an alias name (or domain name bearing a CNAME record).
- PTR Record (TYPE = 12)
PTR (PoinTeR) record, is a record that indicates the domain name associated with a given IP address. It is the exact opposite of an A record, and is used for reverse DNS lookup. A reverse DNS lookup is a query that starts with the IP address and looks up the domain name. The reverse DNS database is rooted in the .arpa top-level domain. The name “arpa” was originally derived from the Advanced Research Projects Agency (ARPA), the organization that developed the ARPANET (the precursor of the Internet).
Reverse DNS lookup and PTR records are generally used as a security and anti-spam measure. Email servers can perform reverse DNS lookups to verify the identities of hosts. System logs usually record IP addresses, and performing reverse DNS lookup converts log data into more human-friendly domain names. The RDATA of PTR record is a “reversed IPv4 address” appended with “.in-addr.arpa” (for the case of IPv6, “reversed IPv6 address” appended with “.1p6.arpa”).
- TXT Record (TYPE = 16)
TXT (TeXT) record, is a record that contains arbitrary text information that can be added to the RR. The TXT record was originally intended as a venue for the domain administrator to enter human-readable notes into the DNS. However, recently, administrators started entering some machine-readable data as well. One domain can have many TXT records. TXT records can be used for email spam prevention and domain ownership verification. The RDATA of TXT record is the TXT-DATA which is a field that contains all inputted text information.
- CAA Record (TYPE = 257)
CAA (Certification Authority Authorization) record, is a record that is used to specify which certificate authorities (CA) are allowed to issue digital certificates for a particular domain. They also provide a means of indicating notification rules in case someone requests a certificate from an unauthorized certificate authority. CAs can perform a DNS lookup for CAA records, and if no CAA records are found, then they (or any) CAs will be allowed to issue a certificate for the domain. However, if CAA records are found, they need to ensure that they are listed as an authorized party before they can issue a certificate. If they are not listed, then they cannot issue a certificate for the domain. But if they are listed in the CAA record, then they are allowed to issue certificates for that domain.
CAA records can set policy for the entire domain or for specific hostnames. CAA records of a domain are also inherited by its subdomains. However, if a subdomain has its own CAA record, then this record takes precedence. If a domain name is an alias name (has CNAME record) for another domain, then the certificate authority looks for the CAA record set at the canonical name. If no CAA record set is found, then, the CA continues searching parent domains where it can find a CAA record. It is not possible for a domain name to have both a CNAME and a CAA record.
Each CAA record consists of the following fields (i.e. CAA’s RDATA): a flag, and a tag-value pair (referred to as a ‘property’). Multiple properties may be associated with the same domain name by publishing multiple CAA records at that domain name.
Flag – is used to represent a critical flag. Usually, it can have the value of either 1 (critical) or 0 (non-critical), with 0 sets as default.
- If a critical flag is asserted (flag = 1), this tells that the property might be unknown or unsupported, and MUST be understood first in order for the CAA record to be correctly processed by a CA. This means that a CA should not issue certificates for any domain, and should send an email notifying the domain owner about the CAA record check failure.
- If a critical flag is not asserted (flag = 0), this tells that the property is compliant to CAA specification, hence it ensures compatibility with future extensions to the CAA specification. This means a CA can use any CAA record info in the zone regardless of whether it understands the property or not. If CA doesn’t understand this CAA record, it can skip over it and use another in the DNS zone file.
It should be noted that a CA can create its own custom flags to give specific directions for issuance.
Tag-Value pair – A tag is a non-zero ASCII string of lowercase letters and numbers that represents the identifier of the property represented by the record. While a value is a quoted string field value associated with the tag. The RFC currently defines three available tags:
- issue: specifies which CA is authorized to issue a digital certificate (any type) for a domain. The value for this tag is the CA, e.g. “letsencrypt.org”, or “sectigo.com”, etc. However, the presence of an empty issue value disallows all issuance.
- issuewild: specifies which CA is authorized to issue a wildcard certificate for a wildcard domain. Issuewild takes precedence over issue for wildcard certificate requests. The value for this tag is also the CA.
- iodef: specifies a method which a CA may report invalid certificate requests to the domain or a possible policy violation. E.g. “mailto:[email protected]” which instructs the CA to send the report to the specified email address.
It should also be noted that each CAA record contains only one tag-value pair. Hence, if you want to authorize two CAs for your domain or if you want to provide notification rules, then you have to make a separate individual CAA record for each.
In addition, if you would like to use CAA to restrict which CA are allowed to issue certificates for your domain, you will need to use a DNS provider that supports setting CAA records. You can check which provider supports CAA records from this list and you can use Automated CAA Record Generator to generate a set of CAA records listing the CAs that you would like to allow. Also, if you don’t want to restrict any CA or if you simply don’t want to be bothered by CAA, then you generally don’t have to do anything.
- Wildcard record
A wildcard record is not like the usual RR, rather, it is a record in a zone that is used to match queries for one or more subdomains by substituting whole labels of the query domain name (domain name being queried) with a “*.<domain name>”, and as long as the query domain name matches the label/s from root domain until the dot following the asterisk. In addition, wildcard records can only be used for matching queries, as long as the queried subdomain does not have any defined RR. This means, if there is an existing RR for a particular subdomain, the RR for that particular subdomain will take precedence over the wildcard record for matching queries. These above-mentioned rules are further described in RFC 4592 section 3.3.1 (Closest Encloser and the Source of Synthesis).
In terms of format, a wildcard in the DNS has much more limitations than other wildcard characters used in other computer systems. Wildcard in DNS is specifically identified by a single asterisk (*) as the leftmost domain label of a domain name, and must be immediately followed by a dot (.). e.g. *.mlytics.com. Multiple asterisks, or asterisks having another character/s besides it, or asterisks placed on other locations in the domain name will not work as a DNS wildcard. For example, **.mlytics.com, or *a.mlytics.com, or a*.mlytics.com, or a.*.mlytics.com will not work as a wildcard record in the DNS.
To have a better understanding on how a wildcard record works in a query, it will be more practical to provide examples of using wildcard records. Note: DNS query tools are described more accurately and in more detail in the article “DNS Troubleshooting Tool” (make a link).
Zone file example:
…
*.mlytics.com 3600 TXT “this is a wildcard”
*.mlytics.com 3600 MX 10 host1.mlytics.com
host1.mlytics.com 3600 A 192.0.1.2
…
Query 1: does host2.mlytics.com has a TXT record?
Answer: *.mlytics.com 3600 TXT “this is a wildcard”
Query 2: does host2.mlytics.com has an MX record?
Answer: *.mlytics.com 3600 MX 10 host1.mlytics.com
Query 3: does host2.mlytics.com has an A record?
Answer: no error but no answer
Query 4: does host1.mlytics.com has an MX record?
Answer: no error but no answer
Note: because host1.mlytics.com has a defined A record, this record will take precedence over the wildcard record during queries
Query 5: does host1.mlytics.com has an A record?
Answer: host1.mlytics.com 3600 A 192.0.1.2
Using a wildcard record can be a little tricky. There are more rules that one should take note when using wildcards. If not properly used, it is not uncommon that one might experience incompatible implementations and unexpected results. So, it is advised to directly check RFC 1034 (original definition) and RFC 4592 (refined definition) for more details.
These are the 10 most common types of DNS records. However, aside from these 10, there are many other DNS record types that can be found in the zone files. You may check this article for the list of all the types of DNS records and a brief description of their functions.