NS1-supported DNS record types

(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:

CAA <flags> <tag> <value>

• flags is an unsigned integer between 0 and 255
• tag is a non-zero sequence of US-ASCII letters and numbers in lowercase.
• value is the <character-string> encoding of the value field.

For example:

$ORIGIN example.com
@ CAA 0 issue "ca.example.net"
@ CAA 0 iodef "mailto:security@example.com"
@ CAA 0 iodef "http://iodef.example.com/"

(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.

(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.

(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 which specifies 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)

• 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 indicates a higher preference.
• weight is the weight of the target. A higher number indicates 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.
test:~ test

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.

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.

• 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.