Set up your own domain name resolution server on CentOS

When you need to manage your own domains in an intranet environment or want to provide faster DNS resolution services for your local network, setting up your own DNS server is a practical choice. On CentOS systems, the most classic tool is BIND (Berkeley Internet Name Domain). This open-source DNS software suite has been around for decades, with mature and complete functionality. By configuring BIND, you can create your own authoritative DNS server, manage private domains, or set up a caching resolver to accelerate network access.

Before you begin, ensure you have a server running CentOS 7 or 8 with administrator privileges. The entire process begins with installing the packages. The main BIND package is called `bind`, while some of its utilities and documentation are in `bind-utils`. You can install them all at once using the `yum` or `dnf` command.

sudo yum install bind bind-utils

After installation, the main BIND service is called `named`. However, before starting it, we need to perform core configuration. The main BIND configuration file is `/etc/named.conf`. It is recommended to back up the original file before making any modifications.

sudo cp /etc/named.conf /etc/named.conf.backup

sudo vi /etc/named.conf

Opening the configuration file, you'll see some default configuration sections. We need to focus on a few key parts. First is the `options` block, which defines global settings. Here, you need to specify the network interface and port the server listens on. If you want the server to listen for DNS queries on all available IP addresses (default port 53), you can keep `listen-on port 53` as `any`. However, for security reasons, it's generally recommended to specify a specific IP address in a production environment.

options {

listen-on port 53 { 127.0.0.1; 192.168.1.10; };

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";

allow-query { localhost; 192.168.1.0/24; };

recursion yes;

};

Note the `allow-query` parameter, which defines which clients can submit DNS queries. Here we allow queries from the local network `192.168.1.0/24` and the local machine. `recursion yes` enables recursive queries, allowing your DNS server to look up other domain names on the internet for clients, essentially acting as a caching resolver.

Next is the section on defining zones. Zone files are the actual storage location for DNS records. Suppose we want to create a private zone `internal.company.local`, we need to add a forward lookup zone and a reverse lookup zone configuration to the end of the `/etc/named.conf` file.

In `named.conf`, find a section like `zone "." IN { ... }`, and add the following after it:

zone "internal.company.local" IN {

type master;

file "internal.company.local.zone";

allow-update { none; };

};

`zone "1.168.192.in-addr.arpa" IN {

type master;

file "192.168.1.rev";

allow-update { none; };

};

The first section defines a forward lookup zone of type `master` (master server), named `internal.company.local.zone`, which will be stored in the `/var/named/` directory. The second section defines the corresponding reverse lookup zone, used to look up hostnames via IP addresses. Note the reverse lookup zone syntax: the IP network part needs to be reversed and appended with the `.in-addr.arpa` suffix. For the `192.168.1.0/24` network segment, it would be `1.168.192.in-addr.arpa`.

Now, we need to create the two zone files we just defined. First, create the forward zone file:

sudo vi /var/named/internal.company.local.zone

The file content should contain basic SOA records, NS records, and some A records. Here's an example:

$TTL 86400

@ IN SOA ns1.internal.company.local. admin.internal.company.local. (

2024011901; serial

3600;refresh

1800; retry

604800; expire

86400;minimum TTL

)

IN NS ns1.internal.company.local.

IN NS ns2.internal.company.local.

ns1 IN A 192.168.1.10

ns2 IN A 192.168.1.11

www IN A 192.168.1.100

mail IN A 192.168.1.101

db IN A 192.168.1.102

The first line, `$TTL`, sets the default time-to-live. The SOA record is a required initial authorization record for each zone file, containing parameters such as the sequence number (which increments after each file modification) and refresh time. Next, two NS records are defined, pointing to the name server for this domain. Following that are the specific A records, mapping hostnames to IP addresses.

Then create the reverse zone file:

sudo vi /var/named/192.168.1.rev

Content as follows:

$TTL 86400

@ IN SOA ns1.internal.company.local. admin.internal.company.local. (

2024011901 ; serial

3600 ; refresh

1800 ; retry

604800 ; expire

86400 ; minimum TTL

)

IN NS ns1.internal.company.local.

IN NS ns2.internal.company.local.

10 IN PTR ns1.internal.company.local.

11 IN PTR ns2.internal.company.local.

100 IN PTR www.internal.company.local.

101 IN PTR mail.internal.company.local.

102 IN PTR db.internal.company.local.

The reverse zone file has a similar structure, but the record type is PTR, used to map IP addresses back to hostnames. Note that only the last part of the IP address (host number) needs to be written in the PTR record.

After creating the zone file, you need to set the file permissions and ownership correctly. BIND usually runs as the `named` user, so these files need to be readable by that user.

sudo chown root:named /var/named/internal.company.local.zone

sudo chown root:named /var/named/192.168.1.rev

sudo chmod 640 /var/named/internal.company.local.zone

sudo chmod 640 /var/named/192.168.1.rev

Next, we need to configure SELinux and the firewall to allow the DNS service to function properly. If SELinux is enabled on your system, ensure the relevant context is correct. You can use the `semanage` command to add the port context required by the DNS service, but BIND's RPM packages usually already include the necessary SELinux policies.

For the firewall, you need to allow port 53 (TCP and UDP) used by the DNS service:

sudo firewall-cmd --permanent --add-service=dns

sudo firewall-cmd --reload

Now, before starting the service, it's best to check the configuration file for syntax errors. BIND provides two useful tools: `named-checkconf` to check the main configuration file and `named-checkzone` to check the zone files.

sudo named-checkconf /etc/named.conf

sudo named-checkzone internal.company.local /var/named/internal.company.local.zone

sudo named-checkzone 1.168.192.in-addr.arpa /var/named/192.168.1.rev

If there are no error outputs, you can start and enable the BIND service:

sudo systemctl start named

sudo systemctl enable named

To verify that the service is running correctly, you can check the service status and listening port:

sudo systemctl status named

sudo netstat -tulpn | grep :53

Now, you can test this DNS server on another machine on the same network. Set the test machine's DNS server to your BIND server's IP address, and then use the `dig` or `nslookup` command to query.

# Test on the client machine

dig www.internal.company.local @192.168.1.10

dig -x 192.168.1.100 @192.168.1.10

If everything is normal, you will get the correct resolution result. You can also test the recursive query function, such as querying an internet domain name to see if the BIND server can return the correct result.

In actual use, you may need to perform regular maintenance. After each modification to the zone file, remember to increment the sequence number in the SOA record and then reload the BIND configuration:

sudo systemctl reload named

BIND logs are stored in `/var/log/messages` by default, but you can also configure more detailed logging in `/etc/named.conf`. Monitoring these logs helps to discover problems, such as a large number of failed queries or denial-of-service attempts.

For security, in addition to firewall configuration, you can consider using TSIG (Transaction Signature) to protect zone transfers, or restrict recursive queries to a smaller client scope. For DNS servers exposed to the public internet, it's also necessary to guard against threats such as DNS amplification attacks.

Setting up your own BIND server requires some initial configuration work, but it gives you complete control. You can create any private domain name on your internal network, quickly modify DNS records without waiting for them to propagate through public DNS, and accelerate network access through caching. Once the basic configuration is running, you can further explore BIND's advanced features, such as views for separating internal and external network resolution and DNSSEC configuration for increased security. This first step begins with installing and configuring those core files.