Skip to content
No-IP Developer Docs

DNS Record Types

DNS has many record types and each type has its own format. In general the values of the fields are in field order and separated by spaces. For instance, the fields of the MX record type are “priority” and “host”. The value then is the priority value, a space, then the host value. If “10” is the priority and “mx.example.com.” is the host, the value would be “10 mx.example.com.”

For more information about DNS Record Types see Wikipedia: List of DNS Record Types.

Common Record Types

A

The most common DNS record type. Value is a single IPv4 address represented by four decimal numbers separated by dots (the most common format).

Format: <IPv4 address>

Example: 169.254.0.1

AAAA

Value is a single IPv6 address represented as eight groups of four hexadecimal digits each, separated by colons (the most common format).

Format: <IPv6 address>

Example: 2001:db8::8a2e:370:7334

CAA

The value consists of three fields: “flag”, “tag”, and “value” separated by spaces. For more complete information see Wikipedia: DNS Certification Authority Authorization.

Format: <flag> <tag> <value>

Example: 0 issue “ca.example.net”

Fields

  • Flag: Currently there is only one value, “0”
  • Tag: Must be one of five values
    • ”issue”: allow certificates to be issued for this exact name
    • ”issuewild”: allow wildcard certificates to be issued
    • ”iodef”: method to report invalid certificates
    • ”contactemail”: How to contact the domain holder
    • ”contactphone”: Another way to contact the domain holder
  • Value: The value is dependent on the “tag” that was selected. For instance, when the tag is “contactemail” the value will be an email address.

CNAME

A canonical name that is like an alias of another. The value is another DNS name that may be in the same zone or in another one.

DNS has many rules about the use of CNAMES. No other record types may share the same name as a CNAME and CNAMEs cannot be used at the root of a zone, also known as the apex, denoted by the symbol ”@“. Also, CNAMEs may not be used as the host of an MX record.

Format: <DNS name>

Example: www.example.com.

MX

MX records tell email servers where to deliver email for the DNS name that they are associated with. For instance, email for user@example.com will be routed by the MX records of example.com.

Format: <priority> <DNS name>

Example: 10 mx.example.com.

The priority value determines which hosts an email server will be try first, lower numbers before higher ones. Records with the same priority will be selected randomly.

The DNS name value may not be a CNAME according to RFC 2181 though some email server software allow it.

NS

NS records tell the DNS network where to send queries to get authoritative information. Every zone has at least one NS record, usually at the root of the zone and managed by the DNS provider. NS records that are not at the root of the zone can be used to sub-delegate the name to another zone, possibly at another provider.

Format: <DNS name>

Example: ns1.example.com.

The DNS name value may not be a CNAME according to RFC 2181.

SOA

SOA records contain values that control the administrative portions of delivering DNS. For instance, how often a zone should be refreshed by secondary servers. Any values that may be configured in the SOA record will be found as part of the Zone management API, such as the TTL to use when a DNS name does not exist (nx_ttl).

SRV

SRV records provide service location information. Along with four fields they have a special name format. Most commonly they are used for SIP phone services. For a full description of SRV records see Wikipedia: SRV Record.

Format: <priority> <weight> <port> <DNS name>

Example: 0 5 5060 sipserver.example.com.

Fields

  • Priority: When multiple records exist ones with lower priority are used first.
  • Weight: When priorities match, higher weight is more likely to be selected.
  • Port: The TCP or UDP port to use when connecting.
  • DNS name: the canonical hostname providing the service (where to connect).

DNS Name Format

The special name format of SRV records lets the client get the connection information based on how it would like to connect.

Format: _<service>._<proto>.<DNS name>.

Example: _sip._tcp.example.com.

Combining the two examples above the full SRV record would be,

_sip._tcp.example.com. IN SRV 0 5 5060 sipserver.example.com.

This record indicates that for the SIP service over TCP, connect to port 5060 on host sip.example.com.

The list of possible services is maintained by IANA.

TXT

TXT record values may contain just about any data. Given their flexibility they are used for many different purposes. Most commonly they are used for SPF and DKIM email validation. Another common use is proving ownership of a DNS name for SSL certificates or other services.

Format: <text>

Example: I am seated in an office, surrounded by heads and bodies.

Structured values are used by many services. SPF is one example where the value starts with v=spf1 followed by list of conditions and a directive.

v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -all

But this is still a TXT record and the value is only interpreted by services that are expecting SPF data.

PTR

PTR records provide a mapping to a canonical name similar to a CNAME. Unlike a CNAME, however, the name is returned rather than being followed. The most common use of PTR records is for reverse DNS; looking up the name associated with an IP address. In reverse DNS the DNS name is decimal or hexadecimal digits. DNS-SD also makes use of PTR records but usually in an automated way.

Format: <DNS name>

Example: www.example.com.

Synthetic Record Types

Synthetic DNS record types are not supported directly by DNS but offer extensions to how DNS works.

_URL

This DNS type represents an HTTP redirect. When creating an _URL record No-IP sets up an HTTP service that will send clients to the specified location, or wrap the “redirect_to” URL in a frameset, depending on the options. The format for the value is JSON.

Format: <json object>

Example: {“redirect_to”: “https://www.noip.com”}

Fields

  • redirect_to: A fully-formed URL (required)
  • mask_enabled: A boolean indicating if the URL should be wrapped in a frameset (optional, default: false)
  • mask_page_title: If mask_enabled is true, this sets the title element in the head of the page (optional)
  • mask_meta_keywords: If mask_enabled is true, this sets the meta keywords element in the head of the page (optional)
  • mask_meta_description: If mask_enabled is true, this sets the meta description element in the head of the page (optional)

Uncommon Record Types

Some of these types are rising in popularity and even replacing more common types. Others are still in use but are niche.

  • DNAME
  • HTTPS
  • NAPTR
  • OPENPGPKEY
  • SMIMEA
  • SSHFP
  • SVCB
  • TLSA
  • URI

DNSSEC Record Types

DNSSEC uses a number of record types but they are mostly controlled by the registries and DNS server software.

  • CDNSKEY
  • CDS
  • DNSKEY
  • DS
  • NSEC
  • NSEC3
  • NSEC3PARAM
  • RRSIG
  • TA

Rare Record Types

These record types are very niche or no longer in common use.

  • AFSDB
  • APL
  • CERT
  • CSYNC
  • DHCID
  • DLV
  • EUI48
  • EUI64
  • HINFO
  • HIP
  • IPSECKEY
  • KEY
  • KX
  • LOC
  • RP
  • ZONEMD