RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1138317 - Implement Handling of idnsZoneActive Attribute
Summary: Implement Handling of idnsZoneActive Attribute
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: bind-dyndb-ldap
Version: 7.1
Hardware: All
OS: Linux
medium
high
Target Milestone: rc
: ---
Assignee: Petr Spacek
QA Contact: Namita Soman
URL:
Whiteboard:
Depends On: 1109759
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-09-04 13:26 UTC by Sebastian
Modified: 2019-04-16 14:17 UTC (History)
6 users (show)

Fixed In Version: bind-dyndb-ldap-6.0-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-05 09:29:23 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:0424 0 normal SHIPPED_LIVE bind-dyndb-ldap bug fix and enhancement update 2015-03-05 14:26:27 UTC

Description Sebastian 2014-09-04 13:26:14 UTC
bind-dyndb-ldap upstream (5.x) does not yet include handling for the LDAP attribute "idnsZoneActive".
Using this attribute, currently included versions (3.5.x) provide functionality like dynamic activation and deactivation of zones. See the following documentation: https://git.fedorahosted.org/cgit/bind-dyndb-ldap.git/tree/README?h=v3#n290

Since newer versions, this functionality is still planned for bind-dyndb-ldap but has not yet been implemented. See https://fedorahosted.org/bind-dyndb-ldap/ticket/127

As customers are actively using this feature in production environments of RHEL 7, a rebase to a newer version of bind-dyndb-ldap as planned in BZ1109759 should not happen unless the newer version is made feature complete.

Comment 2 Sebastian 2014-09-04 13:34:25 UTC
Opened Red Hat Ticket #01184828 for reference and business justification.

Comment 3 Petr Spacek 2014-09-04 17:12:51 UTC
I wonder if bind-dyndb-ldap is the right layer to implement this. Historically it *was* implemented in bind-dyndb-ldap but the implementation caused a lot of pain (race conditions and related bugs everywhere etc.).

Now I'm looking into implementation details again and it is going to be hacky.

To me it seems better (safer & easier at the same time) to implement this feature on the side of LDAP server.

IPA should be able to easily implement ACI which effectively hides all data in sub-trees where idnsZoneActive attribute == FALSE. As a result, bind-dyndb-ldap will not see the data and the zone will be effectively 'inactive'.

I believe that the same should be possible with OpenLDAP ACIs.

Compare required effort:
- Crafting one ACI for LDAP server
vs.
- At least one week of development and testing + risk of race conditions

Solution on LDAP server side has one additional benefit: It will prevent data modification in 'inactive' DNS zones even if bind-dyndb-ldap contains a bug which would potentially allowed that.

Comment 4 Martin Kosek 2014-09-05 08:39:33 UTC
The ACI approach makes sense to me. It should make the implementation straightforward and less fragile.

I am just wondering about the change performance-wise. Ludwig, would we need to for example add idnsZoneActive attribute to IPA indices given that it would be now referred by ACI for DNS services? Or is it OK to simply add the filter to ACI?

Comment 5 Ludwig 2014-09-05 08:47:44 UTC
acis always are evaluated on entries/attributes before they are returned (or not). So the search part based on indexes is already done in that phase.
Only if you want to use idnsZoneActive in a search filter for an internal or external search you need to consider to create an index

Comment 6 Sebastian 2014-09-05 09:15:21 UTC
It is one discussion whether the idnsZoneActive is a technically good solution for the requirement or whether better workarounds exist.

A totally different discussion should be made concerning a rebase of bind-dyndb-ldap to version 5 within RHEL 7. As a customer I expect all features and APIs provided in an initial RHEL release to continue working until the end of life of a release and not be changed in any way be updates somewhere on the way.

From my customer perspective I ask you to implement the missing feature for bind-dyndb-ldap or to not perform a rebase within RHEL 7.

