Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: modify arbitrary fields #527

Closed
johnhtodd opened this issue Dec 27, 2023 · 2 comments
Closed

Feature request: modify arbitrary fields #527

johnhtodd opened this issue Dec 27, 2023 · 2 comments

Comments

@johnhtodd
Copy link

johnhtodd commented Dec 27, 2023

Is your feature request related to a problem? Please describe.
It would be useful to minimize certain kinds of data transmitted by deleting fields. There are also instances where modifying data to minimize cardinality would be useful. This type of deletion or modification would save on backhaul, and also would be useful in certain ways for privacy (such as deleting client IP address data by setting that field to "", even though there is another feature request open to do that in a different way)

Describe the solution you'd like
A transformation that allows arbitrary modification of fields would be the ideal method.

Describe alternatives you've considered
It's not clear that there is any other method to do this currently.

Additional context
Here's what I would imagine this would look like in the configuration file to blank out the DNSTAP version string, and to change the identity string to an arbitrary value of "pdx" (which is one of our POP codes, instead of the specific hostname):

  transforms:
   rewrite:
     dnstap.version: ""
     dnstap.identity: "pdx"

Re-writing RR's or anything that is in an unpredictable array would be very difficult - I haven't thought about that in depth, but maybe that's just not something that is easily (or ever) done in a way that is predictable, other than deleting/nulling data. Field definitions would have to be kept in some way (true/false, numeric, string, etc.) or errors produced on insertion of invalid data into the message.

@dmachard
Copy link
Owner

It will be implemented in the future first stable release.

@dmachard
Copy link
Owner

implemented in the first stable release

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants