This page documents the most common Resource Record (RR) types, including examples of how to use them in your zone. For an overview of how a basic zone skeleton might look like, see What makes up a zone. For more information about the various records, such as their binary representation in DNS messages, see References below.

Resource Records (RRs) are the fundamental building blocks of the Domain Name System: all information contained in it is stored in RRs. There are various types of RRs to do this. Each RR is said to be ‘attached’ to a domain name, which is what gives the record meaning. For example, an A record is used to specify an address of a domain name. An A record attached to the domain name posadis.org. thus gives the address of that domain name.

A resource record is actually a set of five things:

• NAME - The domain name the record is ‘attached to’
• TTL - The amount of time a Caching DNS server may store the record, in seconds. In text representation, the usual Numerical value shortcuts can be used.
• CLASS - Mainly of historic interest; this is the context the RR is defined in. This is currently always IN, or the Internet.
• RRTYPE - The type of data the record contains. See below for an overview
• RRDATA - The type-dependent data

The usual text representation of a record is just the five data fields, separated by a number of spaces, i.e.:

For example, an A record simply has the IP address of the server as its RR data, so a representation of the A record of posadis.org., which can be cached for one day, can be:

posadis.org.     1d       IN   A      

Because IN is the only class value used nowadays, it is often omitted. If other fields are clear from the context, they are sometimes omitted too, for example in Master files where the name and TTL fields can sometimes be omitted.

Note the trailing dot in posadis.org. in the example above? In many contexts, such as in zone master files or in the Posadis Zone Editor, domain names are relative to the zone root domain, which means they will have the root domain of the zone appended (and the @ symbol denotes the root domain name of the zone). For example, if you’re editing the acdam.net. zone, the following domain name

www.acdam.net

does not mean www.acdam.net., it means www.acdam.net.acdam.net.! This is a very important point that often causes confusion. If you want to use absolute domain names, you can, just end the domain name with a dot to indicate it’s absolute. Or, you could just use the relative domain name:

www.acdam.net.
www

The same is also true for domain names in RR data.

Now follows a list of common types of resource records and the text representation of their RR data fields.

IP address of a host, in the usual dotted-quad format. Any domain name can have multiple IP numbers attached to it. In that case, each IP number should be contacted about equally often.

Examples:

127.0.0.1
2

IPv6 address of a host, in the usual colon-separated format. IPv6 is the new protocol that will eventually replace IPv4. There is another way of specifying IPv6 addresses as well, by means of the A6 record type, but it is currently marked as experimental, and Posadis doesn’t support it anyway.

Examples:

::dead:beef
1aef:23f3::1:0

Defines the domain name it is attachted to to be an alias of another domain name. The RR data just contains the target domain name. For example, a CNAME record with data

server.acdam.net.

connected to www.acdam.net. would make www.acdam.net. an alias to server.acdam.net., meaning all queries for it will return the same data as for server.acdam.net.1). For more information, see What makes up a zone.

For maintenance purposes, with the HINFO record type, you can add information on the hardware and software of a computer attached to a domain name. It consists of two free text fields, the first one describing the hardware, and the second one describing the software. If you need spaces in the text fields, use " quotes around them.

Examples:

"AMD Athlon XP" "Debian GNU/Linux 3.0"
"IBM ProServer i500" "Windows XP"

This record is used to store the physical location of a host; this information can be used for visual traceroutes and so on. More information on LOC records can be found here. LOC records contain the following information:

• Longitude in degrees, optionally followed by minutes and seconds, and N or S to denote the northern and southern hemispheres, respectively.
• Latitude in degrees, optionally followed by minutes and seconds, and W or E to denote the western and eastern hemisphere, respectively.
• Altitude in meters, from the sea level2).
• Optionally, the size of the object in meters. Defaults to 1m.
• Optionally, the horizontal precision of the location. Defaults to 10000m.
• Optionally, the vertical precision of the location. Defaults to 10m.

For details, see RFC 1876. These examples are taken from there:

42 21 54 N 71 06 18 W -24m 30m
42 21 43.952 N 71 5 6.344 W -24m 1m 200m
52 14 05 N 00 08 50 E 10m
32 7 19 S 116 2 25 E 10m
42 21 28.764 N 71 00 51.617 W -44m 2000m

This defines the mail server for the domain. If you send an e-mail to , what actually happens is that the MX record(s) for acdam.net. are looked up, and the SMTP servers indicated in the MX records will be used to deliver the e-mail to.

This record type consists of two fields; first is the preference value: if there are multiple MX records for a domain, records with the lowest priority value will be tried first. The second field is the domain name of the SMTP server.

Examples:

5  mail1
5  mail2
10 fallback.external.com.

