GitLab

Joey Salazar authored Jan 10, 2019 and Evan Hunt committed Mar 14, 2019

Test named logs control characters, special characters and large cmd line respectively as octal escaped, special escaped and elipsis

Ondřej Surý authored Dec 21, 2018 and Evan Hunt committed Mar 14, 2019

- Print control characters in octal
- Shorten using an ellipsis when necessary

Resolve "Cppcheck format issues."

Closes #938

See merge request !1685

Resolve "Assert the hevent->rdataset is non-NULL."

Closes #890

See merge request !1543

Merge branch '937-potential-null-pointer-dereference-in-bin-tests-system-dlzexternal-driver-c' into 'master'

Resolve "potential null pointer dereference in bin/tests/system/dlzexternal/driver.c"

Closes #937

See merge request !1683

missing #include <isc/lang.h>

See merge request !1687

A bit more cleanup in the dnssec-keygen manual

See merge request !1678

Tony Finch authored Mar 13, 2019 and Mark Andrews committed Mar 14, 2019

Remove another remnant of shared secret HMAC-MD5 support.

Explain that with currently recommended setups DNSKEY records are
inserted automatically, but you can still use $INCLUDE in other cases.

placeholder

See merge request !1681

Resolve "Missing unlocks in sdlz.c"

Closes #936

See merge request !1677

clean up ECS before reusing clients

Closes #881

See merge request !1675

fix race in socket code

Closes #834

See merge request !1671

When sending an udp query (resquery_send) we first issue an asynchronous
isc_socket_connect and increment query->connects, then isc_socket_sendto2
and increment query->sends.
If we happen to cancel this query (fctx_cancelquery) we need to cancel
all operations we might have issued on this socket. If we are under very high
load the callback from isc_socket_connect (resquery_udpconnected) might have
not yet been fired. In this case we only cancel the CONNECT event on socket,
and ignore the SEND that's waiting there (as there is an `else if`).
Then we call dns_dispatch_removeresponse which kills the dispatcher socket
and calls isc_socket_close - but if system is under very high load, the send
we issued earlier might still not be complete - which triggers an assertion
because we're trying to close a socket that's still in use.

The fix is to always check if we have incomplete sends on the socket and cancel
them if we do.

Silence a Perl warning output by stop.pl

See merge request isc-projects/bind9!1649

On Unix systems, the CYGWIN environment variable is not set at all when
BIND system tests are run.  If a named instance crashes on shutdown or
otherwise fails to clean up its pidfile and the CYGWIN environment
variable is not set, stop.pl will print an uninitialized value warning
on standard error.  Prevent this by using defined().

Allow ifconfig to be called from any directory

See merge request isc-projects/bind9!1563

Petr Menšík authored Feb 25, 2019 and Mark Andrews committed Mar 11, 2019

ifconfig.sh depends on config.guess for platform guessing. It uses it to
choose between ifconfig or ip tools to configure interfaces. If
system-wide automake script is installed and local was not found, use
platform guess. It should work well on mostly any sane platform. Still
prefers local guess, but passes when if cannot find it.

Stabilize "delzsk.example" zone checks

See merge request isc-projects/bind9!1640

When a zone is converted from NSEC to NSEC3, the private record at zone
apex indicating that NSEC3 chain creation is in progress may be removed
during a different (later) zone_nsec3chain() call than the one which
adds the NSEC3PARAM record.  The "delzsk.example" zone check only waits
for the NSEC3PARAM record to start appearing in dig output while private
records at zone apex directly affect "rndc signing -list" output.  This
may trigger false positives for the "autosign" system test as the output
of the "rndc signing -list" command used for checking ZSK deletion
progress may contain extra lines which are not accounted for.  Ensure
the private record is removed from zone apex before triggering ZSK
deletion in the aforementioned check.

Also future-proof the ZSK deletion progress check by making it only look
at lines it should care about.

"dnssec" system test tweaks

Closes #129

See merge request isc-projects/bind9!1545

For checks querying a named instance with "dnssec-accept-expired yes;"
set, authoritative responses have a TTL of 300 seconds.  Assuming empty
resolver cache, TTLs of RRsets in the ANSWER section of the first
response to a given query will always match their authoritative
counterparts.  Also note that for a DNSSEC-validating named resolver,
validated RRsets replace any existing non-validated RRsets with the same
owner name and type, e.g. cached from responses received while resolving
CD=1 queries.  Since TTL capping happens before a validated RRset is
inserted into the cache and RRSIG expiry time does not impose an upper
TTL bound when "dnssec-accept-expired yes;" is set and, as pointed out
above, the original TTLs of the relevant RRsets equal 300 seconds, the
RRsets in the ANSWER section of the responses to expiring.example/SOA
and expired.example/SOA queries sent with CD=0 should always be exactly
120 seconds, never a lower value.  Make the relevant TTL checks stricter
to reflect that.

Always expecting a TTL of exactly 300 seconds for RRsets found in the
ADDITIONAL section of responses received for CD=1 queries sent during
TTL capping checks is too strict since these responses will contain
records cached from multiple DNS messages received during the resolution
process.

In responses to queries sent with CD=1, ns.expiring.example/A in the
ADDITIONAL section will come from a delegation returned by ns2 while the
ANSWER section will come from an authoritative answer returned by ns3.
If the queries to ns2 and ns3 happen at different Unix timestamps,
RRsets cached from the older response will have a different TTL by the
time they are returned to dig, triggering a false positive.

Allow a safety margin of 60 seconds for checks inspecting the ADDITIONAL
section of responses to queries sent with CD=1 to fix the issue.  A
safety margin this large is likely overkill, but it is used nevertheless
for consistency with similar safety margins used in other TTL capping
checks.

Commit c032c54d inadvertently changed
the DNS message section inspected by one of the TTL capping checks from
ADDITIONAL to ANSWER, introducing a discrepancy between that check's
description and its actual meaning.  Revert to inspecting the ADDITIONAL
section in the aforementioned check.

Changes introduced by commit 6b8e4d6e
were incomplete as not all time-sensitive checks were updated to match
revised "nta-lifetime" and "nta-recheck" values.  Prevent rare false
positives by updating all NTA-related checks so that they work reliably
with "nta-lifetime 12s;" and "nta-recheck 9s;".  Update comments as well
to prevent confusion.

Merge branch '803-add-return-code-to-allow-dlz-s-allowzonexfr-to-fall-back-to-to-the-view-s-allow-transfer-setting' into 'master'

Resolve "Add return code to allow dlz's allowzonexfr to fall back to to the view's allow-transfer setting."

Closes #803

See merge request isc-projects/bind9!1292