5047. [bug] Messages logged for certain query processing failures
now include a more specific error description if it is
available. [GL #572]
(cherry picked from commit dc531dc340)
In some cases, setting qctx->result to DNS_R_SERVFAIL causes the value
of a 'result' variable containing a more specific failure reason to be
effectively discarded. This may cause certain query error log messages
to lack specificity despite a more accurate problem cause being
determined during query processing.
In other cases, qctx->result is set to DNS_R_SERVFAIL even though a more
specific error (e.g. ISC_R_NOMEMORY) could be explicitly indicated.
Since the response message's RCODE is derived from qctx->result using
dns_result_torcode(), which handles a number of possible isc_result_t
values and returns SERVFAIL for anything not explicitly listed, it is
fine to set qctx->result to something more specific than DNS_R_SERVFAIL
(in fact, this is already being done in a few cases). Modify most
QUERY_ERROR() calls so that qctx->result is set to a more specific error
code when possible. Adjust query_error() so that statistics are still
calculated properly. Remove the RECURSE_ERROR() macro which was
introduced exactly because qctx->result could be set to DNS_R_SERVFAIL
instead of DNS_R_DUPLICATE or DNS_R_DROP, which need special handling.
Modify dns_sdlz_putrr() so that it returns DNS_R_SERVFAIL when a DLZ
driver returns invalid RDATA, in order to prevent setting RCODE to
FORMERR (which is what dns_result_torcode() translates e.g. DNS_R_SYNTAX
to) while responding authoritatively.
(cherry picked from commit ba91243542)
When something goes wrong while recursing for an answer to a query,
query_gotanswer() sets a flag (qctx->want_stale) in the query context.
query_done() is subsequently called and it can either set up a stale
response lookup (if serve-stale is enabled) or conclude that a SERVFAIL
response should be sent. This may cause confusion when looking at query
error logs since the QUERY_ERROR() line responsible for setting the
response's RCODE to SERVFAIL is not in a catch-all branch of a switch
statement inside query_gotanswer() (like it is for authoritative
responses) but rather in a code branch which appears to have something
to do with serve-stale, even when the latter is not enabled.
Extract the part of query_done() responsible for checking serve-stale
configuration and optionally setting up a stale response lookup into a
separate function, query_usestale(), shifting the responsibility for
setting the response's RCODE to SERVFAIL to the same QUERY_ERROR() line
in query_gotanswer() which is evaluated for authoritative responses.
(cherry picked from commit cb48d410d8)
- update_log() is called to log update errors, but if those errors
occur before the zone is set (for example, when returning NOTAUTH)
it returns without logging anything.
(cherry picked from commit 395f6a1474)
getnameinfo() parameters are detected by configure. Current glibc uses
socklen_t for BUFLEN and int for flags. Because that parameters are
tested only as fallback, it does detect it different way on 32-bit
system. socklen_t is compatible with size_t type on these systems.
Try all variants with int flags, use unsigned flags as last resort.
- set up server correctly when running the second test pass
- reset stats counters before the second pass
- clean up test output
(cherry picked from commit 6d05ec7dc1)
The race condition is the timer elapses before isc__timer_create()
returns the pointer to the caller. Assigning the return pointer before
enabling the timer will fix it.
(cherry picked from commit 21966423cd)
5034. [bug] A race between threads could prevent zone maintenance
scheduled immediately after zone load from being
performed. [GL #542]
(cherry picked from commit feb2a41b7c)
Zone loading happens in a different task (zone->loadtask) than other
zone actions (zone->task). Thus, when zone_postload() is called in the
context of zone->loadtask, it may cause zone maintenance to be queued in
zone->task and another thread can then execute zone_maintenance() before
zone_postload() gets a chance to finish its work in the first thread.
This would not be a problem if zone_maintenance() accounted for this
possibility by locking the zone before checking the state of its
DNS_ZONEFLG_LOADPENDING flag. However, the zone is currently not locked
before the state of that flag is checked, which may prevent zone
maintenance from happening despite zone_postload() scheduling it. Fix
by locking the zone in zone_maintenance() before checking the state of
the zone's DNS_ZONEFLG_LOADPENDING flag.
(cherry picked from commit 56003e9f9f)
Michał Kępień
Evan Hunt
Tony FinchandEvan Hunt
Mark Andrews
Petr MenšíkandMark Andrews
Thomas JachandEvan Hunt
Tinderbox User
Zhaolong ZhangandEvan Hunt