1. 17 Jun, 2021 9 commits
  2. 16 Jun, 2021 14 commits
  3. 15 Jun, 2021 2 commits
    • Mark Andrews's avatar
      Merge branch... · f035a22c
      Mark Andrews authored
      Merge branch '2739-threadsanitizer-data-race-lib-isc-task-c-435-in-task_send-unprotected-access-to-task-threadid' into 'main'
      
      Resolve "ThreadSanitizer: data race lib/isc/task.c:435 in task_send (unprotected access to `task->threadid`)"
      
      Closes #2739
      
      See merge request !5149
      f035a22c
    • Mark Andrews's avatar
      Lock access to task->threadid · 234ad2d0
      Mark Andrews authored
      234ad2d0
  4. 14 Jun, 2021 8 commits
    • Artem Boldariev's avatar
      Merge branch 'artem/dig-large-doh-responses-support' into 'main' · 8d36cac8
      Artem Boldariev authored
      Fix BIND and dig to support large DNS messages over DoH, disable XFRs over DoH
      
      See merge request !5148
      8d36cac8
    • Evan Hunt's avatar
      CHANGES · f8caebe1
      Evan Hunt authored
      Mention that XFRs over DoH are explicitly disabled for now.
      f8caebe1
    • Artem Boldariev's avatar
      Set sock->iface and sock->peer properly for layered connection types · ccd2267b
      Artem Boldariev authored
      This change sets the mentioned fields properly and gets rid of klusges
      added in the times when we were keeping pointers to isc_sockaddr_t
      instead of copies. Among other things it helps to avoid a situation
      when garbage instead of an address appears in dig output.
      ccd2267b
    • Artem Boldariev's avatar
      Make BIND refuse to serve XFRs over DoH · b84fa122
      Artem Boldariev authored
      We cannot use DoH for zone transfers.  According to RFC8484 a DoH
      request contains exactly one DNS message (see Section 6: Definition of
      the "application/dns-message" Media Type,
      https://datatracker.ietf.org/doc/html/rfc8484#section-6).  This makes
      DoH unsuitable for zone transfers as often (and usually!) these need
      more than one DNS message, especially for larger zones.
      
      As zone transfers over DoH are not (yet) standardised, nor discussed
      in RFC8484, the best thing we can do is to return "not implemented."
      
      Technically DoH can be used to transfer small zones which fit in one
      message, but that is not enough for the generic case.
      
      Also, this commit makes the server-side DoH code ensure that no
      multiple responses could be attempted to be sent over one HTTP/2
      stream. In HTTP/2 one stream is mapped to one request/response
      transaction. Now the write callback will be called with failure error
      code in such a case.
      b84fa122
    • Artem Boldariev's avatar
      Pass an HTTP handle to the read callback when finishing a stream · 009752ca
      Artem Boldariev authored
      This commit fixes a leftover from an earlier version of the client-side
      DoH code when the underlying transport handle was used directly.
      009752ca
    • Artem Boldariev's avatar
      Fix a crash in the client-side DoH code (header processing callback) · d5d20ceb
      Artem Boldariev authored
      Support a situation in header processing callback when client side
      code could receive a belated response or part of it. That could
      happen when the HTTP/2 session was already closed, but there were some
      response data from server in flight. Other client-side nghttp2
      callbacks code already handled this case.
      
      The bug became apparent after HTTP/2 write buffering was supported,
      leading to rare unit test failures.
      d5d20ceb
    • Artem Boldariev's avatar
      Nullify connect.cstream in time and keep track of all client streams · 2dfc0d9a
      Artem Boldariev authored
      This commit ensures that sock->h2.connect.cstream gets nullified when
      the object in question is deleted. This fixes a nasty crash in dig
      exposed when receiving large responses leading to double free()ing.
      
      Also, it refactors how the client-side code keeps track of client
      streams (hopefully) preventing from similar errors appearing in the
      future.
      2dfc0d9a
    • Artem Boldariev's avatar
      Fix BIND to serve large HTTP responses · 5b507c11
      Artem Boldariev authored
      This commit makes NM code to report HTTP as a stream protocol. This
      makes it possible to handle large responses properly. Like:
      
      dig +https @127.0.0.1 A cmts1-dhcp.longlines.com
      5b507c11
  5. 13 Jun, 2021 2 commits
  6. 12 Jun, 2021 1 commit
  7. 10 Jun, 2021 4 commits
    • Michał Kępień's avatar
      Merge branch '2759-fix-no-ds-proofs-for-wildcard-cname-delegations' into 'main' · e5673b89
      Michał Kępień authored
      Fix "no DS" proofs for wildcard+CNAME delegations
      
      Closes #2759
      
      See merge request !5155
      e5673b89
    • Michał Kępień's avatar
      Add release note · 16708682
      Michał Kępień authored
      16708682
    • Michał Kępień's avatar
      Add CHANGES entry · c223d816
      Michał Kępień authored
      c223d816
    • Michał Kępień's avatar
      Fix "no DS" proofs for wildcard+CNAME delegations · 7a87bf46
      Michał Kępień authored
      When answering a query requires wildcard expansion, the AUTHORITY
      section of the response needs to include NSEC(3) record(s) proving that
      the QNAME does not exist.
      
      When a response to a query is an insecure delegation, the AUTHORITY
      section needs to include an NSEC(3) proof that no DS record exists at
      the parent side of the zone cut.
      
      These two conditions combined trip up the NSEC part of the logic
      contained in query_addds(), which expects the NS RRset to be owned by
      the first name found in the AUTHORITY section of a delegation response.
      This may not always be true, for example if wildcard expansion causes an
      NSEC record proving QNAME nonexistence to be added to the AUTHORITY
      section before the delegation is added to the response.  In such a case,
      named incorrectly omits the NSEC record proving nonexistence of QNAME
      from the AUTHORITY section.
      
      The same block of code is affected by another flaw: if the same NSEC
      record proves nonexistence of both the QNAME and the DS record at the
      parent side of the zone cut, this NSEC record will be added to the
      AUTHORITY section twice.
      
      Fix by looking for the NS RRset in the entire AUTHORITY section and
      adding the NSEC record to the delegation using query_addrrset() (which
      handles duplicate RRset detection).
      7a87bf46