When inline signing is enabled for a zone without creating signing keys
for it, changes subsequently applied to the raw zone will not be
reflected in the secure zone due to the dns_update_signaturesinc() call
inside receive_secure_serial() failing. Given that an inline zone will
be served (without any signatures) even with no associated signing keys
being present, keep applying raw zone deltas to the secure zone until
keys become available in an attempt to follow the principle of least
astonishment.
(cherry picked from commit 6acf326969)
If a raw zone is modified, but the dns_update_signaturesinc() call in
receive_secure_serial() fails, the corresponding secure zone's database
will not be modified, even though by that time a message containing the
bumped signed serial will already have been logged. This creates
confusion, because a different secure zone version will be served than
the one announced in the logs. Move the relevant dns_zone_log() call so
that it is only performed if the secure zone's database is modified.
(cherry picked from commit cfbc8e264d)
Replace dns_fixedname_init() calls followed by dns_fixedname_name()
calls with calls to dns_fixedname_initname() where it is possible
without affecting current behavior and/or performance.
This patch was mostly prepared using Coccinelle and the following
semantic patch:
@@
expression fixedname, name;
@@
- dns_fixedname_init(&fixedname);
...
- name = dns_fixedname_name(&fixedname);
+ name = dns_fixedname_initname(&fixedname);
The resulting set of changes was then manually reviewed to exclude false
positives and apply minor tweaks.
It is likely that more occurrences of this pattern can be refactored in
an identical way. This commit only takes care of the low-hanging fruit.
(cherry picked from commit 4df4a8e731)
A typo in commit d39ab7440e introduced a bug in zone database reference
counting which leads to a crash if dumping one version of a slave zone
is not finished by the time transferring a newer version from a master
completes. Correct the typo to fix reference counting, thus preventing
crashes.
(cherry picked from commit fbd5658db7)
generated into builddir. If out-of-tree build is used, make unit
will always fail. Kyuafiles and testdata still have to be copied
manually into the builddir.
(cherry picked from commit 95cde3608a)
Instead of checking current dnstap output file size and potentially
synchronously calling dns_dt_reopen() upon every call to dns_dt_send():
- call dns_dt_reopen() asynchronously by queuing an event to the task
specified at dnstap environment creation time,
- ensure no roll event is outstanding before checking dnstap output
file size and potentially queuing another roll event.
This causes dnstap output files to exceed their configured size limits,
but prevents any two threads from performing the roll simultaneously
(which causes crashes).
Instead of relying on the caller to set up task-exclusive mode, make
dns_dt_reopen() enforce task-exclusive mode itself, using the task
specified at dnstap environment creation time.
Implement a new variant of dns_dt_create() to enable a dnstap
environment structure to hold the task in the context of which
dns_dt_reopen() will be executed.
Remove a block of code which dates back to commit 8a2ab2b920, when
dns_zone_asyncload() did not yet check DNS_ZONEFLG_LOADPENDING.
Currently, no race in accessing DNS_ZONEFLG_LOADPENDING is possible any
more, because:
- dns_zone_asyncload() is still the only function which may queue
zone_asyncload(),
- dns_zone_asyncload() accesses DNS_ZONEFLG_LOADPENDING under a lock
(and potentially queues an event under the same lock),
- DNS_ZONEFLG_LOADPENDING is not cleared until the load actually
completes.
Thus, the rechecking code can be safely removed from zone_asyncload().
Note that this also brings zone_asyncload() to a state in which the
completion callback is always invoked. This is required to prevent
leaking memory in case something goes wrong in zone_asyncload() and a
zone table the zone belongs to is indefinitely left with a positive
reference count.
Code handling cancellation of asynchronous zone load events was likely
copied over from other functions when asynchronous zone loading was
first implemented in commit 8a2ab2b920. However, unlike those other
functions, asynchronous zone loading events currently have no way of
getting canceled once they get posted, which means the aforementioned
code is effectively dead. Remove it to prevent confusion.
zone_load() is not always synchronous, it may only initiate an
asynchronous load and return DNS_R_CONTINUE, which means zone loading
has not yet been completed. In such a case, zone_asyncload() must not
clear DNS_ZONEFLG_LOADPENDING immediately and leave that up to
zone_postload().
