How to configure BIND as a secondary DNS server for the ispmanager panel
The ispmanager panel is the default primary name server, even if its records are not transmitted anywhere. If you enable the "Name Server" option, you’ll have to create a master zone for each domain.
Server administrators often send the NS records of purchased domains to their servers with a panel, so that the records automatically get forwarded to the outside world. But this doesn't work for everyone; sometimes the NS records are directed to a third-party name server or a duplicate one is configured so that the site remains accessible if something happens to the master server. In these scenarios, you will have to configure BIND as a secondary name server.
In this article, we will show how to do it using AlmaLinux 8 and Ubuntu 22.04 as examples.
- Configuring a generic server with a BIND name server
- Configuring the master DNS
- Configuring the slave DNS
- Check the result
- Special case: configuring zone transfer from ispmanager to ispmanager
- Conclusions
Configuring a generic server with a BIND name server
First, configure the generic server so that the zones and DNS records are sent to the secondary name servers. Make the changes in the Options section of the name server configuration so that they apply to all zones on the server at once.
Settings strings:
allow-transfer { 172.31.97.22; };
also-notify { 172.31.97.22; };
notify yes;
Result: we allowed zone transfers to a single secondary server and enabled the sending of zone update notifications from the master to the secondary server.
Configuring the master DNS
How to configure the master DNS:
1. Create a new domain name. Here, we’ll create a domain with subdomains, using the wizard in the ispmanager panel. Choose "Manage DNS" → "Create Domain" from the panel menu.
2. Create domain records. Choose "Manage DNS" → domain isptest.test → "Manage DNS records". The result looks like this:
3. Check how the actions are displayed in the service configuration.
Ubuntu:
zone "isptest.test" {
type master;
file "/etc/bind/domains/isptest.test";
};
AlmaLinux:
zone "isptest.test" {
type master;
file "/var/named/domains/isptest.test";
};
The configurations differ only in the location of the files with the domain records. Otherwise, the syntax is the same. Now we’ll move on to configuring the slave server.
Configuring the slave DNS
Ubuntu 22.04
1. Installing packages. Let's assume that we are setting up a clean slave server from scratch.
To do so, we need
- name server packets
- related packages
apt install bind9 dnsutils rsyslog
2. Check that the service is running and is loaded at system startup. To do so, the service status must contain the words active
and enabled
.
Command to display the status of the service:
systemctl status named
3. Start the service. If you see the words inactive
and disabled
in the status, you need to start the service and specify that it should be enabled at system startup.
Commands to start and enable it:
systemctl start named
systemctl enable named
Check the status of the service:
systemctl status named
Verify that the service is listening on port 53:
ss -ptulwn | grep LISTEN | grep 53
4. Create the zone that we want to duplicate on the slave server. Make changes to the main configuration file:
/etc/bind/named.conf
In Ubuntu 22.04, you can make changes to a plug-in file, such as:
/etc/bind/named.conf.local
We copy the main file so that the configuration settings are the same on different OSs. At the very end of the configuration file, we copy the zone with minor changes. This is how the code looks in full:
zone "isptest.test" {
type slave;
file "/etc/bind/slave/isptest.test";
masters { 172.31.97.141; };
};
We have created a slave domain zone with a record in the specified file and specified the Master server from which the zone will receive updates. The service will create the file with the resource records of the zone itself, but you need to create a directory for it and correctly assign permissions.
To do so, use the commands:
mkdir /etc/bind/slave
chown bind:bind /etc/bind/slave
5. Check if the configuration is correct:
named-checkconf /etc/bind/named.conf
If there is no output in the console, then the configuration of the named service is completely correct.
6. Reboot the service and check its status
systemctl restart named
systemctl status named
AlmaLinux 8
1. Install the name server packages and utilities:
yum install bind bind-utils
or
dnf install bind bind-utils
These commands will install the same list of packages. You can use any package manager, dnf or yum. The list can include any console text editor that you prefer; "Vi" is the default. It is for experienced users, but beginners can go with "Nano".
2. Start the service. After installing the packages, it will be in an inactive state; its status will be inactive
or disabled
Input the commands to make the service start and enabled at system startup:
systemctl start named
systemctl enable named
3. Checking the status:
systemctl status named
If you see the words active
and enabled
in the status, you're all set =)
4. Edit the service's main configuration file at the path:
/etc/named.conf
It contains a block of global options—we will override the default values.
The options we will need for editing:
listen-on port 53 { 127.0.0.1; };
In this directive, add the IP to which external requests will be received. In our example, the option will look like this:
listen-on port 53 { 127.0.0.1; 172.31.97.22; };
The second option is to set listening on port 53 on all the IP addresses of the host.To get this configuration, specify the any
parameter:
listen-on port 53 { any; };
Or you can write a double forward slash //
at the beginning of the string. This will indicate that the line is a comment and will not be processed when reading the configuration. Commented-out lines can be seen at the beginning of the configuration file.
Option for listening for a port on an IPv6 address:
listen-on-v6 port 53 { ::1; };
The default is localhost.
Add your IPv6 address or disable this option.
To disable IPv6 listening, change the string to:
listen-on-v6 { none; };
The allow-query
parameter specifies who is allowed to send queries to the server:
allow-query { localhost; };
This option can be edited at your discretion to isolate the server from requests from unwanted IP addresses.
In most cases, it should be commented out with a double forward slash // at the beginning of the line so that each server can contact your name server for domain records. If so, you must specify a list of servers that are allowed to receive responses from your name server to record requests.
With the recursion
option, the name server can contact other name servers to resolve the query:
recursion yes;
See the documentation for more details →
The dnssec-enable
and dnssec-validation
directives include the DNSSEC validation mechanism:
dnssec-enable yes;
dnssec-validation yes;
The directives include a DNSSEC validation mechanism. How to configure DNSSEC is described in the ispmanager documentation →
5. Add a slave zone to the end of the main configuration file: /etc/named.conf
:
zone "isptest.test" {
type slave;
file "/var/named/slave/isptest.test";
masters { 172.31.97.141; };
};
If the masters
or primaries
parameter is specified in the directive, the slave zone will receive updates from a specific IP address.
6. Create a directory to store files with the resource records of domain zones:
mkdir /var/named/slave
chown named:named /var/named/slave
7. Check if the configuration is correct:
named-checkconf /etc/named.conf
8. Reboot the service and check its status:
systemctl restart named
systemctl status named
Check the result
1. Copy the records from the master. he result is a line in the system log. It looks like this:
transfer of 'isptest.test/IN' from 172.31.97.141#53: Transfer completed: 1 messages, 13 records, 372 bytes, 0.001 secs (372000 bytes/sec)
2. Checking to see if there is a file with the records:
Ubuntu 22.04:
ls -l /etc/bind/slave
AlmaLinux 8:
ls -l /var/named/slave
This command will display the contents of the directory with the zone record files. The file that we added to the configuration earlier should appear among them.
3. Checking the issuance of records.
In any network server or slave server, enter the command:
dig isptest.test a @172.31.97.22 +short
With this command, we access the slave nameserver with the IP 172.31.97.22
and ask the dig
utility to output the A records for the domain isptest.test
The response should contain the IP address of the domain, which is recorded in the records on the master.
Now add a new A record on the ispmanager master server in the domain zone.
What to do:
1. Go to "Manage DNS"
2. Choose the domain isptest.test
3. Click "Manage DNS records"
4. Select "Create Record"
What the result looks like:
4. Check the record output from the slave server:
dig dw.isptest.test a @172.31.97.22 +short
If everything works, the record will come back from the slave server immediately. When we added the new record, the master server sent a zone update notification to the slave, and the data on the servers were synchronized. You will see this in the system log.
If the records did not synchronize immediately, run manual domain zone synchronization using this command on the slave server:
rndc retransfer isptest.test
As a result, all records will be updated and new records will be delivered to the slave.
Special case: configuring zone transfer from ispmanager to ispmanager
In this case, the zones are transferred between two panel servers with a BIND name server installed.
What to do:
1. Create a regular administrator in the future slave panel without superuser rights:
"Settings" → "Administrators" → "Create Administrator". The result looks like this:
2. Configure the secondary name server in the master panel using native integration, data from the slave panel, and the new administrator:
"DNS Management" → "DNSmanager" → "Create". The result looks like this:
If you configure the name servers from the default panel, the integration will start immediately. The configuration can be edited if you need to fine-tune the service.
Conclusions
We have configured BIND as a secondary name server; now, domains are sent to the slave server simply and quickly.
The downside of this method is that you need to manually add the required zones to the slave server configuration.
You will find detailed information about the configuration in the documentation:
If you have any questions, come visit our Facebook community →