A

Basic + Expert Modes

Address (A) Record

The Address (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:

Hostname

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

Service Type

Select the service type for your A record.

Host with IP Address

This 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

This sets your host record to our offline website.

TTL (Time To Live)

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.

IP Address

The IP address field takes an IPv4 address (for example, 192.168.1.4).

Redirect URL (Webhop)

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

CNAME

Basic + Expert Modes

CNAME Record

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:

Hostname

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

Alias To

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.

MX

Basic + Expert Modes

Mail Exchanger (MX) Record

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.

TXT

Basic + Expert Modes

TXT Record

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 especially for them.

When creating a TXT record in the standard interface, provide the following data:

Hostname

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.

Data

Unlike with most other record types, for TXT records the Data field is essentially free-form and may even include spaces.

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.

Note: Double quotes are also used when your TXT record has more than 255 characters. This often happens for DKIM and SPF records. If you need more than 255 characters, enclose sections of the text in double quotes. Each string within quotes is treated as its own packet. Multiple strings are treated as being concatenated together without adding spaces. (RFC 4408 section 3.1.3) The second example shows this.

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"

Here is an example of a TXT record for DKIM with more than 255 characters. (note the use of double quotes) When splitting the TXT record, make sure that all intended spaces are within the quotation marks. When the separate strings are concatenated, there are no spaces between the strings.

"v=DKIM1\; k=rsa\; p=MIIBIjANB"
"gkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArHsdDxL+4Gs44BV0TZ8hY2NZ0/qYkqXC1rFHj1WayMXnliHYXZtGdmtpDRJWDC1+/6M8D68
sRu4zQNRiUho4ZISbrmQNbTxe7Zv4GaegexF6yDjzl+BtegDo24gVP/9DMbObv/cFny+Qa8ifM5ThEUMDlKAG+qZL1E/U2fq6vXsHakbfw0Ostz/WeB85c
kW5qePj/yY"
"n3FyKxVy28oKAvOt1rhx1hvkRQA59RfhzmhV/FF78y7OFy87q2k0qHvXKjuTIrHckU95x1wFM6baL7fUIBb3CJSCla7FXoFUip6DwAudm9xO+lnrY4lTo
3nAzw+gCNA+dDGxKETdinFdaJwIDAQAB"

AAAA

Expert Mode

Address Record IPv6 (AAAA)

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 fe80:0000:0000:0000:020d:93ff:feea:ba42.

LOC

Expert Mode

Location (LOC) Record

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.
The Data field takes a specific list of coordinates and information that must be formatted in accordance with RFC 1876:

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.

NS

Expert Mode

Name Server (NS) Record

NS (Name Server) records designate which name servers are responsible for answering DNS queries for a domain (or subdomain).

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 name servers.

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

Expert Mode

Pointer (PTR) Record

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.

SRV

Expert Mode

Service (SRV) Record

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.
The following is 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, and the name MUST NOT be an alias (in the sense of RFC 1034 or RFC 2181).
A Target of “.” means that the service is 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 has 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.