1. 19 May, 2020 2 commits
  2. 21 Apr, 2020 1 commit
    • Ondřej Surý's avatar
      Complete rewrite the BIND 9 build system · 978c7b2e
      Ondřej Surý authored
      The rewrite of BIND 9 build system is a large work and cannot be reasonable
      split into separate merge requests.  Addition of the automake has a positive
      effect on the readability and maintainability of the build system as it is more
      declarative, it allows conditional and we are able to drop all of the custom
      make code that BIND 9 developed over the years to overcome the deficiencies of
      autoconf + custom Makefile.in files.
      This squashed commit contains following changes:
      - conversion (or rather fresh rewrite) of all Makefile.in files to Makefile.am
        by using automake
      - the libtool is now properly integrated with automake (the way we used it
        was rather hackish as the only official way how to use libtool is via
      - the dynamic module loading was rewritten from a custom patchwork to libtool's
        libltdl (which includes the patchwork to support module loading on different
        systems internally)
      - conversion of the unit test executor from kyua to automake parallel driver
      - conversion of the system test executor from custom make/shell to automake
        parallel driver
      - The GSSAPI has been refactored, the custom SPNEGO on the basis that
        all major KRB5/GSSAPI (mit-krb5, heimdal and Windows) implementations
        support SPNEGO mechanism.
      - The various defunct tests from bin/tests have been removed:
        bin/tests/optional and bin/tests/pkcs11
      - The text files generated from the MD files have been removed, the
        MarkDown has been designed to be readable by both humans and computers
      - The xsl header is now generated by a simple sed command instead of
        perl helper
      - The <irs/platform.h> header has been removed
      - cleanups of configure.ac script to make it more simpler, addition of multiple
        macros (there's still work to be done though)
      - the tarball can now be prepared with `make dist`
      - the system tests are partially able to run in oot build
      Here's a list of unfinished work that needs to be completed in subsequent merge
      - `make distcheck` doesn't yet work (because of system tests oot run is not yet
      - documentation is not yet built, there's a different merge request with docbook
        to sphinx-build rst conversion that needs to be rebased and adapted on top of
        the automake
      - msvc build is non functional yet and we need to decide whether we will just
        cross-compile bind9 using mingw-w64 or fix the msvc build
      - contributed dlz modules are not included neither in the autoconf nor automake
  3. 08 Apr, 2020 1 commit
    • Diego dos Santos Fronza's avatar
      Fixed rebinding protection bug when using forwarder setups · cf7b0de1
      Diego dos Santos Fronza authored
      BIND wasn't honoring option "deny-answer-aliases" when configured to
      forward queries.
      Before the fix it was possible for nameservers listed in "forwarders"
      option to return CNAME answers pointing to unrelated domains of the
      original query, which could be used as a vector for rebinding attacks.
      The fix ensures that BIND apply filters even if configured as a forwarder
      (cherry picked from commit af6a4de3)
  4. 21 Feb, 2020 1 commit
  5. 14 Feb, 2020 3 commits
    • Diego dos Santos Fronza's avatar
    • Diego dos Santos Fronza's avatar
      Fixed potential-lock-inversion · e7b36924
      Diego dos Santos Fronza authored
      This commit simplifies a bit the lock management within dns_resolver_prime()
      and prime_done() functions by means of turning resolver's attribute
      "priming" into an atomic_bool and by creating only one dependent object on the
      lock "primelock", namely the "primefetch" attribute.
      By having the attribute "priming" as an atomic type, it save us from having to
      use a lock just to test if priming is on or off for the given resolver context
      object, within "dns_resolver_prime" function.
      The "primelock" lock is still necessary, since dns_resolver_prime() function
      internally calls dns_resolver_createfetch(), and whenever this function
      succeeds it registers an event in the task manager which could be called by
      another thread, namely the "prime_done" function, and this function is
      responsible for disposing the "primefetch" attribute in the resolver object,
      also for resetting "priming" attribute to false.
      It is important that the invariant "priming == false AND primefetch == NULL"
      remains constant, so that any thread calling "dns_resolver_prime" knows for sure
      that if the "priming" attribute is false, "primefetch" attribute should also be
      NULL, so a new fetch context could be created to fulfill this purpose, and
      assigned to "primefetch" attribute under the lock protection.
      To honor the explanation above, dns_resolver_prime is implemented as follow:
      	1. Atomically checks the attribute "priming" for the given resolver context.
      	2. If "priming" is false, assumes that "primefetch" is NULL (this is
                 ensured by the "prime_done" implementation), acquire "primelock"
      	   lock and create a new fetch context, update "primefetch" pointer to
      	   point to the newly allocated fetch context.
      	3. If "priming" is true, assumes that the job is already in progress,
      	   no locks are acquired, nothing else to do.
      To keep the previous invariant consistent, "prime_done" is implemented as follow:
      	1. Acquire "primefetch" lock.
      	2. Keep a reference to the current "primefetch" object;
      	3. Reset "primefetch" attribute to NULL.
      	4. Release "primefetch" lock.
      	5. Atomically update "priming" attribute to false.
      	6. Destroy the "primefetch" object by using the temporary reference.
      This ensures that if "priming" is false, "primefetch" was already reset to NULL.
      It doesn't make any difference in having the "priming" attribute not protected
      by a lock, since the visible state of this variable would depend on the calling
      order of the functions "dns_resolver_prime" and "prime_done".
      As an example, suppose that instead of using an atomic for the "priming" attribute
      we employed a lock to protect it.
      Now suppose that "prime_done" function is called by Thread A, it is then preempted
      before acquiring the lock, thus not reseting "priming" to false.
      In parallel to that suppose that a Thread B is scheduled and that it calls
      "dns_resolver_prime()", it then acquires the lock and check that "priming" is true,
      thus it will consider that this resolver object is already priming and it won't do
      any more job.
      Conversely if the lock order was acquired in the other direction, Thread B would check
      that "priming" is false (since prime_done acquired the lock first and set "priming" to false)
      and it would initiate a priming fetch for this resolver.
      An atomic variable wouldn't change this behavior, since it would behave exactly the
      same, depending on the function call order, with the exception that it would avoid
      having to use a lock.
      There should be no side effects resulting from this change, since the previous
      implementation employed use of the more general resolver's "lock" mutex, which
      is used in far more contexts, but in the specifics of the "dns_resolver_prime"
      and "prime_done" it was only used to protect "primefetch" and "priming" attributes,
      which are not used in any of the other critical sections protected by the same lock,
      thus having zero dependency on those variables.
    • Ondřej Surý's avatar
      Reformat using the new rules · 5777c44a
      Ondřej Surý authored
  6. 13 Feb, 2020 3 commits
    • Evan Hunt's avatar
      apply the modified style · e851ed0b
      Evan Hunt authored
    • Ondřej Surý's avatar
      Use clang-tidy to add curly braces around one-line statements · 056e133c
      Ondřej Surý authored
      The command used to reformat the files in this commit was:
      ./util/run-clang-tidy \
      	-clang-tidy-binary clang-tidy-11
      	-clang-apply-replacements-binary clang-apply-replacements-11 \
      	-checks=-*,readability-braces-around-statements \
      	-j 9 \
      	-fix \
      	-format \
      	-style=file \
      clang-format -i --style=format $(git ls-files '*.c' '*.h')
      uncrustify -c .uncrustify.cfg --replace --no-backup $(git ls-files '*.c' '*.h')
      clang-format -i --style=format $(git ls-files '*.c' '*.h')
    • Ondřej Surý's avatar
      Use coccinelle to add braces to nested single line statement · 36c6105e
      Ondřej Surý authored
      Both clang-tidy and uncrustify chokes on statement like this:
      for (...)
      	if (...)
      This commit uses a very simple semantic patch (below) to add braces around such
      Semantic patch used:
      statement S;
      expression E;
      while (...)
      - if (E) S
      + { if (E) { S } }
      statement S;
      expression E;
      for (...;...;...)
      - if (E) S
      + { if (E) { S } }
      statement S;
      expression E;
      if (...)
      - if (E) S
      + { if (E) { S } }
  7. 12 Feb, 2020 1 commit
  8. 10 Feb, 2020 1 commit
  9. 08 Feb, 2020 1 commit
  10. 05 Feb, 2020 1 commit
    • Ondřej Surý's avatar
      Fix comparison between type uint16_t and wider type size_t in a loop · a9bd6f6e
      Ondřej Surý authored
      Found by LGTM.com (see below for description), and while it should not
      happen as EDNS OPT RDLEN is uint16_t, the fix is easy.  A little bit
      of cleanup is included too.
      > In a loop condition, comparison of a value of a narrow type with a value
      > of a wide type may result in unexpected behavior if the wider value is
      > sufficiently large (or small). This is because the narrower value may
      > overflow. This can lead to an infinite loop.
  11. 14 Jan, 2020 1 commit
  12. 12 Dec, 2019 1 commit
  13. 10 Dec, 2019 2 commits
  14. 02 Dec, 2019 2 commits
  15. 29 Nov, 2019 1 commit
  16. 18 Nov, 2019 1 commit
  17. 31 Oct, 2019 2 commits
    • Michał Kępień's avatar
      Prevent TCP failures from affecting EDNS stats · fce3c93e
      Michał Kępień authored
      EDNS mechanisms only apply to DNS over UDP.  Thus, errors encountered
      while sending DNS queries over TCP must not influence EDNS timeout
    • Michał Kępień's avatar
      Prevent query loops for misbehaving servers · 6cd11599
      Michał Kępień authored
      If a TCP connection fails while attempting to send a query to a server,
      the fetch context will be restarted without marking the target server as
      a bad one.  If this happens for a server which:
        - was already marked with the DNS_FETCHOPT_EDNS512 flag,
        - responds to EDNS queries with the UDP payload size set to 512 bytes,
        - does not send response packets larger than 512 bytes,
      and the response for the query being sent is larger than 512 byes, then
      named will pointlessly alternate between sending UDP queries with EDNS
      UDP payload size set to 512 bytes (which are responded to with truncated
      answers) and TCP connections until the fetch context retry limit is
      reached.  Prevent such query loops by marking the server as bad for a
      given fetch context if the advertised EDNS UDP payload size for that
      server gets reduced to 512 bytes and it is impossible to reach it using
  18. 02 Oct, 2019 2 commits
  19. 01 Oct, 2019 4 commits
  20. 13 Sep, 2019 1 commit
  21. 12 Sep, 2019 1 commit
  22. 30 Aug, 2019 1 commit
    • Ondřej Surý's avatar
      isc_event_allocate() cannot fail, remove the fail handling blocks · 50e109d6
      Ondřej Surý authored
      isc_event_allocate() calls isc_mem_get() to allocate the event structure.  As
      isc_mem_get() cannot fail softly (e.g. it never returns NULL), the
      isc_event_allocate() cannot return NULL, hence we remove the (ret == NULL)
      handling blocks using the semantic patch from the previous commit.
  23. 09 Aug, 2019 1 commit
  24. 02 Aug, 2019 1 commit
  25. 23 Jul, 2019 4 commits