DNS and DHCP in CentOS 7 - SMB Networks

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 Cricket Liu, 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.fromlinux.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:

  • In the 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:

DNS and DHCP on CentOS

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.fromlinux.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 from linux.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 contents of the original declaration files from 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 (Name Daemon). 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: active (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: active (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, expensive, and demanding Reader: if you want to find out -at least- which path leads to the end of the rabbit hole, please calmly read the detailed outputs of each command. 😉 Surely the article will seem a bit long, but do not 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 maintainers of different Linux distributions have, of placing 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«. 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 as 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 mired {
 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;
 //};
    // forward first;

    // I only allow queries to my mired ACL
    allow-query {mired; }; // To check with the command dig 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 no;

    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
zone "desdelinux.fan" {
 type master;
 file "dynamic / db.fromlinux.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; };
};

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 from linux.fan/IN: loading from master file dynamic / db.fromlinux.fan failed: file not found zone fromlinux.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 from linux.fan

... not without a bit of theory first. 😉

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.

minimun: 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 caching 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.fromlinux.fan

[root @ dns ~] # nano /var/named/dynamic/db.fromlinux.fan
$ TTL 3H @ IN SOA dns.fromlinux.fan. root.dns.fromlinux.fan. (1; serial 1D; refresh 1H; retry 1W; expire 3H); minimum or; Negative caching time to live; @ IN NS dns.fromlinux.fan. @ IN MX 10 mail.fromlinux.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 mail IN A 192.168.10.9

We check /var/named/dynamic/db.fromlinux.fan

[root @ dns ~] # named-checkzone from linux.fan /var/named/dynamic/db. fromlinux.fan
zone from linux.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.fromlinux.fan. root.dns.fromlinux.fan. (1; serial 1D; refresh 1H; retry 1W; expire 3H); minimum or; Negative caching time to live; @ IN NS dns.fromlinux.fan. ; 1 IN PTR sysadmin.fromlinux.fan. 3 IN PTR ad-dc.fromlinux.fan. 4 IN PTR fileserver.fromlinux.fan. 5 IN PTR dns.fromlinux.fan. 6 IN PTR proxyweb.desdelinux.fan. 7 IN PTR blog.desdelinux.fan. 8 IN PTR ftpserver.fromlinux.fan. 9 IN PTR mail.fromlinux.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 from linux.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 from linux.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 {"mired"; }; allow-transfer {192.168.10.1/32; }; }; acl "mired" {127.0.0.0/8; 192.168.10.0/24; }; logging {channel "default_debug" {file "data / named.run"; severity dynamic; }; }; 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.fromlinux.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 {"." key initial-257 August 3 "AwEAAagAIKlVZrpC8Ia6gEzahOR + 7W9euxhJhVVLOyQbSEW29O0gcCjF FVQUTf8v6fLjwBd58YI0EzrAcQqBGCzh / RStIoO0g8NfnfL0MTJRkxoX bfDaUeVPQuYEhg2NZWAJQ37VnMVDxP / VHL9M / QZxkjf496 / Efucp5gaD X2RS6CXpoY6LsvPVjR68ZSwzz0apAzvN1dlzEheX9ICJBBtuA7G6LQpz W3hOA5hzCTMjJPJ2LbqF8dsV6DoBQzgul6sGIcGOYl0OyQdXfZ7relS Qageu + ipAdTTJ57AsRTAoub25ONGcLmqrAmRLKBP8dfwhYB1N4knNnulq QXA + Uk7ihz1 ="; };
  • 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 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 0 Jan 29 10:05:32 dns named [1791]: zone 10.168.192.in-addr.arpa/IN: loaded serial 1 Jan 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 1 Jan 29 10:05:32 dns named [1791]: zone localhost.localdomain / IN: loaded serial 0 Jan 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]:  
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.fromlinux.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 from linux.fan nameserver 192.168.10.5

buzz @ sysadmin: ~ $ dig from linux.fan axfr
; << >> DiG 9.9.5-9 + deb8u1-Debian << >> desdelinux.fan axfr ;; global options: + cmd from linux.fan. 10800 IN SOA dns.fromlinux.fan. root.dns.fromlinux.fan. 1 86400 3600 604800 10800 from linux.fan. 10800 IN NS dns.fromlinux.fan. from linux.fan. 10800 IN MX 10 mail.fromlinux.fan. from linux.fan. 10800 IN TXT "FromLinux, 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.fromlinux.fan. 10800 IN A 192.168.10.5 fileserver.fromlinux.fan. 10800 IN A 192.168.10.4 ftpserver.fromlinux.fan. 10800 IN A 192.168.10.8 mail.fromlinux.fan. 10800 IN A 192.168.10.9 proxyweb.fromlinux.fan. 10800 IN A 192.168.10.6 sysadmin.fromlinux.fan. 10800 IN To 192.168.10.1 from linux.fan. 10800 IN SOA dns.fromlinux.fan. root.dns.fromlinux.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.fromlinux.fan.10.168.192.in-addr.arpa. root.dns.fromlinux.fan.10.168.192.in-addr.arpa. 1 86400 3600 604800 10800 10.168.192.in-addr.arpa. 10800 IN NS dns.fromlinux.fan. 1.10.168.192.in-addr.arpa. 10800 IN PTR sysadmin.fromlinux.fan. 3.10.168.192.in-addr.arpa. 10800 IN PTR ad-dc.fromlinux.fan. 4.10.168.192.in-addr.arpa. 10800 IN PTR fileserver.fromlinux.fan. 5.10.168.192.in-addr.arpa. 10800 IN PTR dns.fromlinux.fan. 6.10.168.192.in-addr.arpa. 10800 IN PTR proxyweb.fromlinux.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.fromlinux.fan. 9.10.168.192.in-addr.arpa. 10800 IN PTR mail.fromlinux.fan. 10.168.192.in-addr.arpa. 10800 IN SOA dns.fromlinux.fan.10.168.192.in-addr.arpa. root.dns.fromlinux.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 from linux.fan
buzz @ sysadmin: ~ $ dig IN MX from linux.fan buzz @ sysadmin: ~ $ dig IN TXT from linux.fan
buzz @ sysadmin: ~ $ host dns
dns.fromlinux.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 in our SME network. We hope you enjoyed the entire procedure, which was quite 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 from linux.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.fromlinux.fan y suse-desktop.fromlinux.fan. The checks were as follows:

buzz @ sysadmin: ~ $ host seven
seven.fromlinux.fan has address 192.168.10.30

buzz @ sysadmin: ~ $ host seven.fromlinux.fan
seven.fromlinux.fan has address 192.168.10.30

buzz @ sysadmin: ~ $ dig IN TXT seven.fromlinux.fan
.... ;; QUESTION SECTION:; seven.fromlinux.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.fromlinux.fan
Host seven.desdelinux.fan not found: 3 (NXDOMAIN)

buzz@sysadmin: ~ $ host lager
lager.fromlinux.fan has address 192.168.10.30

buzz@sysadmin: ~ $ host lager.fromlinux.fan
lager.fromlinux.fan has address 192.168.10.30

buzz @ sysadmin: ~ $ dig IN TXT lager.fromlinux.fan
.... ;; QUESTION SECTION:; lager.fromlinux.fan. IN TXT ;; ANSWER SECTION: lager.fromlinux.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.fromlinux.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.fromlinux.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.fromlinux.fan. ;; AUTHORITY SECTION: 10.168.192.in-addr.arpa. 10800 IN NS dns.fromlinux.fan. ;; ADDITIONAL SECTION: dns.fromlinux.fan. 10800 IN A 192.168.10.5 ....

buzz @ sysadmin: ~ $ dig IN TXT suse-desktop.fromlinux.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.fromlinux.fan. ;; ADDITIONAL SECTION: dns.fromlinux.fan. 10800 IN A 192.168.10.5
.

Let's also run the following commands

[root @ dns ~] # dig from linux.fan axfr
; << >> DiG 9.9.4-RedHat-9.9.4-29.el7_2.4 << >> desdelinux.fan axfr ;; global options: + cmd from linux.fan. 10800 IN SOA dns.fromlinux.fan. root.dns.fromlinux.fan. 6 86400 3600 604800 10800 from linux.fan. 10800 IN NS dns.fromlinux.fan. from linux.fan. 10800 IN MX 10 mail.fromlinux.fan. from linux.fan. 10800 IN TXT "FromLinux, 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.fromlinux.fan. 10800 IN A 192.168.10.5 fileserver.fromlinux.fan. 10800 IN A 192.168.10.4 ftpserver.fromlinux.fan. 10800 IN A 192.168.10.8 LAGER.fromlinux.fan. 3600 IN TXT "31b7228ddd3a3b73be2fda9e09e601f3e9"LAGER.fromlinux.fan.   3600 IN A 192.168.10.30 mail.fromlinux.fan. 10800 IN A 192.168.10.9 proxyweb.fromlinux.fan. 10800 IN A 192.168.10.6 suse-desktop.fromlinux.fan. 3600 IN TXT "31b78d287769160c93e6dca472e9b46d73"suse-desktop.desdelinux.fan. 3600 IN A 192.168.10.33 sysadmin.fromlinux.fan. 10800 IN To 192.168.10.1 from linux.fan. 10800 IN SOA dns.fromlinux.fan. root.dns.fromlinux.fan. 6 86400 3600 604800 10800

In the output above, we highlighted on bold that 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 they go by car. The rest I leave it 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 from linux.fan

[root @ dns ~] # nano /var/named/dynamic/db.fromlinux.fan
I modify the zone file for any reason, necessary or not. I save the changes

[root @ dns ~] # rndc thaw from linux.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 from linux.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 6 Jan 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) Jan 1 29:14:10 dns named [45]: received control channel command 'freeze from linux. fan 'Jan 2257 29:14:10 dns named [45]: freezing zone' desdelinux.fan/IN ': success Jan 2257 29:14:10 dns named [58]: received control channel command' thaw desdelinux.fan 'Jan 2257 29:14:10 dns named [58]: thawing zone 'desdelinux.fan/IN': success Jan 2257 29:14:10 dns named [58]: zone desdelinux.fan/IN: journal file is out of date: removing journal file Jan 2257 29:14:10 dns named [58]: zone desdelinux.fan/IN: loaded serial 2257
  • 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.

Your Order

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.

They 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?


The content of the article adheres to our principles of editorial ethics. To report an error click here!.

15 comments, leave yours

Leave a Comment

Your email address will not be published. Required fields are marked with *

*

*

  1. Responsible for the data: Miguel Ángel Gatón
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.

  1.   Cristian Merchan said

    Thank you very much for your commendable work in writing such fruitful articles. It will be of much use to me

  2.   federico said

    And thank you very much, Cristian, for following me and for your assessment of this post. Successes!

  3.   Ismael Alvarez Wong said

    After having made a first look at this new post by Federico, the great professionalism seen throughout the «PYMES» series is once again noticeable; in addition to the great detail that illustrates your domain on two of the most important services (DNS and DHCP) of any network. On this occasion and unlike my previous comments, I have a 2nd comment pending after having put into practice what I have stated in this post.

  4.   crespo88 said

    No comments, pa '400 !!! Fico thank you because you know very well that I read your posts and we cannot ask for more. You start with a very good organization, from how to install and set the personal desktop of a user, the workstation is the base, it is the sense of being of those network services that you explain very well. You have been climbing and although it is true that the level is increasing, it is true that you have written and published for those who are less than those who are starting, for those who have been like me for some time and for the most advanced.
    Over time I have come to the conclusion that I know many have already arrived, the theory, the one that costs us so much to acquire for the simple fact of not wanting to read, because executing is already much easier when we know what we are doing, why ???, the questions, where to find and how to get out of the error that gives so much headache when we don't even know where they come from, worth the redundancy.
    For this reason, I do not want you to leave behind those theoretical elements that you will include about DNS records in the next publication as you announced, much less when it comes to the dear and beloved DEBIAN.
    THANK YOU VERY MUCH and we are waiting.

  5.   dhunter said

    Excellent as always Fico! I wait for the Debian version, I have been playing everything with that distro for years.

  6.   federico said

    Wong: Your opinion after reading is worth a lot. I await your comments when you test the content, because I know that is how you like to do it. 😉

  7.   federico said

    Crespo: As always, your comments are very well received. I see that you have captured the general line that I have raised in the composition of this series. I hope that, like you, many have already noticed. Thanks for your comment.

  8.   federico said

    Dhunter: Good to read you again! You won't have to wait long. By Monday at the latest -or before- it will be finished for publication. Do not think that it is easy for me to cover three different distros, but the Respectable Reader, asks for it. Not only Debian and Ubuntu, but the Three Oriented to SMEs.

  9.   crespo88 said

    If you have published, it is because you can, we support you and we know that you will follow that line.
    As a dhunter I wait for the Debian release with sharp teeth. It would be nice if you covered a little bit about NTP. Sl2 and a big hug. If my teachers had taught me everything like that, HAHAJJA, Platinum Degree, HAHAJJA.

  10.   federico said

    The level of detail in command outputs is necessary to show its importance. They say a lot. It is true that few articles address this level of detail, because they think that they would be long and heavy articles to read. Well, part of a SysAdmin's job is to read those heavy and detailed outputs, not just in the face of a problem, but also in the face of checks.

  11.   Ismael Alvarez Wong said

    Hello Federico, I had promised before, to write some comments after having carefully studied the post in question; Well, here they go next:
    - Great technique of instead of generating the TSIG key for dynamic DNS updates by DHCP, copying the same rndc.key key as dhcp.key, this apparently "so simple" shows that the goal is not only the technicality of the HOWTO-INSTALL-DNS - & - DHCP but teaching us to think, 5 STARS FOR THE AUTHOR.
    - Very interesting in the DNS configuration file, named.conf, the presence of the line «allow-transfer {localhost; 192.168.10.1; }; » to test the Domain «desdelinux.fan» only from the SysAdmin workstation and the localhost (the DNS server itself), and also insert the TSIG key to update the DNS from DHCP.
    - Very good the creation of the direct and inverse zones of the DNS together with the "detailed" explanation of their types of records, in addition to the execution of the command "# named-checkconf -zp" to check all the syntax of the named before its hard reset, as well as examples of running the "dig" command to verify different types of DNS records.
    . In the DHCP configuration (using the /etc/dhcp/dhcpd.conf file):
    - How to add our local network with its range for dynamic IP addresses to assign, the definition of the name-server, etc; as well as how to tell DHCP to update the DNS records through the use of the "ddns- ..." lines in its configuration.
    . When everything is already operational, 5 STARS FOR THE AUTHOR, in the execution of the command "# dig desdelinux.fan axfr" to check the TTL of the computers on the LAN that have static IP of those that have dynamic IP assigned.
    . Finally, GREAT, the manual modification of Zones files by freezing them first with "# rndc freeze desdelinux.fan", then making the modification and finally unfreezing them with "# rndc thaw desdelinux.fan"
    . AND THE BEST, EVERYTHING WAS DONE FROM THE TERMINAL.
    Keep it up Fico.

    1.    Joy said

      Hallo,
      Ik kom net kijken, dit omdat ik probeer te achterhalen hoe het kan dat alles gedeeld en verwijderd wordt op mijn computer zelfs mijn foto's. Ik heb totaal geen control meer over mijn eigen computer on mobiel.
      Het zit m dus ook in het dns in dhcp. Ik weet echt niet hoe ik dit moet oplossen en het kan verwijderen. Misschien dat iemand mij wilt helpen? Dit is namelijk buiten mij om geinstalleerd. Walgelijk gedrag vind ik het.

  12.   federico said

    Wong: your comment complements the article. Seriously, it shows that you have studied it thoroughly. Otherwise, you could not comment with the level of detail that you do. Just add that allow-transfer It is used mainly for when we have a DNS Slave and we allow the transfer of zones from the master to it. I use it that way because it's an easy-to-implement mechanism for doing non-dangerous checks from a single computer. Thank you very much for your 5 rating. Greetings! and I will keep waiting for you in my next articles.

  13.   IgnacioM said

    Hello Federico. I know I am a little late, but I would like to ask you a question.
    Would this procedure help me if I want to point a domain to my vps server?

    Every 15 minutes I get these system messages:

    DHCPREQUEST on eth0 to port 67 (xid =…)
    DHCPACK from (xid =…)
    bound to - renewal in 970 seconds.

    And from what I understand I should create an A record with my domain and the ip of my dedicated server.

    * I congratulate you and thank you for this article, I don't know if it is what I was looking for but I found it very interesting and well explained. In addition I take the recommendation of "DNS and BIND" that I have already been gossiping a bit and it seems very interesting.

    Greetings from Argentina!

    1.    antonio valdes toujague said

      please contact me through valdestoujague@yandex.com