Skip to Main Content
Forums

Administering Oracle Linux 7.2: Part 1 — Configuring a Time Server and Kerberos

Javed A Mohammed-OracleAug 2 2016 — edited Aug 26 2016

by Alexandre Borges

This article is Part 1 of a series that explains how to administer Oracle Linux 7.2. This article focuses on how to configure a Network Time Protocol (NTP) client/server and Kerberos on Oracle Linux 7.2.

Introduction

This article explains how to configure a Kerberos server. Kerberos is a frequently used authentication framework, and it is almost omnipresent in the Microsoft world through the Microsoft Active Directory service. We will have a nice journey, because we will have a chance to manage and keep in touch with details about how Kerberos is working and explore a few respective concepts, most of which are related to cryptography (symmetric keys).

Kerberos, as a network authentication protocol and framework, brings us excellent advantages and features when handling authentication. For example, at beginning of the day, users can log into a Kerberos server to get credentials that will be used to access applications all day long, without any of these applications asking users to enter a username and password. This is known as single sign-on (SSO).

During the process mentioned above, Kerberos helps us by providing authentication without passing any passwords through the network, thus preventing hackers from stealing passwords by monitoring the network. It's also possible to get remote authentication without incurring any unnecessary risks.

One of main support services of Kerberos is a time server, which provides the clock time that is indirectly inserted into a packet for checking the packet's authentication and to prevent replay attacks. So we will review Network Time Protocol (NTP)l concepts and chronyd server configuration procedures before delving into the Kerberos setup.

Note: Before starting, note the following very important information:

  • The myoracle4.example.com host (192.168.1.91) will be our Kerberos and DNS server.
  • The myoracle5.example.com host (192.168.1.92) will be our client.
  • The myoracle6.example.com host (192.168.1.93) will be our second SSH server.

Configuring a Time Server

On a system, and even in our daily life, there are several areas where time is fundamental. For example, every time that we make a bank transaction, the bank system registers our operation into their database together the time when the transaction happens. Another similar example occurs during the administration of a system where important tasks are logged by a central daemon and all registers are entered into either a database or a file followed by their respective time of occurrence. Other examples where time is fundamental include encryption and services.

Kerberos is a service that uses time as a reference to authenticate users, and if the client system is not synchronized with the time server, the user is not able to accomplish the authentication. Later, we will see a clever technique that helps the system to prevent passing a password over the network.

NTP is a client/server service in which there are hosts (clients systems) that need accurate time (client systems use the time in databases, logging systems, encryption, and so on) and a server that provides the time. Usually, client systems use the NTP protocol (port 123/UDP) to get accurate time information from either a private NTP server (deployed inside a company and less reliable) or a public NTP server (offered by very reliable organizations through which the time is provided from either a GPS or atomic source, for example).

