A DNS record is the basic unit of information in the DNS. A record is identified by a domain name (like www.example.com), a type (like A, AAAA, MX, NS, and so on) indicating the type of information contained in the record, some control information like DNS cache time-to-live (TTL), and "answer" data like server IPs, mail hosts, etc, depending on the record type.
The most common DNS record used, an A record simply maps a hostname to an IPv4 address (such as 126.96.36.199). The A record is required in order for users to reach your website or application using its hostname as opposed to memorizing the IPv4 address.
The AAAA Record (sometimes called a Quad A) operates in the same way a A records, except that they point to an IPv6 address (such as FE80::0202:B3FF:FE1E:8329). The IPv6 protocol is the successor to IPv4. While it is not currently as widely used, the need for IPv6 usage is growing constantly as the available address space in the IPv4 protocol is quickly running out
MX (or Mail eXchange) records are used to direct emails sent to your domain. MX records, coupled with a mail server can provide you and your employees, clients, etc. with emails on your own domain such as email@example.com. You can also add multiple MX records with varying priorities for redundancy, if you have multiple mail servers configured.
CAA records allow domain owners to specify which certificate authorities (CAs) are allowed to issue SSL certificates for their domains. A single domain may contain multiple CAA records. The CAA record prevents any other CA from issuing an SSL certificate for your domain—only the CA(s) you authorized in the CAA record, can issue an SSL certificate for your domain.
CAA records are defined by RFC 6844 and specify the following fields:
CAA <flags> <tag> <value>
flagsis an unsigned integer between 0 and 255.
tagis a non-zero sequence of US-ASCII letters and numbers in lowercase.
valueis the <character-string> encoding of the value field.
$ORIGIN example.com @ CAA 0 issue "ca.example.net" @ CAA 0 iodef "mailto:firstname.lastname@example.org" @ CAA 0 iodef "http://iodef.example.com/"
PTR (or pointer) records are usually described as the opposite of an A record. Whereas A records point the domain to an IP address, a PTR record points an IP to a domain. This is often used as spam verification with certain email programs to confirm a mail server is authorized to use the domain from which the email was sent. PTR records usually have to be defined by the owner of the IP address for your server—usually your server hosts. Many hosting companies will set this up for you when you set up a server.
TXT records allow you to contain any text-based information on a domain or subdomain. Applications can use this to check information about a service you are running—typically, SPF records, DomainKeys, and DKIM (two other email verification processes). Usage with SPF can be read about above in the SPF Records section. TXT records may contain any information up to 255 characters.
Typically configured with your registrar, NS records are used to delegate a domain or subdomain to a set of nameservers. Nameservers, such as NS1, hold all the other DNS records for your domain and tell all the other computers connected to the internet what records your domain holds. Therefore, setting the NS record is a critical step in getting your domains and servers online.
SPF records are used during email verification to prevent your domain name from being used by spammers or malicious users. Simply creating an SPF record on your main domain with the content: v=spf1 ip4:188.8.131.52 a -all (replacing 184.108.40.206 with your mail server’s IP address) will tell email receivers that your mail server is the only server allowed to send emails from your domain. All emails received from other servers are to be rejected or marked as spam. If you have multiple mail servers, you can add another ip4:x.x.x.x after the previous one to allow another IP address.
Note: The SPF record is still supported, but shouldn’t be used in new configurations. Instead, making a TXT record with the same content is the more accepted practice today. Commonly, mail servers will define both an SPF and a TXT record for the most compatibility
SRV records are a way to use DNS to locate services for a specific domain. SRV records allow for built-in load balancing of multiple servers using the priority and weight values in the records. They are defined by RFC 2782.
SRV record parameters
- service is the name of a service, such as SIP or XMPP. Underscore required.
- proto is the protocol in use for the service. Normally either TCP or UDP. Underscore required.
- domainname. is the FQDN of the domain using the service.
- ttl is the time to live for the DNS record.
- priority is the priority of the target. A lower number is a higher preference.
- weight is the weight of the target. A higher number is a higher preference.
- target is the hostname of the server which is hosting the service.
You can verify the record has been created correctly using the dig tool as shown in this example:
test:~ test$ dig srv _www._tcp.zone.example @dns1.p08.nsone.net +short 1 100 80 www.zone.example.
NAPTR records are most commonly used with internet telephony (or VoIP) services. It can be used to map telephone numbers and email addresses for VoIP users to SIP servers via SRV records to initiate calls.
HINFO (host info) records are used to associate general information about a host’s CPU and OS with the host’s domain name. For example, if www.example.com was running Ubuntu 16.04 with a 3.2 GHz Intel CPU, you could make this information publicly available by creating an HINFO record with “PC-Intel-3200mhz” and “Ubuntu 16.04” in the CPU and OS fields, respectively. This information can be used by services like FTP to determine the correct procedures for connecting to hosts based on their configuration.
AFSDB records are used to connect domain names to AFS servers, AFS being a network filesystem, similar to NFS but more suited to handle the latency of wide area networks, like the internet, and locally caches files. The AFSDB record is key to this operation, by providing the location to the file database.
Note: This record is experimental and not recognized by all services, and not all nameservers recognize or implement it. The AFSDB record type is deprecated and has been replaced by the SRV record.