One of the most common questions we get from customers on a daily basis is about their domain’s DNS settings. People are looking to get records added, removed, updated or checked for problems. This article will explain the different type of records and what they’re used for in the world of internet hosting. The first part to understanding DNS is knowing some basic terminology and the most common record types and what they are used for.
Zone File Definition:
On a DNS server you can host multiple domains. Each domain will have it’s own set of records that are not associated with any other domain. These are seperated in what are called zones. A domain can actually be seperated into multiple zones classified by sub-domains. For example, under the flarehosting.com domain we could setup seperate zones like sales.flarehosting.com, admin.flarehosting.com and support.flarehosting.com which would all have independant zone files from each other. Each zone file would contain exactly one SOA record and can specify individual settings such as which other DNS servers are allowed to perform zone transfers or define a unique admin email address for each zone.
TTL Definition:
The TTL (Time to Live) value is what tells the rest of the world how long that record is going to be valid for. This value is measured in seconds. Each record in a zone has it’s own TTL value and can be different from other records. By having a TTL value for a record, other computers and DNS servers will cache the record locally for the length of the TTL value. This is used to speed up requests for DNS records and also allows sites to be functional in the event that the DNS server is offline or unavailable. In the SOA record there is a Minimum TTL setting that describes the lowest TTL value any record within the zone is allowed to have. If a record has a TTL value lower than the Mimimum TTL setting in the SOA record the higher of the two TTL values are used.
Reading DNS records:
There are a large variety of DNS tools available that will display records in different ways. Most full query applications will lay the information out in a similar fashion with nearly the same information. Below are some example record queries using DIG from a command line. The first column is the record name. The second column is the TTL. The fourth column is the record type and the last column is the value of the record.
A Record:
> dig a www.flarehosting.com
www.flarehosting.com. 600 IN A 67.219.33.34
MX Record: The MX record is slightly different with an additional column for the priority or preference listed directly after the record type.
> dig mx flarehosting.com
flarehosting.com. 3600 IN MX 5 mx.uploadmysite.com.
SPF Record:
> dig spf flarehosting.com
flarehosting.com. 3600 IN TXT “v=spf1 ip4:208.78.155.0/24 ip4:208.83.24.0/21 a mx ~all”
SOA Record:
The SOA Record (Start of Authority) is the main record in every DNS zone file. Every zone file will have an SOA record which holds information such the primary name server, email address of the person responsible for the DNS zone, serial number of the zone file, and minimum TTL settings.
The serial number is what tells other computers and DNS servers how new the zone file is or if it’s been updated since the last request made.
NS Record:
The NS records allow you to specify which servers are used to lookup records for that zone. Although your registrar also has name server records specified the NS record entries are specifically helpful if you are setting up a sub-domain as a seperate zone that will be hosted with another DNS server.
A Record:
The A record is the most commonly used DNS record type. This is the record that translates human friendly host names to IP addresses so that computers can communicate with each other.
CNAME Record:
The CNAME record is also known as an alias record. This is used when you want to have one record mimic another record. This is most commonly used when you want to mimic a record from another domain so that you don’t have to constantly update it as an A record every time the other DNS is updated. For example, let’s say you want to setup a sub-domain as a Google App. When you do this you would request that a CNAME record would be created for your sub-domain and have it point to ghs.google.com. This way, any time that Google updates the ghs.google.com record your record is updated as well. If you simply setup your sub-domain record as an A record pointing to the same IP address as ghs.google.com then every time Google updates their records you would need to update yours as well.
CNAME records are typically not needed when mimicking another record within the same domain. Some DNS server software do not allow a CNAME record for the host record but instead require they be added as an A record. While many records can have duplicated entries, you can not have a CNAME record and an A record with the same value. Although you can have an MX record point to a CNAME record, Microsoft does not recommend it as a best practice (http://support.microsoft.com/kb/153001).
MX Record:
MX is short for Mail Exchanger. This record is used to tell the internet what servers email should be delivered to for that zone. If you have multiple email servers for fault tolerance then you would have multiple MX records; one for each server. You can also order your MX records with a weight so that all email would be delivered to the primary server first and backup servers next if the primary server is not available. This weight is classified as the Priority or Preference within the record. These are numbers with the lowest number being the highest priority. Although the difference between the records does not matter, it is often setup with gaps between priority numbers so that future records can be inserted easily. Below are some examples of a few MX records:
flarehosting.com. 3600 IN MX 5 mx.uploadmysite.com.
flarehosting.com. 3600 IN MX 15 mx2.uploadmysite.com.
sales.flarehosting.com. 300 IN MX 100 smtp-filter.sales.flarehosting.com
TXT Record:
TXT records are used to store general information about the domain. You can put any information in the TXT record such as the hosting company, contact person, company profile….etc. The most common use of a TXT record is for an SPF record however this is being replaced by the new SPF record type explained below.
SPF Record:
SPF is short for Sender Policy Framework. These records are used to describe what servers or networks are allowed to send email on behalf of the domain and what to do with email if it’s sent from something other than what is described. More information on SPF records can be found at http://www.openspf.org Below are a couple of examples of valid SPF records looked up using Dig:
flarehosting.com. 3600 IN TXT “v=spf1 ip4:208.78.155.0/24 ip4:208.83.24.0/21 a mx ~all”
microsoft.com. 3600 IN TXT “v=spf1 mx include:_spf-a.microsoft.com include:_spf-b.microsoft.com
include:_spf-c.microsoft.com include:_spf-ssg-a.microsoft.com ip4:131.107.115.212
ip4:131.107.115.215 ip4:131.107.115.214 ip4:205.248.106.64 ip4:205.248.106.30
ip4:205.248.106.32 ~all”
As you can see, there are many parts to an SPF record and they can be quite long and complicated. Using the tools at OpenSPF.org you can build and validate your SPF record.
PTR Record:
PTR records are used for reverse DNS lookups. Similar to how an A record will point to an IP address, an IP address can point back to a hostname. One of the most common uses of a reverse DNS lookup is with a mail server validating whether or not the server it is receiving an email from is legitimate. If an email server receives an email from another server or computer it will take the IP address it connected from and looks up the PTR record for that IP to get a valid hostname. Then the receiving email server will lookup the hostname to see if it gets the same IP address. If these do not match it can be cause for concern and often times a receiving mail server will reject the message depending on it’s rulesets. Below is an example of a PTR record when requested from the server using DIG:
34.33.219.67.in-addr.arpa. 3600 IN PTR www.flarehosting.com.
As you can see, the record name is the IP address backwards followed by .in-addr.arpa. All PTR records will follow this pattern no matter which type of DNS server software you use.
DNS Applications:
nslookup – This is a command line tool that is built into most operating systems including Windows and Linux and Solaris among others.
host – Host is a is an application that’s installed by default into most Linux operating systems. There is a Windows version of this application that can be installed as an add on application. Host has a nicer output but is a bit more limited in what can be gathered compared to nslookup and dig.
dig – Dig is my personal favorite and offers a very extensive set flags to get as much information out of a DNS server as you could want. It’s installed by default in most Linux operating systems and is available as an add on application for Windows.
Websites:
http://www.iptools.com
http://www.domainwhitepages.com
http://www.openspf.org
DNS Servers:
Bind – https://www.isc.org/software/bind – This is one of the most widely used DNS servers in the world. It is primarily used in a Linux/Unix environment but can also be installed on a Windows Server.
Microsoft DNS – http://technet.microsoft.com/en-us/windowsserver/dd448607.aspx – Microsoft DNS is only available on Windows platforms. The benefit to Microsoft DNS is that you can store all the DNS zones in Active Directory and add multiple servers with the DNS role. All of the servers pull their information from Active Directory so there isn’t the typical Primary and Secondary servers like you get in most other DNS server environments.
SimpleDNS – http://www.simpledns.com/ – SimpleDNS is only available on Microsoft platforms and comes with a very easy to use interface. It also has a great API which is useful for creating web interfaces that can talk directly with the DNS server in a secure fashion.
