GitLab

Hold qid->lock when calling deref_portentry() as

See merge request !4302

socket_search() need portentry to be unchanging.

    WARNING: ThreadSanitizer: data race
    Write of size 8 at 0x000000000001 by thread T1 (mutexes: write M1):
    #0 deref_portentry lib/dns/dispatch.c:630
    #1 deactivate_dispsocket lib/dns/dispatch.c:861
    #2 udp_recv lib/dns/dispatch.c:1105
    #3 udp_exrecv lib/dns/dispatch.c:1028
    #4 dispatch lib/isc/task.c:1152
    #5 run lib/isc/task.c:1344
    #6 <null> <null>

    Previous read of size 8 at 0x000000000001 by thread T2 (mutexes: write M1, write M2):
    #0 socket_search lib/dns/dispatch.c:661
    #1 get_dispsocket lib/dns/dispatch.c:744
    #2 dns_dispatch_addresponse lib/dns/dispatch.c:3120
    #3 resquery_send lib/dns/resolver.c:2467
    #4 fctx_query lib/dns/resolver.c:2217
    #5 fctx_try lib/dns/resolver.c:4245
    #6 fctx_timeout lib/dns/resolver.c:4570
    #7 dispatch lib/isc/task.c:1152
    #8 run lib/isc/task.c:1344
    #9 <null> <null>

(cherry picked from commit 5c253c41)

DNS_ZONEFLAG_NOIXFR should be DNS_ZONEFLG_NOIXFR

See merge request !4300

(cherry picked from commit 3a044444)

Fix the problems found when writing the unit test for netmgr

See merge request !4294

(cherry picked from commit 58a0e959)

(cherry picked from commit 8797e5ef)

When client disconnects before the connection can be accepted, the named
would log a spurious log message:

    error: Accepting TCP connection failed: socket is not connected

We now ignore the ISC_R_NOTCONNECTED result code and log only other
errors

(cherry picked from commit 5ef71c42)

1. The isc__nm_tcp_send() and isc__nm_tcp_read() was not checking
   whether the socket was still alive and scheduling reads/sends on
   closed socket.

2. The isc_nm_read(), isc_nm_send() and isc_nm_resumeread() have been
   changed to always return the error conditions via the callbacks, so
   they always succeed.  This applies to all protocols (UDP, TCP and
   TCPDNS).

(cherry picked from commit f7c82e40)

There were two problems how tcp_send_direct() was used:

1. The tcp_send_direct() can return ISC_R_CANCELED (or translated error
   from uv_tcp_send()), but the isc__nm_async_tcpsend() wasn't checking
   the error code and not releasing the uvreq in case of an error.

2. In isc__nm_tcp_send(), when the TCP send is already in the right
   netthread, it uses tcp_send_direct() to send the TCP packet right
   away.  When that happened the uvreq was not freed, and the error code
   was returned to the caller.  We need to return ISC_R_SUCCESS and
   rather use the callback to report an error in such case.

(cherry picked from commit 6af08d1c)

(cherry picked from commit d72bc3eb)

When closing the socket that is actively reading from the stream, the
read_cb() could be called between uv_close() and close callback when the
server socket has been already detached hence using sock->statichandle
after it has been already freed.

(cherry picked from commit 97b33e5b)

(cherry picked from commit ff0a336d)

isc_uv_export can return an error - e.g. EMFILE (from dup), handle this
nicely.

(cherry picked from commit ae9a6bef)

There were two problems how udp_send_direct() was used:

1. The udp_send_direct() can return ISC_R_CANCELED (or translated error
   from uv_udp_send()), but the isc__nm_async_udpsend() wasn't checking
   the error code and not releasing the uvreq in case of an error.

2. In isc__nm_udp_send(), when the UDP send is already in the right
   netthread, it uses udp_send_direct() to send the UDP packet right
   away.  When that happened the uvreq was not freed, and the error code
   was returned to the caller.  We need to return ISC_R_SUCCESS and
   rather use the callback to report an error in such case.

(cherry picked from commit afca2e3b)

[v9_16] Ensure use of "echo_i" where possible

See merge request !4290

In many instances 'echo "I:' construct was used where echo_i function
should have been.

Merge 9.16.8 release branch

See merge request !4288

Prepare release notes for BIND 9.16.8

See merge request isc-private/bind9!217

Resolve "stub zone foiled by minimal-responses"

See merge request !4282

After the updates from this branch, BIND now sends glue records for
NS queries even when configured with minimal-responses yes.

This test is very simple, two nameserver instances are created:
    - ns4: master, with 'minimal-responses yes', authoritative
        for example. zone
    - ns5: slave, stub zone

The first thing verified is the transfer of zone data from master
to slave, which should be saved in ns5/example.db.

After that, a query is issued to ns5 asking for target.example.
TXT, a record present in the master database with the "test" string
as content.

If that query works, it means stub zone successfully request
nameserver addresses from master, ns4.example. A/AAAA

The presence of both A/AAAA records for ns4 is also verified in the
stub zone local file, ns5/example.db.

Stub zones don't make use of AXFR/IXFR for the transfering of zone
data, instead, a single query is issued to the master asking for
their nameserver records (NS).

That works fine unless master is configured with 'minimal-responses'
set to yes, in which case glue records are not provided by master
in the answer with nameservers authoritative for the zone, leaving
stub zones with incomplete databases.

This commit fix this problem in a simple way, when the answer with
the authoritative nameservers is received from master (stub_callback),
for each nameserver listed (save_nsrrset), a A and AAAA records for
the name is verified in the additional section, and if not present
a query is created to resolve the corresponsing missing glue.

A struct 'stub_cb_args' was added to keep relevant information for
performing a query, like TSIG key, udp size, dscp value, etc, this
information is borrowed from, and created within function 'ns_query',
where the resolving of nameserver from master starts.

A new field was added to the struct 'dns_stub', an atomic integer,
namely pending_requests, which is used to keep how many queries are
created when resolving nameserver addresses that were missing in
the glue.

When the value of pending_requests is zero we know we can release
resources, adjust zone timers, dump to zone file, etc.

Don't increment network error stats on UV_EOF

See merge request !4277

When networking statistics was added to the netmgr (in commit
5234a8e0), two lines were added that
increment the 'STATID_RECVFAIL' statistic: One if 'uv_read_start'
fails and one at the end of the 'read_cb'.  The latter happens
if 'nread < 0'.

According to the libuv documentation, I/O read callbacks (such as for
files and sockets) are passed a parameter 'nread'. If 'nread' is less
than 0, there was an error and 'UV_EOF' is the end of file error, which
you may want to handle differently.

In other words, we should not treat EOF as a RECVFAIL error.

(cherry picked from commit 6c5ff942)

Fix dnstap system test on FreeBSD

See merge request !4275

This commit ensures that dnstap output files captured
by fstrm_capture are properly flushed before any attempt
on reading them with dnstap-read is done.

By reading fstrm-capture source code it was noticed that
signal SIGHUP is used to flush the capture file.

Drop the expected minimum number of buckets to 4.

See merge request !4265