Setup a Basic Recursive Caching DNS Server and Configure Zones for Domain

Imagine what it would be like if we had to remember the IP addresses of all the websites that we use on a daily basis. Even if we had a prodigious memory, the process to browse to a website would be ridiculously slow and time-consuming.

And what about if we needed to visit multiple websites or use several applications that reside in the same machine or virtual host? That would be one of the worst headaches I can think of – not to mention the possibility that the IP address associated with a website or application can be changed without prior notice.

Just the very thought of it would be enough reason to desist using the Internet or internal networks after a while.

That’s precisely what a world without Domain Name System (also known as DNS) would be. Fortunately, this service solves all of the issues mentioned above – even if the relationship between an IP address and a name changes.

For that reason, in this article, we will learn how to configure and use a simple DNS server, a service that will allow translating domain names into IP addresses and vice versa.

Introducing DNS Name Resolution

For small networks that are not subject to frequent changes, the /etc/hosts file can be used as a rudimentary method of the domain name to IP address resolution.

With a very simple syntax, this file allows us to associate a name (and/or an alias) with an IP address as follows:

[IP address] [name] [alias(es)]

For example,

192.168.0.1 gateway gateway.mydomain.com
192.168.0.2 web web.mydomain.com

Thus, you can reach the web machine either by its name, the web.mydomain.com alias, or its IP address.

For larger networks or those that are subject to frequent changes, using the /etc/hosts file to resolve domain names into IP addresses would not be an acceptable solution. That’s where the need for a dedicated service comes in.

Under the hood, a DNS server queries a large database in the form of a tree, which starts at the root (“.”) zone.

The following image will help us to illustrate:

DNS Name Resolution Diagram
DNS Name Resolution Diagram

In the image above, the root (.) zone contains com, edu, and net domains. Each of these domains are (or can be) managed by different organizations to avoid depending on a big, central one. This allows to properly distribute requests in a hierarchical way.

Let’s see what happens under the hood:

1. When a client makes a query to a DNS server for web1.sales.me.com, the server sends the query to the top (root) DNS server, which points the query to the name server in the .com zone.

This, in turn, sends the query to the next level name server (in the me.com zone), and then to sales.me.com. This process is repeated as many times as needed until the FQDN (Fully Qualified Domain Name, web1.sales.me.com in this example) is returned by the name server of the zone where it belongs.

2. In this example, the name server in sales.me.com. responds to the address web1.sales.me.com and returns the desired domain name-IP association and other information as well (if configured to do so).

All this information is sent to the original DNS server, which then passes it back to the client that requested it in the first place. To avoid repeating the same steps for future identical queries, the results of the query are stored in the DNS server.

These are the reasons why this kind of setup is commonly known as a recursive, caching DNS server.

If you read this far, tweet to the author to show them you care. Tweet a thanks
Gabriel Cánepa
Gabriel Cánepa is a GNU/Linux sysadmin and web developer from Villa Mercedes, San Luis, Argentina. He works for a worldwide leading consumer product company and takes great pleasure in using FOSS tools to increase productivity in all areas of his daily work.

Each tutorial at TecMint is created by a team of experienced Linux system administrators so that it meets our high-quality standards.

Join the TecMint Weekly Newsletter (More Than 156,129 Linux Enthusiasts Have Subscribed)
Was this article helpful? Please add a comment or buy me a coffee to show your appreciation.

5 thoughts on “Setup a Basic Recursive Caching DNS Server and Configure Zones for Domain”

  1. There are 2 typos (well two digits transposed) in the sample reverse DNS zone example given above.

    Here’s the text provided:

    zone "0.168.192.in-addr.arpa" IN {
        type master;
        file "/var/named/0.162.198.in-addr.arpa.zone";
    };
    

    The file directive has the 2 and the 8 transposed. The file name should be “/var/named/0.168.192.in-addr.arpa.zone

    Reply
  2. Hello Mr Canepa,

    First of all I would like to thank you for a very good articles in order to help me to prepare for LFCS. I studied all of them very carefully, but unfortunately I was stuck at the DNS.

    It is about 3th part of this chapter. I don’t know if files /var/named/sales.me.com.zone and /var/named/0.168.192.in-addr.arpa.zone should be appeared automatically or should I append them on my own?

    There are differences between CentOS and Ubuntu because of location of these files – in Ubuntu these files supposed to be in /var/cache/bind…
    I will be thankful for your support.

    Reply
    • Hello again,

      I would like to inform that all questions mentioned above I solved. I just created require zone-files in /etc/bind/.

      Unfortunately I met another issue and I tried to handled with that all the day – without result. When I try to check the answer with host command I received always the same error: “Host ….. not found: 3(NXDOMAIN)“.

      The zone files and option files are done correctly without any errors.

      Could someone help me with that and point me where I should looking for a mistake..? Many thanks in advance.

      Radek.

      Reply

Got something to say? Join the discussion.

Thank you for taking the time to share your thoughts with us. We appreciate your decision to leave a comment and value your contribution to the discussion. It's important to note that we moderate all comments in accordance with our comment policy to ensure a respectful and constructive conversation.

Rest assured that your email address will remain private and will not be published or shared with anyone. We prioritize the privacy and security of our users.