1. 25 May, 2020 2 commits
  2. 22 May, 2020 3 commits
  3. 20 May, 2020 6 commits
  4. 13 May, 2020 1 commit
  5. 05 May, 2020 2 commits
  6. 02 May, 2020 6 commits
  7. 30 Apr, 2020 5 commits
  8. 29 Apr, 2020 2 commits
  9. 28 Apr, 2020 2 commits
  10. 27 Apr, 2020 3 commits
    • Conrad Hoffmann's avatar
      geoip: trigger CNAME chain resolution · 2cdd7c4f
      Conrad Hoffmann authored
      Currently, when the geoip module returns a CNAME, knot will not resolve
      it any further, even if it is within its authority. This forces clients
      or recursors to issue an additional request to resolve the CNAME.
      
      This commit enables the module to take advantage of knot's chain
      resolution by updating the query data with the returned CNAME and
      returning KNOT_IN_STATE_FOLLOW instead of KNOT_IN_STATE_HIT, which will
      let knot to continue with the processing as it would for regular CNAME
      results.
      2cdd7c4f
    • Conrad Hoffmann's avatar
      geoip: stricter validation of CNAME usage · 61d35a16
      Conrad Hoffmann authored
      The geoip module does not validate the semantic validity of views, such
      as that a CNAME cannot occur along with any other record. It will take
      care to only return the right type in any given response, but this can
      still lead to inconsistent results. Furthermore, one can supply two
      CNAMEs in a view, and the module will write both of them into a
      response.
      
      This adds some input validation to tighten the rules of what the module
      will accept as valid configuration, specifically that a CNAME cannot
      occur along any other record in a view. This prevents ambiguities that
      might otherwise arise in the query processing.
      
      The additional storing of the domain name in case of a CNAME was chosen
      in anticipation of using it for enabling CNAME chaing resolution,
      implemented seperately.
      61d35a16
    • Daniel Salzman's avatar
      ctl: increase listen backlog to 5 · 29170ca4
      Daniel Salzman authored
      When a control client reaches its timeout or is interrupted, the connection isn't
      closed by the server immediately. So another connection attempts can be forbiden
      with the error "OS lacked necessary resources". By increasing the listen backlog
      such a situation is less probable to happen.
      29170ca4
  11. 21 Apr, 2020 6 commits
  12. 20 Apr, 2020 2 commits