When a resolver priming attempt completes, the following message is
currently logged:
resolver priming query complete
This message is identical for both successful and failed priming
attempts. Consider the following log excerpts:
- successful priming attempt:
10-Feb-2022 11:33:11.272 all zones loaded
10-Feb-2022 11:33:11.272 running
10-Feb-2022 11:33:19.722 resolver priming query complete
- failed priming attempt:
10-Feb-2022 11:33:29.978 all zones loaded
10-Feb-2022 11:33:29.978 running
10-Feb-2022 11:33:38.432 timed out resolving '_.org/A/IN': 2001:500:9f::42#53
10-Feb-2022 11:33:38.522 timed out resolving './NS/IN': 2001:500:9f::42#53
10-Feb-2022 11:33:42.132 timed out resolving '_.org/A/IN': 2001:500:12::d0d#53
10-Feb-2022 11:33:42.285 timed out resolving './NS/IN': 2001:500:12::d0d#53
10-Feb-2022 11:33:44.685 resolver priming query complete
Include the result of each priming attempt in the relevant log message
to give the administrator better insight into named's resolver priming
process.
The UV_RUNTIME_CHECK() macro requires to keep the function name in sync
like this:
r = func(...);
UV_RUNTIME_CHECK(func, r);
Add semantic patch to keep the function name and return variable in sync
with the previous line.
When libuv functions fail, they return correct return value that could
be useful for more detailed debugging. Currently, we usually just check
whether the return value is 0 and invoke assertion error if it doesn't
throwing away the details why the call has failed. Unfortunately, this
often happen on more exotic platforms.
Add a UV_RUNTIME_CHECK() macro that can be used to print more detailed
error message (via uv_strerror() before ending the execution of the
program abruptly with the assertion.
Add a note to the DNSSEC guide and to the ARM reference that A ZSK/KSK
pair used for signing your zone should have the same algorithm.
This commit also updates the 'dnssec-policy/keys' example to use the
slightly more modern 'rsasha256' algorithm.
For users it's not really important if a RFC is Internet Standard,
Proposed Standard, or Experimental. RFCs are now regrouped by
"Protocol", Best Current Practice, and "catch all" category FYI.
After the build system refactoring, we no longer call AM_PROG_CC_C_O
because it is obsolescent macro. According to the automake manual the
`AC_PROG_CC` has been rewritten in automake 1.14 to not required the
call, thus we need to require at least automake version 1.14.
In autoconf, the AC_INIT() accepts bugreport address for reporting
issues (f.e. when the test suite fails). Instead of providing generic
emails address, change this to the address where to report with the
default Bug template applied.
The task exclusive mode stops all processing (tasks and networking IO)
except the designated exclusive task events. This has impact on the
operation of the server. Add log messages indicating when we start the
exclusive mode, and when we end exclusive task mode.
There are reported occurences where the statitic counters underflows and
starts reporting non-sense.
Add a check for the underflow, when ``named`` is compiled in the
developer mode.
Replace the hard-coded paths for various BIND 9 files (configuration,
pid, etc.) in the man pages and ARM with compile-time values using the
sphinx-build replace system.
This is more complicated, because the restructured text specification
doesn't allow |substitions| inside ``code-blocks``, so for each specific
file we had to create own substition which is sub-optimal, but it is
only way how to do this without adding Sphinx extension.
The isc_thread_setaffinity call was removed in !5265 and we are not
going to restore it because it was proven that the performance is better
without it. Additionally, remove the already disabled cpu system test.
The isc_thread_setconcurrency function is unused and also calling
pthread_setconcurrency() on Linux has no meaning, formerly it was
added because of Solaris in 2001 and it was removed when taskmgr was
refactored to run on top of netmgr in !4918.
The "suppr-lsan.txt" file needs to be referenced with GitLab-specific
variable, otherwise AddressSanitizer won't find it outside the
"isc-projects" project group.
This has been introduced in 8a4f098dee.
When there are more than one tokens initialized in SoftHSMv2,
care must be taken to correctly identify them.
Use a SoftHSMv2 token label which will uniquely identify the
token used for this test.
Use the "--token-label" parameter for the `pkcs11-tool` program
to make sure that it finds and uses the correct token.