1. 29 Jan, 2021 15 commits
    • Michal Nowak's avatar
      Add README.md file to rsabigexponent system test · df53930e
      Michal Nowak authored
      This README.md describes why is bigkey needed.
      (cherry picked from commit a247f24d)
    • Matthijs Mekking's avatar
      Merge branch '2247-add-serve-stale-option-to-set-client-timeout-v9_16' into 'v9_16' · 5d830664
      Matthijs Mekking authored
      Resolve "Add serve-stale option to set client timeout"
      See merge request !4625
    • Matthijs Mekking's avatar
      Rewrap comments to 80 char width serve-stale test · dba01187
      Matthijs Mekking authored
      (cherry picked from commit d8c6655d)
    • Matthijs Mekking's avatar
      Update code flow in query.c wrt stale data · 99c72bf5
      Matthijs Mekking authored
      First of all, there was a flaw in the code related to the
      'stale-refresh-time' option. If stale answers are enabled, and we
      returned stale data, then it was assumed that it was because we were
      in the 'stale-refresh-time' window. But now we could also have returned
      stale data because of a 'stale-answer-client-timeout'. To fix this,
      introduce a rdataset attribute DNS_RDATASETATTR_STALE_WINDOW to
      indicate whether the stale cache entry was returned because the
      'stale-refresh-time' window is active.
      Second, remove the special case handling when the result is
      DNS_R_NCACHENXRRSET. This can be done more generic in the code block
      when dealing with stale data.
      Putting all stale case handling in the code block when dealing with
      stale data makes the code more easy to follow.
      Update documentation to be more verbose and to match then new code
      (cherry picked from commit fa0c9280)
    • Diego Fronza's avatar
      Extracted common function from query_lookup and query_refresh_rrset · 0e62c53c
      Diego Fronza authored
      Both functions employed the same code lines to allocate query context
      buffers, which are used to store query results, so this shared portion
      of code was extracted out to a new function, qctx_prepare_buffers.
      Also, this commit uses qctx_init to initialize the query context whitin
      query_refresh_rrset function.
      (cherry picked from commit 966060c0)
    • Diego Fronza's avatar
      Small optimization in query_usestale · 5cbb28a4
      Diego Fronza authored
      This commit makes the code in query_usestale easier to follow, it also
      doesn't attach/detach to the database if stale answers are not enabled.
      (cherry picked from commit f89ac07b)
    • Diego Fronza's avatar
      Add CHANGES note for [GL #2247] · fe4e0b88
      Diego Fronza authored
      (cherry picked from commit 42c789c7)
    • Diego Fronza's avatar
      Add documentation for stale-answer-client-timeout · b89fc52c
      Diego Fronza authored
      (cherry picked from commit 6ab90704)
    • Diego Fronza's avatar
      Add system tests for stale-answer-client-timeout · bea63000
      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.
      (cherry picked from commit 35fd039d)
    • Diego Fronza's avatar
      Allow stale data to be used before name resolution · 8324c3dd
      Diego Fronza authored
      This commit allows stale RRset to be used (if available) for responding
      a query, before an attempt to refresh an expired, or otherwise resolve
      an unavailable RRset in cache is made.
      For that to work, a value of zero must be specified for
      stale-answer-client-timeout statement.
      To better understand the logic implemented, there are three flags being
      used during database lookup and other parts of code that must be
      . DNS_DBFIND_STALEOK: This flag is set when BIND fails to refresh a
        RRset due to timeout (resolver-query-timeout), its intent is to
        try to look for stale data in cache as a fallback, but only if
        stale answers are enabled in configuration.
        This flag is also used to activate stale-refresh-time window, since it
        is the only way the database knows that a resolution has failed.
      . DNS_DBFIND_STALEENABLED: This flag is used as a hint to the database
        that it may use stale data. It is always set during query lookup if
        stale answers are enabled, but only effectively used during
        stale-refresh-time window. Also during this window, the resolver will
        not try to resolve the query, in other words no attempt to refresh the
        data in cache is made when the stale-refresh-time window is active.
      . DNS_DBFIND_STALEONLY: This new introduced flag is used when we want
        stale data from the database, but not due to a failure in resolution,
        it also doesn't require stale-refresh-time window timer to be active.
        As long as there is a stale RRset available, it should be returned.
        It is mainly used in two situations:
          1. When stale-answer-client-timeout timer is triggered: in that case
             we want to know if there is stale data available to answer the
          2. When stale-answer-client-timeout value is set to zero: in that
             case, we also want to know if there is some stale RRset available
             to promptly answer the client.
      We must also discern between three situations that may happen when
      resolving a query after the addition of stale-answer-client-timeout
      statement, and how to handle them:
      	1. Are we running query_lookup() due to stale-answer-client-timeout
             timer being triggered?
             In this case, we look for stale data, making use of
             DNS_DBFIND_STALEONLY flag. If a stale RRset is available then
             respond the client with the data found, mark this query as
             answered (query attribute NS_QUERYATTR_ANSWERED), so when the
             fetch completes the client won't be answered twice.
             We must also take care of not detaching from the client, as a
             fetch will still be running in background, this is handled by the
             following snippet:
             if (!QUERY_STALEONLY(&client->query)) {
             Which basically tests if DNS_DBFIND_STALEONLY flag is set, which
             means we are here due to a stale-answer-client-timeout timer
          2. Are we running query_lookup() due to resolver-query-timeout being
             In this case, DNS_DBFIND_STALEOK flag will be set and an attempt
             to look for stale data will be made.
             As already explained, this flag is algo used to activate
             stale-refresh-time window, as it means that we failed to refresh
             a RRset due to timeout.
             It is ok in this situation to detach from the client, as the
             fetch is already completed.
          3. Are we running query_lookup() during the first time, looking for
             a RRset in cache and stale-answer-client-timeout value is set to
             In this case, if stale answers are enabled (probably), we must do
             an initial database lookup with DNS_DBFIND_STALEONLY flag set, to
             indicate to the database that we want stale data.
             If we find an active RRset, proceed as normal, answer the client
             and the query is done.
             If we find a stale RRset we respond to the client and mark the
             query as answered, but don't detach from the client yet as an
             attempt in refreshing the RRset will still be made by means of
             the new introduced function 'query_resolve'.
             If no active or stale RRset is available, begin resolution as
      (cherry picked from commit e2194225)
    • Diego Fronza's avatar
      Added option for disabling stale-answer-client-timeout · 0aebad96
      Diego Fronza authored
      This commit allows to specify "disabled" or "off" in
      stale-answer-client-timeout statement. The logic to support this
      behavior will be added in the subsequent commits.
      This commit also ensures an upper bound to stale-answer-client-timeout
      which equals to one second less than 'resolver-query-timeout'.
      (cherry picked from commit 0ad6f594)
    • Diego Fronza's avatar
      Adjusted serve-stale test · 93ca9686
      Diego Fronza authored
      After the addition of stale-answer-client-timeout a test was broken due
      to the following behavior expected by the test.
      1. Prime cache data.example txt.
      2. Disable authoritative server.
      3. Send a query for data.example txt.
      4. Recursive server will timeout and answer from cache with stale RRset.
      5. Recursive server will activate stale-refresh-time due to the previous
         failure in attempting to refresh the RRset.
      6. Send a query for data.example txt.
      7. Expect stale answer from cache due to stale-refresh-time
      window being active, even if authoritative server is up.
      Problem is that in step 4, due to the new option
      stale-answer-client-timeout, recursive server will answer with stale
      data before the actual fetch completes.
      Since the original fetch is still running in background, if we re-enable
      the authoritative server during that time, the RRset will actually be
      successfully refreshed, and stale-refresh-window will not be activated.
      The next queries will fail because they expect the TTL of the RRset to
      match the one in the stale cache, not the one just refreshed.
      To solve this, we explicitly disable stale-answer-client-timeout for
      this test, as it's not the feature we are interested in testing here
      (cherry picked from commit a12bf4b6)
    • Diego Fronza's avatar
      Add stale-answer-client-timeout option · 3478794a
      Diego Fronza authored
      The general logic behind the addition of this new feature works as
      When a client query arrives, the basic path (query.c / ns_query_recurse)
      was to create a fetch, waiting for completion in fetch_callback.
      With the introduction of stale-answer-client-timeout, a new event of
      type DNS_EVENT_TRYSTALE may invoke fetch_callback, whenever stale
      answers are enabled and the fetch took longer than
      stale-answer-client-timeout to complete.
      When an event of type DNS_EVENT_TRYSTALE triggers fetch_callback, we
      must ensure that the folowing happens:
      1. Setup a new query context with the sole purpose of looking up for
         stale RRset only data, for that matters a new flag was added
         'DNS_DBFIND_STALEONLY' used in database lookups.
          . If a stale RRset is found, mark the original client query as
            answered (with a new query attribute named NS_QUERYATTR_ANSWERED),
            so when the fetch completion event is received later, we avoid
            answering the client twice.
          . If a stale RRset is not found, cleanup and wait for the normal
            fetch completion event.
      2. In ns_query_done, we must change this part:
      	 * If we're recursing then just return; the query will
      	 * resume when recursion ends.
      	if (RECURSING(qctx->client)) {
      		return (qctx->result);
         To this:
      	if (RECURSING(qctx->client) && !QUERY_STALEONLY(qctx->client)) {
      		return (qctx->result);
         Otherwise we would not proceed to answer the client if it happened
         that a stale answer was found when looking up for stale only data.
      When an event of type DNS_EVENT_FETCHDONE triggers fetch_callback, we
      proceed as before, resuming query, updating stats, etc, but a few
      exceptions had to be added, most important of which are two:
      1. Before answering the client (ns_client_send), check if the query
         wasn't already answered before.
      2. Before detaching a client, e.g.
         isc_nmhandle_detach(&client->reqhandle), ensure that this is the
         fetch completion event, and not the one triggered due to
         stale-answer-client-timeout, so a correct call would be:
         if (!QUERY_STALEONLY(client)) {
      Other than these notes, comments were added in code in attempt to make
      these updates easier to follow.
      (cherry picked from commit 171a5b75)
    • Diego Fronza's avatar
      Added dns_view_staleanswerenabled() function · 7bf8950a
      Diego Fronza authored
      Since it takes a couple lines of code to check whether stale answers
      are enabled for a given view, code was extracted out to a proper
      (cherry picked from commit 74840ec5)
    • Diego Fronza's avatar
      Avoid iterating name twice when constructing fctx->info · f3bd2737
      Diego Fronza authored
      This is a minor performance improvement, we store the result of the
      first call to strlcat to use as an offset in the next call when
      constructing fctx->info string.
      (cherry picked from commit 49c40827)
  2. 28 Jan, 2021 20 commits
  3. 27 Jan, 2021 3 commits
  4. 26 Jan, 2021 2 commits
    • Matthijs Mekking's avatar
      Merge branch '2178-dnssec-fromlabel-ec_crash-v9_16' into 'v9_16' · 59d78bf7
      Matthijs Mekking authored
      Resolve "dnssec-keyfromlabel  ECDSAP256SHA256 error on AEP Keypers HSM"
      See merge request !4602
    • Matthijs Mekking's avatar
      Make opensslecdsa_parse use fromlabel · 4a36b6d9
      Matthijs Mekking authored
      When 'opensslecdsa_parse()' encounters a label tag in the private key
      file, load the private key with 'opensslecdsa_fromlabel()'. Otherwise
      load it from the private structure.
      This was attempted before with 'load_privkey()' and 'uses_engine()',
      but had the same flaw as 'opensslecdsa_fromlabel()' had previously,
      that is getting the private and public key separately, juggling with
      pointers between EC_KEY and EVP_PKEY, did not create a valid
      cryptographic key that could be used for signing.
      (cherry picked from commit 57ac70ad)