Dnsmasq-centos7

Dnsmasq-centos7

This repository is for those who are trying to setup a CentOS 7 machine as their corporate (or home) firewall.
In this tutorial I’m using the built-in Firewall instead of iptables because it is more convenient and it’ll do for us now.
I also use dnsmasq for DHCP services because a lot of other features can be implemented if required.
In the beginning I’ll just tell you the methods and the way of configuration. Some explaination will be at the end of the document.

Requirenemtns

A DHCP (Dynamic Host Configuration Protocol) server dynamically assigns IP addresses and other network configuration parameters to each device on a network.

A DNS forwarder on a LAN forwards DNS queries for non-local domain names to upstream DNS servers (outside that network), while a DNS caching server answers recursive requests from clients so that the DNS query can be resolved faster, thus improving DNS lookup speeds to previously visited sites.

What is DNSMASQ

dnsmasq (DNS masquerade) is a lightweight, easy to configure DNS forwarder, designed to provide DNS (and optionally DHCP and TFTP) services to a small-scale network. It can serve the names of local machines which are not in the global DNS.

Install dnsmasq in your CentOS / RHEL Linux

sudo yum install dnsmasq

Once you have installed it, you can check the status:

systemctl status dnsmasq

sudo systemctl start dnsmasq

sudo systemctl enable dnsmasq

The result should be similar to this:

Configure dnsmasq Server

The dnsmasq server can be configured via the /etc/dnsmasq.conf file. Since DNS is enabled by default, we suggest creating a backup of the .conf file before making any changes:

cp /etc/dnsmasq.conf /etc/dnsmasq.conf.orig

Now open the /etc/dnsmasq.conf file using your preferred text editor (we use “nano” )

Let’s understand better the settings we entered:

Listen-address

This option is used to set the IP address where dnsmasq will listen on. In this guide we want our CentOS/RHEL server to listen for DHCP and DNS requests on the LAN, so we are going to set the listen-address to its LAN IP addresses (including the localhost 127.0.0.1).

Interface

The interface option is used to restrict the interface dnsmasq listens on. Note that you can add more lines if you mean to have more than one interface.

Domain

This option is used to set the domain. This means DHCP clients will have FQDN (fully qualified domain names) while the set domain is the same and also sets the domain DHCP option for all clients.

Using the address option, you can force your local domain to an IP address(es)

Nameservers

In the example, we used Google’s ones, but you can eventually choose to use a different one, “127.0.0.53”, which is the address of the local caching stub resolver. It forwards DNS requests to whatever upstream DNS servers you specify.

sudo dnsmasq —test

Setting Up dnsmasq with resolv. conf File

This short step shows you how to set the localhost address as the only nameserver in resolv.conf file. This is intended to make all queries to be sent to dnsmasq.

Open resolv.conf file:

Save and exit.

To prevent the overwriting of our changes by the local daemon (NetworkManager) we are going to set the immutable attribute to our file using the chattr command this way:

sudo chattr +i /etc/resolv.conf

We can also make a quick check if everything is right with lsattr command:

Defining DNS Hosts and Names and Testing Local DNS

Now restart dnsmasq to apply the above changes:

sudo systemctl restart dnsmasq

Note: If you have the firewall service running, then you need to open DNS and DHCP services in its configuration:

sudo firewall-cmd —add-service=dns —permanent sudo firewall-cmd —add-service=dhcp —permanent sudo firewall-cmd —reload

To test if everything is working fine we can use bind-utils:

If you don’t have them installed on your system, just run the command:

sudo yum install bind-utils

dig domain.abc

or

nslookup domain.abc

and also test the FQDN:

dig webservertest.domain.abc

or

nslookup webservertest.domain.abc

