I have a huge zone receiving a constant flow of small dns updates. My
secondaries receive notifications and transfer the zone incrementally.
Cool, everything works as expected.
Nevertheless, I see this lines in my logs, constantly (every time a
change arrives incrementally):
"""
15-Jan-2023 17:49:47.662 general: info: rpz: rpz.local: new zone version
came too soon, deferring update for 28 seconds
15-Jan-2023 17:49:54.716 notify: info: client @11f80268 X.X.X.X#63514:
received notify for zone 'rpz.local'
15-Jan-2023 17:49:54.716 general: info: zone rpz.local/IN: notify from
X.X.X.X#63514: serial 8991
15-Jan-2023 17:50:15.662 general: info: rpz: rpz.local: reload start
15-Jan-2023 17:50:16.884 general: info: rpz: rpz.local: reload done
"""
Ok, my updates are coming too fast (first line). No problem, the
secondary will eventually retrieve the changes. What worries me is the
last couple of lines: The rpz zone (big, around 800.000 domains) is
being reloaded constantly and it takes a couple of seconds eating CPU,
when the incremental changes are actually pretty tiny.
I would guess the incremental changes would do an incremental change in
memory structures, not a full zone reload taking a couple of seconds and
sucking an entire CPU core.
My secondary configuration is pretty trivial:
"""
[...]
response-policy {
zone "rpz.local" policy nxdomain;
};
[...]
zone "rpz.local" {
type slave;
file "../secundarios/db.rpz.local";
allow-query { 127.0.0.1; };
allow-transfer { none; };
masters {
X.X.X.X;
};
};
"""
Is this maybe related with being a "response-policy" zone? If this is
the case and a malware RPZ is going to be BIG by definition, what would
be the suggested approach?
Thanks!
PS: I have not tried alternative secondary storage backends yet, like
"map". I am trying to understand what is going on first.
--
Jesús Cea Avión _/_/ _/_/_/ _/_/_/
j...@jcea.es - https://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/
Twitter: @jcea _/_/ _/_/ _/_/_/_/_/
jabber / xmpp:j...@jabber.org _/_/ _/_/ _/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/
"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
