General index of the series: Computer Networks for SMEs: Introduction
Hello friends!. We will see in this article how we can implement the important pair of services for networks constituted by the DNS and DHCP on CentOS - Linux, specifically in its version 7.2.
- Some articles about DNS refer to the fact that the implementation of this service is a bit obscure and difficult. I don't quite agree with that statement. I'd rather say that it's a bit conceptual and that many of its config files have fussy syntax. Luckily, we have tools to check, step by step, the syntax of each configuration file that we modify. Therefore, we will try to make reading this post as pleasant and enjoyable as possible..
For those who are looking for the basics of both services, we strongly recommend starting your search on Wikipedia, both in its Spanish and English versions. It is no less true that articles in English are almost always more complete and coherent. Still, Wikipedia is a very good starting point.
For those of you who really want to learn about DNS and BIND, we recommend reading the book «OReilly - DNS and BIND 4ed" written by Paul albitz y Liu Cricket, or a later edition that surely exists.
We have already published an article on the subject entitled «DNS and DHCP in openSUSE 13.2 Harlequin - SME Networks»For lovers of the graphic environment. However, from now on they will be faced with articles on this subject -not on others- written with much use of the emulator of a terminal or console. Wow, in the classic style used by UNIX® / Linux System Administrators.
If you want to know more about the last name of the title of this article «SME Networks»You can visit the page in this blog«SME networks: first virtual cut«. In it you will find links to many other published articles.
- After the installation of the CentOS 7 Operating System is finished with the packages we recommend, el directory /usr/share/doc/bind-9.9.4/ It contains a good amount of documentation that we recommend you consult before venturing into an Internet search without first knowing that, at your fingertips and in your own home, you can find what you are looking for.
Base system installation
General data of the domain and DNS server
Domain name: desdelinux.fan DNS server name: dns.desdelinux.fan IP adress: 192.168.10.5 Subnet mask: 255.255.255.0
Installation
We start with a new or clean installation of the CentOS 7 operating system as indicated in the previous article «CentOS 7 Hypervisor I - SMB Networks«. We only need to make the following changes:
- At Imagen 22 «SOFTWARE SELECTION«, We recommend choosing in the left column«Base Environment»The option corresponding to a«Infrastructure server«, While in the right column«Plugins for Selected Environment»Select the check box«DNS name server«. We will install the DHCP server later.
- Let's remember the declaration of the additional repositories as shown in the Imagen 23, after setting the «NETWORK & TEAM NAME«.
- The images referring to the partitions that we will create on our hard drive are only given as guides. Feel free to select the partitions at your own discretion, practice, and good judgment.
- Finally, in the Image 13 «NETWORK & TEAM NAME», we must change the values according to the general parameters of the declared domain and DNS server, without forgetting to specify the host name -in this case «dns«- after the network configuration is completed. It is positive to do ping -from another host- to the specified IP address after the network is active:
There are really few and very obvious changes that we must make with respect to the previous article.
Initial checks and adjustments
After we install the operating system we must review the following files at least, and for this we start a session via SSH from our computer sysadmin.desdelinux.fan:
buzz @ sysadmin: ~ $ ssh 192.168.10.5 buzz@192.168.10.5's password: Last login: Sat Jan 28 09:48:05 2017 from 192.168.10.1 [buzz @ dns ~] $
The above operation may take longer than normal, and it is mainly due to the fact that we do not yet have a DNS on the LAN. Check again later that DNS is working.
[buzz @ dns ~] $ cat / etc / hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 :: 1 localhost localhost.localdomain localhost6 localhost6.localdomain6 [buzz @ dns ~] $ cat / etc / hostname dns [buzz @ dns ~] $ cat / etc / sysconfig / network-scripts / ifcfg-eth0 TYPE=Ethernet BOOTPROTO=none DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6INIT=no IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_PEERDNS=yes IPV6_PEERROUTES=yes IPV6_FAILURE_FATAL=no NAME=eth0 UUID=946f5ac9-238a-4a94-9acb-9e3458c680fe DEVICE=eth0 ONBOOT=yes IPADDR=192.168.10.5 PREFIX=24 GATEWAY=192.168.10.1 DNS1=127.0.0.1 DOMAIN=desdelinux.fan [buzz @ dns ~] $ cat /etc/resolv.conf # Generated by NetworkManager search desdelinux.fan nameserver 127.0.0.1
The main configurations respond to our selections. Note that even on a server Red Hat 7 - CentOS 7, is configured by default when NetworkManager so that this is the one who manages the network interfaces, be they wired or wireless (WiFi), VPN connections, PPPoE connections, and any other network connection.
[buzz @ dns ~] $ sudo systemctl status networkmanager [sudo] password for buzz: ● networkmanager.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) [buzz @ dns ~] $ sudo systemctl status NetworkManager ● NetworkManager.service - Network Manager Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled; vendor preset: enabled) Active: active (running) since Sat 2017-01-28 12:23:59 EST; 12min ago Main PID: 705 (NetworkManager) CGroup: /system.slice/NetworkManager.service └─705 / usr / sbin / NetworkManager --no-daemon
Red Hat - CentOS also allows you to connect and disconnect network interfaces using the classic commands Ifup e ifdown. Let's run on a server console:
[root @ dns ~] # ifdown eth0 Device 'eth0' successfully disconnected. [root @ dns ~] # ifup eth0 Connection activated successfully (D-Bus active path: / org / freedesktop / NetworkManager / ActiveConnection / 1)
- We suggest do not change the default settings that CentOS 7 offers with respect to NetworkManager.
We definitively declare the repositories that we are going to use and update the operating system if necessary:
[buzz @ dns ~] $ su Password: [root @ dns buzz] # cd /etc/yum.repos.d/ [root @ dns yum.repos.d] # ls -l total 28 -rw-r - r--. 1 root root 1664 Dec 9 2015 CentOS-Base.repo -rw-r - r--. 1 root root 1309 Dec 9 2015 CentOS-CR.repo -rw-r - r--. 1 root root 649 Dec 9 2015 CentOS-Debuginfo.repo -rw-r - r--. 1 root root 290 Dec 9 2015 CentOS-fasttrack.repo -rw-r - r--. 1 root root 630 Dec 9 2015 CentOS-Media.repo -rw-r - r--. 1 root root 1331 Dec 9 2015 CentOS-Sources.repo -rw-r - r--. 1 root root 1952 Dec 9 2015 CentOS-Vault.repo
It is healthy to read the content of the original declaration files of the CentOS recommended repositories. The changes we make here are due to the fact that we do not have Internet access, and we work with local repositories downloaded from the WWW Village, by colleagues who make our lives a little easier.
[root @ dns yum.repos.d] # mkdir original [root @ dns yum.repos.d] # mv CentOS- * original / [root @ dns yum.repos.d] # nano centos-repos.repo [centos-base] name=CentOS-$releasever baseurl=http://10.10.10.1/repos/centos/7/base/ gpgcheck=0 enabled=1 [centos-updates] name=CentOS-$releasever baseurl=http://10.10.10.1/repos/centos/7/updates/x86_64/ gpgcheck=0 enabled=1 [root @ dns yum.repos.d] # yum clean all Loaded plugins: fastestmirror, langpacks Cleaning repositories: centos-base centos-updates Cleaning up everything [root @ dns yum.repos.d] # yum update Loaded plugins: fastestmirror, centos-base langpacks | 3.4 kB 00:00 centos-updates | 3.4 kB 00:00 (1/2): centos-base / primary_db | 5.3 MB 00:00 (2/2): centos-updates / primary_db | 9.1 MB 00:00 Determining fastest mirrors No packages marked for update
The message «No (exist) packages marked for update» - «No packages marked for update»Indicates that, by declaring the most up-to-date repositories available to us during installation, precisely the most current packages were installed.
About the SELinux context and the firewall
We are going to focus this article - fundamentally - on the implementation of DNS and DHCP services, which is its Main Objective.
If any reader selected a Security Policy during the installation process, as indicated in the Imagen 06 of the reference article «CentOS 7 Hypervisor I - SMB Networks»Used for the installation of this DNS - DHCP server, and you find that you do not know how to properly configure SELinux and the CentOS Firewall, we suggest you execute the following:
Modify the file / etc / sysconfig / selinux and change SELINUX = enforcing by SELINUX = disable
[root @ dns ~] # nano / etc / sysconfig / selinux # This file controls the state of SELinux on the system. # SELINUX = can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX = disabled # SELINUXTYPE = can take one of three two values: # targeted - Targeted processes are protected, # minimum - Modification of targeted policy. Only selected processes are pr $ # mls - Multi Level Security protection. SELINUXTYPE = targeted
Then run the following commands
[root @ dns ~] # setenforce 0
[root @ dns ~] # service firewalld stop Redirecting to / bin / systemctl stop firewalld.service [root @ dns ~] # systemctl disable firewalld Removed symlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service. Removed symlink /etc/systemd/system/basic.target.wants/firewalld.service.
If you are implementing a DNS server facing the Internet, you should NOT do the above, but configure the SELinux context and the Firewall correctly. See "Server Configuration with GNU / Linux, by the author Joel Barrios Dueñas" or CentOS documentation itself - Red Hat
We configure the BIND - named
- El directory /usr/share/doc/bind-9.9.4/ contains a good amount of documentation that we recommend you consult before venturing into an Internet search without first knowing that, at your fingertips and in your own home, you can find what you are looking for
In many distributions the DNS service installed through the BIND package is called named (NameDaemon). In CentOS 7 it is installed disabled by default, according to the output of the following command, where it states that its status is «disabled«, And that this state is predefined by its« seller »- vendor preset. For the record, BIND is Free Software.
Enabling the named service
[root @ dns ~] # systemctl status named ● named.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named.service; disabled; vendor preset: disabled) Active: inactive (dead) [root @ dns ~] # systemctl enable named Created symlink from /etc/systemd/system/multi-user.target.wants/named.service to /usr/lib/systemd/system/named.service. [root @ dns ~] # systemctl start named [root @ dns ~] # systemctl status named ● named.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; vendor preset: disabled) Active: activate (running) since Sat 2017-01-28 13:22:38 EST; 5min ago Process: 1990 ExecStart = / usr / sbin / named -u named $ OPTIONS (code = exited, status = 0 / SUCCESS) Process: 1988 ExecStartPre = / bin / bash -c if [! "$ DISABLE_ZONE_CHECKING" == "yes"]; then / usr / sbin / named-checkconf -z /etc/named.conf; else echo "Checking of zone files is disabled"; fi (code = exited, status = 0 / SUCCESS) Main PID: 1993 (named) CGroup: /system.slice/named.service └─1993 / usr / sbin / named -u named Jan 28 13:22:45 dns named [1993]: error (network unreachable) resolving './NS/IN': 2001: 500: 2f :: f # 53 Jan 28 13:22:47 dns named [1993]: error (network unreachable) resolving './ DNSKEY / IN ': 2001: 500: 3 :: 42 # 53 Jan 28 13:22:47 dns named [1993]: error (network unreachable) resolving' ./NS/IN ': 2001: 500: 3 :: 42 # 53 Jan 28 13:22:47 dns named [1993]: error (network unreachable) resolving './DNSKEY/IN': 2001: 500: 2d :: d # 53 Jan 28 13:22:47 dns named [1993 ]: error (network unreachable) resolving './NS/IN': 2001: 500: 2d :: d # 53 Jan 28 13:22:47 dns named [1993]: error (network unreachable) resolving './DNSKEY/ IN ': 2001: dc3 :: 35 # 53 Jan 28 13:22:47 dns named [1993]: error (network unreachable) resolving' ./NS/IN ': 2001: dc3 :: 35 # 53 Jan 28 13: 22:47 dns named [1993]: error (network unreachable) resolving './DNSKEY/IN': 2001: 7fe :: 53 # 53 Jan 28 13:22:47 dns named [1993]: error (network unreachable) res olving './NS/IN': 2001: 7fe :: 53 # 53 Jan 28 13:22:48 dns named [1993]: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out [root @ dns ~] # systemctl restart named [root @ dns ~] # systemctl status named ● named.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; vendor preset: disabled) Active: activate (running) since Sat 2017-01-28 13:29:41 EST; 1s ago Process: 1449 ExecStop = / bin / sh -c / usr / sbin / rndc stop> / dev / null 2> & 1 || / bin / kill -TERM $ MAINPID (code = exited, status = 0 / SUCCESS) Process: 1460 ExecStart = / usr / sbin / named -u named $ OPTIONS (code = exited, status = 0 / SUCCESS) Process: 1457 ExecStartPre = / bin / bash -c if [! "$ DISABLE_ZONE_CHECKING" == "yes"]; then / usr / sbin / named-checkconf -z /etc/named.conf; else echo "Checking of zone files is disabled"; fi (code = exited, status = 0 / SUCCESS) Main PID: 1463 (named) CGroup: /system.slice/named.service └─1463 / usr / sbin / named -u named Jan 28 13:29:41 dns named [1463]: managed-keys-zone: journal file is out of date: removing journal file Jan 28 13:29:41 dns named [1463]: managed-keys-zone: loaded serial Jan 2 28 13:29:41 dns named [1463]: zone 0.in-addr.arpa/IN: loaded serial 0 Jan 28 13:29:41 dns named [1463]: zone localhost.localdomain / IN: loaded serial 0 Jan 28 13:29:41 dns named [1463]: zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0 Jan 28 13:29:41 dns named [1463]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 .6.ip0.arpa / IN: loaded serial 28 Jan 13 29:41:1463 dns named [0]: zone localhost / IN: loaded serial 28 Jan 13 29 : 41: 1463 dns named [28]: all zones loaded Jan 13 29:41:1463 dns named [28]: running Jan 13 29:41:1 dns systemd [XNUMX]: Started Berkeley Internet Name Domain (DNS).
After we enable the service named and we start it for the first time, the output of the command systemctl status named shows errors. When we restart the service below, the named creates all the configuration files that, by default, are necessary for its correct operation. Therefore, when we execute the command again systemctl status named no more errors are shown.
- Dear, dear, and demanding Reader: if you want to know -at least- which path leads to the end of the rabbit hole, please read carefully the detailed outputs of each command. I'm sure the article will seem a bit long, but you can't deny that it gains in explanation and clarity..
We modify the file /etc/named.conf
Many reader comments express -I don't say it– the mania that the maintainers of the different Linux distributions have, of placing the system configuration files in folders with different names depending on the distro. They are right. But what can we, the simple users who use these distributions, do? Adapt!
By the way, in FreeBSD, UNIX® clone «The Origin», the file is in /usr/local/etc/namedb/named.conf; while in Debian, in addition to splitting into the four files named.conf, named.conf.options, named.conf.default-zones, and named.conf.local, is in the folder / etc / bind /. Those who want to know where openSUSE places it, read «DNS and DHCP in openSUSE 13.2 Harlequin - SME Networks«. The readers are right!.
And as we always do: before modifying anything, we save the original configuration file under another name.
[root @ dns ~] # cp /etc/named.conf /etc/named.conf.original
To make life easier, instead of generating the key TSIG for dynamic DNS updates by DHCP, we copy the same key rndc.key , the dhcp.key.
[root @ dns ~] # cp /etc/rndc.key /etc/dhcp.key
[root @ dns ~] # nano /etc/dhcp.key
key "dhcp-key" {algorithm hmac-md5; secret "OI7Vs + TO83L7ghUm2xNVKg =="; };
For the named can read the file just copied, we modify its owner group:
[root @ dns ~] # chown root: named /etc/dhcp.key [root @ dns ~] # ls -l /etc/rndc.key /etc/dhcp.key -rw-r -----. 1 root named 77 Jan 28 16:36 PM /etc/dhcp.key -rw-r -----. 1 root named 77 Jan 28 13:22 /etc/rndc.key
Small details like the previous one are what can drive us crazy trying to find out, now ... where is the problem ...? with some more adjectives, which we don't write out of respect for the Respectable.
Now if - finally! - we modify the file /etc/named.conf. The changes or additions that we have made, with respect to the original, are in bold. Take a good look at how few.
[root @ dns ~] # nano /etc/named.conf
// // 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. //
// Access Control List declaring which networks will be able to consult
// my named server
acl looked {
127.0.0.0 / 8;
192.168.10.0 / 24;
};
options {
// I declare that the named daemon also listen for the interface
// eth0 which has the IP: 192.168.10.5
listen-on port 53 {127.0.0.1; 192.168.10.5; };
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";
// Forwarders statement
// forwarders {
// 0.0.0.0;
// 1.1.1.1;
//};
// forwardfirst;
// I only allow queries to my mired ACL
allow-query { mired; }; // To check with the dig command desdelinux.fan axfr // from the SysAdmin workstation and localhost only // We do not have slave DNS servers. We don't need it...until now.
allow-transfer {localhost; 192.168.10.1; };
/ * - 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 * /
// We want an AUTHORITY server for our LAN - SME
recursion not;
dnssec-enable yes; dnssec-validation yes; / * Path to ISC DLV key * / bindkeys-file "/etc/named.iscdlv.key"; managed-keys-directory "/ var / named / dynamic"; pid-file "/run/named/named.pid"; session-keyfile "/run/named/session.key"; }; 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 include the TSIG key for dynamic DNS updates // by DHCP
include "/etc/dhcp.key";
// Declaration of the name, type, location, and update permission
// of the DNS Records Zones // Both Zones are MASTERS
area "desdelinux.fan" {
typemaster;
file "dynamic/db.desdelinux.fan";
allow-update {key dhcp-key; };
};
zone "10.168.192.in-addr.arpa" {
typemaster;
file "dynamic / db.10.168.192.in-addr.arpa";
allow-update {key dhcp-key; };
};
We check the syntax
[root @ dns ~] # named-checkconf [root @ dns ~] #
Since the above command does not return anything, the syntax is OK. However, if we execute the same command, but with the option -z, the output will be:
[root @ dns ~] # named-checkconf -z zone localhost.localdomain/IN: loaded serial 0 zone localhost/IN: loaded serial 0 zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 .ip6.arpa/IN: loaded serial 0 zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0 zone 0.in-addr.arpa/IN: loaded serial 0 zone desdelinux.fan/IN: loading from master file dynamic/db.desdelinux.fan failed: file not found zone desdelinux.fan/IN: not loaded due to errors. _default/desdelinux.fan/IN: file not found zone 10.168.192.in-addr.arpa/IN: loading from master file dynamic/db.10.168.192.in-addr.arpa failed: file not found zone 10.168.192.in- addr.arpa/IN: not loaded due to errors. _default/10.168.192.in-addr.arpa/IN: file not found
Of course they are errors that occur because we have not yet created the DNS Registration Zones for our domain.
- For more information on the command named-checkconf, run man named-checkconf, before looking for any other information on the Internet. I assure you it will save a good deal of time.
We create the Direct Zone file desdelinux.fan
… but not before a little theory.
As a template to create the zone data file, we can take the /var/named/named.empty, or the /usr/share/doc/bind-9.9.4/sample/var/named/named.empty. Both are identical.
[root @ dns ~] # cat /var/named/named.empty $ TTL 3H @ IN SOA @ rname.invalid. (0; serial 1D; refresh 1H; retry 1W; expire 3H); minimum or Negative caching time to live NS @ A 127.0.0.1 AAAA :: 1
Time of life - Time to live TTL SOA record
Let's take a parenthesis to explain the TTL - Time to live from the register SOA - Start of Authority of a Master Zone. It is interesting to know their meanings for when we want to modify any of their values.
$ TTL: Time of life - Time to live for all records in the file that follow the declaration (but precede any other $ TTL declaration) and do not have an explicit TTL declaration.
serial: Serial number of the Zone data. Every time we manually modify a DNS record in a zone, we must increase that number by 1, especially if we have slave or secondary servers. Every time a secondary or slave DNS server contacts its master server, it asks for the serial number of the master's data. If the slave's serial number is lower, then the data for that zone on the slave server is out of date, and the slave performs a zone transfer to update itself.
refresh: Tells the slave server the time interval in which it should check if its data is up to date with respect to the master.
retry: If the master server is not available - because it got sick, let's say - for the slave after a time interval refresh, retry It tells the slave how long to wait before trying to contact its master again.
expired: If the slave cannot contact its master for an interval of time expiredThen if the slave-master zone relationship was screwed up, and the slave server has no choice but to expire the zone in question. The expiration of a zone by a slave DNS server means that it will stop responding to DNS queries related to that zone, because the available data is too old to be useful.
- The above teaches us indirectly and loaded with great common sense -the least common of the senses- that if we do not need slave DNS servers for the operation of our SME, we do not implement it, unless they are strictly necessary. Let's always try to go from the simple to the complex.
minimum: In versions prior to BIND 8.2, the last record SOA It also indicates the Default Lifetime - Default time to live, and Negative Cache Lifetime - Negative cache time to live for the Zone. This time refers to all negative responses given by the authoritative server for the Zone.
Zone file /var/named/dynamic/db.desdelinux.fan
[root@dns ~]# nano /var/named/dynamic/db.desdelinux.fan $TTL 3H @ IN SOA dns.desdelinux.fan. root.dns.desdelinux.fan. ( 1 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H ) ; minimum or ; Negative caching time to live ; @ IN NS dns.desdelinux.fan. @ IN MX 10 email.desdelinux.fan. @ IN TXT "FromLinux, your Blog dedicated to Free Software" ; sysadmin IN A 192.168.10.1 ad-dc IN A 192.168.10.3 fileserver IN A 192.168.10.4 dns IN A 192.168.10.5 proxyweb IN A 192.168.10.6 blog IN A 192.168.10.7 ftpserver IN A 192.168.10.8. 192.168.10.9 mail IN A XNUMX
We check /var/named/dynamic/db.desdelinux.fan
[root@dns ~]# named-checkzone desdelinux.fan /var/named/dynamic/db.desdelinux.fan areas desdelinux.fan/IN: loaded serial 1 OK
We create the Reverse Zone file 10.168.192.in-addr.arpa
- The SOA record of this Zone is the same as that of the Direct Zone without considering the MX record..
[root @ dns ~] # nano /var/named/dynamic/db.10.168.192.in-addr.arpa $TTL 3H @ IN SOA dns.desdelinux.fan. root.dns.desdelinux.fan. ( 1 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H ) ; minimum or ; Negative caching time to live ; @ IN NS dns.desdelinux.fan. ; 1 IN PTR sysadmin.desdelinux.fan. 3 IN PTR ad-dc.desdelinux.fan. 4 IN PTR fileserver.desdelinux.fan. 5 IN PTR dns.desdelinux.fan. 6 IN PTR proxyweb.desdelinux.fan. 7 IN PTR blog.desdelinux.fan. 8 IN PTR ftpserver.desdelinux.fan. 9 IN PTR mail.desdelinux.fan. [root @ dns ~] # named-checkzone 10.168.192.in-addr.arpa /var/named/dynamic/db.10.168.192.in-addr.arpa zone 10.168.192.in-addr.arpa/IN: loaded serial 1 OK
Before restarting the named we check its configuration
- Until we are sure that the configuration files of the named named.conf, and its zone files are not correctly configured, we suggest not restarting the named daemon. If we do this and later modify a zone file, we must increase the serial number of the modified zone by 1.
- Let's look at the "." at the end of domain and host names.
[root @ dns ~] # named-checkconf [root @ dns ~] # named-checkconf -z zone localhost.localdomain/IN: loaded serial 0 zone localhost/IN: loaded serial 0 zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 .ip6.arpa/IN: loaded serial 0 zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0 zone 0.in-addr.arpa/IN: loaded serial 0 zone desdelinux.fan/IN: loaded serial 1 zone 10.168.192.in-addr.arpa/IN: loaded serial 1
All current named configuration
To gain clarity, and although the article becomes long, we give the complete output of the command named-checkconf -zp:
[root @ dns ~] # named-checkconf -zp
zone localhost.localdomain/IN: loaded serial 0 zone localhost/IN: loaded serial 0 zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 .ip6.arpa/IN: loaded serial 0 zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0 zone 0.in-addr.arpa/IN: loaded serial 0 zone desdelinux.fan/IN: loaded serial 1 zone 10.168.192.in-addr.arpa/IN: loaded serial 1 options { bindkeys-file "/etc/named.iscdlv.key"; session-keyfile "/run/named/session.key"; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; listen-on port 53 { 127.0.0.1/32; 192.168.10.5/32; }; listen-on-v6 port 53 { ::1/128; }; managed-keys-directory "/var/named/dynamic"; memstatistics-file "/var/named/data/named_mem_stats.txt"; pid-file "/run/named/named.pid"; statistics-file "/var/named/data/named_stats.txt"; dnssec-enable yes; dnssec-validation yes; recursion no; allow-query { "watched"; }; allow-transfer { 192.168.10.1/32; }; }; acl "watched" { 127.0.0.0/8; 192.168.10.0/24; }; logging { channel "default_debug" { file "data/named.run"; dynamic severity; }; }; key "dhcp-key" { algorithm "hmac-md5"; secret "OI7Vs+TO83L7ghUm2xNVKg=="; }; zone "." IN { type hint; file "named.ca"; }; zone "localhost.localdomain" IN { type master; file "named.localhost"; allow-update { "none"; }; }; zone "localhost" IN { type master; file "named.localhost"; allow-update { "none"; }; }; zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN { type master; file "named.loopback"; allow-update { "none"; }; }; zone "1.0.0.127.in-addr.arpa" IN { type master; file "named.loopback"; allow-update { "none"; }; }; zone "0.in-addr.arpa" IN { type master; file "named.empty"; allow-update { "none"; }; }; zone"desdelinux.fan" { type master; file "dynamic/db.desdelinux.fan"; allow-update { key "dhcp-key"; }; }; zone "10.168.192.in-addr.arpa" { type master; file "dynamic/db.10.168.192.in-addr.arpa "; allow-update { key "dhcp-key"; }; }; managed-keys { "." initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g 0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD F6dsV6DoBQzgul68sGIcGOYl0OyQdXfZ1relS Qageu+ipAdTTJ9AsRTAoub7ONGcLmqrAmRLKBP6dfwhYB3N5knNnulq QxA +Uk2ihz8="; };
- Following the procedure of modifying the named.conf According to our needs and check, and create each zone file and check it, we doubt that we will have to face major configuration problems. In the end we realize that it is a boy's game, with many concepts and fussy syntax.
The checks returned satisfactory results, therefore we can restart the BIND - named.
We restart the named and check its status
[root @ dns ~] # systemctl restart named.service [root @ dns ~] # systemctl status named.service
If we get any kind of error in the output of the last command, we must restart the named.service and recheck your professional status. If the errors disappeared, the service started successfully. Otherwise, we must carry out a thorough review of all the modified and created files, and repeat the procedure.
The correct output of the status should be:
[root @ dns ~] # systemctl status named.service ● named.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; vendor preset: disabled) Active: active (running) since Sun 2017-01-29 10:05:32 EST; 2min 57s ago Process: 1777 ExecStop=/bin/sh -c /usr/sbin/rndc stop > /dev/null 2>&1 || /bin/kill -TERM $MAINPID (code=exited, status=0/SUCCESS) Process: 1788 ExecStart=/usr/sbin/named -u named $OPTIONS (code=exited, status=0/SUCCESS) Process: 1786 ExecStartPre =/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z /etc/named.conf; else echo "Checking of zone files is disabled"; fi (code=exited, status=0/SUCCESS) Main PID: 1791 (named) CGroup: /system.slice/named.service └─1791 /usr/sbin/named -u named Jan 29 10:05:32 dns named [1791]: zone 1.0.0.127.in-addr.arpa/IN: loaded serial Jan 0 29 10:05:32 dns named[1791]: zone 10.168.192.in-addr.arpa/IN: loaded serial Jan 1 29 10:05:32 dns named[1791]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN : loaded serial 0 Jan 29 10:05:32 dns named[1791]: zone desdelinux.fan/IN: loaded serial Jan 1 29 10:05:32 dns named[1791]: zone localhost.localdomain/IN: loaded serial Jan 0 29 10:05:32 dns named[1791]: zone localhost/IN: loaded serial 0 Jan 29 10:05:32 dns named[1791]: all zones loaded Jan 29 10:05:32 dns named [1791]: running Jan 29 10:05:32 dns systemd [1]: Started Berkeley Internet Name Domain (DNS). Jan 29 10:05:32 dns named [1791]: zone 10.168.192.in-addr.arpa/IN: sending notifies (serial 1)
Checks
The checks can be run on the same server or on a machine connected to the LAN. We prefer to do them from the team sysadmin.desdelinux.fan to which we gave express permission so that it can make Zone Transfers. The file / Etc / resolv.conf of that team is the following:
buzz @ sysadmin: ~ $ cat /etc/resolv.conf # Generated by NetworkManager search desdelinux.fan nameserver 192.168.10.5 buzz@sysadmin:~$ dig desdelinux.fan axfr ; <<>> DiG 9.9.5-9+deb8u1-Debian <<>> desdelinux.fan axfr ;; global options: +cmd desdelinux.fan. 10800 IN SOA dns.desdelinux.fan. root.dns.desdelinux.fan. 1 86400 3600 604800 10800 desdelinux.fan. 10800 IN NS dns.desdelinux.fan. desdelinux.fan. 10800 IN MX 10 email.desdelinux.fan. desdelinux.fan. 10800 IN TXT "DesdeLinux, your blog dedicated to Free Software" ad-dc.desdelinux.fan. 10800 IN A 192.168.10.3 blog.desdelinux.fan. 10800 IN A 192.168.10.7 dns.desdelinux.fan. 10800 IN TO 192.168.10.5 fileserver.desdelinux.fan. 10800 IN A 192.168.10.4 ftpserver.desdelinux.fan. 10800 IN A 192.168.10.8 mail.desdelinux.fan. 10800 IN A 192.168.10.9 proxyweb.desdelinux.fan. 10800 IN A 192.168.10.6 sysadmin.desdelinux.fan. 10800 IN TO 192.168.10.1 desdelinux.fan. 10800 IN SOA dns.desdelinux.fan. root.dns.desdelinux.fan. 1 86400 3600 604800 10800 ;; Query time: 0 msec ;; SERVER: 192.168.10.5#53(192.168.10.5) ;; WHEN: Sun Jan 29 11:44:18 EST 2017 ;; XFR size: 13 records (messages 1, bytes 385) buzz @ sysadmin: ~ $ dig 10.168.192.in-addr.arpa axfr ; <<>> DiG 9.9.5-9+deb8u1-Debian <<>> 10.168.192.in-addr.arpa axfr ;; global options: +cmd 10.168.192.in-addr.arpa. 10800 IN SOA dns.desdelinux.fan.10.168.192.in-addr.arpa. root.dns.desdelinux.fan.10.168.192.in-addr.arpa. 1 86400 3600 604800 10800 10.168.192.in-addr.arpa. 10800 IN NS dns.desdelinux.fan. 1.10.168.192.in-addr.arpa. 10800 IN PTR sysadmin.desdelinux.fan. 3.10.168.192.in-addr.arpa. 10800 IN PTR ad-dc.desdelinux.fan. 4.10.168.192.in-addr.arpa. 10800 IN PTR fileserver.desdelinux.fan. 5.10.168.192.in-addr.arpa. 10800 IN PTR dns.desdelinux.fan. 6.10.168.192.in-addr.arpa. 10800 IN PTR proxyweb.desdelinux.fan. 7.10.168.192.in-addr.arpa. 10800 IN PTR blog.desdelinux.fan. 8.10.168.192.in-addr.arpa. 10800 IN PTR ftpserver.desdelinux.fan. 9.10.168.192.in-addr.arpa. 10800 IN PTR mail.desdelinux.fan. 10.168.192.in-addr.arpa. 10800 IN SOA dns.desdelinux.fan.10.168.192.in-addr.arpa. root.dns.desdelinux.fan.10.168.192.in-addr.arpa. 1 86400 3600 604800 10800 ;; Query time: 0 msec ;; SERVER: 192.168.10.5#53(192.168.10.5) ;; WHEN: Sun Jan 29 11:44:57 EST 2017 ;; XFR size: 11 records (messages 1, bytes 352) buzz@sysadmin:~$ dig IN SOA desdelinux.fan buzz@sysadmin:~$ dig IN MX desdelinux.fan buzz@sysadmin:~$ dig IN TXT desdelinux.fan buzz @ sysadmin: ~ $ host dns dns.desdelinux.fan has address 192.168.10.5 buzz @ sysadmin: ~ $ host sysadmin sysadmin.desdelinux.fan has address 192.168.10.1 ... And any other checks we need
- So far, we have the basis for a DNS server on our SME network. We hope you enjoyed the whole procedure, which was pretty simple, right?
We install and configure DHCP
[root @ dns ~] # yum install dhcp
Loaded plugins: fastestmirror, centos-base langpacks | 3.4 kB 00:00:00 centos-updates | 3.4 kB 00:00:00 Loading mirror speeds from cached hostfile Resolving dependencies -> Running transaction test ---> Package dhcp.x86_64 12: 4.2.5-42.el7.centos must be installed -> Resolving dependencies terminated Resolved Dependencies ============================================= ================================================= =================================== Package Architecture Version Repository Size =========== ================================================= ================================================= ====================== Installing: dhcp x86_64 12: 4.2.5-42.el7.centos-base 511k Transaction Summary ==== ================================================= ================================================= ============================ Install 1 Package Total download size: 511k Installed size: 1.4 M Is this ok [y / d / N]: y Downloading packages: dhcp-4.2.5-42.el7.centos.x86_64.rpm | 511 kB 00:00:00 Running transaction check Running transaction test Transaction test succeeded Running transaction Installing: 12: dhcp-4.2.5-42.el7.centos.x86_64 1/1 Checking: 12: dhcp-4.2.5-42. el7.centos.x86_64 1/1 Installed: dhcp.x86_64 12: 4.2.5-42.el7.centos Done!
[root @ dns ~] # nano /etc/dhcp/dhcpd.conf
# # DHCP Server Configuration file. # see /usr/share/doc/dhcp*/dhcpd.conf.example # see dhcpd.conf(5) man page # ddns-update-style interim; ddns-updates on; ddns-domainname "desdelinux.fan."; ddns-rev-domainname "in-addr.arpa."; ignore client-updates; authoritative; option ip-forwarding off; option domain-name "desdelinux.fan"; # option ntp-servers 0.pool.ntp.org, 1.pool.ntp.org, 2.pool.ntp.org, 3.pool.ntp.org; include "/etc/dhcp.key" ; zone desdelinux.fan. { primary 127.0.0.1; key dhcp-key; } zone 10.168.192.in-addr.arpa. { primary 127.0.0.1; key dhcp-key; } shared-network redlocal { subnet 192.168.10.0 netmask 255.255.255.0 { option routers 192.168.10.1; option subnet-mask 255.255.255.0; option broadcast-address 192.168.10.255; option domain-name-servers 192.168.10.5; option netbios-name-servers 192.168.10.5; range 192.168.10.30 192.168.10.250; } } # END dhcpd.conf
[root @ dns ~] # dhcpd -t
Internet Systems Consortium DHCP Server 4.2.5 Copyright 2004-2013 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Not searching LDAP since ldap-server, ldap-port and ldap-base-dn were not specified in the config file
[root @ dns ~] # systemctl enable dhcpd
Created symlink from /etc/systemd/system/multi-user.target.wants/dhcpd.service to /usr/lib/systemd/system/dhcpd.service.
[root @ dns ~] # systemctl start dhcpd
[root @ dns ~] # systemctl status dhcpd
● dhcpd.service - DHCPv4 Server Daemon Loaded: loaded (/usr/lib/systemd/system/dhcpd.service; enabled; vendor preset: disabled) Active: active (running) since dom 2017-01-29 12:04:59 ITS T; 23s ago Docs: man: dhcpd (8) man: dhcpd.conf (5) Main PID: 2381 (dhcpd) Status: "Dispatching packets ..." CGroup: /system.slice/dhcpd.service └─2381 / usr / sbin / dhcpd -f -cf /etc/dhcp/dhcpd.conf -user dhcpd -group dhcpd --no-pid Jan 29 12:04:59 dns dhcpd [2381]: Internet Systems Consortium DHCP Server 4.2.5 Jan 29 12 : 04: 59 dns dhcpd [2381]: Copyright 2004-2013 Internet Systems Consortium. Jan 29 12:04:59 dns dhcpd [2381]: All rights reserved. Jan 29 12:04:59 dns dhcpd [2381]: For info, please visit https://www.isc.org/software/dhcp/ Jan 29 12:04:59 dns dhcpd [2381]: Not searching LDAP since ldap -server, ldap-port and ldap-base-dn were not specified in the config file Jan 29 12:04:59 dns dhcpd [2381]: Wrote 0 leases to leases file. Jan 29 12:04:59 dns dhcpd [2381]: Listening on LPF / eth0 / 52: 54: 00: 12: 17: 04 / redlocal Jan 29 12:04:59 dns dhcpd [2381]: Sending on LPF / eth0 / 52: 54: 00: 12: 17: 04 / redlocal Jan 29 12:04:59 dns dhcpd [2381]: Sending on Socket / fallback / fallback-net Jan 29 12:04:59 dns systemd [1]: Started DHCPv4 Server Daemon.
What remains to be done?
Simple. Start a Windows 7 or other client with Free Software and start testing and checking. We did it with two clients: seven.desdelinux.fan y suse-desktop.desdelinux.fan. The checks were as follows:
buzz @ sysadmin: ~ $ host seven seven.desdelinux.fan has address 192.168.10.30 buzz@sysadmin:~$ host seven.desdelinux.fan seven.desdelinux.fan has address 192.168.10.30 buzz@sysadmin:~$ dig IN TXT seven.desdelinux.fan .... ;; QUESTION SECTION: ;seven.desdelinux.fan. IN TXT ;; ANSWER SECTION: seven.desdelinux.fan. 3600 IN TXT"31b7228ddd3a3b73be2fda9e09e601f3e9"....
We rename the team "seven" to "LAGER" and reboot. After restarting the new LAGER, we check:
buzz @ sysadmin: ~ $ host seven Host seven not found: 5 (REFUSED) buzz@sysadmin:~$ host seven.desdelinux.fan Host seven.desdelinux.fan not found: 3(NXDOMAIN) buzz@sysadmin: ~ $ host lager lager.desdelinux.fan has address 192.168.10.30 buzz@sysadmin:~$host lager.desdelinux.fan lager.desdelinux.fan has address 192.168.10.30 buzz@sysadmin:~$ dig IN TXT lager.desdelinux.fan .... ;; QUESTION SECTION: ;lager.desdelinux.fan. IN TXT ;; ANSWER SECTION: lager.desdelinux.fan. 3600 IN TXT"31b7228ddd3a3b73be2fda9e09e601f3e9"....
Regarding the suse-desktop client:
buzz @ sysadmin: ~ $ host suse-dektop Host suse-dektop not found: 5 (REFUSED) buzz @ sysadmin: ~ $ host suse-desktop suse-desktop.desdelinux.fan has address 192.168.10.33 buzz@sysadmin:~$ host suse-desktop.desdelinux.fan suse-desktop.desdelinux.fan has address 192.168.10.33 buzz @ sysadmin: ~ $ host 192.168.10.33 33.10.168.192.in-addr.arpa domain name pointer suse-desktop.desdelinux.fan. buzz @ sysadmin: ~ $ host 192.168.10.30 30.10.168.192.in-addr.arpa domain name pointer LAGER.desdelinux.fan.
buzz @ sysadmin: ~ $ dig -x 192.168.10.33 .... ;; QUESTION SECTION: ;33.10.168.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 33.10.168.192.in-addr.arpa. 3600 IN PTR suse-desktop.desdelinux.fan. ;; AUTHORITY SECTION: 10.168.192.in-addr.arpa. 10800 IN NS dns.desdelinux.fan. ;; ADDITIONAL SECTION: dns.desdelinux.fan. 10800 IN TO 192.168.10.5 .... buzz@sysadmin:~$ dig IN TXT suse-desktop.desdelinux.fan.... ;suse-desktop.desdelinux.fan. IN TXT ;; ANSWER SECTION: suse-desktop.desdelinux.fan. 3600 IN TXT "31b78d287769160c93e6dca472e9b46d73" ;; AUTHORITY SECTION: desdelinux.fan. 10800 IN NS dns.desdelinux.fan. ;; ADDITIONAL SECTION: dns.desdelinux.fan. 10800 IN TO 192.168.10.5 ...
Let's also run the following commands
[root@dns ~]# dig desdelinux.fan axfr ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.4 <<>> desdelinux.fan axfr ;; global options: +cmd desdelinux.fan. 10800 IN SOA dns.desdelinux.fan. root.dns.desdelinux.fan. 6 86400 3600 604800 10800 desdelinux.fan. 10800 IN NS dns.desdelinux.fan. desdelinux.fan. 10800 IN MX 10 email.desdelinux.fan. desdelinux.fan. 10800 IN TXT "DesdeLinux, your blog dedicated to Free Software" ad-dc.desdelinux.fan. 10800 IN A 192.168.10.3 blog.desdelinux.fan. 10800 IN A 192.168.10.7 dns.desdelinux.fan. 10800 IN TO 192.168.10.5 fileserver.desdelinux.fan. 10800 IN A 192.168.10.4 ftpserver.desdelinux.fan. 10800 IN A 192.168.10.8 LAGER.desdelinux.fan. 3600 IN TXT"31b7228ddd3a3b73be2fda9e09e601f3e9"LAGER.desdelinux.fan. 3600 IN A 192.168.10.30 email.desdelinux.fan. 10800 IN A 192.168.10.9 proxyweb.desdelinux.fan. 10800 IN A 192.168.10.6 suse-desktop.desdelinux.fan. 3600 IN TXT"31b78d287769160c93e6dca472e9b46d73" suse-desktop.desdelinux.fan. 3600 IN A 192.168.10.33 sysadmin.desdelinux.fan. 10800 IN TO 192.168.10.1 desdelinux.fan. 10800 IN SOA dns.desdelinux.fan. root.dns.desdelinux.fan. 6 86400 3600 604800 10800
In the output above, we highlighted on bold TTL -in seconds- for the computers with IP addresses granted by the DHCP service, those that have an explicit declaration of the TTL 3600 given by the DHCP. Fixed IPs are guided by the $ TTL of 3H -3 hours = 10800 seconds- declared in the SOA record of each zone file.
They can check the reverse zone in the same way.
[root @ dns ~] # dig 10.168.192.in-addr.arpa axfr
Other extremely interesting commands are:
[root@dns ~]# named-journalprint /var/named/dynamic/db.desdelinux.fan.jnl [root @ dns ~] # named-journalprint /var/named/dynamic/db.10.168.192.in-addr.arpa.jnl [root @ dns ~] # journalctl -f
Manual modification of Zones files
After DHCP comes into play of dynamically updating the zone files of the namedIf at any time we need to manually modify a zone file, we must carry out the following procedure, but not before knowing a little more about the operation of the utility rndc for name server control.
[root @ dns ~] # man rndc
...
freeze [zone [class [view]]]
Suspend updates to a dynamic zone. If no zone is specified, then all zones are suspended. This allows manual edits to be made to a zone normally updated by dynamic update. It also causes changes in the journal file to be synced into the master file. All dynamic update attempts will be refused while the zone is frozen.
thaw [zone [class [view]]]
Enable updates to a frozen dynamic zone. If no zone is specified, then all frozen zones are enabled. This causes the server to reload the zone from disk, and re-enables dynamic updates after the load has completed. After a zone is thawed, dynamic updates will no longer be refused. If the zone has changed and the ixfr-from-differences option is in use, then the journal file will be updated to reflect changes in the zone. Otherwise, if the zone has changed, any existing journal file will be removed. ....
What, did you think I was going to transcribe the whole manual?… a piece and you're off to the car. I'll leave the rest to you.
Basically:
- rndc freeze [zone [class [view]]], suspends the dynamic update of a zone. If one is not specified, all will freeze. The command allows manual editing of the frozen zone or all zones. Any dynamic update will be denied while frozen.
- rndc thaw [zone [class [view]]], enables dynamic updates on a previously frozen zone. The DNS server reloads the zone file from disk, and dynamic updates are re-enabled after the reload is complete.
Cautions to be taken when we manually edit a zone file? The same as if we were creating it, without forgetting to increase the serial number by 1 or serial before saving the file with the final changes.
Example:
[root @ dns ~] # rndc freeze desdelinux.fan
[root@dns ~]# nano /var/named/dynamic/db.desdelinux.fan
I modify the zone file for any reason, necessary or not. I save the changes
[root @ dns ~] # rndc thaw desdelinux.fan
A zone reload and thaw was started. Check the logs to see the result.
[root @ dns ~] # journalctl -f
Jan 29 14:06:46 dns named[2257]: thawing zone 'desdelinux.fan/IN': success
Jan 29 14:06:46 dns named[2257]: zone desdelinux.fan/IN: zone serial (6) unchanged. zone may fail to transfer to slaves.
Jan 29 14:06:46 dns named[2257]: zone desdelinux.fan/IN: loaded serial 6
The error in the previous output, which appears in red on the console, is due to the fact that I "forgot" to increase the serial number by 1. If I had followed the procedure correctly, the output would have been:
[root @ dns ~] # journalctl -f -- Logs begin at Sun 2017-01-29 08:31:32 EST. -- Jan 29 14:06:46 dns named[2257]: zone desdelinux.fan/IN: loaded serial Jan 6 29 14:10:01 dns systemd[1]: Started Session 43 of user root. Jan 29 14:10:01 dns systemd[1]: Starting Session 43 of user root. Jan 29 14:10:01 dns CROND[2693]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jan 29 14:10:45 dns named[2257]: received control channel command 'freeze desdelinux.fan' Jan 29 14:10:45 dns named[2257]: freezing zone 'desdelinux.fan/IN': success Jan 29 14:10:58 dns named[2257]: received control channel command 'thaw desdelinux.fan' Jan 29 14:10:58 dns named[2257]: thawing zone 'desdelinux.fan/IN': success Jan 29 14:10:58 dns named[2257]: zone desdelinux.fan/IN: journal file is out of date: removing journal file Jan 29 14:10:58 dns named[2257]: zone desdelinux.fan/IN: loaded serial 7
- Reader friends, I repeat that you have to read the command outputs carefully. For something its developers spent so much work programming each command, no matter how simple it is.
Summary
So far we have addressed the implementation of the DNS - DHCP pair, important and crucial services for the good performance of our SME Network, referring to the granting of dynamic addresses through DHCP and the resolution of computer and domain names through DNS.
We seriously hope you enjoyed the entire procedure as we did. Although it may seem more difficult using the console, it is much easier and more educational to implement a service in UNIX® / Linux with its help.
Please forgive me for any misinterpretation of concepts thought, created, written, revised, rewritten, and published in the language of Shakespeare, not Cervantes.
Next delivery
I think a little more of the same - with theoretical additions on DNS records - but in Debian. We can't forget that distribution, right?