Introduction

This tutorial attempts to explain some of the inner-workings of DNS specifically in regards to web hosting. If you are thinking of getting in to web hosting, or have been hosting web sites for a while, you will likely benefit from this DNS tutorial. There are entire books written about DNS so I will not attempt to fully explain, in exhaustive detail, the complex system that makes up DNS. It is not the purpose of this tutorial to serve as a complete reference for DNS, but rather it is meant to act as a guide in helping you understand what parts of DNS to focus on for web hosting and maintaining a fully functioning web site.
Before we can begin let us first familiarize ourselves with some common terminology associated with DNS. First off, DNS is an acronym, which is commonly known as Domain Name System or Domain Name Service. DNS relies on some protocols that have been refined over time – and some that have refined DNS – as the Internet has grown and expanded to what it is today. Such protocols as HTTP, FTP, TCP, IP, and UDP should be basic general knowledge for those of us with a solid understanding of the Domain Name System. These protocols fall under the Internet Protocol Suite or what’s more commonly known as TCP/IP. What we need to know about this suite, for the purpose of this tutorial, focuses mostly on those aforementioned protocols.

Starting With The Domain Name

If you want to host a web site you will need a domain name. You can register a domain name with any of the registrars available online, through your ISP, or through a web hosting company. The process begins by selecting a Top Level Domain or TLD. This is a domain like com, net, or org, for example. The TLD is at the root of the domain hierarchy. To a human we read a domain from left to right. For example, www.domain.com is read starting with the www and ending with com. To a computer or DNS server, the domain name is read from right to left starting with the TLD and ending with the lowest point in the domain name space relative to the tree of the domain hierarchy. So www.domain.com translates to com.domain.www in a DNS because the DNS needs to start at the top of the domain name space and work its way down in order to resolve. You may ask, why use this nonsensical routine that contradicts the way you read and understand domain names? To us it seems contradicting based on how we may have become accustomed to reading a domain name, but to computers it makes sense based on how the DNS is designed. What you need to remember is that DNS is a hierarchical system and finds authoritative name servers by searching at the top of the hierarchy and working its way down until it finds the parent name servers. DNS is also delegated into zones and subzones to make it more efficient.
A Fully Qualified Domain Name or FQDN is distinguished by its uniqueness in the domain name space and is some times referred to as an absolute domain name. For example, if we have a server on a network with the host-name server1 then server1 will be relative to its root domain. If that root domain, including the TLD, happens to be domain.com then server1.domain.com is an FQDN as there can only be one server1.domain.com even though there may be many server1’s in other parts of the domain name space (e.g. server1.mydomain.com, server1.yourdomain.com, server1.ourdomain.com, etc). The host is thus unique in the domain name space and this is an important part of how the DNS was designed to remain hierarchical in a host-to-client fashion. The machine can now be uniquely identified on the Internet by server1.domain.com regardless of one’s physical location.

Name Servers

ISPs setup DNS servers and DNS resolvers that communicate with each other to locate information about domain names. The Name Servers tell us where to look for information about a particular domain name. Registrars retain the name server information that points to a particular domain name. This is called an NS record. It shows up on dig (a linux networking tool) as domain.com. 86400 IN NS ns1.domain.com, for example. You can set multiple name servers, but the general practice is that you have at least two name servers for each domain. This way if one fails then hopefully the secondary name server will still resolve. You can use the same name servers for multiple domains. Name servers can be both public and private. When the name servers point to the domain itself then the IP or Internet Protocol address must also be set in the A records of that domain name.
If you are using a shared hosting account you will most likely use your web hosts name servers set on that server. Some web hosts will allow you to use private name servers. In this matter you will set ns1.yourdomain.com and ns2.yourdomain.com as the name servers for you domain with your domain registrar and specify the IPs that your web host provides you for those name servers.
If you are running a dedicated server you will need to have your own DNS software installed. The standard is usually BIND. BIND stands for Berkley Internet Name Daemon and is sometimes referred to as named. Low-end VPS machines or some home networks may use smaller foot-print DNS server software such as Dnsmasq. While BIND has had some security vulnerabilities BIND9 is still certainly popular in use. Your focus should be on DNS cacheing and recursive DNS queries rather than authoritative DNS, unless you really know what you’re doing.

A Records, CNAMEs, PTR, and MX Records

People will commonly use www.domain.com in their browsers rather than domain.com when visiting a website. If you are hosting your web sites thinking these two are one and the same you are mistaken. They are in fact viewed as two different web sites. Common search engine bots like Google’s Google Bot will crawl these URLs as two different web sites. To avoid any confusion there is a good way to work around this both on the DNS side and through your web server software (for example, configuring your .htacess file to treat this with a 301 perm redirect).
First, you should consider that CNAME records (Canonical Name) will create a second lookup when retrieving the records. They can be avoided by simply using the alias as an A record. The A record can then look something like this:

If we add www.example.com. to A 192.0.32.10 then the alias will still point to the same IP without creating an CNAME lookup. This is because the server will first find www.example.com IN CNAME example.com and then proceed to lookup example.com to find it IN A 192.0.32.10

If you’re not familiar with the numbers showing up in the dig these are called TTL or Time To Live. They represent how often the records should be updated. The settings can vary based on record type. Again because DNS is a hierarchical distributed system the authoritative name servers will pass the records on to the caching name servers until the TTL has expired. This can cause different load issues depending on how low or high the TTL is set. It is generally not a good idea to lower your TTL too much unless you are constantly updating your DNS records, which is likely never the case.
Your MX records (Mail Exchange) are prioritized. So MX 0 should always be the first point of mail delivery. The lower the number set in the MX record the higher priority it gets.
Its also important to consider rDNS or Reverse DNS for your domain especially if you plan on sending mail from that domain. Some mail servers will attempt to verify fcrDNS, or Forward Confirmed Reverse DNS, from ips they receive mail from in order to prevent domain name spoofing (this is where a malicious server attempts to use some one else’s domain in their email header). Reverse DNS is basically the opposite of what we discussed earlier. Instead of the resolver using the domain name to find an IP address it is using an IP address to find a domain name. This can be done through a PTR record or Pointer Record. The IPv4 uses the in-addr.arpa domain and IPv6 uses the ip6.arpa domain. The pointer record helps us resolve the reverse DNS lookup in these domains. Forward Confirmed Reverse DNS is a full loop. The mail server will usually take the IP that the mail was received from and will attempt to resolve it to a domain using the reverse DNS lookup. That domain is then resolved back to an IP address and if the IPs match then the the fcrDNS test is a pass (i.e. we can be pretty sure that this IP is the one that correctly delivered the mail). Failing the fcrDNS test does not necessarily prevent your mail from being delivered, but most large email servers – especially ones that handle millions of emails per day like Yahoo, MSN, or Gmail – will delay or possibly reject the mail delivery. It might also get filtered out as spam so make sure you have correctly configured your rDNS. This process will require a dedicated IP address to become a fully qualified loop.

There are many other areas to be looked at in setting up and configuring DNS so I will try to update this tutorial where possible. Feel free to let me know if you have any questions or suggestions for this tutorial or to correct/append anything I may have overlooked.