Commits (4)
-
Michał Kępień authored
Due to the way the "mirror" system test is set up, it is impossible for the "verify-unsigned" and "verify-untrusted" zones to contain any serial number other than the original one present in ns2/verify.db.in. Thus, using presence of a different serial number in the SOA records of these zones as an indicator of problems with mirror zone verification is wrong. Look for the original zone serial number instead as that is the one that will be returned by ns3 if one of the aforementioned zones is successfully verified.
46480a4b -
Michał Kępień authored
In the "mirror" system test, ns3 periodically sends trust anchor telemetry queries to ns1 and ns2. It may thus happen that for some non-recursive queries for names inside mirror zones which are not yet loaded, ns3 will be able to synthesize a negative answer from the cached records it obtained from trust anchor telemetry responses. In such cases, NXDOMAIN responses will be sent with the root zone SOA in the AUTHORITY section. Since the root zone used in the "mirror" system test has the same serial number as ns2/verify.db.in and zone verification checks look for the specified serial numbers anywhere in the answer, the test could be broken if different zone names were used. The +noauth dig option could be used to address this weakness, but that would prevent entire responses from being stored for later inspection, which in turn would hamper troubleshooting test failures. Instead, use a different serial number for ns2/verify.db.in than for any other zone used in the "mirror" system test and check the number of records in the ANSWER section of each response.
2cbf1028 -
Michał Kępień authored
The "mirror" system test checks whether log messages announcing a mirror zone coming into effect are emitted properly. However, the helper functions responsible for waiting for zone transfers and zone loading to complete do not wait for these exact log messages, but rather for other ones preceding them, which introduces a possibility of false positives. This problem cannot be addressed by just changing the log message to look for because the test still needs to discern between transferring a zone and loading a zone. Add two new log messages at debug level 99 (which is what named instances used in system tests are configured with) that are to be emitted after the log messages announcing a mirror zone coming into effect. Tweak the aforementioned helper functions to only return once the log messages they originally looked for are followed by the newly added log messages. This reliably prevents races when looking for "mirror zone is now in use" log messages and also enables a workaround previously put into place in the "mirror" system test to be reverted.
9c611dd9 -
Michał Kępień authored
Improve stability of mirror zone system tests See merge request !1505
724663c1
Showing