On the NS1 platform, you can create several different types of records with a zone. Records are used to map a URL to an IP address, and each record contains a specific set of data 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 in the DNS record.
A record is a basic unit of information in the DNS — identified by a domain name and a record type (such as A, AAAA, MX, NS, etc.) which indicates the nature of the information contained in the record. The record configuration specifies TTL values, the associated answers (e.g., server IP addresses, mail hosts, etc.), and other details based 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). Follow the steps below to create a DNS record in the NS1 portal.
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.
Follow the instructions below to create a new DNS record in the NS1 portal.
Navigate to DNS > Zones to view a list of zones associated with your account.
-
Click the name of the desired zone to drill down into zone details.
-
In the bottom left corner, click Add Record.
-
Select the record type from the drop-down menu. Refer to Record types below for details.
Specify a name (i.e., subdomain) for the record or leave the field blank to create a root-level record.
Specify the TTL value in seconds (default is 3600 seconds).Refer to Best practices: TTL configuration for details.
-
Under Answers, add one or more DNS answers and click Add Answer after each entry. Answer configuration options vary depending on the type of record you are creating. Refer to Record types below for details.
Note
Many record types support multiple answers (e.g., multiple endpoints to which you can direct DNS traffic). You can configure Filter Chains within the record to determine which answer(s) to return based on characteristics of the source and target IP. Refer to Configure records with multiple answers for details.
Once complete, click Save All Changes. The new record appears in the list of records within the zone.
Below is a list of record types that you can create within the Add Record modal. Refer to a specific type of record to learn more about it and for details on how to configure each record answer (based on the type).
(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.
(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.
(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) 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 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.
(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.