Bind cache is not updated when an unit change IP

[Giuseppe Petralia]

Description
===========
After removing and adding a designate bind, this changed IP.
In the other two units in /var/cache/bind/
we could still find reference to the old unit.

Expected behaviour
===========
Cache is flushed and the configuration is reloaded when a new unit is added

Workaround
===========
We manually run:

rndc flush + reconfig + reload

[Drew Freiberger (afreiberger)]

I've reproduced this with the following:

Deployed the bundle from charm-designate-bind/src/tests/bundles/focal-ussuri.yaml
Created zone with:
openstack zone create --debug --email <email address hidden> mysite.com.
Added A record in the zone:
openstack recordset create --type A --record 10.5.0.1 mysite.com. gw.mysite.com.
Looked up the record in designate-bind:
dig gw.mysite.com @10.5.0.7
    gw.mysite.com. 3600 IN A 10.5.0.1
Add a new unit with:
juju add-unit designate-bind
looked up the record on the new server after the model settles:
dig gw.mysite.com @10.5.0.12
    ;; WARNING: recursion requested but not available

When I look at the new unit, the slave.zone file has been created but is blank due to rndc RBAC failures.

I'm pulling a juju-crashdump now to attach to the bug.

[Drew Freiberger (afreiberger)]

My reproducer ran into issues on focal related to bug 1881532 which has a fix in-flight from Liam. I'll work to reproduce on bionic.

https://review.opendev.org/#/c/733600/

[Drew Freiberger (afreiberger)]

I am not able to reproduce my focal dns resolution on scaled-out units issue on bionic.

For clarity, the issue noted in bug is not a functional issue, but rather a lingering security issue that leaves old members of the bind cluster in the rndc allowed transfer cache. Worthy of cleanup, but not causing lack of DNS resolution or designate functionality.

[Drew Freiberger (afreiberger)]

When trying to re-create this, I cannot find any references in /var/cache/bind directory on any nodes to the removed unit. Was this specifically in reference to stale recordsets such as "ns1.admin.cloud-dns-name.com" within the zone files on non-new units?

@peppepetra86: Can you describe the entire workflow of both juju and openstack zone/recordset commands around the issue you've identified?

I'm wondering if your remaining units were non-leaders and thus "slaves" for purposes of requesting sync, and thus were subject to the refresh TTL on the zone files rather than the charm auto-refreshing all units' zone caches.

[Launchpad Janitor (janitor)]

[Expired for OpenStack Designate-Bind Charm because there has been no activity for 60 days.]