freeipa

Clone
Source Code
GIT

#3478 Drop --dynamic-update option from IPA DNS
Closed: wontfix 5 years ago Opened 11 years ago by pspacek.

Closed: wontfix
Reopen Issue

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 is present (some value is added as default)
  • update policy is not effective because default dynamic update value is FALSE

BIND's solution ("classical"):

  • Updates are not allowed if no update policy is present.
  • Comments are allowed inside update policy, e.g.:
    • /* this text is ignored, but following policy applies: */ grant EXAMPLE.COM krb5-self * A;

Change proposal:

  • Remove boolean attribute idnsAllowDynUpdate from LDAP completely
  • ipa dnszone-mod --dynamic-update=FALSE will enclose whole update policy into comment.
    • grant EXAMPLE.COM krb5-self * A; => /* updates disabled: grant EXAMPLE.COM krb5-self * A; */
  • ipa dnszone-mod --dynamic-update=TRUE will delete de-comment update policy.
    • /* updates disabled: grant EXAMPLE.COM krb5-self * A; */ => grant EXAMPLE.COM krb5-self * A;
  • No CLI change from user's point of view.
  • On upgrade: Whole update policy is enclosed to comment block if dynamic update value is FALSE or the attribure is not present. This will work with old and new version of the bind-dyndb-ldap plugin at the same time.

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:

 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 :-)

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:

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

    Number of entries returned 3

  • 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?

  • We may also make Dynamic update setting in Web UI more visible, if it is not obvious

Releasing tickets from distant milestones.

Metadata Update from @pspacek:
- Issue assigned to someone
- Issue set to the milestone: Future Releases
7 years ago

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)
5 years ago

Login to comment on this ticket.

Metadata
None
None
None
normal
None
None
None
None
defect
None
None
DNS
None
0
None
None
None
None
todo
None
None
None
Powered by Pagure 5.13.3
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.