[designate] How to avoid NXDOMAIN or stale data during cold start of a (new) machine

Michael Johnson johnsomor at gmail.com
Tue Jun 7 00:04:12 UTC 2022


Hi Christian,

Sorry I misunderstood the scenario.

There are two ways zones can be resynced:
1. Using the "designate-manage pool update" command. This will force
an update/recreate of all of the zones.
2. When a zone is in ERROR or PENDING for too long, the
WorkerPeriodicRecovery task in producer will attempt to repair the
zone.

I don't think there is a periodic task that checks the BIND instances
for missing content at the moment. Adding one would have to be done
very carefully as it would be easy to get into race conditions when
new zones are being created and deployed.

Michael

On Mon, Jun 6, 2022 at 9:59 AM Christian Rohmann
<christian.rohmann at inovex.de> wrote:
>
> Hey Michael, all,
>
> sorry for the late reply, just got around to playing with Designate and
> BIND9 again ...
>
>
> On 10/05/2022 19:04, Michael Johnson wrote:
> > On startup, BIND9 will start sending SOA serial number queries for all
> > of the zones it knows about. In the case of Designate, that means
> > BIND9 will send out requests to the miniDNS instances to check if the
> > serial number in Designate is newer than the one in BIND9. If the
> > serial number in Designate is newer, BIND9 will initiate a zone
> > transfer from the miniDNS in Designate.
> >
> > BIND9, by default, will do 20 SOA serial number queries at a time
> > (less on older versions of BIND). See the serial-query-rate setting in
> > the rate limiter knowledge base article[1].
> >
> > The tuning knowledge base article[2] also discusses settings that can
> > be adjusted for secondary servers that may also help speed up a cold
> > startup.
> >
> > Off my head, I don't know of a way to tell BIND9 to not answer queries
> > via rdnc or such. I usually block network access to a new BIND9
> > instance until the "rdnc status" shows the "soa queries in progress"
> > and "xfers running" drop to 0 or a low number.
>
> Thanks for your thoughts and for distinguishing the sync of existing
> domains via AXFR/IXFR zone-transfers, because I was actually talking
> about an empty BIND9 in need to actually learn about zones.
> Maybe I was not clear about that on my initial post. But in the case of
> BIND9 not having a zone configured it requires input from designate
> before asking for the latest zone data from mDNS.
> Think about a freshly restored or a newly added server to the pool that
> requires to have ALL zones added and until then is not doing any IXFR /
> AXFR, but wrongfully sending NXDOMAIN.
>
> For new zones there is
> https://github.com/openstack/designate/blob/5d5d83e511acbf5d6f34e9a998ff16d96c5bb162/designate/backend/impl_bind9.py#L76
> which creates the zone (via rndc addzone -
> https://docs.openstack.org/designate/latest/admin/backends/bind9.html#bind9-configuration).
> and triggers mDNS.
>
> But I don't quite get how Designate would recognize that a zone is
> "missing" on one of the BIND9 servers in the pool.
> What would be the task that checks or determines that a server of the
> pool does not have some / all of the zones (anymore)?
> Is there no form of health check for backends to see if they have all
> zones? Like a simple count or comparison of the zone list?
> I'd like to form a readiness check to e.g. block all external queries
> until all zones exist. There is an open issues about this even:
> https://gitlab.isc.org/isc-projects/bind9/-/issues/3081
>
> Or is there any way / designate-manage command to trigger this or a
> re-creating of all zone for a backend or a way to remove and re-add a
> BIND9 backend to have designate
> treat it as new and not configured to then do all those "rndc addzone"
> commands?
>
>
> Regards
>
> Christian
>



More information about the openstack-discuss mailing list