Reference: DNS record types

Common record types

Certain record types are used frequently as they serve a particularly critical role in the DNS lookup process, including:

• A or AAAA ("address") records contain the IPv4 or IPv6 addresses, respectively, of the application host servers. When you enter a web address in your browser search bar, the DNS resolver searches for the A or AAAA record for the domain you requested and shares the IP address(es) with your client (device) so it can locate the website host server containing the content you're looking for.
• CNAME records are commonly used to direct incoming queries for one domain (www.example.com) to another domain (example.com) for which the relevant records can be found. This prevents you from having to maintain identical sets of DNS records for multiple domains. Note that CNAME records cannot be used at the zone apex. In other words, they can apply only to a subdomain of the zone FQDN.
• ALIAS records are an NS1-specific record type that function similarly to CNAME records, but they can be used at the zone apex.
• NS ("nameserver") records are automatically generated when you publish a zone to a DNS network. When you publish a zone to the Managed DNS network, for example, the NS record is automatically populated with the hostnames of the authoritative DNS nameservers to which the zone is assigned. This is important information you must use to update the nameserver delegation for this domain at your domain registrar.
• SOA (start of authority) records are automatically generated when you create a zone, and they contain administrative information about the primary nameserver for the domain as well as a set of time-to-live (TTL) values that dictate how long DNS resolvers should store zone data in their cache before requesting updated information.

A record

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

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

AAAA record

(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"
            ]
        }
    ]
}

AFSDB record

(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"]
        }
    ]
}

ALIAS record

(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"
            ]
        }
    ]
}

CAA record

(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",
                ";"
            ]
        }
    ]
}

CDNSKEY

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

CDS record

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

CERT record

(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=="
            ]
        }
    ]
}

CNAME record

(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 Comparing CNAME, ALIAS, and linked records for more information.

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 (for example, company.hostname.com) and using the CNAME to point to the customer's preferred domain (for example, 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.

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

CSYNC record

(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" 
            ]
        }
    ]
}

DHCID record

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

DNAME record

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

DNSKEY record

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

DS record

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

HINFO record

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

HTTPS record

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

• Connect directly to HTTP/3 (QUIC transport) alternative endpoints.
• Obtain the Encrypted ClientHello (ECH) keys associated with an alternative endpoint.
• Support non-default TCP and UDP ports.
• Enable SRV-like benefits (such as apex delegation) for HTTP.
• Provide an HSTS-like indication (HSTS) signaling that the “https” scheme should be used instead of “http” for all HTTP requests to this host and port.

{
    "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"
            ]
        }
    ]
}

NATPR record

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

NS record

(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"
            ]
        }
    ]
}

NSEC record

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

NSEC3 record

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

MX record

(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. 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"
            ]
        }
    ]
}

PTR record

(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"
      ]
    }
  ]
}

SOA record

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

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.

SRV record

(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"
            ]
        }
    ]
}

REDIRECT record

Specific to the NS1 Connect platform and auto-generated after creating a URL redirect configuration, the REDIRECT record type replaces the URLFWD record to enable URL redirects over HTTP or HTTPS. Refer to URL redirects for details.

RP record

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

RRSIG record

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

SMIMEA record

(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"
            ]
        }
    ]
}

SPF record

(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"
            ]
        }
    ]
}

SVCB record

Designed to address issues around service discovery, a new family of "service-binding" (SVCB) record types provides clients with complete instructions to access a service. Providing this information avoids transient connection to a suboptimal endpoint, negotiates a preferred protocol, and offers relevant public keys — helping to improve performance and privacy.

SVCB and HTTPS (an SVCB-compatible record type) records allow clients to resolve a single additional DNS record in a way that:

• Specifies targets (or alternative endpoints) that are authoritative for the service, along with associated parameters.
• Does not assume all alternative endpoints have the same parameters or capabilities or that the same entity operates them.
• Enables CNAME-like functionality at a zone apex for participating protocols and generally allows delegation of operational authority for an origin within the DNS to an alternate name. See "SVCB vs. HTTPS" below for more information about configuring CNAME-like functionality using both record types.

Note that, in addition to the goals listed above, you can use HTTPS records can be used for configurations specific to the HTTP protocol. Refer to "HTTPS record" for details.

{
    "zone": "example.com",
    "domain": "_8080._foo.example.com",
    "type": "SVCB",
    "answers": [
        {
            "answer": [
                0, "foosvc.example.net."
            ]
        }
    ]
}

{
    "zone": "example.com",
    "domain": "_8080._bar.example.com",
    "type": "SVCB",
    "answers": [
        {
            "answer": [
                0, ".", "port"=8888
            ]
        }
    ]
}

TLSA record

(RFC 6698) This record type is used to associate a transport layer security (TLS) server certificate or public key with the domain name (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"
            ]
        }
    ]
}

TXT record

(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"
            ]
        }
    ]
}