Dnsmasq is a lightweight, easy to configure DNS forwarder, designed to provide DNS (and optionally DHCP and TFTP) services to a small-scale network. It can serve the names of local machines which are not in the global DNS. This article was written while using CentOS 7, so it is safe to say that it also fully covers RHEL 7, Fedora and generally the whole Red Hat family of operating systems and possibly Novell’s SLES and OpenSUSE.

Install RPM

Modify or add the below content in your dns caching server configuration file.

In this configuration, we assume that the system doesn’t have libvirtd package because libvirtd uses dnsmasq for its virtual guests.

Here,
cache-size — Set the size of the cache. The default is to keep 150 hostnames. By setting the cache size to 0 disables the feature.
resolv-file — Here we use a separate file where dns caching server reads the IPs of the parent nameservers
no-poll — To prevent dns caching server from polling the ‘resolv’ file for changes.
listen-address — Bind only to the provided address

Upstream Nameservers

We have used a separate file to store the IPs of the parent nameservers; that is /etc/resolv.dnsmasq. We will use the same syntax as in /etc/resolv.conf add the nameserver IP addresses. Check sample output below: Here 10.0.2.32 is the IP address of my named chroot dns server.

For this step you must have an upstream DNS server available in your network.

Switch name resolution

For hostnames that do not exist in /etc/hosts the system still uses the nameserver inside /etc/resolv.conf for name resolution.

To start using dns caching server, change the /etc/resolv.conf to send all DNS queries to the local loopback interface. If the file contains multiple nameserver entries remove them so only the one entry is left.

If you write the DNS information in the primary network interface file, you need to update the DNS options in the network file also. Under some circumstances (due to DHCP or you network configuration files) nameserver lines in /etc/resolv.conf may be updated replacing the reference to the loopback interface.

Starting DNSMASQ Service

Use systemctl to enable and start the dns caching server service:

Check the port 53 status using netstat:

Step-by-Step Tutorial: Configure DNS Server using bind chroot (CentOS/RHEL 7/8)

Verify DNS caching Server

Install the tcpdump package on aterminal (Term A)

Some websites or domain names have multiple IP addresses associated with them. For that reason and other reasons, tcpdump may show multiple queries.

For the first ping you should see multiple entries in the tcpdump but you re-run the ping second time then you will observe no packets being transmitted from the host so our DNS caching server is working as expected.

Lastly I hope the steps from the article to configure DNS caching server on CentOS / RHEL 7 Linux node was helpful. So, let me know your suggestions and feedback using the comment section.

References:
Red Hat Knowledgebase

How to get script execution time from within the shell script in Linux

Didn’t find what you were looking for? Perform a quick search across GoLinuxCloud

It is not mandatory to only use the services from this article to configure PXE boot server in Linux. You can also use other services like NFS, FTP etc to serve the purpose.

What is PXE boot server?

PXE, or Preboot eXecution Environment, allows you to instruct computers to boot using network resources. This allows you to control a single source to install servers without the need to physically insert some DVDs or USB sticks.

Design of the PXE network boot

How to install EPEL repo in RHEL 8 Linux

Create kickstart file

Since we plan to automate our installation using kickstart and network boot PXE server so we will need a working kickstart file. I have written another article which contains a sample kickstart configuration file which you can use for reference. For this article I will use kickstart file /root/kickstart.conf with below content.

Configure HTTP

Loading kickstart files over the network from the kernel line during an install only supports NFS, HTTP, and FTP. In this recipe, I choose HTTP as it is a common technology within companies and easy to secure.

Install the Apache server rpm if not installed already

# yum -y install http

# mkdir /var/www/html/kickstart
# cp /root/kickstart.conf /var/www/html/kickstart

Give appropriate permission

# chown -R apache:apache /var/www/html/

Next try to download the kickstart file to make sure it is accessible from the apache server

How to create anaconda updates.img used with inst.updates in RHEL 7/8

Setup the source repository for network installation

I have a vanilla Red Hat DVD which I will use as my repository for the installation via network but instead of copying, I will mount my image.

