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 just A, CNAME, MX and TXT records and the "Expert" interface which includes support for additional record types. This KB article provides examples of the use of each type of record supported in the Expert interface. A separate KB article is provided to document the records supported in the Standard interface.

Note: You can switch between the Standard and Expert interfaces at any time using the "Preferences" link in the upper right hand corner of the window 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 record types other than A, CNAME, MX and TXT will not be visible when in the Standard interface.

The TTL Field

Before discussing the various different DNS records, a short note on the TTL field is in order. TTL stands for Time To Live. This is the length of time (expressed in seconds) that caching name servers will store this record in their local cache before performing a new query.

Setting a low TTL value (60 seconds, for instance) 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 will provide for somewhat 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.

A Records

An A (or address) record maps a host name to an IPv4 address.

A records are also the only records in Custom DNS for which we provide the ability to update dynamically.

The Host field is restricted to allow only the characters A thru Z, the digits 0 thru 9 and the hyphen (-). Note that the (-) character may not be used in either the first or last position. The host field may be left blank and may also be the single character '*' (which generates a wildcard A record).

The Data field takes an IPv4 address (for example 192.168.1.2).

Host records in Custom DNS can be changed into WebHop redirections or use the Offline Hostname feature. You can learn more about the interface here. To access these additional host settings in Expert, simply click the link for the A record under the Host column.

AAAA Records

A AAAA (pronounced "quad-A") record maps a host name to an IPv6 address.

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 these. If you aren't sure whether or not you need one, odds are you don't.

As with A records, The Host field is restricted to allow only the characters A thru Z, the digits 0 thru 9 and the hyphen (-). Note that the (-) character may not be used in either the first or last position. The host field may be left blank and may also be the single character '*' (which generates a wildcard AAAA record).

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

CNAME Records

CNAME (canonical name) records map one host name to another, making the first host an "alias" for the second. For example, in the record:

www.example.com.   43200      IN      CNAME   example.com.

the host "www.example.com" is an alias for (has a cname of) "example.com".

There is one very important limitation on CNAME records, and that is if a given host has a CNAME record, it can not have any other record (not even a second CNAME).

As with A records, the Host field is restricted to allow only the characters A thru Z, the digits 0 thru 9 and the hyphen (-). The Host field may also be the single character '*' (which generates a wildcard CNAME record). However, unlike with A records, the Host field for CNAME records may NOT be left blank.

The Data field takes a FQDN (fully qualified domain name). This should in general be the name of an A record, but may also point to the name of another CNAME record.

LOC Records

LOC (stands for location) records are very rarely used, though various uses have been proposed. The most interesting of these involves hi tech thieves with GPS units (thanks Men and Mice) and ICBMs. The intent behind LOC records is to provide a geographic location record for a host. Perhaps something useful could be found to be done with these involving Google Maps...

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

As with A records, The Host field is restricted to allow only the characters A thru Z, the digits 0 thru 9 and the hyphen (-). Note that the (-) character may not be used in either the first or last position. The host field may be left blank and may also be the single character '*' (which generates a wildcard LOC record).

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

MX (mail exchanger) records indicate where mail for a domain should be delivered. Detailed info on MX records and their use in Custom DNS can be found in the following KB articles:

Examples of MX records used with our MailHop services: 

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

The Host 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. Note, this FQDN must be defined by an A or AAAA record and never by a CNAME.

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.

However, these NS records are not displayed in either the Expert or Standard interface and can not be modified in any way.

When creating an NS record, the Host field takes the name of the subdomain you are trying to create and the Data takes the FQDN of the name server you are delegating the subdomain too. Typically you will create at least two NS records for any given subdomain. as with MX records FQDN of the name server must be defined by an A or AAAA record and never by a CNAME.

One specific use for creating NS records within a Custom DNS zone would be to delegate a subdomain of your domain back to our Custom DNS servers so that you (or another customer) could create a separate Custom DNS zone to manage the subdomain.

Example of a subdomain delegated back to Custom DNS: 

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

You can , of course, also 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". That is, they map an IP address to a host name instead of mapping a host name to an IP address.Detailed info on PTR records and their use in Custom DNS can be found in the following KB articles:

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

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 (.). These parts are Service, Proto, and Name.

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: It should be noted that 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

TXT records are a funny beast. They used to be used for purely descriptive labels on hosts, so you could pack info into the DNS record that specified something useful about the machine the host pointed to.

For instance, you might have had TXT records like these: 
fred.example.com.   43200   IN  TXT  "This is Fred Jones in Accounting"
fred.example.com.   43200   IN  TXT  "Phone: 202-555-1212"

Very useful in a large organization with hundreds or even thousands of machines. Lately TXT records have started being used as the dumping ground for new, experimental DNS based technologies such as Domain Keys and SPF.

The Host field is restricted to allow only the characters A thru Z, the digits 0 thru 9, the hyphen (-) and the underscore (_). The Host field can be left blank and can also be the single character '*' (which generates a wildcard TXT record).

Unlike with most other record types, for TXT records the Data field is essentially free form and may even include spaces. When entering a string that includes spaces you must enclose the string in double quotes or the individual words will be separately quoted.

An example SPF and Domain Key TXT records: 

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"