This option was "invented" by IPA and doesn't have BIND equivalent. Admins and support guys are confused by that fact and often make a mistake at this point.
IMHO we should follow rule of least surprise: (Quote from Wikipedia): In more practical terms, the principle aims to exploit users' pre-existing knowledge as a way to minimize the learning curve for instance by designing interfaces borrowing heavily from "functionally similar or analogous programs with which your users are likely to be familiar."
We should not force admins to go back to the school if it's unnecessary :-)
Current IPA solution:
update policy
dynamic update
FALSE
BIND's solution ("classical"):
/* this text is ignored, but following policy applies: */ grant EXAMPLE.COM krb5-self * A;
Change proposal:
idnsAllowDynUpdate
ipa dnszone-mod --dynamic-update=FALSE
grant EXAMPLE.COM krb5-self * A;
/* updates disabled: grant EXAMPLE.COM krb5-self * A; */
ipa dnszone-mod --dynamic-update=TRUE
I think that the biggest source of mistake is that both dynamic update switch and dynamic update policy is hidden by default. I.e. the following dnszone listing does not show any hint if dynamic update is enabled for a zone or not:
# ipa dnszone-find Zone name: 78.16.10.in-addr.arpa. Authoritative nameserver: vm-037.idm.lab.bos.redhat.com. Administrator e-mail address: hostmaster.idm.lab.bos.redhat.com. SOA serial: 1362059315 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Active zone: TRUE Allow query: any; Allow transfer: none; Zone name: example.com Authoritative nameserver: vm-037.idm.lab.bos.redhat.com. Administrator e-mail address: hostmaster.example.com. SOA serial: 1362136521 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Active zone: TRUE Allow query: any; Allow transfer: none; Zone name: idm.lab.bos.redhat.com Authoritative nameserver: vm-037.idm.lab.bos.redhat.com. Administrator e-mail address: hostmaster.idm.lab.bos.redhat.com. SOA serial: 1362123174 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Active zone: TRUE Allow query: any; Allow transfer: none; ---------------------------- Number of entries returned 3 ----------------------------
User needs to pass --all option to see that setting:
--all
ipa dnszone-find --all dn: idnsname=78.16.10.in-addr.arpa.,cn=dns,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com Zone name: 78.16.10.in-addr.arpa. Authoritative nameserver: vm-037.idm.lab.bos.redhat.com. Administrator e-mail address: hostmaster.idm.lab.bos.redhat.com. SOA serial: 1362059315 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant IDM.LAB.BOS.REDHAT.COM krb5-subdomain 78.16.10.in-addr.arpa. PTR; Active zone: TRUE Dynamic update: TRUE Allow query: any; Allow transfer: none; nsrecord: vm-037.idm.lab.bos.redhat.com. objectclass: top, idnsrecord, idnszone dn: idnsname=example.com,cn=dns,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com Zone name: example.com Authoritative nameserver: vm-037.idm.lab.bos.redhat.com. Administrator e-mail address: hostmaster.example.com. SOA serial: 1362136521 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant IDM.LAB.BOS.REDHAT.COM krb5-self * A; grant IDM.LAB.BOS.REDHAT.COM krb5-self * AAAA; grant IDM.LAB.BOS.REDHAT.COM krb5-self * SSHFP; Active zone: TRUE Dynamic update: FALSE Allow query: any; Allow transfer: none; nsrecord: vm-037.idm.lab.bos.redhat.com. objectclass: top, idnsrecord, idnszone dn: idnsname=idm.lab.bos.redhat.com,cn=dns,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com Zone name: idm.lab.bos.redhat.com Authoritative nameserver: vm-037.idm.lab.bos.redhat.com. Administrator e-mail address: hostmaster.idm.lab.bos.redhat.com. SOA serial: 1362123174 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant IDM.LAB.BOS.REDHAT.COM krb5-self * A; grant IDM.LAB.BOS.REDHAT.COM krb5-self * AAAA; grant IDM.LAB.BOS.REDHAT.COM krb5-self * SSHFP; Active zone: TRUE Dynamic update: TRUE Allow query: any; Allow transfer: none; nsrecord: vm-037.idm.lab.bos.redhat.com. objectclass: top, idnsrecord, idnszone
I agree that this is confusing. However, I am against changing the semantics of --dynamic-update option in IPA. It breaks assumptions on our API, --dynamic-update option would suddenly not represent an attribute in zone LDAP entry but it would magically change other LDAP attribute in an unexpectable way - at least for me it breaks the "rule of least surprise", I would be surprised with this behavior a lot :-)
--dynamic-update
To improve the situation, I propose following:
Show "Dynamic Update" LDAP attribute by default so that one can immediately see if dynamic updates are allowed or not:
Zone name: 78.16.10.in-addr.arpa. Authoritative nameserver: vm-037.idm.lab.bos.redhat.com. Administrator e-mail address: hostmaster.idm.lab.bos.redhat.com. SOA serial: 1362059315 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Dynamic update: TRUE Active zone: TRUE Allow query: any; Allow transfer: none;
Zone name: example.com Authoritative nameserver: vm-037.idm.lab.bos.redhat.com. Administrator e-mail address: hostmaster.example.com. SOA serial: 1362136521 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Dynamic update: TRUE Active zone: TRUE Allow query: any; Allow transfer: none;
Zone name: idm.lab.bos.redhat.com Authoritative nameserver: vm-037.idm.lab.bos.redhat.com. Administrator e-mail address: hostmaster.idm.lab.bos.redhat.com. SOA serial: 1362123174 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Active zone: TRUE Dynamic update: FALSE Allow query: any; Allow transfer: none;
As you told, admins get confused when they see that BIND parsed the IPA ACL for a zone, but dynamic updates then still do not work because of disabled Dynamic updates. What about improving bind-dyndb-ldap logging and just pushing ACL /* DISABLED */ to BIND or something similar to prevent confusion in BIND logs?
bind-dyndb-ldap
/* DISABLED */
Releasing tickets from distant milestones.
Metadata Update from @pspacek: - Issue assigned to someone - Issue set to the milestone: Future Releases
Thank you taking time to submit this request for FreeIPA. Unfortunately this bug was not given priority and the team lacks the capacity to work on it at this time.
Given that we are unable to fulfil this request I am closing the issue as wontfix. To request re-consideration of this decision please reopen this issue and provide additional technical details about its importance to you.
Metadata Update from @rcritten: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.