scratching the surface of DNS

DNS stands for Domain Name Server (or System). It provides a "directory" like service to map a domain name to a IP host. The setup and configuration of DNS is critical since it can make a website "invisible" on the internet if not done correctly. Understand the basic stuff can make this process a lot easier.

First, some terminologies and tools that can check for DNS setting

DNS uses has different record types to define a domain. The most used one are as follows:

A - stores the host ip address CNAME - alias record, for example, is the alias for

MX - mail exchange record which tells mail server how to route emails.

CNAME – Canoical name: Used to assign aliases to existing A records, for example, a can have other alias such as,…etc.

Once the basic meanings are clear, you shouldn't have too much trouble to read the report from , where you can spot the DNS problems with your server and make changes.

If you have access to a *nix system, the "dig" command can be very helpful too:

dig tells me the A record for the domain.

dig mx tells me the MX record.

Notice we lose the "www" part because we really need to check the domain name without it. People use email address like email[at], instead of email[at]

dig is a powerful command and you can certainly dig out a lot more information than above. A look at dig man page should make a nice guide on this.


Next, is an example of using BIND to run a DNS service.

BIND – Berkeley Internet Name Domain

BIND is an implementation of DNS protocols. It includes a set of components that are necessary to run and maintain a DNS server. The BIND package is installed on the vast majority of the DNS server machines on the internet.


Named it part of the BIND package and will run as a Daemon process to handle the DNS requests.


This file serves as a name server configuration file. It provides the settings for named to run. Most of the settings do not need to be changed. But to add a domain name to a name server, a "zone" setting has to be added into this file, like the one below:

zone "" { type master; file "/var/named/"; };

This basically tells named that it should handle the request for domain name "" and the zone file for this domain is /var/named/

A "zone" is not necessarily mapped to a domain name, it can also be mapped to a sub-domain name like "".

zone file

A zone file, for example "/var/named/" in the above example, tells the DNS server HOW to keep this zone record. For example, how often should the server updates other DNS servers about the whereabout (IP) of this domain. Here is what is looks like:

zone file example

To understand this, we need some explanation:

  1. Throughout the file, there are numbers like 14400 and 86400, they are the Time To Live (TTL) value. It defines the length of time, in seconds, a particular zone info is valid. As you can see in the beginning of the file, "$TTL 14400" sets the default value. And the individual records have their own and can overwrite.
  2. SOA – Start Of Authority. This specifies the primary name server for this domain name and a set of values that are related to the name server. I am going lazy here, if you need to understand what they are for you can find it from this RedHat documentation.
  3. NS records. Again they define the primary and secondary name servers for this domain. 
  4. A record, like explained in the previous section, shows the IP that this domain is pointing to.
  5. MX record points to the same sever since I have the mail server running on the same server. Multiple MX records indicate the multiple mail servers for the domain. And the number 0 shows the priority of the server.
  6. My CNAME records include www, mail and ftp. So if a user tries to access, or, the name sever knows where to point them to.

Once you have one working zone file in place, it can be used as a template for the others. The zone file has some special format, such as the "." following each domain TLD. They have to be there or it won't work.

With a host management tool such as Cpanel, all these can pretty much configured through a friendly UI without getting down to the dirty work of file editing. However, knowing these simple concepts can help you better understand the process and know where to look into when needed.

This entry was posted in server setup. Bookmark the permalink.