Calling nextpart() after reconfiguring ns1 is not safe, because the
expected log message may appear in ns5/named.run before nextpart() is
run. With the TTL for ./DNSKEY set to 20 seconds, ns5 will refresh it
after 10 seconds, by which time wait_for_log() will already have failed.
This results in a false negative.
However, just calling nextpart() before reconfiguring ns1 would
introduce a different problem: if ns5 refreshed ./DNSKEY between these
two steps, the subsequent wait_for_log() call would return immediately
as it would come across the log message about a failure while refreshing
./DNSKEY instead of the expected success. This in turn would result in
a different false negative as the root key would still be uninitialized
by the time "rndc secroots" is called.
Prevent both kinds of false negatives by:
- calling nextpart() before reconfiguring ns1, in order to prevent the
first case described above,
- looking for a more specific log message, in order to prevent the
second case described above.
Also look for a more specific log message in the first part of the
relevant check, not to fix any problem, but just to emphasize that a
different fetch result is expected in that case.
With these tweaks in place, if a (failed) ./DNSKEY refresh is scheduled
between nextpart() and reconfiguring ns1, wait_for_log() will just wait
for two more seconds (one "hour"), at which point another refresh
attempt will be made that will succeed.
(cherry picked from commit 012ca0a27d)
- wait for the transfer completion message to apear in the log instead
of the notify message. this ensures we don't check for the presense of
transfered records during the time between the notify and the
transfer.
(cherry picked from commit ad32553c1d)
4905. [bug] irs_resconf_load() ignored resolv.conf syntax errors
when "domain" or "search" options were present in that
file. [GL #110]
(cherry picked from commit 1f18d33804)
The "sortlist-v4.conf" unit test for irs_resconf_load() is always run
twice due to a duplicate entry in the "tests" table. Remove one of them
to prevent this.
(cherry picked from commit 6c09f305ae)
irs_resconf_load() stores the value returned by add_search() into ret
without consulting its current value first. This causes any previous
errors raised while parsing resolv.conf to be ignored as long as any
"domain" or "search" statement is present in the file.
Prevent this by returning early in case an error is detected while
parsing resolv.conf. Ensure that "searchlist" and "magic" members of
the created irs_resconf_t structure are always initialized before
isc_resconf_destroy() is called.
(cherry picked from commit 1f400b68a8)
- don't bail out of the loop if clients are exceeded, just count incidents
- verbosely describe expectations and results
(cherry picked from commit 86838b2a02)