Comment 9 Dmitri Pal 2014-09-05 10:51:15 UTC
(In reply to Sebastian from comment #6)
> It is one discussion whether the idnsZoneActive is a technically good
> solution for the requirement or whether better workarounds exist.
> 
> A totally different discussion should be made concerning a rebase of
> bind-dyndb-ldap to version 5 within RHEL 7. As a customer I expect all
> features and APIs provided in an initial RHEL release to continue working
> until the end of life of a release and not be changed in any way be updates
> somewhere on the way.
> 
> From my customer perspective I ask you to implement the missing feature for
> bind-dyndb-ldap or to not perform a rebase within RHEL 7.

The package is a part of the IdM/IPA solution it is not supported as a stand alone package. You might use it and we will fix issues in it as it is a part of RHEL and by that we have obligations to make it work, however there is also no ABI guarantee on it, so, sorry, it will be implemented in the way that makes most technical sense to do.

Thank you
Dmitri

Comment 10 Petr Spacek 2014-09-10 07:27:36 UTC
After all, it was decided to implement this functionality directly in bind-dyndb-ldap again. ACI approach is too cumbersome.

Comment 11 Martin Kosek 2014-09-11 07:35:01 UTC
Marking as Regression given the behavior is supported in RHEL-7.0 and we will need to fix in RHEL-7.1 - whether on IPA or bind-dyndb-ldap side.

Comment 13 Petr Spacek 2014-09-23 10:55:37 UTC
This enhancement was implemented in upstream commits:
5ef943a39cfdfbadeb2a41cc3efd707caeca36bd
169f5e5f2a551253bc489edf109eab71a8331c3f
3dd95594e664b7b59a9f8c1d15cb1280eebeb3e7
27a911cae9de911938d90c94c61cecd494136fc1
23f2ddb317ab46419ea83725f458caae1b432fb5

Comment 14 Petr Spacek 2014-09-23 11:31:33 UTC
There is nothing to document because previous version shipped with RHEL 7.0 didn't have the problem described in this bug.

Comment 15 Petr Spacek 2014-09-23 13:59:13 UTC
Steps to verify:
1) Add an IPA zone
2) Add a record to the IPA zone
3) Verify that the record is resolvable using dig/host/nslookup

4) Disable the zone: ipa dnszone-disable <zone.name>
5) Verify that no record from the disabled zone is resolvable using dig/host/nslookup

6) Enable the zone again: ipa dnszone-enable <zone.name>
7) Verify that the record is resolvable using dig/host/nslookup

Comment 17 Namita Soman 2014-11-24 19:09:24 UTC
Verified using:
bind-dyndb-ldap-6.0-1.el7.x86_64
ipa-server-4.1.0-8.el7.x86_64

Followed steps to verify from #comment15 

# ipa dnszone-add bz1138317.testrelm.test
  Zone name: bz1138317.testrelm.test.
  Active zone: TRUE
  Authoritative nameserver: mgmt9.testrelm.test.
  Administrator e-mail address: hostmaster
  SOA serial: 1416855757
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  BIND update policy: grant TESTRELM.TEST krb5-self * A; grant TESTRELM.TEST krb5-self * AAAA; grant
                      TESTRELM.TEST krb5-self * SSHFP;
  Dynamic update: FALSE
  Allow query: any;
  Allow transfer: none;


# ipa dnsrecord-add  bz1138317.testrelm.test host1 --a-rec 1.2.3.4
  Record name: host1
  A record: 1.2.3.4

# host host1.bz1138317.testrelm.test 
host1.bz1138317.testrelm.test has address 1.2.3.4

# ipa dnszone-disable  bz1138317.testrelm.test 
--------------------------------------------
Disabled DNS zone "bz1138317.testrelm.test."
--------------------------------------------

# host host1.bz1138317.testrelm.test 
Host host1.bz1138317.testrelm.test not found: 3(NXDOMAIN)


# ipa dnszone-enable  bz1138317.testrelm.test 
-------------------------------------------
Enabled DNS zone "bz1138317.testrelm.test."
-------------------------------------------

# host host1.bz1138317.testrelm.test 
host1.bz1138317.testrelm.test has address 1.2.3.4

Comment 19 errata-xmlrpc 2015-03-05 09:29:23 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0424.html


Note You need to log in before you can comment on or make changes to this bug.