Given these two records in the acdam.net. zone, a mail server will first try mail1.acdam.net. and mail2.acdam.net. (not nessecarily in that order), and only if both fail it will try fallback.external.com..

For more information, see Using DNS for e-mail.

NS records attached to the top of a zone list the name servers that are authoritative for the zone. In a zone file, you’d usually want to have NS records for the zone itself, and for any subzones that are delegated to other DNS servers. The NS record just has the domain name of a nameserver as its data.

Examples:

ns1
ns.secondary.com.

PTR records are used in the in-addr.arpa. and ip6.int namespaces for reverse-mapping IP numbers to domain names. For details, see Reverse mapping. The PTR record just contains the domain name for the IP number. It is unusual for an IP to have more than one PTR record attached; the PTR record should always point to a canonical name (that is, the target domain name should not be an alias to another domain name).

Examples:

www.acdam.net.

RP records can be used to record information on who is responsible for a domain name. This record type is only used by specific applications. It consists of an e-mail address (as with the SOA RNAME field, this is in domain name format), and a domain name which has additional information (in the form of TXT records) about the responsible person. Either field can be . to denote tha that information is not available.

Examples

 john-doe-info.acdam.net.
 .

The SOA record, which is always the first record in a zone master file, contains general information about the zone. It is always attached to the zone root (i.e., @), and it consists of seven data fields:

• MNAME - Domain name of the primary DNS server for the zone
• RNAME - E-mail address of zone maintainer. Usually given in domain name format, i.e. admin.mydomain.net. for . Posadis also supports giving e-mail addresses rather than domain names.
• SERIAL - Serial number of the zone. Secondary DNS servers use this to check whether the zone has changed since their last update, so it should always be increased after modifying the zone. Most zone editing software does this automatically.
• REFRESH - Update interval for secondary DNS servers
• RETRY - Retry interval for secondary DNS servers
• EXPIRE - Expire value for secondary DNS servers
• NTTL - TTL for non-existence of domains

For more information on the secondary DNS server fields, see Authoritative DNS. An example SOA record with reasonable values could be (the following two are equivalent):

ns1   1d 2h 1000h 2d
ns1 admin.mydomain.net.  1d 2h 1000h 2d

The SRV record offers a way to list services for a domain name. Its uses are discussed in the Using DNS for naming hosts article.

SRV records are attached to special types of domain names, of the form

_._.

For example, a SRV-aware client wanting to connect to the web server, which is the HTTP service over the TCP protocol, for the acdam.net. domain, would do a lookup for SRV records for the following domain name (a pretty complete list of services is here):

_http._tcp.acdam.net.

Now, this domain name would have SRV records attached to it, each SRV record pointing to a server providing HTTP service for the domain. The SRV record itself consists of four fields:

• Priority - As in MX records, SRV records with lower priority value are tried first
• Weight - Does load balancing: SRV records of same priority have a chance proportional to their weights of being chosen. For example, if there are two records, one with weight 40 and one with weight 10, the one with weight 4 will be used four times as much.
• Port - Port to connect to
• Target - Domain name for the host that provides the service

So, for example, given the following records in a zone:

_http._tcp.acdam.net. 2h  SRV  10 70  80   athlon.acdam.net.
_http._tcp.acdam.net. 2h  SRV  10 30  80   newserver.acdam.net.
_http._tcp.acdam.net. 2h  SRV  80 100 8080 backup-web.acdam.net.
athlon.acdam.net.     2h  A    
newserver.acdam.net.  2h  A    
backup-web.acdam.net. 2h  A    

In this case, 70% of all HTTP queries of SRV-aware clients would go to port 80 of , and 30% of all queries would go to port 80 of . Only if both web servers are offline, port 8080 on the backup web server, , would be tried.

You can use TXT records to add free-form text to DNS; there are applications, such as DNS-based spam filters, that use it, and you can use it yourself to add any kind of information you want to a domain name, for example, a location, a telephone number, or anything else. Use your imagination.

The field consists of a number of text strings; if a text string contains spaces, it should have quotes around it. Examples:

"Upstairs bedroom PC"
"John F. Doe" "Internal phone: 402"

WKS records provide information about the services provided by a server. The record has the following format:

  ...

Here, is the IPv4 address of the server (since different IP numbers for one domain name could offer different services even if that doesn’t make much sense), is a protocol such as tcp or udp, and is a list of services, such as http or ftp, and port numbers.

The WKS record is not used much anymore nowadays (there is no IPv6 equivalent of WKS records either). SRV records today provide a better way of dealing with services. Still, an example record:

192.168.1.1 tcp dns http ftp 8080

• RFC 1035 is the official standard describing a number of standard RR types, including their binary format
• Chapter 8 from DNS for Rocket Scientists has a pretty complete overview of RR types
• DNS.net has a long list of RR types, including references to their definitions