Each piece of data stored within a zone file is called a resource record. There are a large number of different record types that can exist for a domain. The most common record types are as follows:
The DNS 'SOA' record is a mandatory entry for any DNS zone. It is the 'Start of Authority' record; its purpose is to inform DNS resolvers that this server is the authoritative server for the requested domain name.
The structure of an SOA record is as follows:
@ 14400 IN SOA ns1.example.com. admin.example.com. (
2012121902 ; serial number
3600; refresh seconds
600; retry seconds
86400; expire seconds
3600; minimum TTL seconds );
The first entry in the 'SOA' record contains the name of the host where the zone file is located (ns1.example.com above) as well as the administrative email contact for the DNS zone (admin.example.com above – the '@' symbol is replaced with a '.' within DNS zone files).
The 'serial number' value is used as a type of version control on the DNS records. Where multiple nameservers are configured, ensuring that each server's SOA serial number value is the same is a good indication that DNS changes have been replicated on all nameservers.
The 'refresh' value is how long a secondary nameserver will wait before checking whether updates have been made on the primary server. When checking, the secondary server will check the serial number of the zone on the master server, and if different will request a zone transfer to update its local copy.
The 'retry' value is how long a secondary nameserver will wait to retry a zone transfer in the event the initial attempt fails.
The 'expire' value is how long a secondary nameserver will continue to attempt a zone transfer before giving up. If this value is reached before a successful zone transfer is made, the secondary nameserver will expire its local zone file and stop responding to user queries.
The 'minimum TTL' value is an indication of how long a DNS cache may hold a negative value (e.g. an error message) before requesting fresh copies.
'A' records are one of the key record types within the DNS. Their purpose is to define a relationship between a human-friendly name and an IPv4 address. These records are useful for pointing different portions of your domain to different IP addresses (e.g. pointing 'www.example.com' to your web server).
Each DNS 'A' record consists of both a host name and IP address. The format of these records is as follows:
<NODE NAME> IN A <IP ADDRESS>
The 'node name' value above will be the portion of the address that precedes '.example.com' (for example 'www'). The IP address is the location that the resulting hostname ('www.example.com') will point to.
'AAAA' records are similar to DNS 'A' records.The only difference is that 'AAAA' records point to IPv6 addresses instead of IPv4 addresses. Configuration of the record and layout is the same: simply replace 'A' with 'AAAA' and use an IPv6 address.
'NS' records are used to specify what the nameservers for the domain name are. These should ideally match the values set at the domain name registrar.
Each DNS 'NS' record consists of both the domain name and nameserver hostname and is formatted as follows:
example.com. IN NS <HOSTNAME OF NAMESERVER>
The hostname will generally be a value such as 'ns1.yourdomain.com' or 'ns1.yourwebhost.com'. If these values do not match those configured with the domain name registrar, it can lead to problems accessing your website in certain circumstances.
'CNAME' is short for canonical name. These records are used to define an alias for another domain or hostname. These records are particularly useful when you have multiple hostnames that are located on the same IP address.
Each 'CNAME' record needs to point to another valid hostname, either for the same domain or even a completely different domain. Generally 'CNAME' records point to a hostname that is configured in a DNS 'A' record. The format of these records is as follows:
<HOSTNAME> IN CNAME <EXISTING HOSTNAME>
The hostname is the value preceding the '.example.com' as in the 'A' record example and is typically something like 'www.' The existing hostname could be another hostname for the current domain, for example 'blog.example.com.' In this case, when a user attempts to visit 'www.example.com' they will see the content associated with 'blog.example.com.'
If the existing hostname value is set to a hostname on a different domain — for example 'www.domain2.com' — when a user visits 'www.example.com' they will see the same content as a user visiting 'www.example.com.'
'MX' is short for Mail Exchanger. These records are used to identify the server that handles email address for your domain name.
Each 'MX' record contains three pieces of information: the hostname, the priority and the mail server's hostname. The format of an 'MX' record is as follows:
<HOSTNAME> IN MX <PRIORITY> <MAIL SERVER HOSTNAME>
The hostname value is the domain for which the MX record exists. This is generally set to the value of your domain name (e.g. 'example.com.').
The priority value is a numerical value that signifies the priority of this particular MX record — and hence the mail server. The values used for this are only important if you have more than one mail server. The lower the value of the priority field, the higher the priority of the mail server.
The mail server hostname is then the hostname that handles email for this domain. It could be a google.com address if the domain uses Google Apps for email hosting, but the simplest setup is to have the hostname set to 'mail.example.com'. If this is the case, it is important to ensure that a valid DNS 'A' record exists for the 'mail' hostname. If this isn't configured properly, you may experience issues receiving email at your domain.
'TXT' (or text) records serve multiple purposes. They allow for virtually any free text to be stored and can be assigned to specific hostnames. The typical format for a TXT record is as follows:
<HOSTNAME> IN TXT <TEXT DATA>
'TXT' records often store sender policy framework (SPF) data . SPF data is used to inform email servers which actual systems are authorized to send mail on behalf of the given hostname. This is useful in the prevention of spam emails being sent with a forged sender address originating from your domain. (RFC 4408 discourages this practice as 'not optimal', however, because SPF now has its own DNS resource record type (code 99).)
Another common use of the 'TXT' records is for DomainKeys Identified Mail (DKIM) data. These records allow a receiving mail server to authenticate entities that have signed a specific email message. DKIM is similar to SPF in that it can help reduce spam email from containing forged email addresses originating from your domain, but it also contains a large amount of additional functionality.
The 'PTR' record type is used to perform the exact opposite functionality of the DNS 'A' record. Where the 'A' record allows for the translation of a domain name or hostname into an IP address, the 'PTR' record allows for an IP address to be translated into a domain name.
The format of a 'PTR' record is as follows:
<IP REVERSED>.in-addr.arpa PTR <DOMAIN>.
The first field is the IP address in reverse format, with the 'in-addr.arpa' value appended to the end, for example '22.214.171.124.in-addr.arpa'. The domain value would then be the domain name you want the IP address (192.168.0.1 in this example) to resolve to.
Ensuring that both forward lookups (using 'A' records) and reverse lookups (using 'PTR' records) match is important: in some instances, applications will not work correctly if this is not configured correctly. For example, some mail servers will not accept mail from a mail server if the reverse lookup does not match the domain name the email is originating from.