Configure DNS server step by step part 1

Cashing only DNS to start

First deployment: How do we test if everything works correctly?

First, I will create a VM with the minimum installation of Rocky Linux 9. Then I will deploy bind and bind-utils on what will become my DNS server.

# dnf install -y bind bind-utils

How to configure your network settings. The best way is to use nmtui to configure the network stack. Because I have a lot going on, I am doing a lot on the DHCP server on OPNsense. This way I can keep track of the IP addresses assigned to the different VMs (or systems) I use.

When the installation is done, there will be named.conf file in the /etc directory.

Let's have a look at this file.

//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//

options {
        listen-on port 53 { 127.0.0.1; };
        listen-on-v6 port 53 { ::1; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        secroots-file   "/var/named/data/named.secroots";
        recursing-file  "/var/named/data/named.recursing";
        allow-query     { localhost; };

        /*
         - If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.
         - If you are building a RECURSIVE (caching) DNS server, you need to enable
           recursion.
         - If your recursive DNS server has a public IP address, you MUST enable access
           control to limit queries to your legitimate users. Failing to do so will
           cause your server to become part of large scale DNS amplification
           attacks. Implementing BCP38 within your network would greatly
           reduce such attack surface
        */
        recursion yes;

        dnssec-validation yes;

        managed-keys-directory "/var/named/dynamic";
        geoip-directory "/usr/share/GeoIP";

        pid-file "/run/named/named.pid";
        session-keyfile "/run/named/session.key";

        /* https://fedoraproject.org/wiki/Changes/CryptoPolicy */
        include "/etc/crypto-policies/back-ends/bind.config";
};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "." IN {
        type hint;
        file "named.ca";
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

We will walk through the file as we advance in configuring the DNS server.

Something important is the command to check the named.conf file. (see the video)
If it generates a message, correct the reason because otherwise your DNS server will not work or heaven not start.

# named-checkconf

Let's start the service and see what it is doing out of the box.

# systemctl start named

Check which name server is still doing the resolves for the DNS server. Using the dig command. And by checking the /etc/resolv.conf file. Force the dig command to use the DNS server we started up.

# dig @localhost www.google.com

The first time this is taking a long time and second try it was much faster. This is due to caching. Let's have a deeper dive in this.

How can we see what is in the cache?

First we have to dump the cache to a file, and then we can inspect if the resolve can be done by the cache. The dump-file can be found in the named.conf file.

# rndc dumpdb -cache
# grep example.com /var/named/data/cache_dump.db

You can also flush the cache. And with the same grep command, we can verify if the cache was flushed. After dumping the cleared cache naturally.

# rndc flush
# rndc dumpdb -cache
# grep example.com /var/named/data/cache_dump.db

Configure the DNS server to use itself to do the resolving. By using nmtui. Change DNS by entering 127.0.0.1 and select not to use the DHCP proposed named servers. (Verify with dig, who is resolving).

Let's configure the DNS server that clients on our network can also use this DNS server to their resolving.

Let's see what we have to change in the named.conf file to make this happen.
First, we have to add the IP address to the option listen-on port. Add the subnet to the allow-query.

listen-on port 53 { 127.0.0.1; 10.67.10.122; }
allow-query {localhost; 10.67.10.0/24; }

Now that this is done, we have some checking to do. First the name.conf file before restarting the named service.

# named-checkconf
# systemctl restart named

Check if the IP address is listening to port 53. "ss" is replacing the netstat command.

# ss -an | grep LISTEN

Make sure the firewall is accepting connections on port 53.

# firewall-cmd --list-all
add dns service permanent 
# firewall-cmd --permanent --add-service=dns --zone=public
reload the rules
# firewall-cmd --reload

Change DNS in nmtui for resolving and restart the NetworkManager.

After this, check if this will work for a client. For this purpose, I have configured a VM called yt_dns_client. In the meantime, you can open with tail the log files to keep an eye on what is happening when resolving domain names.

on the DNS server
# tail -f /var/log/messages

If you are not using IPv6, you can disable it with these edits.

Edit /etc/sysconfig/named and set

        OPTIONS="-4"

Also optionally comment 'listen-on-v6 port 53 { ::1; };'

To start the named service at boot, do not forget to execute the next command

# systemctl enable named

In the next video Part 2, we will configure zones to add our proper domain names.