Managed DNS Express: Fast, reliable DNS without breaking the bank. Get your first month FREE today! Get it now

Your Current Language Is:

Record Types Supported in Dyn Standard DNS

Dyn Standard 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.

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 Dyn Email 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 Dyn Standard 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.)

Host (A) Records

A host (A) record maps a hostname to an IP 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 Dyn Standard DNS have the following attributes:

  • The Hostname field is the name of the host record itself, such as www in www.domain.com. Hostnames are restricted to the characters A thru Z, the digits 0 thru 9, and hyphens (-). The host field can be left blank to create a second-level record (e.g. domain.com). Using a single asterisk (*) generates a wildcard record, which resolves for all possible subdomains (e.g. *.domain.com will resolve for www.domain.com, ftp.domain.com, asdf1234.domain.com, etc.).
  • The Service Type field chooses the desired service:
    • Host with IP Address is a standard host record, which publishes the IP Address field in DNS.
    • Webhop Redirect sets your host record to our Webhop server’s IP, which sends visitors to the desired Redirect URL. You can learn more in the URL forwarding section.
    • Offline Hostname sets your host record to our offline website.
  • The TTL sets the Time to Live value for the host record. The longer the cache time, the less often visitors will need to look up a new copy of the record.
    If the IP address changes frequently, use a low TTL so visitors will retrieve the most up-to-date address; if the IP address changes very rarely or never changes, use a high TTL so visitors will not need to resolve it as often, allowing them to reach your site faster.
  • The IP address field takes an IPv4 address (for example 192.168.1.4).
  • The Redirect URL field takes a full URL (such as http://www.example.com/subdir/page.html), and can be used to redirect to alternate ports (such as http://www.example.com:8080).
  • If Cloak this page? is checked, the redirection will be hidden with frames. The title bar is replaced with the Cloak Page Title.

Enter sample data in the fields below to see the A record which would be generated:

.example.com
Service Type


Host with IP Address
Webhop Redirect

example.com.
60
IN
A
0.0.0.0

Alias (CNAME) Records

CNAME records alias one host name to another. For example, many customers alias www.example.com to example.com; this ensures that both www.example.com and example.com are always assigned to the same IP address. CNAME records in Dyn Standard DNS take the following options:

  • As with host (A) records, the Hostname field is restricted to allow only the characters A thru Z, the digits 0 thru 9 and the hyphen (-). The Hostname field can use an asterisk (*) to generate a wildcard CNAME record. (The Hostname field cannot be left blank, as RFCs prohibit second-level CNAME records.)
  • The Alias To 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.

Enter sample data in the field below to see the CNAME record which would be generated:

.example.com

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

Mail eXchanger (MX) Records

Mail eXchanger (MX) records define the destination servers for a domain’s email. In the Dyn Standard DNS Standard interface, customers are provided with a simple text field for entering their domain’s MX records in order of preference. If you have more than one MX record with the same priority, or wish to create MX records for subdomains (e.g. an MX record for forums.domain.com), you may create these records through the Expert interface.

Enter sample data in the field below to see the MX record which would be generated and a description of how mail would be delivered:


example.com.
43200
IN
MX
10 mail.example.com.
example.com.
43200
IN
MX
20 backup.example.com.

Text (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 DKIM 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 creating a TXT record in the standard interface you provide the following data:

  • The Hostname field is restricted to allow only the characters A thru Z, the digits 0 thru 9, the hyphen (-) and the underscore (_). The Hostname field can be left blank to create a second-level record, and can use an asterisk (*) 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. Please note: When entering a string that includes spaces, such as SPF records, you must enclose the string in double quotes; otherwise, individual words will be separately quoted and break up the record into multiple parts.

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"

Enter sample data in the field below to see the TXT record which would be generated:

.example.com

hidden.example.com.
43200
IN
TXT
"Nothing to see here..."

AAAA Records in the Expert Interface

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

LOC Records in the Expert Interface

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

NS Records

NS (Name Server) records designate which name servers are responsible for answering DNS queries for a domain (or subdomain). Every zone in Dyn Standard 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 Dyn Standard 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 Dyn Standard 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.

In Dyn Standard 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 in the Expert Interface

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 find more detailed information on reverse DNS and PTR records in our Reverse DNS support article.

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

SRV Records in the Expert Interface

SRV (Service) records are a generalization and expansion of features provided by MX records. Where MX records work only for email 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 (not a real service type, used for example) 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

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), though in general we suggest no value lower than 60 seconds or higher than one week.

Community Forum

Need help setting up your network? Ask your question in our community of networking experts.
Dyn Community Forum »

Email Support

Email support is available for all paid accounts, and is our preferred method of contact. If you have a paid service, please login to view the support page.

Phone Support

Phone Support is only available to customers with certain services. If you have a paid service, please login to view the support page.