Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
BIND
BIND
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 629
    • Issues 629
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 112
    • Merge Requests 112
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source Projects
  • BINDBIND
  • Issues
  • #1147

Closed
Open
Created Jul 17, 2019 by Cathy Almond@cathyaDeveloper

Feature request for logging TSIG on client queries and/or in RPZ rewrites

From Support Ticket #14942

The use case is a scenario where for clients with 'stable' IP addresses, access to a set of custom resolvers is permitted by client IP address, but for other more mobile clients, is done via TSIG key.

Clients are identifiable either by source IP or by TSIG key being used.

It is a local requirement that it be possible to identify which clients have made queries that have been rewritten via RPZ (the obvious use case here being to identify clients that might have been infected with malware).

The easiest way to identify the TSIG-capable migratory clients would be to have to RPZ logging identify clients not just by IP address, but by TSIG key used (if any).

Another tack (if RPZ processing doesn't have access to the client query context with the TSIG key) might be to emit this in dnstap or query logging and then cross-reference or otherwise identify clients that 'need to be identified' on the basis of the queries they're making.

How hard would this be to achieve and also to integrate into BIND in such a way that the feature doesn't detrimentally affect users who are not interested in whether or not their client queries arrive with TSIG?

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None