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

Christian Rohmann christian.rohmann at inovex.de
Mon Jun 6 16:59:41 UTC 2022


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