1. 11 May, 2020 5 commits
  2. 09 May, 2020 1 commit
  3. 05 May, 2020 2 commits
  4. 02 May, 2020 2 commits
  5. 01 May, 2020 7 commits
  6. 30 Apr, 2020 1 commit
  7. 29 Apr, 2020 9 commits
  8. 28 Apr, 2020 6 commits
  9. 25 Apr, 2020 2 commits
  10. 23 Apr, 2020 5 commits
    • Daniel Salzman's avatar
    • Daniel Salzman's avatar
    • Daniel Salzman's avatar
    • Conrad Hoffmann's avatar
      geoip: trigger CNAME chain resolution · 903613b8
      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
    • Conrad Hoffmann's avatar
      geoip: stricter validation of CNAME usage · 4a5fb64e
      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
      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.