The smallest unit of queriable data in the DNS. Each ResourceRecord has a type which gives particular meaning to its payload. These types include:


Short for "address". An IPv4 address. Specified in RFC:1035. Example:  A

Like A, but stores an IPv6 address; to be obsoleted by A6. Specified in RFC:1886. Example:  AAAA  2002:c000:0200::1

Supposed to obsolete AAAA for IPv6 addresses. Many people continue using AAAA due to the complexity of A6, see AAAAvsA6. Specified in RFC:2874. Example:

N         A6  64  ::1234:5678:9ABC:DEF0 SN-1.IP6
SN-1.IP6  A6  48  0:0:0:1:: IP6
IP6       A6  48  0::0 CUST-X.IP6.A.NET.
IP6       A6  48  0::0 CUST-X.IP6.B.NET.

Short for Canonical Name, an alias for a hostname. Often used for well known services so that points to Specified in RFC:1035. Example:   CNAME       A  CNAME   A

Some record types in DNS are not allowed to be CNAMEs. Similar to DNAME. See the NamedNotes page for more details.


Basically a CNAME for an entire domain. Specified in RFC:2672. Example: IN DNAME

With this in place resolves to

Support for this feature is spotty. DanBernstein refuses to implement it and it doesn't seem to be mentioned at all in MicrosoftWindows (as of 2004-07-14). Only BIND seems to support it, but since it will also serve you a CNAME, most resolvers should deal with it properly:      86400  IN  DNAME      0  IN  CNAME       80464  IN  CNAME     80464  IN  A

MicrosoftWindows still seems to get confused however.


GPS location of the machine or site. Specified in RFC:1876. Example: LOC 37 48 30.000 S 175 17 36.000 E 66.00m 3000m 30m 10m

This means 37 deg 48' 30" South (latitude), 175 deg 17' 36" East (longitude), and 66 metres about sea level. The last two numbers appear to mean that the whole site is within 3000 metres of the given point. The point is accurate to about 30 metres, although this interpretation may be wrong. (It will be in the appropriate RFC if anyone can be bothered looking it up.)

xtraceroute(1) will use these records if it can find them. Unfortunately not many sites use them.


MailExchanger. Identifies the SMTP MailServer(s) responsible for the domain. When no MX record exists and an A record does, the A record is chosen to take mail. Specified in RFC:1035. Example:  IN MX  10

The "10" is the priority. Delivery will be attempted to MailServers in order of ascending priority value.

Note: the data for an MX record is a host name, NOT an IP address. The following will NOT work:  IN MX  10

Also, the host name ( in the example) MUST have an A record, NOT a CNAME record.

In the initial part of a ZoneFile, indicates the NameServers which are authoritative for this domain. Elsewhere, indicates that a subdomain is being delegated to another set of NameServers. Specified in RFC:1035.

A pointer. Used for a ReverseLookup. Specified in RFC:1035. Example:

192  PTR  hostname.domain.

Note: don't forget the trailing fullstop!


Start of Authority. Defines information about a domain (called a zone, defined in a ZoneFile), such as a serial number defining the 'version' of the zone, and various timeout and caching values that should be used when records from a given zone are retrieved. The format name <ttl> class rr name-server email-address (serial refresh retry expire negttl). Specified in RFC:1035. Example:

$TTL 604800
$ORIGIN ethernal.tla.
@  IN  SOA  ns1.ethernal.tla. root.ethernal.tla. (
       2004111901  ; Serial
       604800      ; Refresh (7 days)
       86400       ; Retry   (24 hours)
       2419200     ; Expire  (28 days)
       604800 )    ; Neg TTL (7 days)

The name is given as "@", since that is the shorthand for the value of $ORIGIN. TTL is missing from this example, as it takes the zone default defined above as $TTL. The name-server field is basically the FQDN of the PrimaryNameServer for the domain (don't forget the trailing fullstop!). The email-address field is the address of the person responsible for the domain -- the first dot should be read as an @, so above should be read as root@ethernal.tla. The values in parenthesis are described below:

Serial number:
Generally given in YYYYMMDDXX format, giving 100 possible revisions of any given zone in a day (Usually more than enough). Always remember to increment this when editing the ZoneFile, since a change to the serial number is what triggers ZoneTransfers by SecondaryNameServers.
Defines the interval in seconds between checks by a SecondaryNameServer as to whether the serial number has changed. When a change is detected, this means it needs to refresh its copy of the zone by requesting a ZoneTransfer from the PrimaryNameServer.
Defines the number of seconds for a SecondaryNameServer to wait before retrying a zone refresh, after a failure.
Defines the number of seconds for a SecondaryNameServer to keep zone records, and answer authoritatively with them if it can't contact the PrimaryNameServer. (so, if the above refresh fails, and it's been retrying for this long).
Neg TTL:
Defines the number of seconds that a client should remember that a negative response was received from this server. So, if a remote server asks us what the address for foo.ethernal.tla is but it doesn't exist, it will cache the negative answer we gave it for this many seconds, even if we add that name to the zone a couple of seconds later.


Up to 255 bytes of arbitrary binary data. Specified in RFC:1035.

A more comprehensive list of ResourceRecords is at: