-
Diego Fronza authored
This commit add 4 tests for the new option: 1. Test default configuration of stale-answer-client-timeout, a value of 1.8 seconds, with stale-refresh-time disabled. 2. Test disabling of stale-answer-client-timeout. 3. Test stale-answer-client-timeout with a value of zero, in this case we take advantage of a log entry which shows that a stale answer was promptly used before an attempt to refresh the RRset is made. We also check, by activating a disabled authoritative server, that the RRset was successfully refreshed after that. 4. Test stale-answer-client-timeout 0 with stale-refresh-time 4, in this test we want to ensure a couple things: - If we have a stale RRSet entry in cache, a request must be promptly answered with this data, while BIND must also attempt to refresh the RRSet in background. - If the attempt to refresh the RRSet times out, the RRSet must have its stale-refresh-time window activated. - If a new request for the same RRSet arrives, it must be promptly answered with stale data due to stale-refresh-time being active for this RRSet, in this case no attempt to refresh the RRSet is made. - Enable authoritative server, ensure that the RRSet was not refreshed, to honor stale-refresh-time. - Wait for stale-refresh-window time pass, send another request for the same RRSet, this time we expect the answer to be the stale entry in cache being hit due to stale-answer-client-timeout 0. - Send another request, this time we expect the answer to be an active RRSet, since it must have been refreshed during the previous request.
35fd039d