NS1 Status

Articles in this section

NS1-supported DNS record types

  • Updated
Follow

A Domain Name System (DNS) record is 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).

Record type Description
A The most common DNS record used, an A record maps a hostname to an IPv4 address (ex. 33.22.33.44). An A record is required in order for users to reach a website or application using its hostname as opposed to memorizing the IPv4 address.
AAAA AAAA records function in the same way as an A records, except that they point to an IPv6 address (ex. FE80::0202:B3FF:FE1E:8329). The IPv6 protocol is the successor to IPv4. The limited number of permutations possible for IPv4 addresses has resulted in recent growth in the number of IPv6 addresses being used. 
AFSDB 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

Domain owners can use 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 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>

where
  • 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/"

CERT

Defined by RFC 4398 which is updated by 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 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.

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 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 is used by services like FTP to determine the correct procedures for connecting to hosts based on their configuration.
MX MX (or mail exchange) 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 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 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.
 PTR 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.
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 (.).  
SPF 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 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 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

TXT 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.
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.
  • 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 custom path or query forwarding. Refer to this article for more information on creating and customizing URLFWD records.

Related articles

Comments

0 comments

Article is closed for comments.