# mount /root/rhel-server-7.4-x86_64-dvd.iso /var/www/html/rhel/
mount: /dev/loop0 is write-protected, mounting read-only

Since we will use the repo over our HTTP server hence I will use mount partition inside /var/www/html

Configure TFTP service

Now that you have set up a network installation server, it is time to configure PXE boot. This allows you to boot a server you want to install from the network card of the server. ( You normally have to change default boot order, or press a key while booting, to activate PXE boot (Mostly F12) The PXE server next hands out a boot image that the server you want to install uses to start the initial phase of the boot.

Install the RPMs

First of all you need to install all the rpms required to configure PXE boot server

The xinetd service is also known as the Internet super service. It comes from a time where memory resources were limited, and to use memory as efficiently as possible, xinetd could be configured to listen on many ports, making it possible to access many different services. Using xinetd can still be helpful, particularly for services that are not accessed very often. The xinetd service will make sure that the service is started when some processes access its port, and will also shut it down after a specific period of inactivity.

# sed -i ‘/disable/ s/yes/no/’ /etc/xinetd.d/tftp

# systemctl enable xinetd
# systemctl start xinetd

# mkdir /var/lib/tftpboot/rhel7

Since our DVD is already mounted on /var/www/html/rhel, we can copy the required files from the same location

Next, create the PXE configuration directory using this command:

# mkdir /var/lib/tftpboot/pxelinux.cfg

default menu.c32
prompt 0
timeout 300
ontimeout 2

menu title PXE Boot Menu
label 1
menu label ^1 — Install RHEL 7 x64 with Local http Repo
kernel rhel7/vmlinuz
append initrd=rhel7/initrd.img showopts devfs=nomount

label 2
menu label ^2 — Boot from local media
localboot 0x80

Steps to configure PXE boot server using DNSMASQ server

In case you plan to use DNSMASQ instead of DHCP, then you can use the below steps to configure your DNSMASQ services

Install the RPMs

# interfaces to bind to
interface=eth0,lo
# the domain for this DNS server
domain=example.com
# DHCP lease range
dhcp-range=eth0,10.0.2.200,10.0.2.220,10h
# PXE – the address of the PXE server
dhcp-boot=pxelinux.0,pxeserver,10.0.2.20
# Gateway
dhcp-option=3,10.0.2.2
pxe-prompt=»Press F8 for menu.», 60
enable-tftp
tftp-root=/var/lib/tftpboot

# systemctl enable dnsmasq
# systemctl start dnsmasq

Steps to configure PXE boot server using DHCP server

In case you plan to use DHCP instead of DNSMASQ, then you can use the below steps to configure your DHCP services

Configure DHCP Server

On an installation server, the TFTP server cannot exist without a DHCP server. When making a PXE boot, the DHCP server is the first to answer with all the required IP-related configuration and information about the DHCP server that is to be used.

How to configure VLAN with bond using kickstart in Linux (CentOS/RHEL 7)

Next configure your /etc/dhcp/dhcpd.conf. Below is my sample config file. Here you need to add separate entry for every host MAC Address (as highlighted) to netboot using PXE server.

In the DHCP configuration file, a subnet is specified. This is the subnet where the PXE server should offer its services. In most configurations, this would be a dedicated network, which is a good idea, because you do not want workstations that perform a PXE boot to get installed with Red Hat Enterprise Linux by accident. If you want to offer PXE-based installation services on a network where also clients are in use that rely on PXE boot, it is recommended to define a class statement to define which machines should be allowed to use PXE boot and which should not.

Within the subnet definition, the next-server statement gives the IP address of the server that is configured with TFTP. Even if it is on the same server that is offering DHCP, you should still specify the next-server IP address. The filename statement defines the file that should be offered to workstations that are making a PXE boot. Notice that this filename is relative to the TFTP server root as defined in the TFTP configuration file.

PSSH — 10 practical examples to use parallel SSH in Linux

Open the firewall on your server using these commands (however, this may not be necessary):

# firewall-cmd —add-service=dns —permanent
# firewall-cmd —add-service=dhcp —permanent
# firewall-cmd —add-service=tftp —permanent
# firewall-cmd —reload

If you face any issues during your POC stage then you can disable and stop the firewall services and validate your configuration to isolate the cause of the failure. Once the issue is found, it is strongly recommended to keep the firewall services enabled and active.

How the flow would work?

On your server side in the /var/log/messages you can monitor the progress of the PXE boot

Solved: Kickstart clearpart not working in RHEL CentOS 7 8

When using DHCP

When using DNSMASQ

Kickstart post install script examples in RHEL CentOS 7 8

Here in the message as you see multiple messages with not found.
Once the client retrieves and executes pxelinux.0, it is hard-coded to look for a file from the pxelinux.cfg/ subdirectory relative to where pxelinux.0 was found.

First, it will look for a file named after the MAC address, in the form 01-xx-xx-xx-xx-xx-xx; then, it will look for a file named by the IP address as provided by the DHCP server. The IP address is looked up in hexadecimal format. i.e. 10 in hexadecimal is 0x0A, 0 is 0x00, 2 is 0x02, and 217 is 0xD9, so 10.0.2.217 is 0x0A0002D9.

You can also get this value using printf in the below format

# printf «%02x%02x%02x%02xn» 10 0 2 217

Below is a sample of the splash screen with «PXE Boot menu» which will be printed on that target node once booted from the NIC card.

Lastly I hope the steps from the article to configure PXE boot server on Linux was helpful. This is a very small part of what actually we can do when configuring a PXE boot server. There are various other options to customise the configuration or use other protocols like NFS. So, let me know your suggestions and feedback using the comment section.

Why do you need to configure Master Slave DNS Server?

In production environment we are always concerned about uptime and redundancy so with Master Slave DNS server configuration our master server data is automatically replicated to the slave server hence anytime if the master server goes down for some reason then your slave server can act as the primary DNS server by them time you fix the master server.

So you can again ask, why not have two or more than two DNS server in the network and if one goes down then other one will any how act as primary?
This is correct but in such case you will have to manually perform the same changes on all your DNS servers in the network but if you configure master slave DNS server, any change you do on master DNS server is automatically replicated on the slave DNS server so there is little chance of human error and no re-work needed hence it is recommended to configure Master Slave DNS Server.

Since I had already configured a DNS server within chroot environment. Here I will use the same configuration with relevant changes required to configure Master Slave DNS Server.

How to run script with systemd at shutdown only (not at reboot)

My Setup Detail

Master DNS Server — 10.0.2.32 (master.example.com)

Slave DNS Server — 10.0.2.31 (slave.example.com)

Configure Master DNS Server

To start with first of all we need to install the bind chroot rpm on the master dns server

(M) Sample named. conf

Our sample named configuration file with custom changes are highlighted.

We will need to do some changes in our master DNS server’s /etc/named.conf to configure master slave DNS server but we will do that once the named-chroot service is UP and running on the master.

(M) Sample zone configuration

Below is my zone configuration from named.rfc1912.zones files. No special changes required here to configure Master Slave DNS Server:

(M) Sample forward zone file

Below is my forward zone file. No special changes required here to configure Master Slave DNS Server:

(M) Sample reverse zone file

Below is my reverse zone file. No special changes required here to configure Master Slave DNS Server:

(M) Enable chroot environment

Next mount all the DNS configuration files on the chroot environment

(M) Verify DNS configuration

Next verify your configuration

In this article I have disabled firewalld and selinux on my RHEL 7 setup.

(M) Update resolv. conf file

6 ssh authentication methods to secure connection (sshd_config)

(M) Start named-chroot service

But before, make sure to stop and disable any named service which is available and running on your RHEL 7 Linux host since we plan to use named-chroot:

Now we can start the named chroot service

(M) Verify DNS Server

Next verify the DNS server configuration:

So our basic DNS server is up and running, let us configure our slave DNS server.

Configure Slave Server

Next let us proceed with the configuration of our slave server to configure the Master Slave DNS Server in Linux

(S) Install bind-chroot rpm

Similar to master DNS server we need to install bind-chroot rpm here

(S) Configure named. conf

Next modify your /etc/named.conf file with the slave DNS server IP as highlighted below. Remaining all the entries will be left untouched.

include «/etc/named.rfc1912.zones»;
include «/etc/named.root.key»;

Step-by-Step Tutorial: Configure Software RAID 4 in Linux

(M) Configure named. conf

Now at this stage we must do some additional configuration changes on our Master DNS server’s /etc/named.conf. Add below content:

Here 10.0.2.31 is my Slave DNS server. With these changes the Master DNS Server will automatically notify the Slave DNS Server for any changes and will also transfer the changed content.

(S) Update zone configuration

Next we need to configure /etc/named.rfc1912.zones file to add the zone record for our forward and reverse zone file for the Slave DNS Server. Append the below content to your named.rfs1912.zones file

Adjust the IP address and file name as per your environment here.

(S) Enable chroot environment

Mount the bind configuration files on chroot environment

(S) Verify DNS configuration

Next verify the configuration file using named-checkconf

Since there was no output on screen so it means there were no syntax errors found in our bind configuration files.

How to check and disable transparent hugepages ( CentOS / RHEL 7 )

(M & S) Update resolv. conf file

Update the same entries in /etc/resolv.conf on the master dns server

(M & S) Start named-chroot service

Next we can start the named-chroot service on the Slave DNS Server and also restart the named-chroot service on master since we had done some changes on our Master DNS Server as well.

So all our services are UP and running.

Now as soon as you start the named chroot service on the slave, you will observe that zone files will be create automatically on the slave server under /var/named/slaves/

These zone files will not be in readable format and should not be modified as they get updated automatically every time the named-chroot service is reloaded or restarted on the Master DNS Server.

Configure postfix mail server and client with examples (CentOS/RHEL 7/8)

Verify Master to Slave Data Replication

Now since our named-chroot service is running on the Slave DNS Server, the zones related data will be instantly transferred from master to slave under /var/named/data/named.run

Below is a sample content from my /var/named/data/named.run

managed-keys-zone: loaded serial 2
zone 0.in-addr.arpa/IN: loaded serial 0
zone 2.0.10.in-addr.arpa/IN: loaded serial 2
zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0
zone example.com/IN: loaded serial 6
zone localhost.localdomain/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 localhost/IN: loaded serial 0
all zones loaded
running

We can verify this by modifying our forward zone file on the Master DNS Server by adding a new A record

Here we have added a new A record for «test» and updated the serial number.

Make sure you update the serial number every time you modify the zone files or else the slave will fail to get an update.

Next reload the named-chroot service and observe the logs under /var/named/data/named.run on slave server

Below logs are seen on slave server under /var/named/data/named.run. So our transfer was successfully completed:

client 10.0.2.32#25912: received notify for zone ‘example.com’
zone example.com/IN: Transfer started.
transfer of ‘example.com/IN’ from 10.0.2.32#53: connected using 10.0.2.31#39338
zone example.com/IN: transferred serial 7
transfer of ‘example.com/IN’ from 10.0.2.32#53: : 1 messages, 8 records, 247 bytes, 0.002 secs (123500 bytes/sec)
zone example.com/IN: sending notifies (serial 7)

Next verify the A record resolution on slave server

So the data has been transferred successfully so our master to slave replication is working successfully.

DVWA SQL Injection Exploitation Explained (Step-by-Step)

Lastly I hope the steps from the article to configure Master Slave DNS Server on Linux (RHEL/CentOS 7) was helpful. So, let me know your suggestions and feedback using the comment section.