+++ This bug was initially created as a clone of Bug #2158775 +++

Description of problem: Removing the last DNS type for ipa-ca does not work.


Version-Release number of selected component (if applicable):


How reproducible: Always


Steps to Reproduce:1. Install a server
2. In my manual test the server IPv6 address WAS added to ipa-ca so I used ipa dnsrecord-del to remove it
3. Install a client
4. Install a replica with --setup-ca
5. ipa server-del replica
6. dig -t AAAA ipa-ca.DOMAIN

Actual results:
The replica AAAA record is listed.

Expected results:


Additional info:

--- Additional comment from Florence Blanc-Renaud on 2023-01-06 15:15:26 UTC ---

Sudhir, can you add a bit more info?

> 1. Install a server
which options are provided? Is --ip-address provided (with IPv4, with IPv6)?

> 2. In my manual test the server IPv6 address WAS added to ipa-ca so I used ipa dnsrecord-del to remove it
Was the server IPv6 address also added to the server DNS records?

> 3. Install a client
> 4. Install a replica with --setup-ca
Is --ip-address provided (with IPv4, IPv6)?

> 5. ipa server-del replica
> 6. dig -t AAAA ipa-ca.DOMAIN
>
> Actual results:
> The replica AAAA record is listed.

--- Additional comment from Rob Crittenden on 2023-01-06 15:41:54 UTC ---

Flo, for clarity the failing test we reproduced this with is ipatests/test_integration/test_ipahealthcheck::TestIpaHealthCheck::test_ipahealthcheck_ca_not_configured

Sudir ran the tests and we watched the logs live as the servers were installed.

The initial server created only a DNS A record for ipa-ca.

The replica was installed via promotion, so client install first, then ipa-replica-install --setup-ca.

This added both an A and an AAAA record for ipa-ca.

Based on the servers install logs:

ipa-server-install: no address was passed in
ipa-replica-install: the IPv4 address was passed in

One major difference is the order in which ipa-client-install is executed. The replica runs it first so there are already A and AAAA records for itself when the server install completes and I suspect that is why the AAAA record is added to ipa-ca (not that this is wrong).

But there is still an issue in ipa-ca cleanup. My working assumption is that the last record of a given type gets orphaned.

I suppose there is also a bug in that the initial install doesn't get an IPv6 address in ipa-ca.

DNS looked like this after the replica install was completed:

# dig -t A ipa-ca.example.test.
;; ANSWER SECTION:
ipa-ca.example.test.  1       IN      A       0.0.0.83
ipa-ca.example.test.  1       IN      A       0.0.0.175

# dig -t AAAA ipa-ca.example.test.
;; ANSWER SECTION:
ipa-ca.example.test.  1       IN      AAAA    aaaa:52:0:a9:f816:3eff:fe3a:951b

The test uninstalls the replica and then re-installs it without a CA. The same queries post install look like:

# dig -t A ipa-ca.example.test.
;; ANSWER SECTION:
ipa-ca.example.test.  1       IN      A       0.0.0.83

# dig -t AAAA ipa-ca.example.test.
;; ANSWER SECTION:
ipa-ca.example.test.  1       IN      AAAA    aaaa:52:0:a9:f816:3eff:fe3a:951b

So the IPv6 address got left behind somehow.

--- Additional comment from Florence Blanc-Renaud on 2023-01-06 16:01:08 UTC ---

Rob, thanks for the clarifications.
Could this be somehow related to https://pagure.io/freeipa/issue/9195, for which there is a PR in progress https://github.com/freeipa/freeipa/pull/6358 Wipe the ipa-ca DNS record when updating system records ?

--- Additional comment from Rob Crittenden on 2023-01-06 16:50:53 UTC ---

Yes, it could be the same issue. I've started working on the the PR again.