0

BIND 9.19 Planning: Refactoring zone.c

Matthijs Mekking edited this page 2021-11-04 08:35:52 +00:00

Table of Contents

• The problems with zone.c

Back to agenda: https://gitlab.isc.org/isc-projects/bind9/-/wikis/BIND-9.19-Plan

Attendees: Mark, Matthijs, Petr, Michał K, Michal N., Aram, Artem, Evan.

tl;dr: We identified the issues with zone.c and think the refactoring of this file can be done in parallel with the refactoring of RBTDB.

The problems with zone.c

Mark: There are a couple of issues:

• inline-signing and ixfr-from-differences. We can only apply the differences if we're already up & running when we try to apply the differences; we don't maintain a separate copy of the zone as it was when the server stopped.
• It would be nice to get rid of the two instances of the zone structure for inline zones (coalesce them - that would help with locking).
• The two above issues might have a commonality between them; if we get rid of all the DNSSEC records in a signed zone, the signed instance has a copy of the unsigned zone inside - we can recover that; we can diff against the unsigned records in the signed instance and the records in the unsigned instance;
• We need to be able to push off ZONEMD processing - sending zone processing out to event processing (splitting the process into smaller chunks) - zone_postload() needs to be split in two, made restartable, or... maybe do ixfr-from-differences incrementally as well, same as ZONEMD

Matthijs: does it make sense to split ZONEMD into chunks?

Mark: you still want queries to be handled.

Matthijs: sure, we should offload, but splitting into chunks? It is a process about validation and we can't do much with the zone object until the validation has completed.

Mark: we can generate the hash incrementally; that should improve our response time elsewhere in the system

Matthijs: not sure... pushing it off should also help with response times; best to extract it out to a separate process; the amount of locking happening when we split things into chunks also comes at a cost; wonder if we could do a different approach without the splitting part.

Michal: do we have an extra "offload" thread to process long-term stuff? "over" the CPU count?

Artem: we were supposed to have a thread pool and it should just run wherever it wants, without any CPU pinning; I think it should work just fine.

Michal: agrees, this is the simplest solution; let's stick to that if we can make it work

Petr agrees. Matthijs agrees.

Matthijs: apart from the things Mark mentioned, the only other thing I can think of is "simple" refactoring - splitting up functions into smaller units, maybe even shorter files? would make that easier to comprehend

Evan: low-hanging fruit: move dns_zonemgr to its own file

Matthijs: There is also the notify, soa query stuff.

Mark: the reason so many stuff is in there is because it accesses the zone object (encapsulation)

Matthijs: we can always revise the zone API.

Evan: we can also have the zone structure in zone.h or in zone_p.h.

Mark: most of it is just managing the zone themselves and putting them on a linked list etc.; collapsing the two zone instances may get rid of Coverity reports about locking issues; I believe they are all false positives, but...

Matthijs: would it make sense to do that in 9.19? if so, at what point in the 9.19 release? it seems we can do that in parallel with RBTDB refactoring

Mark: agrees.