Guide to DNS record types

(RFC 1035) The most common DNS record used, an A (or address) record maps a domain to an IPv4 address (e.g., 198.0.2.36) of the computer hosting the domain. All zones should contain at least one A record for users to access a website or application using its hostname.

{
    "zone": "example.com",
    "domain": "sub.example.com",
    "type": "A",
    "answers": [
        {
            "answer": [
                "198.0.2.36"
            ]
        },
        {
            "answer": [
                "198.0.2.37"
            ]
        }
    ]
}

(RFC 3596) AAAA records function in the same way as A records, except that they map domains to an IPv6 address (e.g., 2001:db8:85a3::8a2e:370:7334) of the computer hosting the domain.

{
    "zone": "example.com",
    "domain": "sub.example.com",
    "type": "AAAA",
    "answers": [
        {
            "answer": [
                "2001:db8:85a3::8a2e:370:7334"
            ]
        }
    ]
}

(NS1-specific) ALIAS is a special record type that works like a CNAME record but can be used safely at the zone apex. On the NS1 platform, ALIAS records always resolve to A and AAAA records by running a DNS resolver in each of NS1’s PoPs. Resolution to the target is a completely internal process — DNS recursors making the query cannot differentiate between an ALIAS record and an A (or AAAA) record. An ALIAS record will always return one or more A or AAAA records. Since ALIAS is a pseudo-record, the response will never include the ALIAS record itself.

curl -X PUT -H "X-NSONE-Key: $NSONE_API_KEY" https://api.nsone.net/v1/zones/<zoneName>/<domain>/ALIAS -d '
{
    "zone": "<zoneFQDN>",
    "domain": "<zoneFQDN>",
    "type": "ALIAS",
    "override_address_records": false,
    "answers": [
        {
            "answer": [
                "<targetDomain>"
            ]
        }
    ]
}'
{
    "zone": "example.com",
    "domain": "example.com",
    "type": "ALIAS",
    "answers": [
        {
            "answer": [
                "new.example.com"
            ]
        }
    ]
}

(RFC 1035) 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. If DNSSEC is enabled, an alias name (prefix of a CNAME record domain) may have RRSIG and NSEC/NSEC3 records but may have no other data. Refer to this article for more information.

Common use cases for a CNAME record include:

{
    "zone": "example.com",
    "domain": "company.example.com",
    "type": "CNAME",
    "answers": [
        {
            "answer": [
                "company.com"
            ]
        }
    ]
}

(RFC 1035) 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 to the organization's domain, such as support@ns1.com. You can add multiple MX records with varying priorities if multiple mail servers are configured.

{
    "zone": "example.com",
    "domain": "example.com",
    "type": "MX",
    "answers": [
        {
            "answer": [
                1,
                "mailhost1.example.com"
            ]
        }
    ]
}

(RFC 1035) Typically configured with your registrar, nameserver (NS) records are used to delegate a domain or subdomain to a set of nameservers. Nameservers, such as NS1’s Managed DNS nameservers, host all DNS data for a domain and tell all the other computers connected to the internet which records your domain holds. Therefore, setting the NS record is a critical step in getting your domains and servers online.

{
    "zone": "example.com",
    "domain": "sub.example.com",
    "type": "NS",
    "answers": [
        {
            "answer": [
                "ns1.sub.example.com"
            ]
        },
        {
            "answer": [
                "ns2.sub.example.com"
            ]
        }
    ]
}

(RFC 4034) An NSEC record (sometimes referred to as the “next secure record”) is used to provide an authenticated denial of existence. It contains a link to the next domain name and the record types that exist for that domain. DNS resolvers use NSEC records to verify the non-existence of a record name and type as part of DNSSEC validation.

(RFC 5155) The NSEC3 record provides authenticated denial of the existence of DNS records. It lists record types present at the original domain name of the NSEC3 record and includes the next hashed owner name in the hash order of the zone. NSEC3 records are similar to NSEC records, but NSEC3 uses cryptographically hashed record names to avoid the enumeration of the record names in a zone.

(RFC 1035) Often described as the opposite of an A record, pointer (PTR) records are used for reverse zone lookups. 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.

After creating a reverse zone (for example, 2.0.192.in-addr.arpa), you can add a PTR record to the zone. For the record’s subdomain prefix, you can enter the final octet or character of the IP address for the server or leave this field blank to indicate an apex-level record.

{
  "zone": "2.0.192.in-addr.arpa",
  "domain": "2.0.192.in-addr.arpa",
  "type": "PTR",
  "answers": [
    {
      "answer": [
        "www.example.com"
      ]
    }
  ]
}

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

SOA records are generated automatically by the platform, but they do not appear in the list of records alongside others within the zone. You can modify SOA settings by editing the zone settings in the portal or via API.

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

{
    "zone": "example.com",
    "domain": "_discard._tcp.example.com",
    "type": "SRV",
    "answers": [
        {
            "answer": [
                1, 100, 9, "server.example.com"
            ]
        }
    ]
}