Usually, system administrators install some private NTP servers inside their company, which provide time to their client systems and services, but these private servers fetch a precise and accurate time from a public pool (group) of NTP servers. (For North America, this pool is found at http://www.pool.ntp.org/zone/north-america, and for United States the pool is described at http://www.pool.ntp.org/zone/us.) It is interesting to note that if your company has stable and not-overloaded bandwidth, your servers can become part of the public NTP pool (more information can be found on http://www.pool.ntp.org/en/join.html).

Thus, the final NTP schema for a company could be the following:

NTP clients -> Private NTP servers -> Public NTP server pool

NTP concepts are sophisticated and you should know that NTP servers are classified by "stratum" levels (0 to 15) according to various criteria that indicate their time accuracy and reliability (more information is available at http://www.ntp.org/ntpfaq/NTP-s-algo.htm). Lower stratum levels offer more-accurate time; stratum 0 is known as the reference clock.

Before configuring Kerberos, we will configure a local NTP service, and we will be use two systems (myoracle4 and myoracle5) as the server and client, respectively. A simple schema will be shown here, because the main purpose is to explain the concepts and show how to configure an NTP environment.

The first step for configuring an NTP service is to get the current time information on either system, as shown in Listing 1:

[root@myoracle5 ~]# timedatectl

      Local time: Mon 2015-04-20 18:50:12 BRT

  Universal time: Mon 2015-04-20 21:50:12 UTC

        RTC time: Mon 2015-04-20 21:50:12

        Timezone: America/Sao_Paulo (BRT, -0300)

     NTP enabled: yes

NTP synchronized: yes

RTC in local TZ: no

      DST active: no

Last DST change: DST ended at

                  Sat 2015-02-21 23:59:59 BRST

                  Sat 2015-02-21 23:00:00 BRT

Next DST change: DST begins (the clock jumps one hour forward) at

                  Sat 2015-10-17 23:59:59 BRT

                  Sun 2015-10-18 01:00:00 BRST

Listing 1

Listing 1 shows the following information:

  • Local time is BRT (Brasilia Summer Time) in my location; all abbreviations are available at https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations.
  • Universal time is the primary time standard by which the world regulates clocks and time (Coordinated Universal Time [UTC]).
  • RTC time is the RTC (real-time clock) provided by an internal circuit on the computer, which includes a battery that keeps track of the time even when the machine is turned off.
  • Timezone is the region that observes the time for commercial, social, and legal purposes. A list is available at https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).
  • NTP enabled indicates whether this host is fetching time from an NTP server.
  • NTP synchronized indicates whether the local time is synchronized with an NTP server.
  • RTC in local TZ indicates whether the RTC time is maintained in local time. If the value of this field is no, the RTC time is maintained in UTC.
  • DST active indicates whether Daylight Saving Time (DST) is active in the current location.
  • Last DST change is the last time when DST was in effect.
  • Next DST change indicates the next period when DST will be in effect.

In this case, the time zone is Sao Paulo, but you can list all time zones by running the command in Listing 2:

[root@myoracle5 ~]# timedatectl list-timezones

Africa/Abidjan

Africa/Accra

Africa/Addis_Ababa

Africa/Algiers

Africa/Asmara

...

Listing 2

For example, if you have to change the time zone to America/New_York, execute these commands:

[root@myoracle5 ~]# timedatectl set-timezone America/New_York

[root@myoracle5 ~]# timedatectl

      Local time: Mon 2015-04-20 18:04:37 EDT

  Universal time: Mon 2015-04-20 22:04:37 UTC

        RTC time: Mon 2015-04-20 22:04:37

        Timezone: America/New_York (EDT, -0400)

     NTP enabled: yes

NTP synchronized: yes

RTC in local TZ: no

      DST active: yes

Last DST change: DST began at

                  Sun 2015-03-08 01:59:59 EST

                  Sun 2015-03-08 03:00:00 EDT

Next DST change: DST ends (the clock jumps one hour backwards) at

                  Sun 2015-11-01 01:59:59 EDT

                  Sun 2015-11-01 01:00:00 EST

Two Linux services that are able to provide time services are ntpd (from Oracle Linux 6) and chronyd (from Oracle Linux 7). Because chronyd is installed by default on Oracle Linux 7 and it is the recommended clock service to be use, I am using it in this article.

The first step is to check whether the public pools of NTP servers are available and reachable (there is a good NTP server list at http://www.pool.ntp.org/zone/@). We need these pools of NTP servers to provide time to our local NTP server to make the time more accurate.

Therefore, having the list of the public NTP server pools (for example, we can use a pool for Brazil; see http://www.pool.ntp.org/zone/br), we are able to verify the availability of the servers by running the command shown in Listing 3:

[root@myoracle4 ~]# ntpdate -q 1.br.pool.ntp.org

server 200.129.0.46, stratum 2, offset -0.005986, delay 0.08086

server 200.189.40.8, stratum 2, offset -0.004017, delay 0.04520

server 200.160.0.8, stratum 2, offset -0.008282, delay 0.04192

server 200.192.232.8, stratum 2, offset -0.003690, delay 0.06099

20 Apr 19:53:34 ntpdate[6220]: adjust time server 200.160.0.8 offset -0.008282 sec

Listing 3

In Listing 3, the option -q means "query only" so the time has not been set. Another interesting fact is that different servers from the pool answered our request, and they informed us of their IP addresses, stratum level, and eventual delay.

Each pool is back-ended by several NTP servers (as shown in Listing 3) and the recommendation is to use at least three aliases from the same pool. In fact, it is preferable to configure four servers closest your country, as mentioned in this reference, for example:

0.br.pool.ntp.org

1.br.pool.ntp.org

2.br.pool.ntp.org

3.br.pool.ntp.org

We could repeat the procedure using similar commands with continental NTP pools (for example, the South America pools) by running the command below:

[root@myoracle4 ~]# ntpdate -q 0.south-america.pool.ntp.org

server 190.181.129.115, stratum 2, offset -0.000690, delay 0.19424

server 200.160.7.186, stratum 1, offset -0.007801, delay 0.04253

server 66.60.22.202, stratum 4, offset -0.006213, delay 0.29182

server 190.139.102.146, stratum 3, offset 0.046463, delay 0.18404

20 Apr 19:54:23 ntpdate[6235]: adjust time server 200.160.7.186 offset -0.007801 sec

In this case, when using continental servers, we also need to point to at least three servers aliases (preferable four) from the same pool, as shown below:

0.south-america.pool.ntp.org

1.south-america.pool.ntp.org

2.south-america.pool.ntp.org

3.south-america.pool.ntp.org

Instead of using the old NTP service (ntpd), which it still present in Oracle Linux 7, we must use the new chronyd service to keep updated time on the system. As mentioned earlier, the chronyd service is the recommend method for providing accurate time for applications and other services on Oracle Linux 7.We should use the ntpd service only when there is no chronyd service installed on the host. A few advantages of chronyd are that it supports intermittent internet connections and it keeps track of the computer's local clock offset compared to the remote public NTP servers to fix its time while the computer is not connected to the internet. chronyd is very accurate (down to about microseconds).

To configure the chronyd server, the first step is to change the /etc/chronyd.conf file to include the chosen NTP servers, according our previous discussion and as shown below:

[root@myoracle4 ~]# cat /etc/chrony.conf| grep '^server'

server 0.br.pool.ntp.org

server 1.br.pool.ntp.org

server 2.br.pool.ntp.org

server 3.br.pool.ntp.org

Once more, we should remember that is recommended to include at least three aliases to the same pool.

Before proceeding, it would be nice to check whether the chrony package is installed (it should be) by running the following command:

[root@myoracle4 ~]# rpm -qa | grep chrony

chrony-2.1.1-1.el7.x86_64

Now, enable and start the chronyd service by running these commands:

[root@myoracle4 ~]# systemctl enable chronyd.service

ln -s '/usr/lib/systemd/system/chronyd.service' '/etc/systemd/system/multi-user.target.wants/chronyd.service'

[root@myoracle4 ~]# systemctl start chronyd

Sometimes, it takes times for the initial synchronization to occur.  We can accelerate the process by executing the ntpdate command with one of sources, as shown below:

[root@myoracle4 ~]# ntpdate -q 0.br.pool.ntp.org

server 192.99.2.8, stratum 2, offset -0.001648, delay 0.19318

server 201.49.148.135, stratum 1, offset -0.003443, delay 0.05640

server 200.160.7.193, stratum 1, offset -0.001256, delay 0.03940

3 Feb 04:14:46 ntpdate[3661]: adjust time server 200.160.7.193 offset -0.001256 sec

To verify that our local clock server is synchronizing to the public NTP pool of servers, execute the command shown in Listing 4:

[root@myoracle4 ~]# chronyc sources

210 Number of sources = 4

MS Name/IP address         Stratum Poll Reach LastRx Last sample

===============================================================================

^+ c.ntp.br                      2   6    77    10  -5913us[-6964us] +/-   38ms

^- time100.stupi.se              1   6    77     7  -9494us[-9494us] +/-  123ms

^* b.st1.ntp.br                  1   6    77     9  +1033us[  -19us] +/-   17ms

^- aprihop.cdknnjln.sodtech.     2   6    37    74  +1535us[+1909us] +/-   98ms

Listing 4

The meaning of each column in Listing 4 is as follows:

  • M: Tells us the mode of the remote server (source), where ^ means a server, = means a peer, and # means a locally connected reference clock.

  • S: Indicates the source of the remote servers, where:

    * means the source to which chronyd is currently synchronized.

    + indicates another acceptable source.

    - indicates an acceptable source that was excluded by the algorithm.

    ? indicates that connectivity was lost.

    x means that the clock is a false clock when compared to the majority of other sources.

    ~ means that the source appears to be volatile (too much variability and changing its time very often).

  • Name/IP address: Shows the IP address or name of the remote clock server (source).

  • Stratum: Shows the stratum level of the source. When analyzing the output in Listing 4, here is a very interesting point: if the stratum level of the remote server (source) is 2, our stratum level must be 3 (it's always the source stratum level + 1).

  • Poll: Means the rate at which the remote server (source) is being polled. In this case, 10 means 2^10 (1024) seconds.

  • Reach: An octal number that shows the reach register (8 bits) of the remote server. It is updated on every received or missed packet from the remote server. For example, 377 means that a valid reply was received for all of the last eight transmissions.

  • LastRx:  Indicates how long ago the last update was received from the remote server.

  • Last sample: Shows the offset time between the local clock server and the remote clock server (source).

To gather statistics from the remote clock servers (sources), execute the command shown in Listing 5:

[root@myoracle4 ~]# chronyc sourcestats -v

210 Number of sources = 4

                             .- Number of sample points in measurement set.

                            /      .- Number of residual runs with same sign.

                           |     /      .- Length of measurement set (time).

                           |    |     /      .- Est. clock freq error (ppm).

                           |    |    |      /           .- Est. error in freq.

                           |    |    |     |           /         .- Est. offset.

                           |    |    |     |           |         |   On the -.

                           |    |    |     |           |         |   samples. \

                           |    |    |     |           |         |            /

Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev

==============================================================================

c.ntp.br                    6   5   323     -3.107     31.736  -4039us   730us

time100.stupi.se            6   3   326     -8.187     81.559  -7596us  2029us

b.st1.ntp.br                6   5   324     +2.834     62.155  +1918us  1848us

aprihop.cdknnjln.sodtech.   5   4   259     +7.888     64.905  +2387us   983us

Listing 5

The following explains each column shown in Listing 5:

  • Name/IP Address: Indicates the name or IP address of the remote clock server.
  • NP: Indicates the number of runs of residuals having the same sign following the last regression. If this number becomes too low, chronyd discards old samples and run the regression again until the number of runs becomes acceptable.
  • NR: Indicates the number of runs of residuals having the same sign following the last regression. We should concern with this number only if it becomes too small when compared to the number of samples, because that would be an indication that the server is not so good for providing the time.
  • Span: Indicates the interval between the oldest and newest sample.
  • Frequency: Indicates the estimated residual frequency for the server.
  • Freq Skew: Indicates a limit for the expected and tolerable frequency errors (in parts per million).
  • Offset: Indicates the estimated offset from our local clock server compared to the remote clock server (source).
  • Std Dev: Indicates the estimated standard deviation of the sample.

Finally, collect information about the main time reference by running the command shown in Listing 6:

[root@myoracle4 ~]# chronyc tracking

Reference ID    : 201.49.148.135 (b.st1.ntp.br)

Stratum         : 2

Ref time (UTC)  : Wed Feb  3 06:17:33 2016

System time     : 0.001213228 seconds slow of NTP time

Last offset     : -0.000584088 seconds

RMS offset      : 0.000635298 seconds

Frequency       : 8.662 ppm slow

Residual freq   : -0.557 ppm

Skew            : 24.767 ppm

Root delay      : 0.034529 seconds

Root dispersion : 0.002150 seconds

Update interval : 65.2 seconds

Leap status     : Normal

Listing 6

The meaning of each row in Listing 6 is as follows:

  • Reference ID: The IP address/name of the remote clock server (source).
  • Stratum: Indicates how many hops our local clock server is away from the reference clock that provides time to the remote clock server. This is interesting because, as explained previously, the remote NTP server was at stratum level 2, so our local clock server is at stratum level 3.
  • Ref time (UTC): The UTC time at which the last measurement from the reference source was processed.
  • System time: Indicates a potential difference between the time provided by chronyd and the local system clock fetched by a system call. Usually, it is not relevant.
  • Last offset: Indicates the estimated local offset measured on the last clock update.
  • RMS offset: Indicates an average of offsets over the clock time.
  • Frequency: Indicates (in parts per million) the rate at which the local clock would be wrong if chronyd was not correcting it.
  • Residual freq: Reflects any difference between the frequency that should be used and the frequency currently being used.
  • Skew: Indicates a limit for the expected and tolerable frequency errors.
  • Root delay: Indicates the total difference between the time of the local clock server and the time of the reference clock that provides time to the remote clock server.
  • Root dispersion: Indicates the total dispersion (a concept related to statistical measurement variations) of the clock that was accumulated from the stratum-1 servers up to the local clock server.
  • Update interval: Indicates how long ago the last update happened.
  • Leap status: Indicates the leap (offset) status, which can be Normal, Insert Second, Delete Second, or Not Synchronized.

To begin configuring our local client, let's alter the /etc/chrony.conf file on the client system (the following command is executed on myoracle5) to point the same four NTP pools we used for the myoracle4 system, as shown in Listing 7:

[root@myoracle5 ~]# cat /etc/chrony.conf | grep '^server'

server 0.br.pool.ntp.org

server 1.br.pool.ntp.org

server 2.br.pool.ntp.org

server 3.br.pool.ntp.org

Listing 7

The configuration in Listing 7 is the recommended configuration (as explained previously) and we could use it. However, if you want either to prevent each client from accessing the internet to get the correct clock or if some clients do not have internet access, you can cause your client host (myoracle5) to get the clock from myoracle4 by changing the chrony.conf file, as shown below:

[root@myoracle5 ~]# cat /etc/chrony.conf | grep '^server'

server 192.168.1.91

If we stopped here, our configuration (with myoracle5 fetching its time from myoracle4) would not work because the chronyd server (on the myoracle4 host) does not accept queries from any client. Therefore, change the /etc/chrony.conf file on the chronyd server (on myoracle4) to accept queries from local systems (in this case, the myoracle5 client):

[root@myoracle4 ~]# cat /etc/chrony.conf | grep '^allow'

allow 192.168.1/24

For our changes to take effect, restart the chronyd server by executing this:

[root@myoracle4 ~]# systemctl restart chronyd.service

There are some additional tasks to do now. We must remember to open the NTP port (123/UDP) in the firewall on the chronyd server (myoracle4) by running the following commands:

[root@myoracle4 ~]# firewall-cmd --permanent --zone=public --add-port=123/udp

[root@myoracle4 ~]# firewall-cmd --reload

Update the client time (the reasons are the same as explained previously for the ntpd service) from the chronyd server by running the next command:

[root@myoracle5 ~]# ntpdate 192.168.1.91

3 Feb 04:35:46 ntpdate[3501]: adjust time server 192.168.1.91 offset 0.001157 sec

Then, restart the chronyd service on the client by executing the commands shown in Listing 8:

[root@myoracle5 ~]# systemctl restart chronyd.service

[root@myoracle5 ~]# systemctl status chronyd.service

chronyd.service - NTP client/server

   Loaded: loaded (/usr/lib/systemd/system/chronyd.service; disabled; vendor preset: enabled)

   Active: active (running) since Wed 2016-02-03 04:35:15 BRST; 1min 7s ago

  Process: 3492 ExecStartPost=/usr/libexec/chrony-helper update-daemon (code=exited, status=0/SUCCESS)

  Process: 3489 ExecStart=/usr/sbin/chronyd $OPTIONS (code=exited, status=0/SUCCESS)

Main PID: 3491 (chronyd)

   CGroup: /system.slice/chronyd.service

           └─3491 /usr/sbin/chronyd

Feb 03 04:35:15 myoracle5.example.com systemd[1]: Starting NTP client/server...

Feb 03 04:35:15 myoracle5.example.com chronyd[3491]: chronyd version 2.1.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +DEBUG +...CHASH)

Feb 03 04:35:15 myoracle5.example.com chronyd[3491]: Generated key 1

Feb 03 04:35:15 myoracle5.example.com systemd[1]: Started NTP client/server.

Hint: Some lines were ellipsized, use -l to show in full.

Listing 8

As we can see in Listing 8, the chronyd client started its synchronism operation. To track this operation, execute the command shown in Listing 9:

[root@myoracle5 ~]# chronyc tracking

Reference ID    : 192.168.1.91 (192.168.1.91)

Stratum         : 3

Ref time (UTC)  : Wed Feb  3 06:37:24 2016

System time     : 0.000000000 seconds slow of NTP time

Last offset     : +0.001040759 seconds

RMS offset      : 0.001040759 seconds

Frequency       : 0.000 ppm fast

Residual freq   : +13.658 ppm

Skew            : 1000000.000 ppm

Root delay      : 0.016670 seconds

Root dispersion : 32.407433 seconds

Update interval : 0.0 seconds

Leap status     : Normal

Listing 9

According to Listing 9, everything is OK. Verify the source clock server, which, in this case, is our local clock server (myoracle4, which has the IP address 192.168.1.91), as shown below:

[root@myoracle5 ~]# chronyc sources

210 Number of sources = 1

MS Name/IP address         Stratum Poll Reach LastRx Last sample

===============================================================================

^* 192.168.1.91                  2   6    17     2   -860us[-1171us] +/-   10ms

This is great! Everything is working as expected.

Now, we can proceed to configure the DNS server.

Configuring the DNS Server

To succeed with our Kerberos configuration, the name resolution of our system must be correct and it is extremely important to know that using a DNS service is recommended, because Kerberos requires fully qualified domain names and not short host names.

In a common DNS configuration in the real world, we would have both master and slave DNS servers, but we will keep things simple here. So we will review only how to configure a master DNS server.

Once more, we should remember the system names and their respective IP addresses:

  • myoracle4.example.com: 192.168.1.91 (our DNS master server)
  • myoracle5.example.com: 192.168.1.92
  • myoracle6.example.com: 192.168.1.93

To begin, we must install the bind package in our server:

[root@myoracle4 ~]# yum install -y bind

Edit the /etc/named.conf file and make the changes (shown in bold) in Listing 10:

[root@myoracle4 ~]# more /etc/named.conf | grep -v '^//'

options {

   listen-on port 53 { any; };

   listen-on-v6 port 53 { ::1; };

   directory    "/var/named";

   dump-file    "/var/named/data/cache_dump.db";

   statistics-file "/var/named/data/named_stats.txt";

   memstatistics-file "/var/named/data/named_mem_stats.txt";

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

   /*

    - 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

   */

   recursion yes;

   forwarders { 8.8.8.8; 8.8.4.4; };

   dnssec-enable yes;

   dnssec-validation yes;

   dnssec-lookaside auto;

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

};

zone "example.com" IN {

   type master;

   file "forward.example.com.db";

   allow-update { none; };

};

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

   type master;

   file "reverse.1.168.192.db";

   allow-update { none; };

};

include "/etc/named.rfc1912.zones";

include "/etc/named.root.key";

Listing 10

Here's a summarized explanation about each bold configuration change shown in Listing 10:

  • **listen-on port 53 { any; };**  allows the DNS service (BIND) to listen to port 53 for requests on any network interface.
  • **allow-query { localhost;192.168.1.0/24; };**  allows only the client from this address and the network address to query the DNS server for IP address translation.
  • **forwarders { 8.8.8.8; 8.8.4.4; };**   configures this DNS master server to forward any request not related to domain example.com to external DNS servers.
  • **zone "example.com"**  block specifies that any request for translating from a name to an IP address must be searched for in the forward.example.com.db file in the  /var/named directory. Additionally, the parameter allow-update { none; } disables DHCP updates to the forward.example.com.db file.
  • **zone "1.168.192.in-addr.arpa"** block specifies that any request for translating from an IP address to a name must be searched for in the reverse.1.168.192.db file. Additionally, the parameter allow-update { none; } disables DHCP updates to the reverse.1.168.192.db file.

Now, we have to create the /var/named/forward.example.com.db file as shown in Listing 11:

[root@myoracle4 ~]# more /var/named/forward.example.com.db

$TTL 86400

@    IN  SOA     myoracle4.example.com. root.example.com. (

20160201  ;Serial

3600        ;Refresh

1800        ;Retry

604800      ;Expire

86400       ;Minimum TTL

)

;The name server information

@    IN  NS      myoracle4.example.com.

;The IP address of the name server

myoracle4    IN  A       192.168.1.91

;Remaining records

myoracle5    IN  A       192.168.1.92

myoracle6    IN  A       192.168.1.93

Listing 11

Here are a few quick explanations for Listing 11:

  • The first line configures the SOA (Start of Authority), that is, it specifies which host is the master server (myoracle4) and the contact email address (root.example.com means [root@example.com](mailto:root@example.com)).
  • The second line is the serial number that represents the version of this configuration file. This is very important when there is a slave server. In such a case, I use the date in reverse.
  • The line beginning with @ represents the domain (in this case, example.com) and it configures myoracle4.example.com as its name server.
  • The last three lines configure address (A) records to resolve from a name to an IP address.

Create the /var/named/reverse.1.168.192.db file, as shown in Listing 12:

[root@myoracle4 ~]# more /var/named/reverse.1.168.192.db

$TTL 86400

@   IN  SOA     myoracle4.example.com. root.example.com. (

20160202  ;Serial

3600        ;Refresh

1800        ;Retry

604800      ;Expire

86400       ;Minimum TTL

)

;The name server information

@ IN  NS      myoracle4.example.com.

;The pointer records

91   IN   PTR     myoracle4.example.com.

92   IN   PTR     myoracle5.example.com.

93   IN   PTR     myoracle6.example.com.

Listing 12

This file is very similar to the previous one, but in Listing 12, the last three lines are using PTR records, which translate from an IP address to a name.

Now, it's appropriate to check the syntax of the configuration files by running the next command:

[root@myoracle4 ~]# named-checkconf

An empty output means that everything is OK.

Change the DNS client configuration of each host to point to our master server. First, list the available network interfaces and network connections as shown in Listing 13:

[root@myoracle4 ~]# ip link

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

2: eno16777736: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000

    link/ether 00:0c:29:a1:ff:84 brd ff:ff:ff:ff:ff:ff

3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT

    link/ether 52:54:00:53:a8:f6 brd ff:ff:ff:ff:ff:ff

4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN mode DEFAULT qlen 500

    link/ether 52:54:00:53:a8:f6 brd ff:ff:ff:ff:ff:ff

[root@myoracle4 ~]# nmcli con show

NAME         UUID                                  TYPE            DEVICE     

eno16777736  e4f26d9f-2d70-4d3a-9feb-6d943b88ed36  802-3-ethernet  eno16777736

Listing 13

According to the output in Listing 13, the connection and the network interface have the same name (eno16777736).

Modify the DNS server setting for the eno16777736 connection, as shown below:

[root@myoracle4 ~]# nmcli con mod "eno16777736" ipv4.dns 192.168.1.91

Modify the domain search domain parameter for the eno16777736 connection by executing the following command:

[root@myoracle4 ~]# nmcli con mod "eno16777736" ipv4.dns-search example.com

To make the changes take effect, execute the following commands to bring the eno16777736 connection down and up:

[root@myoracle4 ~]# nmcli con down "eno16777736"

Connection 'eno16777736' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/0)

[root@myoracle4 ~]# nmcli con up "eno16777736"

Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/1)

