DNS record basics

In DNS domain records appear in two basic places: regular zones containing hostname-to-address records, and reverse zones containing address-to-hostname records. We'll deal with the first type of data first, since it's the most common and all domain owners have to deal with it. Reverse zones are managed by the people who run the underlying networks, not the domain owners, although coordination is expected.

When e-mail addresses need to be expressed as hostnames, you convert them by replacing the '@' with a '.'. Thus, root@domain.xyz would convert to root.domain.xyz. There's some ambiguity if the username part of an e-mail address is the same as the name of a host in the domain, but it can be resolved by remembering that fields that contain e-mail addresses never contain real hostnames and vice-versa. If the username portion of an e-mail address contains '.' it can be ambiguous how to reverse the conversion, but e-mail addresses in DNS records are for human consumption and we're supposed to be intelligent enough to figure it out considering that most e-mail addresses have only the domain name to the right of the '@' and don't include a hostname there (thus it'd normally be abc.xyz@example.com, not abc@xyz.example.com).

In some of the records you'll see an '@' used in the first field. This is a placeholder referring to the name of the origin domain (the domain the zonefile is for). This is a shorthand allowed because there's a number of common records that don't have a name inside the domain, the name field would be the domain itself, and it's ambiguous to leave the first field blank. Rather than making you write out the fully-qualified form of the origin domain, '@' is used to make it more convenient.

This is by no means an exhaustive discussion. I've only described the most common types of records used for basic domains. Wikipedia has a more extensive list of the kinds of records you can find in DNS. Many of these are special-purpose (for instance, records supporting DNSSEC), or are of historical interest (eg. LOC records indicating the physical location of a host, jokingly referred to as an ICBM address record).

Administrative records

SOA

@ IN SOA primary_nameserver admin_email serial_number refresh retry expire default_ttl

The "start of authority" record, it's the first record in a zone file. It's job is to anchor the zone and provide administrative information. Typically the name field is '@', the origin of the zone, since that's what the SOA record applies to. The primary nameserver field should be correct and point to the most authoritative nameserver for the domain. The admin e-mail field should likewise be correct and point to the person (or e-mail account) responsible for DNS maintenance, not necessarily the owner of the domain. The serial number is used to track changes in the zone, it gets updated every time the zone is changed so that secondary nameservers can tell if their copy of the zone information is out-of-date (they query the SOA from the master, if the serial number is greater than theirs then they need to get a new copy of the zone from the master). It's fairly common to use the format YYYYMMDDnn for the serial number, recording the date of the last change to the zone plus a 2-digit edit number during that day (incremented when the file's edited, reset to 01 if the date part changes). The assumption here is that manually-edited zonefiles don't normally change several times a day, which is usually a good assumption. When the zonefile is automatically generated, a straight numeric serial number is more common since that's easier for software to keep track of. You'll see this when domain DNS information is maintained in a database and/or dynamically generated and the zonefiles are automatically created when the underlying data changes.

NS

A

AAAA

@ IN NS fqdn

fqdn IN A ip_address

fqdn IN AAAA ipv6_address

The glue records that tie a domain into the overall DNS system. In the parent zone, NS and matching A records allow the parent zone nameservers to respond to queries by directing the querent to the domain's actual nameservers. These are repeated in the zonefile itself to allow the parent zone to automatically update the list of authoritative nameservers for the zone. The NS records in the zonefile are authoritative, the ones supplied to the parent zone initially are used to seed the process and are replaced early on. What the parent does is take the initial NS records and query those servers for all NS records for the zone. It stores the answer and uses that information to direct queries to the authoritative nameservers.

The term "fqdn" is used here to indicate a fully-qualified or absolute domain name ending in a period and spelling out the full DNS name with no abbreviation. The A/AAAA records for nameservers in the domain itself will of course be present in the zonefile naturally, so nothing special's needed for NS records that refer to in-zone nameservers. But for out-of-zone (their DNS names are in another domain) nameservers the DNS system traditionally has needed a bit of a bootstrap. So some additional A/AAAA "glue" records are included to give IP addresses for those nameservers. Since these names are outside the zone you don't want the zone origin domain appended to their names, you want them used as-is. So, you spell out their full name and end it with a period to tell Bind these are absolute names, not ones relative to the zone's origin. This applies only to these "glue" records, not to regular A/AAAA records for hosts in the domain.

Traditionally only A records appeared in the glue information, but as IPv6 is deployed you're going to see AAAA records appearing more and more often. The only difference is in the record type and whether an IPv4 or IPv6 address appears in the record.

RP

TXT

@ IN RP email_address person_name

person IN TXT "contact information"

The responsible-party information for the domain. The e-mail address of the person responsible for the domain itself (or at least DNS administration), followed by a pseudo-hostname referring to a text record containing identifying information and contact information for the responsible party. That pseudo-hostname needs to be an FQDN in the RP record, however the corresponding TXT record's name can be a relative or unqualified name (just the leading portion of the FQDN with the domain part supplied from the origin). These records aren't used for DNS operation, they're intended to hold contact information within DNS itself so people who need to contact the DNS administrator for a zone can get contact information strictly by querying DNS without needing to rely on anything else like a Web site or WHOIS.

Hostname records

A

AAAA

name IN A ip_address

name IN AAAA ipv6_address

A and AAAA records are the most basic ones in DNS, providing the mapping from hostnames back to IP addresses. The name portion is usually relative, just the host name itself with the domain appended automatically based on the origin domain of the zonefile. Thus the A record for host www.example.com would just be www, with the origin of the zonefile set to example.com. If you need to give an address for a hostname outside the domain, use a fully-qualified name ending with a '.' to prevent appending of the origin domain.

It's allowed to have multiple A or AAAA records for a single name. In that case the DNS server software will return all of them, cycling them around so no single address is always returned first. This can be used as a poor-man's form of load balancing. It's not perfect though: each client's expected to cache and reuse responses to queries, and while the nameserver will rotate names the client won't and will continue to use whatever order it got originally. Client behavior's also undefined if the first returned address doesn't respond. Some client software will try the additional addresses in turn until it finds one that responds, some will simply use the first address and fail if it doesn't respond.

CNAME

name IN CNAME real_name

CNAME records are just nicknames or aliases for other names. The real name portion can be an unqualified name in the same domain, or a fully-qualified name in a different domain. CNAME records don't provide addresses, when a CNAME is returned as the answer for a query the querent is expected to submit another query for the returned name, and continue doing this until either a real A or AAAA record is found or a limit on the number of iterations allowed is reached. Note that you can't tell from the CNAME record whether it'll eventually resolve to an IPv4 (A record) or IPv6 (AAAA record) address.

MX

SPF

TXT

@ IN MX priority mailserver

@ IN SPF "SPF rule text"

@ IN TXT "SPF rule text"

MX records, along with SPF and TXT, are mostly used for mail handling. The priority field indicates the order of preference for mailservers. Lower numbers are preferred over higher ones, so give the smallest numbers to the mailservers capable of handling the most load and use larger numbers for backups. The mailserver must be a name associated with an A or AAAA record, CNAMEs aren't allowed here. Unqualified names are allowed if the mailserver is in the zone, mailservers outside the zone must be named using a fully-qualified name. Note that for mail to work an MX record needs to be given for the domain (hence why normally these records are for @, since mail's handled on a domain basis not by individual hosts). Technically if there isn't an MX record you aren't supposed to be able to send mail to that destination, meaning that mail directly to individual hosts is not supposed to work (unless each host has an MX record naming it's own A or AAAA record). A lot of client software has a hack for broken MX records, though, where if it can't find an MX record it'll query for A/AAAA records for the domain and try to use those. Don't depend on this, get your MX records right and it'll make your life a lot easier.

SPF stands for "Sender Policy Framework", and describes the rules for what hosts on the Internet are allowed to send mail from a particular domain. It's value is complex, I'd suggest starting with the Wikipedia entry for an overview and then going to the SPF main site or this more detailed explanation. SPF is important for dealing with spam, it allows recipients to distinguish mail coming from the official mail systems for your domain vs. stuff sent by third parties claiming to be from your domain. If all your mail is routed through a central server, SPF is easy since you simply declare that that server's the official sender for your domain. If you need to send mail from arbitrary systems for addresses in your domain (eg. you need to use your ISP's e-mail servers to send mail with your domain in the From field), it gets more complex.

