This ticket was deferred, meaning we do not wan't to address it at the moment. Please target your valuable effort on tickets in current milestones, it will be of a great help! Thanks!

We had a further discussion with Lynn and Dmitri about this ticket. It was moved to Deferred not because we had no cycles to do that, but because the proposed solution was inconsistent with IPA framework and we did not want to do that this way.

DNS policy is just a single-value string stored in DNS zone LDAP object, adding just --append-policy to dnszone-mod would create inconsistency with all other single-value attributes in IPA. I would not like to have IPA API full of one-time options which were used once but we which would have to be kept in API forever.

If we accept the premise that DNS update policy is special and needs special handling, lets at least add options for full control of it to make it complete:

• dnszone-mod --add-update-policy=STR Appends BIND update policy element to current update policy
• dnszone-mod --remove-update-policy=STR Removes BIND update policy element from current update policy

Replying to [comment:5 mkosek]:

DNS policy is just a single-value string stored in DNS zone LDAP object,

... but it has some internal meaning even to IPA and that meaning
seems to be a list of entries. In other words, the fact that it is
a single-values does not mean that semantically, it is a list.

adding just --append-policy to dnszone-mod would create inconsistency with all other single-value attributes in IPA. I would not like to have IPA API full of one-time options

Ummm, why API? It can be handled completely on the CLI side, can't it?

• dnszone-mod --add-update-policy=STR Appends BIND update policy element to current update policy
• dnszone-mod --remove-update-policy=STR Removes BIND update policy element from current update policy

That is certainly possible too.

Replying to [comment:6 adelton]:

Replying to [comment:5 mkosek]:

DNS policy is just a single-value string stored in DNS zone LDAP object,

... but it has some internal meaning even to IPA and that meaning
seems to be a list of entries. In other words, the fact that it is
a single-values does not mean that semantically, it is a list.

Strictly speaking, for IPA it's just a string that is later interpreted by bind-dyndb-ldap/BIND. But I see what you mean. FYI, this attribute could not be made a multivalued entry in LDAP because order matters in this case and LDAP by design does not guarantee order of values in multi valued attribute.

If you come up with reasonable and consistent API how to handle it, we can look at it. Also note that there are other attributes of that type which contains BIND-style list of ACL elements and which may benefit from that consistent approach too:

  --allow-query=STR     Semicolon separated list of IP addresses or networks
                        which are allowed to issue queries
  --allow-transfer=STR  Semicolon separated list of IP addresses or networks
                        which are allowed to transfer the zone

adding just --append-policy to dnszone-mod would create inconsistency with all other single-value attributes in IPA. I would not like to have IPA API full of one-time options

Ummm, why API? It can be handled completely on the CLI side, can't it?

It cannot ATM. FreeIPA framework does not allow CLI side only options AFAIK, it is designed differently. You define an option, it becomes an FreeIPA server API option which is then called by FreeIPA client. The client does not handle the entry in LDAP, the server does - thus the API.

Replying to [comment:7 mkosek]:

It cannot ATM. FreeIPA framework does not allow CLI side only options AFAIK, it is designed differently. You define an option, it becomes an FreeIPA server API option which is then called by FreeIPA client. The client does not handle the entry in LDAP, the server does - thus the API.

Ah. Well, my idea was that client (CLI) while seeing --append-policy would first do call equivalent to ipa dnszone-show --all to get the current value of the BIND update policy, append the value of the parameter to obtained value, and then proceed with ipa dnszone-mod --update-policy with the new value.

Sure, I understand that (and it could work that way, dnsrecord-mod interactive mode also gathers a copy of LDAP entry from server first).

But as I wrote above, IPA framework currently does not support this type of options. You would have to first write a support for it.

But IMO, even if you add the option, there should be some consistent approach to this kind of options to not pollute CLI with one-time options. Even if the new option is not in API, we would still not be able to remove at will any time we want, people may still have scripts using them - so there is not much difference from having them in API.

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.