Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-145535

IPA fails to update reverse record (when it exists)

Linking RHIVOS CVEs to...Migration: Automation ...Sync from "Extern...XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • rhel-10.1
    • ipa
    • None
    • None
    • None
    • rhel-idm-zta
    • None
    • False
    • False
    • Hide

      None

      Show
      None
    • 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.

       

              twoerner Thomas Woerner
              tomkep Tomasz Kępczyński
              Florence Renaud Florence Renaud
              Sudhir Menon Sudhir Menon
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Created:
                Updated: