-
Bug
-
Resolution: Unresolved
-
Undefined
-
None
-
rhel-10.1
-
None
-
None
-
None
-
rhel-idm-zta
-
None
-
False
-
False
-
-
None
-
None
-
None
-
None
-
Unspecified
-
Unspecified
-
Unspecified
-
x86_64
-
None
What were you trying to do that didn't work?
Creation/update of an A record in zone marked with "Allow PTR sync: True" should create/update related PTR record. It works in cases where PTR record in question does not exist but it does not update existing record.
What is the impact of this issue to you?
Reverse DNS zone does not match forward DNS zone. Not sure where it matters but I do know it may cause kerberos failures in some deployment cases.
Please provide the package NVR for which the bug is seen:
ipa-client-common-4.12.2-24.el10_1.1.noarch
ipa-healthcheck-core-0.16-11.el10.noarch
ipa-selinux-4.12.2-24.el10_1.1.noarch
ipa-common-4.12.2-24.el10_1.1.noarch
ipa-client-4.12.2-24.el10_1.1.x86_64
ipa-server-common-4.12.2-24.el10_1.1.noarch
ipa-server-4.12.2-24.el10_1.1.x86_64
ipa-healthcheck-0.16-11.el10.noarch
ipa-server-dns-4.12.2-24.el10_1.1.noarch
ipa-server-trust-ad-4.12.2-24.el10_1.1.x86_64
How reproducible is this bug?:
Always.
Steps to reproduce
Lets's check there are no pre-existing records:
lytta:~> ipa dnsrecord-find jot23.net test0 ---------------------------- Number of entries returned 0 ---------------------------- lytta:~> ipa dnsrecord-find 168.192.in-addr.arpa test0 ---------------------------- Number of entries returned 0 ----------------------------
Create test01.jot23.net and check:
lytta:~> nsupdate -g > server 127.0.0.1 > add test01.jot23.net 1234 in a 192.168.255.123 > > lytta:~ lytta:~> ipa dnsrecord-find jot23.net test0 Record name: test01 A record: 192.168.255.123 ---------------------------- Number of entries returned 1 ---------------------------- lytta:~> ipa dnsrecord-find 168.192.in-addr.arpa test0 Record name: 123.255 PTR record: test01.jot23.net. ---------------------------- Number of entries returned 1 ----------------------------
Both forward and reverse records are created and are correct.
Create test02.jot23.net with THE SAME IP address and check:
lytta:~> nsupdate -g > server 127.0.0.1 > add test02.jot23.net 2345 in a 192.168.255.123 > > lytta:~> lytta:~> ipa dnsrecord-find jot23.net test0 Record name: test01 A record: 192.168.255.123 Record name: test02 A record: 192.168.255.123 ---------------------------- Number of entries returned 2 ---------------------------- lytta:~> ipa dnsrecord-find 168.192.in-addr.arpa test0 Record name: 123.255 PTR record: test01.jot23.net. ---------------------------- Number of entries returned 1 ----------------------------
test01.jot23.net exists and keeps the address. I expected this.
test02.jot23.net exists and points to 192.168.255.123. I also expected this.
192.168.255.123 points back to test01.jot23.net. This is unexpected and the record should point to the latest hostname assigned to it, i.e. test02.jot23.net. This is a fault. This is inconsistent with how ISC DHCP server used to handle reverse updates, they were unconditional and they always pointed to the hostname from the latest update. This also means that when the dynamic address is recycled it will NOT be updated to whatever host got it but will keep the first name which got it indefinitely.
The same problem can be easily reproduced for IPv6 addresses.
Expected results
PTR record should be updated regardless its existence state.
Actual results
PTR record keeps old name causing forward and reverse DNS inconsistency.