Verify whether all configurations were accomplished successfully by running the next command:

[root@myoracle4 ~]# nmcli con show "eno16777736" | grep ipv4.dns

ipv4.dns:                               192.168.1.91

ipv4.dns-search:                        example.com

Open the necessary firewall ports by changing permanently the firewall configuration file, as shown below:

[root@myoracle4 ~]# firewall-cmd --permanent --add-service=dns

Now, reload this configuration into memory:

[root@myoracle4 ~]# firewall-cmd -reload

Manage the permission (chgrp command), ownership (chown command), and the Security Enhanced Linux (SELinux) configuration (restorecon command), as shown below:

[root@myoracle4 ~]# chgrp named -R /var/named[root@myoracle4 ~]# chown -v root:named /etc/named.conf[root@myoracle4 ~]# restorecon /etc/named.conf[root@myoracle4 ~]# restorecon -rv /var/named

Enable the DNS service to run upon the next boot by executing the following command:

[root@myoracle4 ~]# systemctl enable namedCreated symlink from /etc/systemd/system/multi-user.target.wants/named.service to /usr/lib/systemd/system/named.service.

Start the DNS service by running the following command:

[root@myoracle4 ~]# systemctl start named

Check if the DNS service is running by running the next command:

[root@myoracle4 ~]# 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 Wed 2016-02-03 07:22:03 BRST; 51s ago

  Process: 38265 ExecStart=/usr/sbin/named -u named $OPTIONS (code=exited, status=0/SUCCESS)

  Process: 38263 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: 38268 (named)

   CGroup: /system.slice/named.service

           └─38268 /usr/sbin/named -u named

