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