I have a RHEL7 machine setup with Dynamic DNS and until few days back it was working fine. However, recently I have started seeing a problem where the DNS records for client machines are not getting updated.

Below are the log messages I can see in /var/log/dhcpd.log file.

Feb 2 22:23:28 server dhcpd: DHCPREQUEST for 192.168.122.190 from 52:54:00:a1:13:51 via virbr0
Feb 2 22:23:28 server dhcpd: DHCPACK on 192.168.122.190 to 52:54:00:a1:13:51 (client2) via virbr0
Feb 2 22:23:28 server dhcpd: Unable to add forward map from client2.dreamz.com to 192.168.122.190: REFUSED

Below is my /etc/named.conf configuration file.

[root@server ~]# cat /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.
//
// See the BIND Administrator's Reference Manual (ARM) for details about the
// configuration located in /usr/share/doc/bind-{version}/Bv9ARM.html

options {
listen-on port 53 { 192.168.122.1; };
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 { any; };

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

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

# forwarders {
# 192.168.0.1;
# 8.8.8.8;
# };
};

logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};

zone "." IN {
type hint;
file "named.ca";
};

zone "dreamz.com" IN {
type master;
file "dynamic/dreamz.com.db";
allow-update { key "rndc.key"; };
};

zone "122.168.192.in-addr.arpa" IN {
type master;
file "dynamic/dreamz.com.rev.db";
allow-update { key "rndc.key"; };
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
include "/etc/rndc.key";
[root@server ~]#

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

Following is my /etc/dhcp/dhcpd.conf configuration file.

[root@server ~]# cat /etc/dhcp/dhcpd.conf
# dhcpd.conf
#
# Sample configuration file for ISC dhcpd
#

# option definitions common to all supported networks...
option domain-name "dreamz.com";
option domain-name-servers 192.168.122.1;

default-lease-time 600;
max-lease-time 7200;

# Use this to enble / disable dynamic dns updates globally.
ddns-update-style interim;
ddns-updates on;
ddns-domainname "dreamz.com";
ddns-rev-domainname "122.168.192.in-addr.arpa";

key rndc-key {
algorithm hmac-md5;
# secret tv+KeJs07tcJjV8YCBf4Pw==;
secret bZhm+2tHnAeDDe0VzAMw1g==;
};

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local6;

# No service will be given on this subnet, but declaring it helps the
# DHCP server to understand the network topology.

subnet 10.152.187.0 netmask 255.255.255.0 {
}

# This is a very basic subnet declaration.

#subnet 10.254.239.0 netmask 255.255.255.224 {
# range 10.254.239.10 10.254.239.20;
# option routers rtr-239-0-1.example.org, rtr-239-0-2.example.org;
#}

# This declaration allows BOOTP clients to get dynamic addresses,
# which we don't really recommend.

subnet 192.168.122.0 netmask 255.255.255.0 {
interface virbr0;
range dynamic-bootp 192.168.122.10 192.168.122.254;
option broadcast-address 192.168.122.254;
option routers 192.168.122.1;
option domain-name "dreamz.com";
option domain-name-servers 192.168.122.1;
}

# A slightly different configuration for an internal subnet.
#subnet 10.5.5.0 netmask 255.255.255.224 {
# range 10.5.5.26 10.5.5.30;
# option domain-name-servers ns1.internal.example.org;
# option domain-name "internal.example.org";
# option routers 10.5.5.1;
# option broadcast-address 10.5.5.31;
# default-lease-time 600;
# max-lease-time 7200;
#}

# Hosts which require special configuration options can be listed in
# host statements. If no address is specified, the address will be
# allocated dynamically (if possible), but the host-specific information
# will still come from the host declaration.

#host passacaglia {
# hardware ethernet 0:0:c0:5d:bd:95;
# filename "vmunix.passacaglia";
# server-name "toccata.fugue.com";
#}

# Fixed IP addresses can also be specified for hosts. These addresses
# should not also be listed as being available for dynamic assignment.
# Hosts for which fixed IP addresses have been specified can boot using
# BOOTP or DHCP. Hosts for which no fixed address is specified can only
# be booted with DHCP, unless there is an address range on the subnet
# to which a BOOTP client is connected which has the dynamic-bootp flag
# set.
#host fantasia {
# hardware ethernet 08:00:07:26:c0:a5;
# fixed-address fantasia.fugue.com;
#}
#
# You can declare a class of clients and then do address allocation
# based on that. The example below shows a case where all clients
# in a certain class get addresses on the 10.17.224/24 subnet, and all
# other clients get addresses on the 10.0.29/24 subnet.

#class "foo" {
# match if substring (option vendor-class-identifier, 0, 4) = "SUNW";
#}

#shared-network 224-29 {
# subnet 10.17.224.0 netmask 255.255.255.0 {
# option routers rtr-224.example.org;
# }
# subnet 10.0.29.0 netmask 255.255.255.0 {
# option routers rtr-29.example.org;
# }
# pool {
# allow members of "foo";
# range 10.17.224.10 10.17.224.250;
# }
# pool {
# deny members of "foo";
# range 10.0.29.10 10.0.29.230;
# }
#}

zone dreamz.com. {
primary 192.168.122.1;
key rndc-key;
}

zone 122.168.192.in-addr.arpa. {
primary 192.168.122.1;
key rndc-key;
}
[root@server ~]#

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

[root@server ~]# cat /etc/resolv.conf
# Generated by NetworkManager
search dreamz.com
nameserver 192.168.0.1
nameserver 192.168.122.1
[root@server ~]#
[root@server ~]# nslookup client2
Server: 192.168.0.1
Address: 192.168.0.1#53

** server can't find client2: NXDOMAIN

[root@server ~]#
[root@server ~]# nslookup client2.dreamz.com
Server: 192.168.0.1
Address: 192.168.0.1#53

** server can't find client2.dreamz.com: NXDOMAIN

[root@server ~]#

[root@server ~]# cat /etc/rndc.key
key "rndc-key" {
algorithm hmac-md5;
secret "bZhm+2tHnAeDDe0VzAMw1g==";
};
[root@server ~]#


[root@server ~]# ls -l /etc/rndc.key
-rw-r----- 1 root named 77 Feb 2 20:51 /etc/rndc.key
[root@server ~]#

Haven't we been here a few times before?
https://www.linuxquestions.org/quest...il-4175515766/
https://www.linuxquestions.org/quest...ts-4175635924/

And as you've been asked before, you need to put your files in CODE tags; edit your post please, because it's pretty hard to read as is. You've been working with DNS for at least five years now, and you're using RHEL 7. Have you contacted Red Hat, and use the support you're PAYING FOR (RIGHT???) Have you applied the patches/bug fixes, since you also get them with your RHEL subscription?

Since we don't know if what you posted in your configs is actually CORRECT for your environment, is the domain in your DHCP server the same as what's in your DNS server? You should contact RHEL support first, after you make sure the patches/fixes have been applied for your system.

Haven't we been here a few times before?
https://www.linuxquestions.org/quest...il-4175515766/
https://www.linuxquestions.org/quest...ts-4175635924/


--- Yes we have been here before but for different problems. Earlier it was static DNS but this time it is Dynamic DNS.

And as you've been asked before, you need to put your files in CODE tags; edit your post please, because it's pretty hard to read as is. You've been working with DNS for at least five years now, and you're using RHEL 7. Have you contacted Red Hat, and use the support you're PAYING FOR (RIGHT???) Have you applied the patches/bug fixes, since you also get them with your RHEL subscription?

--- Sure, I will put the configuration files in CODE tags next time. I've been working with DNS for five years and haven't had any problem after initial struggle however, you are not guaranteed that you won't face any problem after five years.

Since we don't know if what you posted in your configs is actually CORRECT for your environment, is the domain in your DHCP server the same as what's in your DNS server? You should contact RHEL support first, after you make sure the patches/fixes have been applied for your system.

--- I am doing this in my personal lab and don't have the RedHat subscription. This configuration was working perfect until few days back and haven't made any changes to it but still got the problem.

Right; like it was last year, with the subject description of "Dynamic DNS can't resolve its own name but successfully resolving clients". So still dynamic DNS, right?? Did you apply any of the suggestions in that thread?
You need to do it in THIS thread, now. Edit your post to make it actually readable, and you've been asked several times before, but still don't do it. And you were asked if you contacted Red Hat support, and whether you have the bugfixes/updates applied to your DNS server from Red Hat. Do you and have you???

And the fact that you posted last year about a dynamic DNS issue indicates that you DID have problems.
Sorry, no, it doesn't work that way...if it was working and you've made ZERO changes, then it should still be working. SOMETHING has changed, somewhere. And it doesn't matter if it's your 'personal lab' or not...if you don't pay for RHEL, don't use it. You're not doing yourself any favors, especially since CentOS is free, and nearly identical. Without a RHEL subscription, you DO NOT get bugfixes/patches/updates...working on stuff that could have issues is a great way of making your life harder.

Interesting also, that the 'dreamz.com' domain points to an online gambling website...and that this is your 'personal lab'.....