1. 14 Mar, 2019 3 commits
  2. 13 Mar, 2019 1 commit
  3. 12 Mar, 2019 1 commit
    • Witold Kręcicki's avatar
      Fix a race in fctx_cancelquery. · ff401e67
      Witold Kręcicki authored and Evan Hunt's avatar Evan Hunt committed
      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.
      (cherry picked from commit 56183a39)
  4. 08 Mar, 2019 6 commits
  5. 05 Mar, 2019 1 commit
  6. 21 Feb, 2019 5 commits
  7. 19 Feb, 2019 1 commit
  8. 18 Feb, 2019 4 commits
  9. 08 Feb, 2019 1 commit
  10. 07 Feb, 2019 3 commits
  11. 31 Jan, 2019 1 commit
    • Evan Hunt's avatar
      Change #4148 wasn't complete · a6afd50c
      Evan Hunt authored
      - there was a memory leak when using negotiated TSIG keys.
      - TKEY responses could only be signed when using a newly negotiated
        key; if an existent matching TSIG was found in in the keyring it
        would not be used.
      (cherry picked from commit 73ba24fb)
  12. 30 Jan, 2019 1 commit
  13. 29 Jan, 2019 1 commit
  14. 23 Jan, 2019 1 commit
  15. 21 Jan, 2019 1 commit
  16. 17 Jan, 2019 1 commit
    • Witold Krecicki's avatar
      If possible don't use forwarders when priming the resolver. · aa9866c3
      Witold Krecicki authored and Evan Hunt's avatar Evan Hunt committed
      If we try to fetch a record from cache and need to look into
      hints database we assume that the resolver is not primed and
      start dns_resolver_prime(). Priming query is supposed to return
      NSes for "." in ANSWER section and glue records for them in
      ADDITIONAL section, so that we can fill that info in 'regular'
      cache and not use hints db anymore.
      However, if we're using a forwarder the priming query goes through
      it, and if it's configured to return minimal answers we won't get
      the addresses of root servers in ADDITIONAL section. Since the
      only records for root servers we have are in hints database we'll
      try to prime the resolver with every single query.
      This patch adds a DNS_FETCHOPT_NOFORWARD flag which avoids using
      forwarders if possible (that is if we have forward-first policy).
      Using this flag on priming fetch fixes the problem as we get the
      proper glue. With forward-only policy the problem is non-existent,
      as we'll never ask for root server addresses because we'll never
      have a need to query them.
      Also added a test to confirm priming queries are not forwarded.
      (cherry picked from commit b49310ac)
      (cherry picked from commit f8963ad7)
  17. 16 Jan, 2019 2 commits
  18. 15 Jan, 2019 2 commits
  19. 09 Jan, 2019 4 commits