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 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 a basic unit of information in the DNS — identified by a domain name, a type (such as A, AAAA, MX, NS, etc.) indicating the kind 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).
The following are common industry-wide record types that are supported by NS1:
(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.
Configuration:
For each answer, enter an IPv4 address corresponding to an endpoint to which you want to point DNS traffic.
(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 (WAN) and locally caches files. The AFSDB record is key to this operation — providing the location to the file database.
Warning
This record is experimental and not recognized by all services. Not all name servers recognize or implement it. Typically, in most DNS systems, the AFSDB record type is deprecated and has been replaced by the SRV record.
Configuration:
For each answer, enter a service subtypes and an AFS cell server.
(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 can 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.
Configuration:
For each answer, enter the flag (an unsigned integer between 0 and 255), tag (a non-zero sequence of lowercase US-ASCII letters and numbers), and a value (a <character_string> encoding of the value field) for the certificate authority (CA) that should be permitted to issue an SSL certificate for your domain.
(RFC 4398, 6944) CERT 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.
Configuration:
For each answer, enter the type, keytag, algorithm, and certificate used to verify the authenticity of the sending and receiving parties.
(RFC 1034, 2181) A Canonical Name (CNAME) record maps one domain name (an alias) to another domain (the canonical name). There can 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.
Note
Generally, CNAMEs should not be used at the zone apex or domain root.
Common use cases for a CNAME record include:
Specifying a unique hostname for specific network services, such as email or FTP, and redirecting that hostname to the root domain.
For hosted services, mapping a subdomain for individual customers on the service provider's domain (e.g., company.hostname.com) and use the CNAME to point to the customer's preferred domain (e.g., www.company.com).
Registering the same domain in several countries and creating CNAME records for each country's TLD.
Pointing multiple domains owned by a company back to the primary website.
Configuration:
Add the "real" or target domain as an answer within this record. The CNAME record serves as an alias for the specified domain.
(RFC 6672) Whereas a CNAME record defines an alias for a single domain or node, a Delegation Name (DNAME) record is used to create an alias (i.e., domain) for an entire subsection of the DNS namespace (i.e., a domain and all of its subdomains).
Configuration:
Add the "real" or target domain as an answer within this record. The DNAME record serves as an alias for the specified domain and all of its subdomains.
(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.
Configuration:
For each answer, enter the relevant host hardware data (e.g., CPU) and operating system.
(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.
Configuration:
For each answer, enter a mail server (e.g., mailhost1.example.com) and assign a priority number. The priority number specifies preference and informs the sequence that an email server receives emails.
(RFC 3403) Naming Authority Pointer (NAPTR) records are most commonly used with internet telephony (or VoIP) services. They can be used to map telephone numbers and email addresses for VoIP users to SIP servers via SRV records to initiate calls.
Configuration:
For each answer, enter the following information:
Order for answer processing: A 16-bit unsigned integer specifying the order in which the NAPTR records MUST be processed to ensure the correct ordering of rules. Low numbers are processed before high numbers, and once a NAPTR is found whose rule "matches" the target, the client MUST NOT consider any NAPTRs with a higher value for order (except as noted below for the Flags field).
Preference (if others have equal order values): A 16-bit unsigned integer that specifies the order in which NAPTR records with equal "order" values SHOULD be processed, low numbers being processed before high numbers. This is similar to the preference field in an MX record, and is used so domain administrators can direct clients towards more capable hosts or lighter weight protocols. A client may look at records with higher preference values if it has a good reason to do so such as not understanding the preferred protocol or service. The important difference between Order and Preference is that once a match is found the client MUST NOT consider records with a different Order but they MAY process records with the same Order but different Preferences. In other words, the preference is used to give weight to rules that are considered the same from an authority standpoint but not from a simple load balancing standpoint.
Flags: At this time only four flags, "S", "A", "U", and "P", are defined in the RFC. The "S", "A" and "U" flags denote a terminal lookup, meaning that this NAPTR record is the last one and that the flag determines what the next stage should be. The "S" flag means that the next lookup should be for SRV records. "A" means that the next lookup should be for either an A or AAAA record. The "U" flag means that the next step is not a DNS lookup but that the output of the Regexp field is an URI that adheres to the 'absoluteURI' production found in the ABNF of RFC 2396. Since there may be applications that use NAPTR to also lookup aspects of URIs, be aware that this may cause loop conditions. The "P" flag says that the remainder of the application side algorithm shall be carried out in a Protocol-specific fashion. The new set of rules is identified by the protocol specified in the Services field.
Service(s) available down rewrite path: Specifies the service(s) available down this rewrite path. It may also specify the particular protocol that is used to talk with a service. A protocol MUST be specified if the flags field states that the NAPTR is terminal. If a protocol is specified, but the flags field does not state that the NAPTR is terminal, the next
(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.
Note
When you create a new zone, an NS record is automatically created within the zone. The NS record contains one or more answers — each corresponding to the assigned nameservers within the relevant DNS network. If you do not select a network during zone creation (i.e., if you leave the zone "unpublished"), then an empty NS record is created within the zone.
Configuration:
For each answer, enter the IP address or hostname of the name server associated with this record. Note that these values are auto-populated for zones published within the Managed DNS network.
(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 (e.g., for reverse zone look-ups). 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.
Configuration:
For each answer, enter a domain to which this PTR record should point.
(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 (.).
Configuration:
For each answer, enter the email address of the person responsible for this host/domain name (replacing the '@' sign with a period) and the domain within which the TXT record exists.
(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:
MNAME: The domain name of the name server that was the original or primary source of data for this zone
RNAME: A domain name corresponding to the email address of the person responsible for this zone
SERIAL: The unsigned 32-bit version number of the original copy of this zone. Zone transfers preserve this value
REFRESH: The amount of time before the zone should be refreshed.
RETRY: The amount of time that should elapse before a failed refresh is retried
EXPIRE: The maximum amount of time that can elapse before the zone is no longer authoritative
MINIMUM: The amount of time used to cache negative responses (NXD)
(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
While the SPF record type is still supported, it is not recommended for new configurations. Instead, make a TXT record with the same content as this is the more accepted practice today. Many mail servers will define both an SPF and TXT record for the most compatibility.
Configuration:
Under Answers, enter the sender policy framework configuration. For example, v=spf1 ip4:11.11.11.11 a ~all.
(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.
Configuration:
Within the answer, enter the following information corresponding to the A or AAA record to which this SRV record should resolve:
Priority of target host: enables administrators to prioritize one server that supports the given service over another. A server with a lower priority value will receive more traffic than other servers.
Relative weight for hosts with same priority: Weighted value of the target server. A server with a higher weight will receive more traffic than other servers with the same priority.
TCP or UDP service port: TCP or UDP port of the target server.
Host providing service: The name of a service, such as SIP or XMPP.
(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). TXT records may contain any information up to 255 characters per string. A single zone may contain multiple TXT records.
Configuration:
For each answer, enter the desired text to return when the domain is queried.
The following record types are specific to the NS1 platform:
(NS1-specific record type) 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 an 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.
Note
Use ALIAS records at the zone apex only. Note that resolution may be slower for ALIAS records than CNAME or linked records due to the additional external lookup process.
Configuration:
Select or deselect the option to override the TTL of the target record with the value defined in this ALIAS record. For each answer, enter one an A or AAAA record to which this ALIAS record should resolve.
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 type 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 About CNAME, ALIAS, and linked records for more information.
(NS1-specific record type) 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.
Permanent (301): This type of redirect indicates to search engines that they should remove the old page from their database and replace it with the new target page. (Recommended for SEO)
Temporary (302): Less common, this type of redirect indicates to search engines that they should keep the old domain or page indexed as the redirect is only temporary. While both pages might appear in the search results, a temporary redirect suggests to the search engine that it should prefer the new target page.
Masking: This type of redirect preserves the redirected domain in the browser's address bar. This lets the user see the address they entered, even though the content displayed is coming from a different web page.
Optionally, URLFWD records may be configured with a custom path or query forwarding. Refer to this article for more information on creating and customizing URLFWD records.