DNS records are used to map a URL to an IP address. They are stored in DNS servers and contain critical information that helps navigate DNS traffic. For example, when a user searches for a URL is in a web browser, the URL is forwarded to the DNS servers, and then directed to a specific web server based on the information outlined in the DNS record.
A record is the basic unit of information in the DNS—identified by a domain name, a type (such as A, AAAA, MX, NS, etc.) indicating type of information contained in the record, control information (such as TTL), and associated answer data (such as server IP addresses, mail hosts, etc.) depending on the record type. The most common record types are A (address), CNAME (canonical name), MX (mail exchange), NS (name server), PTR (pointer), SOA (start of authority) and TXT (text record).
Standard record types
The following are common industry-wide record types that are supported by NS1:
Record type | Description |
A | (RFC 1035) The most common DNS record used, an A record maps a hostname to an IPv4 address (ex. 33.22.33.44). All zones must contain an A record in order for users to access a website or application using its hostname as opposed to memorizing the IPv4 address. |
AAAA | (RFC 3596) AAAA records function in the same way as A records, except that they map hostnames to an IPv6 address (ex. FE80::0202:B3FF:FE1E:8329). The limited number of permutations possible for IPv4 addresses has resulted in recent growth in the number of IPv6 addresses being used. |
AFSDB | (RFC 1183) AFSDB records are used to connect domain names to Andrew File System (AFS) servers. AFS is similar to NFS, but better suited to handle the latency of wide area networks (such as the internet) and locally caches files. The AFSDB record is key to this operation—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. |
CAA |
(RFC 6844) Domain owners can use DNS Certification Authority Authorization (CAA) records 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 an unauthorized CA from issuing an SSL certificate for your domain—in other words, only the CA(s) authorized in the CAA record can issue an SSL certificate for your domain. CAA records specify the following fields:
For example:
|
CERT |
(RFC 4398, 6944) CERT resource records provide a space in the DNS for certificates and related certificate revocation lists (CRLs). These certificates verify the authenticity of the sending and receiving parties. The CRLs identify the certificates that are no longer valid. |
CNAME |
(RFC 1034, 2181) A Canonical Name (CNAME) record maps one domain name (an alias) to another (the canonical name). There may be only one such canonical name for any one alias. That name should generally be a name that exists elsewhere in the DNS, though there are some rare applications for aliases with the accompanying canonical name undefined in the DNS. An alias name (label of a CNAME record) may, if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no other data. Refer to this article for more information. |
DNAME | (RFC 6672) As opposed to a CNAME record which maps only a single node, a DNAME record is used to redirect an entire subsection (or subtree) of the DNS namespace to another domain. Once implemented, all names that end with a particular suffix are redirected to another part of the DNS. |
HINFO | (RFC 1035) Host information (HINFO) 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, this information can be made publicly available by creating an HINFO record with “PC-Intel-3200mhz” and “Ubuntu 16.04” in the CPU and OS fields, respectively. This information is used by services like FTP to determine the correct procedures for connecting to hosts based on their configuration. |
MX | (RFC 1035, RFC 7505) Mail exchange (MX) records are used to direct emails sent to your domain. MX records, coupled with a mail server, provide organizations (employees, clients, etc.) with emails the organization's domain, such as support@ns1.com. If you have multiple mail servers configured, you can add multiple MX records with varying priorities. |
NAPTR | (RFC 3403) Naming Authority Pointer (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. |
NS | (RFC 1035) Typically configured with your registrar, Name server (NS) records are used to delegate a domain or subdomain to a set of name servers. Name servers, 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. |
PTR | (RFC 1035) Pointer (PTR) 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 (ex. reverse zone lookups). 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. |
RP | (RFC 1183) Typically, the "responsible person" record contains information about the person responsible for the domain. It is usually an email address where the "@" sign is replaced by a period (.). |
SOA |
(RFC 1035, 2038) The Start of Authority (SOA) resource record contains administrative information about the zone that controls the zone transfer. The format of the zone transfer includes
|
SPF | (RFC 4408, 7208) Sender Policy Framework (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:11.11.11.11 a -all (replacing 11.11.11.11 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 | (RFC 2782) Service locator (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. SRV record parameters include:
You can verify the record has been created correctly using the dig tool as shown in this example:
|
TXT | (RFC 1035) Text (TXT) records allow you to contain any text-based information on a domain or subdomain. Applications can use this to collect information about a service—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 per string. A zone may container multiple TXT records. |
NS1-specific record types
The following record types are specific to the NS1 platform.
ALIAS |
ALIAS is a pseudo-record that works like a CNAME record, but can be used safely at the zone apex because it always resolves to A (or AAAA) record(s). Resolution to the target is a completely internal process—DNS recursors making the query will not be able to differentiate between an ALIAS record and a “real” A (or AAAA) record. When queried, an ALIAS record will always return one or more A or AAAA records. Since ALIAS is a pseudo-record, the query result will never contain ALIAS. There is no good reason to use an ALIAS record outside of the zone apex. Since it requires an extra external lookup, resolution can be slower than a CNAME or linked record. Refer to this article for more information. |
Linked records |
Using a linked record avoids the timely and error-prone tasks of manually creating and maintaining identical configurations across multiple records. Linked records tell the NS1 authoritative server to use the full configuration from a target record that exists somewhere else on the NS1 platform. Note: The target record does not need to be in the same zone as the linked record. For example, a CDN using NS1 DNS services can instruct its customer (who is also using NS1) to use a linked record to point to the customer’s domain at the CDN, instead of a CNAME. This eliminates DNS round trips and (for A or AAAA records) allows direct resolution at the zone apex. A linked record can be any record type (A, MX, CNAME, etc.), but it must be the same types as a target or it will not resolve. Compared to a CNAME record, a linked record typically requires one less DNS lookup—often shortening the response time for the requesting resolver or user to receive the final answer. Linked records are specific to NS1, and their resolution is a completely internal process. During resolution, the full configuration from the target record (including advanced configuration options) is duplicated into the source record such that (other than the name of the record) they resolve identically. DNS recursors making the query will not be able to differentiate between a linked record and the “real” target to which it points. Linked records support all NS1 features and capabilities used by the target record—including real-time data feeds. Refer to this article for more information. |
URLFWD | URL forwarding (or URL redirecting) is a technique used to make a single web page available via multiple URLs. NS1 users can easily set up URL forwarding (HTTP redirects or masking) between zones. There are three types of URL redirects: Permanent (301), Temporary (302), or Masking.
|