(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, and one TXT record may contain multiple answers.

{
    "zone": "example.com",
    "domain": "example.com",
    "type": "TXT",
    "answers": [
        {
            "answer": [
                "string"
            ]
        }
    ]
}

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

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.

(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 of the file database.

{
    "zone": "example.com",
    "domain": "afsdbrecord.example.com",
    "type": "AFSDB",
    "answers": [
        {
            "answer": [1,"arecord.example.com"]
        }
    ]
}

(RFC 8659) Domain owners can use DNS Certification Authority Authorization (CAA) records to indicate one or more certificate authorities (CAs) allowed to issue SSL certificates for a domain. Before issuing a certificate, compliant CAs must check for the CAA record unless an exception specified in the relevant certificate policy (CP) or certification practices statement (CPS) applies. The CAA record prevents an unauthorized CA from issuing an SSL certificate for your domain.

{
    "zone": "example.com",
    "domain": "caa.example.com",
    "type": "CAA",
    "answers": [
        {
            "answer": [
                0,
                "issue",
                "letsencrypt.org"
            ]
        }
    ]
}

{
    "zone": "example.com",
    "domain": "caa.example.com",
    "type": "CAA",
    "answers": [
        {
            "answer": [
                0,
                "issue",
                ";"
            ]
        }
    ]
}

(RFC 7344) The “child DNSKEY” (CDNSKEY) record type is used to enable DNSSEC on a child zone (i.e., subdelegation). Each record contains one or more DNSSEC keys required to sign zone data contained in this child zone.

(RFC 7344) The “child DS” (CDS) record type is used to enable DNSSEC on a child zone (i.e., subdelegation). Once created, the parent zone is notified of its existence, and, in response, the parent zone retrieves the CDS record and inserts the corresponding DS record data.

(RFC 4398, 69446944) 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.

{
    "zone": "example.com",
    "domain": "certrecord.example.com",
    "type": "CERT",
    "answers": [
        {
            "answer": [
                 "OID" "12345" "PRIVATEOID" "AZwz/Q=="
            ]
        }
    ]
}

(RFC 7477) CSYNC records indicate which delegation records published by a child DNS operator should be processed by a parental agent and used to update the parent’s zone data. These types of records are published at the apex of the child zone, making it easier for operators to update their delegation records within the parent’s set quickly.

Typically, there are some record types expected to remain in sync across parent and child zones. Most commonly, these include the NS records and any necessary A or AAAA records (“glue records”). It can be a challenge for operators of child DNS zones to update delegation records quickly, particularly when managing a large, complex set of DNS zones. The CSYNC record presents an automated mechanism for signaling updates at the child zone that must be reflected in the parent zone data.

{
    "zone": "example.com",
    "domain": "example.com",
    "type": "CSYNC",
    "answers": [
        {
            "answer": [
                "1652223375", 3, "A NS AAAA" 
            ]
        }
    ]
}

(RFC 4701) DHCID records are referenced by DHCP clients or servers to associate a DHCP client’s identity with a DNS name so that multiple DHCP clients and servers may deterministically perform dynamic DNS updates to the same zone.

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

(RFC 4034) The DNSSEC key (DNSKEY) record stores public DNSSEC key data for a particular zone for use in the DNSSEC authentication process. In this process, a zone signs its authoritative record data using a private key and stores the corresponding public key in the DNSKEY record.

DNSKEY records are auto-generated when you enable DNSSEC online signing for a given NS1 zone and populated with data generated by NS1.

(RFC 4034) The DS record points to the relevant DNSKEY record to use in the DNSSEC authentication process for this zone.

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

The HTTPS record is an SVCB-compatible record type designed specifically for the HTTP protocol. This record type can be used to enable CNAME-like functionality at the zone apex or for multi-CDN hosting. It signals to the client that it can connect over a secure connection, skipping the initial unsecured request, and it advertises the different HTTP versions supported by the website.

In addition to those listed under the SVCB record description, goals specific to the HTTPS record type include:

{
    "zone": "example.com",
    "domain": "example.com",
    "type": "HTTPS",
    "answers": [
        {
            "answer": [
                0, "example.net."
            ]
        }
    ]
}

{
    "zone": "example.com",
    "domain": "example.com",
    "type": "HTTPS",
    "answers": [
        {
            "answer": [
                 1 . alpn="h3,h2"
            ]
        }
    ]
}

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

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

(RFC 4034) DNSSEC uses public key cryptography to sign and authenticate DNS records. Digital signatures are stored in RRSIG records and are used in the DNSSEC authentication process. A validator can use the RRSIG record data to authenticate records from the zone. RRSIG records contain the signature for a DNS record with a particular name, class, and type. It specifies a validity interval for the signature and uses the algorithm, the signer’s name, and the key tag to identify the DNSKEY record containing the public key that a validator can use to verify the signature.

(RFC 8162) The SMIMEA record is used to associate an end entity certificate or public key with an associated email address, thus forming a “SMIMEA certificate association.” It allows an application or service to obtain a S/MIME certificate or public key and use it for verifying a digital signature or encrypting a message to the public key. The DNS answer must pass DNSSEC validation.

{
    "zone": "example.com",
    "domain": "example.com",
    "type": "SMIMEA",
    "answers": [
        {
            "answer": [
                0, 0, 1, "d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971"
            ]
        }
    ]
}

(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:198.0.2.201 a -all (replacing the IP address 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 will be rejected or marked as spam. You can specify multiple IPv4 addresses as individual answers in the SPF record if you have multiple mail servers.

{
    "zone": "example.com",
    "domain": "example.com",
    "type": "SPF",
    "answers": [
        {
            "answer": [
                "v=spf1 ip4:198.0.2.201 a ~all"
            ]
        }
    ]
}

(RFC 6698) This record type is used to associate a transport layer security (TLS) server certificate or public key with the domain name (i.e., zone) within which this record is located, thus forming a “TLSA certificate association.”

{
    "zone": "example.com",
    "domain": "example.com",
    "type": "TLSA",
    "answers": [
        {
            "answer": [
                0, 0, 1, "d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971"
            ]
        }
    ]
}