Feb 03 07:22:02 myoracle4.example.com named[38268]: zone 0.in-addr.arpa/IN: loaded serial 0

Feb 03 07:22:02 myoracle4.example.com named[38268]: zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0

Feb 03 07:22:02 myoracle4.example.com named[38268]: 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/I...rial 0

Feb 03 07:22:02 myoracle4.example.com named[38268]: zone 1.168.192.in-addr.arpa/IN: loaded serial 20160202

Feb 03 07:22:02 myoracle4.example.com named[38268]: zone localhost.localdomain/IN: loaded serial 0

Feb 03 07:22:02 myoracle4.example.com named[38268]: zone localhost/IN: loaded serial 0

Feb 03 07:22:02 myoracle4.example.com named[38268]: zone example.com/IN: loaded serial 20160201

Feb 03 07:22:02 myoracle4.example.com named[38268]: all zones loaded

Feb 03 07:22:02 myoracle4.example.com named[38268]: running

Feb 03 07:22:03 myoracle4.example.com systemd[1]: Started Berkeley Internet Name Domain (DNS).

Hint: Some lines were ellipsized, use -l to show in full.

Finally, we could test the DNS configuration either by running the nslookup command or the dig command. If you have performed a minimal installation of Oracle Linux 7.x, first install these commands because they are not installed by default. To do that, execute the following commands to update the current installation, list the necessary packages, and install them:

[root@myoracle4 ~]# yum -y update[root@myoracle4 ~]# yum provides nslookup[root@myoracle4 ~]# yum provides dig[root@myoracle4 ~]# yum install 32:bind-utils-9.9.4-29.el7_2.3.x86_64

Continuing, let's use the nslookup command, as shown below:

[root@myoracle4 ~]# nslookup
Comments
Post Details
Added on Aug 2 2016
#legacy-documents, #linux, #oracle-linux
0 comments
3,410 views