TXT records are free-form records containing arbitrary text. We've seen them used elsewhere in the RP information for a domain. In this context they're used to hold a copy of the SPF record for systems that don't support the SPF record type. It's good practice to include this, just take the SPF record and change the record type from SPF to TXT and leave everything else the same.

PTR

You'll occasionally see PTR records included in regular zone files, mostly when the admins are being picky and technically correct and including network number and subnet mask information in DNS rather than leaving it to local files on machines. This isn't needed for normal everyday use, and getting it right is beyond the scope of this discussion. If you want to do it right you need to know a fair bit about networking and should consult more technical references for the details.

Reverse zones

Reverse zones are managed by the people who maintain the physical networks, not by the people who own domains, because they map from IP address space (which is a function of the network) back to names. Traditionally the network and the domain were owned by the same entity, a company or university or the like, so the two were maintained in parallel. These days the network's more likely to be owned by a hosting company and the domain owner won't have much to do with managing the reverse zone. With IPv6 this is changing back to the traditional model, as the end user (domain owner) is responsible for an entire /64 network and thus controls their own IPv6 address space again.

Reverse zones live in a special domain named in-addr.arpa, and for IPv4 addresses you create a hostname corresponding to an address by taking the octets of the address and reversing their order. Thus, 192.168.99.12 would appear as 12.99.168.192.in-addr.arpa.

PTR

octet IN PTR fqdn

The name field of a PTR record is usually the trailing octet(s) of the IP address, in reverse order. The value is the fully-qualified name of the host at that address. It's common for this to not be the name normally used for the host, eg. when a Web site's hosted in a data center the hostname most people use may be www.example.com resolving to IP address 192.168.99.12, but the PTR record for 12.99.168.192.in-addr.arpa might point to hostname s7r12-a.sjdc.hostingcompany.com (which also resolves to 192.168.99.12). This is perfectly legal. The rule is that the name an address resolves to has to resolve back to that same address, not that there's a 1-1 mapping between names and addresses. As we described under the discussion on A and AAAA records, a single name can resolve to multiple IP addresses. Multiple different A and AAAA records in the same or different domains can also resolve to the same IP address, so a single IP address can have multiple different names. If you start with an address, resolve to a name and then resolve that name back to an address, the only thing you can assume is that if everything's kosher then one of the addresses you get will be the one you started from. Nothing else is guaranteed.

IPv6 addresses are much longer, consisting of 32 numbers 0-15 corresponding to the 4-bit nibbles making up the 128-bit IPv6 address, again in reverse order. PTR records for IPv6 live in the special ip6.arpa domain.