Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Description of problem:
I know this bug could tend to be closed but I wanted to document a very bad behavior.
We have a customer with a removed replica where the dns records have not been deleted.
I remember this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1296898
[RFE] it could be nice to have a way to clean dns zones and records of deleted records references.
so, the problem is that a dnsrecord of a deleted replica is broken. We see there is not an A record for idm02 replica.
######
Record name: idm01
A record: <ip address1>
...
Record name: idm02
...
Record name: idm04
A record: <ip address 4>
######
And named.run:
28-Aug-2017 03:15:07.810 zone <master zone x>/IN: NS 'idm02.domain' has no address records (A or AAAA)
28-Aug-2017 03:15:07.810 zone <master zone x>/IN: not loaded due to errors.
28-Aug-2017 03:15:07.810 4 master zones from LDAP instance 'ipa' loaded (5 zones defined, 0 inactive, 1 failed to load)
28-Aug-2017 03:15:07.815 zone xxx.yyy.in-addr.arpa/IN: sending notifies (serial 1503882907)
28-Aug-2017 03:15:07.815 zone zzzz.wwww.zzz.in-addr.arpa/IN: sending notifies (serial 1503882907)
28-Aug-2017 03:15:07.815 zone <master zone Y>/IN: sending notifies (serial 1503882907)
28-Aug-2017 03:15:08.457 zone <master zone x>/IN: NS 'idm02.domain' has no address records (A or AAAA)
28-Aug-2017 03:15:08.457 zone <master zone x>/IN: not loaded due to errors.
28-Aug-2017 03:15:08.457 update_zone (syncrepl) failed for master zone DN
Version-Release number of selected component (if applicable): RHEL7.4
Comment 4Florence Blanc-Renaud
2018-10-22 15:28:36 UTC
The issue is not caused by the empty Record for idm02, but rather because there is a '@' DNS resource record that is containing a NS record with a host not known.
I reproduced the same behavior with the following:
configure ipa server with integrated DNS
in the WebGUI, navigate to Network services > DNS > DNS Zones
select the zone for the ipa domain
select the @ record
in the NS table, click on add and add a host name that is not known (but part of the domain and including the trailing .):
dummy.ipadomain.com.
check the box Skip DNS check
If you then restart the ipa stack, the bind process will show the error in its logs in /var/named/data/named.run:
22-Oct-2018 16:57:46.098 zone ipadomain.com/IN: NS 'dummy.ipadomain.com' has no address records (A or AAAA)
22-Oct-2018 16:57:46.098 zone ipadomain.com/IN: not loaded due to errors.
22-Oct-2018 16:57:46.098 0 master zones from LDAP instance 'ipa' loaded (1 zones defined, 0 inactive, 1 failed to load)
Comment 5Florence Blanc-Renaud
2018-10-22 15:44:39 UTC
Note 1: when removing a broken replica with ipa-replica-manage del, the command properly removes the NS record. I am not sure how the customer got into this situation but could not reproduce.
Note 2: ipa commands are still working on the remaining master, and there are 2 possible paths to fix the issue:
- either remove the broken replica with "ipa-replica-manage del <repl> --clean"
- or remove the NS record pointing to the missing replica with "ipa dnsrecord-del ipadomain.com. '@' --ns-rec=dummy.ipadomain.com."
We could write a KB related to this issue. German, would you agree with this resolution?
Comment 7Florence Blanc-Renaud
2018-10-23 14:02:29 UTC