Support - Zerigo DNS

Host types

DNS Host records all have a type. Officially they are called RRs (resource records). This article will discuss each of the types supported by the Zerigo platform along with any special notes on how to use them.


Probably the most basic type is the A or Address record. An A record associates a name ( to an IP ( A records always point to IPv4 addresses.


AAAA records are also address records. They serve the same function as A records except they are for IPv6 addresses.


CNAME stands for canonical name. It's a way of aliasing one hostname to another hostname. There are some rules about valid use of CNAMES.

First, a CNAME record trumps nearly all other record types for the same hostname. As such, for the a single hostname, Zerigo does not allow both a CNAME and another record type that would be ignored anyway.

Second, CNAMEs may not be configured without a hostname. That is, they may not apply to the plain domain name. You may however use an Alias record instead, which doesn't have such a limitation.


DNS specifications prohibit having a CNAME on the base domain. This is what Alias record, a fake record interpreted by Zerigo DNS server, is supposed to workaround. Whenever a query for aliased domain is performed, our DNS server performs a live lookup for the target of Alias record and returns records present on the target domain.

Consider this example: IN A IN ALIAS
$ dig +noall +answer @zerigo
this. 600 IN A


MX stands for Mail eXchanger. An MX record identifies which server is designated to process incoming email for a given hostname.

In the absence of an MX record, email programs will default to trying the A record instead. However, this is far from ideal and an MX record should always be configured if you intended to receive email.

MX records also require a priority, which identifies the order in which to try each mail server when there is more than one MX record. Lower numbers are a higher priority (eg: 10 is a higher priority than 20).

An MX record must point to a hostname which itself resolves to an A or AAAA record (not a CNAME).


NAPTR (Naming Authority PoinTeR) records are a complex record type designed to provide a translation system from abstract, standardized URNs (Universal Resource Names) into concrete, more useful URIs (Universal Resource Identifiers). They are commonly used in SIP/VOIP applications.


Domain name servers are identified by NS records. The NS records for the configured domain (and any specified slave servers) are automatically managed by Zerigo. The only time you may need to add your own NS records is to delegate a subdomain.


PTR records are part of building a reverse domain. Reverse domains allow IP addresses to be associated back to domain names.

Reverse domains themselves must be configured specially. For IPv4, the domain will look something like For IPv6, the domain will be closer to

In both cases Zerigo will automatically detect a valid IPv4 or IPv6 reverse domain and enable PTR records.

For IPv4 reverse domains, the hostname will most commonly be a single number, such as 23.

Hostnames for IPv6 reverse domains will tend to be more substantial, such as


Start of Authority, or SOA, records are somewhat like a header for a domain. They provide some general information to other nameservers about how to cache and otherwise process records for the domain. SOA records are automatically managed by the Zerigo platform.


SPF records a special type of TXT record. They hold information about who is allowed to send email from a certain domain. You may put SPF information in an SPF record, a TXT record, or both.

Please note the usage of SPF record is discouraged these days - you should only use a TXT record with SPF information.

RFC 7208 Section 3.1 reads: During the period when SPF was in development, requirements for assigning a new DNS RR type were more stringent than they are today and support for the deployment of new DNS RR types was not deployed in DNS servers and provisioning systems. The end result was that developers of SPF discovered it was easier and more practical to follow the TXT RR type for SPF.


SRV records provide information about where to find a particular service. They are commonly used to identify LDAP and XMPP servers.

The priority field for SRV records works just like MX records: lower numbers are a higher priority.

SRV records also need a weight and port number in addition to the full hostname. All three of these items are combined into the data field, like this: 10 389

The weight is a way to balance the load unevenly between servers. Two SRV records, one with a weight of 10 and the other with 20, will result in one server getting 1/3 the traffic and the other 2/3s.


TXT, or text, records are free-form fields used to deliver an arbitrary block of text. They are most commonly used to deliver SPF and DKIM information, or to perform Google Apps domain authorization.