Practice
So, we have a master (primary) DNS server, and in addition to it we need to "bolt on" a second brother-in-arms. If you need to set up the master server for Debian - that has already been covered
First, a couple of words - what for. The thing is that registrars require at least two DNS servers with different IP addresses and/or names on the internet in order to register DNS zones. The explanation is simple - one server should be the primary one, the second - in case the first one fails. For this reason, with only one nameserver you can work within your internal network, but you won't be able to register a zone on the internet - you'll be asked for the IP address of another such "brother-in-arms".
DNS is designed so that, at its core, it assumes several servers working in parallel at once. On one hand, this can somewhat reduce the load on them by distributing DNS requests among several machines, and on the other hand - it helps with fault tolerance.
The general layout looks like this: there is a master (primary) server and one or more secondary (slave) servers. The master server stores the data, and it is on this server that the administrator makes changes to DNS zones when needed. The additional (slave) servers receive zone data updates from the master server and have a full up-to-date picture of the "world" of the zones they serve.
At the same time, the slave servers also have complete information about the DNS zones they serve. Therefore, if the master server fails, any served zone can still be obtained from a secondary server - it will also answer the query.
The administrator makes changes on the master server. After a DNS zone has been changed - the master notifies the secondary servers about this and transfers the changes. Not immediately - during the next synchronization. But this way we get a situation where identical data resides on all DNS servers at once, so the failure of one of them does not lead to a failure of the enterprise's DNS service as a whole.
Well then, enough chewing on theory (especially since you can read a lot more in specialized literature). Our task is to show how to install and configure a secondary DNS server on a machine running Linux Debian.
Installation
Configuration
bind stores its settings under /etc/bind. Let's go into this directory - everything from now on will happen there.
1) Create the directory that will hold the configurations of our DNS zones.
Note. You don't need to write anything into this directory yourself! The slave server's DNS service will create the zone files here on its own during synchronization with the master server.
2) Open the named.conf.options file for editing and bring it to the following form (the options are commented; you need to set their values correctly for your own case, not just copy the examples):
Here:
As you can see - all addresses are for example only. In your particular case they will be your own.
Save the file.
3) Now open the named.conf file and see that it contains 3 references to our configurations:
We will add one more reference - to a file with descriptions of our DNS zones:
And let's save this config file.
4) Now let's create the file /etc/bind/named.conf.zones and write a test zone into it. This file will look something like this:
Here we see that I specified a zone "test.int" that deliberately does not exist on the internet. Its type on this server is slave, so we added the "masters" option, inside which we specified which server to receive and request updates from.
Thus, on the slave server we also need to declare the DNS zones it will own and specify which server exactly to get information about these zones from. The difference is that there is no need to write out the zones themselves (i.e. there's NO need to create zone configuration files) - BIND will connect to the master server on its own and get all the necessary data.
Note. For the test to succeed - the zone test.int must be declared on the master server. In this case - on server 11.22.33.44 (by the way, don't forget to change this fictitious IP address to the address of your master server!)
If the master server is already up and running, you can use an existing "production" zone instead of test.int.
Verification
Let's ask our secondary server to reread the information:
If everything is configured correctly on the master server's side - the slave server will copy the DNS zone test.int to itself and start answering queries regarding it.
Let's check. A file named test.int should appear in the /etc/bind/slave directory, with content identical to the zone on the master server's side. That's right - we didn't need to fill in the zone ourselves on the slave server's side - it read it itself from the master server.
Now let's check that the slave server answers queries for the test.int zone:
If successful - the response should provide you with information about the zone's IP address.
This concludes the server configuration.
A bit more
First. In order for slave servers to copy changed zones from master servers - the administrator must increase the "Serial" parameter (i.e. the serial number) of the zone being edited. And specifically increase it - not just change it.
The logic here is as follows: during synchronization, the slave server does not receive the entire dataset for each zone every time. It only looks at the zone's serial number - and only if the serial number has increased (not stayed the same and not decreased) - only in that case does the slave request all the information for that zone from the master server.
Second. To manually synchronize a zone with the master server, without waiting for anything and without taking the zone's serial number into account - enter the following command on the slave machine:
Where instead of test.int - specify the name of the zone that needs to be forcibly transferred to the slave server.
Often we have to look for familiar configuration files in operating systems that are new to us. For some reason, these files are not in their usual location.
In this note - the location of the PHP configuration file (php.conf or php.ini) on FreeBSD, Linux Debian/ubuntu, and Linux CentOS/RedHat.
So,
FreeBSD:
/usr/local/etc/php.ini
In the case of FreeBSD, it may not exist initially, but there will be php.ini-... files nearby with various configurations, one of which can simply be copied to php.ini
Debian/ubuntu:
/etc/php7/apache2/php.ini
CentOS/RedHat:
/etc/httpd/conf.d/php.conf
or
/etc/php.ini
Comments