Record Types Supported in Custom DNS Expert Interface

Custom DNS provides two separate interfaces to editing DNS records: the Standard interface which provides support for basic record types such as A, CNAME, MX and TXT records, and the Expert interface which includes support for additional record types such as PTR, NS, SRV and more. This article provides examples of the use of each type of record supported in the Expert interface. (A separate article is provided to document the records supported in the Standard interface.)

Standard vs. Expert Interfaces

The following chart demonstrates the differences between the Standard and Expert interfaces.

  Standard Expert
Record Types A, CNAME, MX, TXT A, CNAME, MX, TXT, AAAA, LOC, NS, PTR, SRV
Interface Wizard-based BIND-style (Host, TTL, Type, Data)
Advantages Easier to use, one-click configuration for MailHop® services More record types, customize TTL and Data field for any record

Note: You can switch between the Standard and Expert interfaces at any time using the "Preferences" button upper right of the page when viewing a Custom DNS zone. This setting is stored on a per zone basis, so some zones can be in the Standard interface and others can be in the Expert interface. No data is lost when switching between interfaces, but you cannot add, modify or delete records other than A, CNAME, MX and TXT in the Standard interface. (A list of additional record types appears under the Advanced Records section at the bottom of the page.)

The Hostname Field

The Hostname field is essentially a label given to a record, such as www.domain.com or ftp.domain.com, to differentiate it from other records for a domain. A record's hostname is restricted to allow only the characters A thru Z, the digits 0 thru 9, and hyphens (-). Note that hyphens may not be used in either the first or last position (e.g. -www.domain.com or ftp-.domain.com). Certain specific record types, such as SRV, can use underscores (_). In most cases, the hostname field may be left blank to create a second-level record for the domain itself (e.g. a MX record for domain.com), and an asterisk (*) can be used to create a wildcard record that will accept any hostname (e.g. the A record *.domain.com would cover www.domain.com, ftp.domain.com and asdf1234.domain.com).

The TTL Field

A record's TTL, or Time To Live, is the length of time (in seconds) that caching name servers will store this record in their local cache before performing a new query. Setting a low TTL value (e.g. 60 seconds) will shorten the length of time that it takes other name servers to notice that you have made a change. Setting a high TTL value (e.g. 12 hours) will provide for better overall performance (as your records will stay in cache longer, and a full lookup won't be required as often). You can learn more about caching and our recommended TTL values for each record here, though in general we suggest no value lower than 60 seconds or higher than one week.

Record Types

Host (A) Records

An A (or address) record maps a host name to an IPv4 address. This allows visitors to locate the address of your server, similar to a phone book listing the telephone number for a person or business. Host records in Custom DNS can be automatically updated using update clients, which utilize our open update procotol.

Host records in Custom DNS have three options:

AAAA Records

AAAA (pronounced "quad-A") records map hostnames to IPv6 addresses. IPv6 is a new standard for providing a larger, fully routable network than can be achieved using the legacy IPv4 address space. However, at present very few computers on the Internet are actually making use of IPv6, and most customers do not require AAAA records. If you aren't sure whether or not you need one, odds are you don't.

The Data field takes an IPv6 address (e.g. fe80:0000:0000:0000:020d:93ff:feea:ba42).

CNAME Records

CNAME records alias one host name to another. For example, many customers alias www.domain.com to domain.com; this ensures that both www.domain.com and domain.com are always assigned to the same IP address.

The Data field takes a FQDN (fully qualified domain name). Usually, CNAME records are aliased to host (A) records, but CNAMEs may also point to other CNAME records.

There is one very important limitation on CNAME records: if a given hostname has a CNAME record, it can not have any other record, including MX, A or even other CNAMEs.

LOC Records

LOC (Location) records are very rarely used, though various uses have been proposed. The most interesting of these involves high-tech thieves with GPS units (thanks Men and Mice), ICBMs, geocaching and alternate realtiy games. The intent behind LOC records is to provide a geographic location record for a host.

Here's an example of an LOC record which might be used with an ICBM:

osama.bin.laden.
86400
IN
LOC
35 49 56.652 N 73 46 22.912 E 2147m 1609344m 2000m

The Data field for LOC records is fairly complex. From RFC 1876 we have:

