Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • BIND BIND
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 616
    • Issues 616
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 94
    • Merge requests 94
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source ProjectsISC Open Source Projects
  • BINDBIND
  • Issues
  • #1795
Closed
Open
Issue created Apr 27, 2020 by Michał Kępień@michalOwner

Some dnstap data may not be logged in BIND 9.15.6+

The introduction of netmgr doubled the number of threads from which dnstap data may be logged: previously, it could only happen from within taskmgr worker threads; with netmgr, it can happen both from taskmgr worker threads and from network threads. Since the argument passed to fstrm_iothr_options_set_num_input_queues() was not updated to reflect this change, some calls to fstrm_iothr_get_input_queue() can now return NULL, effectively preventing some dnstap data from being logged. Whether this bug is triggered or not depends on thread scheduling order and packet distribution between network threads, but will almost certainly be triggered on any recursive resolver sooner or later.

This issue has been introduced by !2528 (merged) (specifically by commit 53f0b6c3), i.e. it affects BIND 9.15.6+. It was not caught by the dnstap system test for two reasons:

  • the problem is rarely triggered in that system test as a low number of queries is sent to the tested servers,

  • another rarely triggered issue (with the test code itself) has been known to exist before and it has very similar symptoms.

I believe a fix for this issue warrants a release note.

Assignee
Assign to
Time tracking