Hide Forgot
Description of problem: Possible regression of BZ767725 running nsupdate no longer seems to update reverse entries when a forward is changed. Version-Release number of selected component (if applicable): ipa-server-3.3.2-2.el7.x86_64 How reproducible: always Steps to Reproduce: Copy the reproduction steps from BZ767725 comment 4 https://bugzilla.redhat.com/show_bug.cgi?id=767725#c4 Actual results: Verify starting addresses: :: [ PASS ] :: Running: ipa dnsrecord-find testrelm.com ipaqavmg > /tmp/tmp.wMBAiromGQ/output.txt (Expected 0, got 0) Record name: ipaqavmg A record: 10.16.98.192 SSHFP record: 1 1 17EFB60E0C470439F8BDBEEA4606E8F4A779383C, 1 2 4640F0F926338B2013BC37FC09CAB10EE6AE5AD05AC0F1140AF79DD5 50791770 ---------------------------- Number of entries returned 1 ---------------------------- ipa dnsrecord-find 98.16.10.in-addr.arpa. 192 > /tmp/tmp.wMBAiromGQ/output.txt (Expected 0, got 0) Record name: 192 PTR record: ipaqavmg.testrelm.com. ---------------------------- Number of entries returned 1 ---------------------------- Change records with this input to nsupdate: zone testrelm.com update delete ipaqavmg.testrelm.com IN A update add ipaqavmg.testrelm.com 86400 IN A 10.16.98.193 send Verify that the record changed: ipa dnsrecord-find testrelm.com ipaqavmg Record name: ipaqavmg A record: 10.16.98.193 SSHFP record: 1 1 17EFB60E0C470439F8BDBEEA4606E8F4A779383C, 1 2 4640F0F926338B2013BC37FC09CAB10EE6AE5AD05AC0F1140AF79DD5 50791770 ---------------------------- Number of entries returned 1 ---------------------------- ipa dnsrecord-find 98.16.10.in-addr.arpa. 193 ---------------------------- Number of entries returned 0 Expected results: The forward changed, but not the reverse. Additional info: This bug may be better filed against another component. This test worked in rhel 6. I am unsure when the behaviour changed.
Petr, can you please advise from bind-dyndb-ldap POV? I am not aware of any related change in IPA DNS module.
There were some changes in bind-dyndb-bind, mainly fixes about IPv6 and some race conditions, so the bug could be there. Gregg, I don't see any information about your configuration nor any information from logs. Please make sure that everything is configured according to: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/SyncPTR Please check /var/log/messages and post any error messages to this bug. My guess is that the testing data doesn't pass validation in bind-dyndb-ldap. See section "Existing values in A/AAAA and PTR records matches." in the document linked above.
Petr, your guess was correct, allow-sync-ptr was not configured for the default zone in IPA. After I ran "ipa dnszone-mod testrelm.com. --allow-sync-ptr=TRUE", my tests started passing. So, is this a ipa bug? I need to verify that this is happening, but it's looking like the allow-sync-ptr flag is not getting set upon running ipa-server-install --setup-dns
For some reason, ptr sync is not enabled on my default domain during these tests. I am not sure why. It seems to be set on other ipa machines around here. Am I right in assuming that this flag should be set on IPA domains? My config before setting allow-sync-ptr flag: dn: idnsname=testrelm.com,cn=dns,dc=testrelm,dc=com Zone name: testrelm.com Authoritative nameserver: mgmt3.testrelm.com. Administrator e-mail address: hostmaster.testrelm.com. SOA serial: 1382053507 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant TESTRELM.COM krb5-self * A; grant TESTRELM.COM krb5-self * AAAA; grant TESTRELM.COM krb5-self * SSHFP; Active zone: TRUE Dynamic update: TRUE Allow query: any; Allow transfer: none; nsrecord: mgmt3.testrelm.com., cloud-qe-7.testrelm.com. objectclass: top, idnsrecord, idnszone
AFAIK PTR record synchronization always has to be enabled manually. I don't think that there was a change in this area. Namita did the same test for https://bugzilla.redhat.com/show_bug.cgi?id=1010396 (RHEL 6) and the behaviour was the same. See https://bugzilla.redhat.com/show_bug.cgi?id=1010396#c8 step "2".