d1 [m1 [s1]] {"N"|"S"} d2 [m2 [s2]] {"E"|"W"} alt["m"] [siz["m"] [hp["m"] [vp["m"]]]]
where:
d1:
[0 .. 90]
(degrees latitude)
d2:
[0 .. 180]
(degrees longitude)
m1, m2: [0 .. 59]
(minutes latitude/longitude)
s1, s2: [0 .. 59.999]
(seconds latitude/longitude)
alt:
[-100000.00 .. 42849672.95] BY .01 (altitude in meters)
siz, hp, vp: [0 .. 90000000.00] (size/precision in meters)
If omitted, minutes and seconds default to zero, size defaults to 1m,
horizontal precision defaults to 10000m, and vertical precision
defaults to 10m.
These defaults are chosen to represent typical
ZIP/postal code area sizes, since it is often easy to find
approximate geographical location by ZIP/postal code.

The parts contained within square brackets [] are optional and may be omitted.

MX Records

Mail eXchanger (MX) records define the destination servers for a domain's email. You can learn more information about MX records in general in our E-mail, Mail Exchangers, and DNS article, and learn specific information about email with Custom DNS in our Getting E-mail With Custom DNS article.

Here are sample MX records using our MailHop Relay and MailHop Forward services:

example.com.
43200
IN
MX
10 mx1.mailhop.org.
example.com.
43200
IN
MX
20 mx2.mailhop.org.

The Hostname field is typically left blank and represents the portion of the email address to the right of the @ character. For example, if you are creating an MX record to control where mail addressed to users@example.com should be sent, then the Host field is left blank. For users@freemail.example.com you would enter "freemail".

The Data field takes two values separated by a space. The first value (the Preference) is a number from 0 to 9999 and determines the order in which mail servers should be tried. For example, if you have two MX records, one with a Preference 5 and one with a Preference of 10, mail delivery will be attempted to the mail server with the Preference of 5 first. The second value in the Data field is the FQDN name of the mail server to which the mail should be sent.

MX records may only ever use A or AAAA records in the Data field. MX records may never be assigned to a CNAME or IP address.

NS Records

NS (Name Server) records designate which name servers are responsible for answering DNS queries for a domain (or subdomain). Every zone in Custom DNS has 5 NS records:

example.com.
86400
IN
NS
ns1.mydyndns.org.
example.com.
86400
IN
NS
ns2.mydyndns.org.
example.com.
86400
IN
NS
ns3.mydyndns.org.
example.com.
86400
IN
NS
ns4.mydyndns.org.
example.com.
86400
IN
NS
ns5.mydyndns.org.

These NS records are not displayed in either the Expert or Standard interface, and can not be modified in any way. However, customers can create third-level or lower NS records to delegate a specific subdomain to another set of nameservers.

When creating an NS record, the Hostname field takes the name of the subdomain you are trying to delegate, and the Data takes the FQDN of the name server to which you are delegating. Typically, you should create at least two NS records for any given subdomain. As with MX records, FQDN of the name server can only use A or AAAA records; they cannot use CNAMEs or IP addresses.

The most common use for NS records is when a customer is using third-party DNS for a domain, and wants to delegate a specific subdomain to Custom DNS. At the third-party DNS provider, the customer would create records like so:

some-customer.example.com.
86400
IN
NS
ns1.mydyndns.org.
some-customer.example.com.
86400
IN
NS
ns2.mydyndns.org.
some-customer.example.com.
86400
IN
NS
ns3.mydyndns.org.
some-customer.example.com.
86400
IN
NS
ns4.mydyndns.org.
some-customer.example.com.
86400
IN
NS
ns5.mydyndns.org.

The subdomain some-customer.example.com would now resolve to Custom DNS, where it can be kept updated with a client; the rest of the domain's DNS settings are left untouched, and are still resolved by the third-party provider. You can learn more about using subdomains with Custom DNS here.

In Custom DNS, you can use NS records to delegate a subdomain off to your own (or third party) name servers:

some-host.example.com.
86400
IN
NS
ns1.example.com.
some-host.example.com.
86400
IN
NS
ns2.example.com.

PTR Records

PTR (Pointer) records provide what is known as "reverse DNS". PTR records assign IP addresses to a host name, instead of mapping a host name to an IP address. You can learn more detailed information on reverse DNS and PTR records in our What is Reverse DNS and Reverse DNS in Custom DNS articles.

Before PTR records will function in Custom DNS, you must contact your Internet Service Provider and ask them to delegate the IP addresses to us as described in the Reverse DNS in Custom DNS article. If you create a PTR record in a Custom DNS zone, but do not ask your ISP to delegate it to our servers, it will not function.

SRV Records

SRV (Service) records are a generalization and expansion of features provided by MX records. Where MX records work only for mail delivery and provide "failover" via the Priority value, SRV records add in support for load balancing (via the Weight value) and port selection (via the Port value). SRV records are most often used for service discovery applications such as Zero Configuration Networking.

This flexibility makes SRV records fairly complex and both the Host and Data fields of SRV records are different from other record types. The Host field of an SRV record is composed of three parts separated by periods (.):

Service
The symbolic name of the desired service, as defined in Assigned Numbers [STD 2, RFC 1700] or locally. An underscore (_) is prepended to the service identifier to avoid collisions with DNS labels that occur in nature.
Proto
The symbolic name of the desired protocol, with an underscore (_) prepended to prevent collisions with DNS labels that occur in nature. _TCP and _UDP are at present the most useful values for this field, though any name defined by Assigned Numbers or locally may be used (as for Service). The Proto is case insensitive.
Name
The domain and/or host this RR refers to.

Here we have an example of the Host portion of an SRV record for the LDAP service on the domain example.com: 

_ldap._tcp.example.com

The Data value for an SRV record is comprised of four parts separated by spaces. These parts are Priority, Weight, Port and Target.

Priority
The priority of this target host. Clients will attempt to contact the target host with the lowest-numbered priority it can reach. This value is an integer in the range 0-65535.
Weight
The weight field specifies a relative weight for entries with the same priority. Larger weights are given a proportionately higher probability of being selected. This value is an integer in the range 0-65535. If you have only a single SRV record, use 0 as the weight.
Port
The port on this target host of this service. This value is an integer in the range 0-65535. This is often as specified in Assigned Numbers but need not be, and may in any case be different from the default port defined for a service.
Target
The domain name of the target host. There MUST be one or more address records for this name, the name MUST NOT be an alias (in the sense of RFC 1034 or RFC 2181).

A Target of "." means that the service is decidedly not available at this domain.

Here is an example of how SRV records might be used to provide load balancing and failover for FOO (a mythical service type) traffic: 

_foo._tcp.example.com.
43200
IN
SRV
0 1 8000 slow-box.example.com.
_foo._tcp.example.com.
43200
IN
SRV
0 3 8000 fast-box.example.com.
_foo._tcp.example.com.
43200
IN
SRV
1 0 8080 backup-one.example.com.
_foo._tcp.example.com.
43200
IN
SRV
1 0 9000 backup-two.example.com.

In the above example, there are two primary servers each having a Priority of 0. The second server (fast-box.example.com) has a higher weight so that (on average) 75% of the traffic would be directed to this server and 25% to the slower server.

If neither of the primary servers can be reached, clients would fall back to connecting to the secondary servers which have a priority of 1. Since each of these servers have a weight of 0, each server would tend to get the same number of connection requests.

Note also the use of different Port values for the secondary servers. This shows how SRV records can be used to redirect traffic to a port other than the port commonly used for that service.

Cautionary Note: SRV record support is still very limited. With the exception of fairly new services (notably VOIP services and some chat services), SRV records are not supported. Hopefully this will change over time. At the time of this writing, no HTTP clients (web browsers) support SRV records, despite the obvious benefits that such support would provide.

Detailed info on SRV records is available in RFC 2782

TXT Records

Unlike other record types, Text (TXT) records are free-form; they can be used for purely descriptive labels on hosts (e.g. "This is Bob's old Dell in Accounting"), or they can be used for a variety of special functions such as Domain Keys and SPF records. Because text records are free-form, new services and protocols can make use of DNS without needing to have a new record type created specially for them.

When using text records that include spaces, make sure to add double quotes (" ") around the Data field. Without the quotes, each space causes the record to be broken into separate pieces, which can cause problems with special records like SPF. Here are example SPF and Domain Key TXT records (note the use of double quotes):

example.com.
43200
IN
TXT
"v=spf1 a a:outbound.mailhop.org ~all"
_domainkey.example.com.
43200
IN
TXT
"t=y\; o=~\; r=postmaster@example.com"