SSL_VERIFY_FAIL_IF_NO_PEER_CERT that can reject client
connections without peer cert during the handshake, which is nicer
than just a connection drop to the client (when we then check
for no peer certificate afterwards).
- Added serve-stale functionality as described in
draft-ietf-dnsop-serve-stale-10. `serve-expired-*` options can be used
to configure the behavior.
- Updated cachedb to honor `serve-expired-ttl`; Fixes#107.
- Renamed statistic `num.zero_ttl` to `num.expired` as expired replies
come with a configurable TTL value (`serve-expired-reply-ttl`).
- Fixed stats when replying with cached, cname-aliased records.
- Added missing default values for redis cachedb backend.
Add a new configure option `--with-libbsd', which allows to use libbsd's
portable implementations of:
strlcpy strlcat arc4random arc4random_uniform reallocarray
instead of the embedded code copies in contrib/, which will be
difficult to maintain in the long term.
Also patch util/random.c so that, when building with libbsd and without
OpenSSL, arc4random can still be used as the PRNG. Otherwise, building
with libnettle would need a kernel-specific getentropy implementation,
and libbsd does not export one.
[edmonds@debian.org: Imported patch description from BTS, refreshed
patch against Unbound 1.9.6.]
We cannot use a 'quick' lock (i.e. lock spinning on the CPU) for the log
lock because it can wait a lot on I/Os. Using a 'quick' lock leads to
eating the CPU for no good reason.
Example of 'pidstat' output when using various locks for log_lock:
- 'quick' lock and slow log file system (tail -f on the log file on XFS on RHEL 8)
04:15:11 PM UID TGID TID %usr %system %CPU CPU Command
04:15:21 PM 998 16431 - 100.00 4.20 100.00 2 unbound
04:15:21 PM 998 - 16431 31.00 1.00 32.00 2 |__unbound
04:15:21 PM 998 - 16432 31.30 0.80 32.10 0 |__unbound
04:15:21 PM 998 - 16433 30.20 1.40 31.60 1 |__unbound
04:15:21 PM 998 - 16434 30.70 1.00 31.70 3 |__unbound
- 'quick' lock and log file system being fast
04:15:40 PM UID TGID TID %usr %system %CPU CPU Command
04:15:50 PM 998 16431 - 10.00 1.60 11.60 1 unbound
04:15:50 PM 998 - 16431 2.50 0.50 3.00 1 |__unbound
04:15:50 PM 998 - 16432 2.30 0.40 2.70 3 |__unbound
04:15:50 PM 998 - 16433 2.70 0.30 3.00 0 |__unbound
04:15:50 PM 998 - 16434 2.60 0.40 3.00 2 |__unbound
- 'basic' lock (this commit) and slow log file system (tail -f on the log file on XFS on RHEL 8)
04:29:48 PM UID TGID TID %usr %system %CPU CPU Command
04:29:58 PM 998 11632 - 7.10 14.10 21.20 3 unbound
04:29:58 PM 998 - 11632 1.70 3.20 4.90 3 |__unbound
04:29:58 PM 998 - 11633 1.60 3.30 4.90 1 |__unbound
04:29:58 PM 998 - 11634 2.00 4.10 6.10 1 |__unbound
04:29:58 PM 998 - 11635 1.90 3.50 5.40 1 |__unbound
We can see in the above example, when 'basic' lock is used, that CPU
isn't consumed when log file system is slow.
Another reproducer scenario: put the log file on a NFS share with 'sync'
option.
