1. 08 Aug, 2018 4 commits
    • Ondřej Surý's avatar
      994e6569
    • Ondřej Surý's avatar
    • Ondřej Surý's avatar
    • Michał Kępień's avatar
      Restore zone database and zone node if cache search results are to be ignored · b6c77202
      Michał Kępień authored
      When query processing hits a delegation from a locally configured zone,
      an attempt may be made to look for a better answer in the cache.  In
      such a case, the zone-sourced delegation data is set aside and the
      lookup is retried using the cache database.  When that lookup is
      completed, a decision is made whether the answer found in the cache is
      better than the answer found in the zone.
      
      Currently, if the zone-sourced answer turns out to be better than the
      one found in the cache:
      
        - qctx->zdb is not restored into qctx->db,
        - qctx->node, holding the zone database node found, is not even saved.
      
      Thus, in such a case both qctx->db and qctx->node will point at cache
      data.  This is not an issue for BIND versions which do not support
      mirror zones because in these versions non-recursive queries always
      cause the zone-sourced delegation to be returned and thus the
      non-recursive part of query_delegation() is never reached if the
      delegation is coming from a zone.  With mirror zones, however,
      non-recursive queries may cause cache lookups even after a zone
      delegation is found.  Leaving qctx->db assigned to the cache database
      when query_delegation() determines that the zone-sourced delegation is
      the best answer to the client's query prevents DS records from being
      added to delegations coming from mirror zones.  Fix this issue by
      keeping the zone database and zone node in qctx while the cache is
      searched for an answer and then restoring them into qctx->db and
      qctx->node, respectively, if the zone-sourced delegation turns out to be
      the best answer.  Since this change means that qctx->zdb cannot be used
      as the glue database any more as it will be reset to NULL by RESTORE(),
      ensure that qctx->db is not a cache database before attaching it to
      qctx->client->query.gluedb.
      
      Furthermore, current code contains a conditional statement which
      prevents a mirror zone from being used as a source of glue records.
      Said statement was added to prevent assertion failures caused by
      attempting to use a zone database's glue cache for finding glue for an
      NS RRset coming from a cache database.  However, that check is overly
      strict since it completely prevents glue from being added to delegations
      coming from mirror zones.  With the changes described above in place,
      the scenario this check was preventing can no longer happen, so remove
      the aforementioned check.
      
      If qctx->zdb is not NULL, qctx->zfname will also not be NULL;
      qctx->zsigrdataset may be NULL in such a case, but query_putrdataset()
      handles pointers to NULL pointers gracefully.  Remove redundant
      conditional expressions to make the cleanup code in query_freedata()
      match the corresponding sequences of SAVE() / RESTORE() macros more
      closely.
      b6c77202
  2. 06 Aug, 2018 1 commit
  3. 02 Aug, 2018 7 commits
  4. 01 Aug, 2018 3 commits
  5. 27 Jul, 2018 1 commit
  6. 23 Jul, 2018 1 commit
  7. 20 Jul, 2018 1 commit
  8. 19 Jul, 2018 5 commits
  9. 17 Jul, 2018 5 commits
  10. 16 Jul, 2018 1 commit
    • Michał Kępień's avatar
      Do not replace lo0 address on Solaris · 61892190
      Michał Kępień authored
      lo0 and lo0:0 are the same interface on Solaris.  Make sure
      bin/tests/system/ifconfig.sh does not touch lo0:0 in order to prevent it
      from changing the address of the loopback interface on Solaris.
      61892190
  11. 13 Jul, 2018 3 commits
  12. 11 Jul, 2018 8 commits