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

feat(inputs.dns_query): Allow ignoring errors of specific types #14992

Merged
merged 1 commit into from
Mar 20, 2024

Conversation

powersj
Copy link
Contributor

@powersj powersj commented Mar 14, 2024

Summary

Allows the user to specify ignoring certain error types from printing in the logs.

Checklist

  • No AI generated code was used in this PR

Related issues

fixes: #14941

@telegraf-tiger telegraf-tiger bot added feat Improvement on an existing feature such as adding a new setting/mode to an existing plugin plugin/input 1. Request for new input plugins 2. Issues/PRs that are related to input plugins labels Mar 14, 2024
@powersj
Copy link
Contributor Author

powersj commented Mar 14, 2024

@srebhan thoughts on this method of letting the user ignore errors in the logs? The user would still get a metric as expected indicating the error, but would hide it from the logs?

@srebhan
Copy link
Member

srebhan commented Mar 14, 2024

@powersj the error in the original issue is NXDOMAIN i.e. non-existing domain. I think this is a valid and usual response given that we want to query the DNS server. So the question is more, should we generate a different metric here in case the operation was not successful.

@powersj
Copy link
Contributor Author

powersj commented Mar 14, 2024

I think this is a valid and usual response given that we want to query the DNS server

I agree and we currently return the following metric with an error result and the return code of NXDOMAIN:

dns_query,domain=qwe.example.com,rcode=NXDOMAIN,record_type=A,result=error,server=1.1.1.1 query_time_ms=101.723123,result_code=2i,rcode_value=3i 1709918720000000000

should we generate a different metric here in case the operation was not successful.

See above, as we already do return a metric with the error message. The reporter's request was to hide error messages in logs, not modify or change any metric.

@srebhan
Copy link
Member

srebhan commented Mar 15, 2024

@powersj sorry to be so ambiguous! What I want to say is that a NXDOMAIN answer is valid for an A request (and probably others) and should not cause an error at all! The check and error is there to handle cases where we get some completely unexpected, unrelated and thus invalid answer to the query...

@powersj
Copy link
Contributor Author

powersj commented Mar 15, 2024

Ahh thanks for the clarification. So how would we determine "completely unexpected"? Would we ignore NXDOMAIN status and log an error for other issues like "SERVFAIL", "BADCOOKIE", "BADALG"?

@powersj powersj self-assigned this Mar 15, 2024
@powersj
Copy link
Contributor Author

powersj commented Mar 19, 2024

@srebhan updated PR to omit nxdomain, I'm not sure about the others (maybe YXDOMAIN?) as they do seem to be server or request related:

  • FORMERR (Format Error): Indicates that the DNS query was not formatted correctly by the client. The DNS server cannot process the request due to a syntax error.

  • SERVFAIL (Server Failure): The DNS server was unable to process the request due to a problem with the server itself. This could be due to a variety of issues, including server overload, network connectivity problems, or configuration errors.

  • NXDOMAIN (Non-Existent Domain): The domain name referenced in the query does not exist. This means the DNS server cannot find a corresponding IP address for the queried hostname.

  • NOTIMP (Not Implemented): The DNS server does not support the requested type of query. This error is returned when a DNS server or resolver receives a request for a feature or operation that it does not support.

  • REFUSED: The DNS server refused to answer for the query. This can be due to several reasons, such as administrative policies where the server is configured to deny certain requests from specific clients or due to rate limiting.

  • YXDOMAIN (Name Exists when it should not): Indicates that a name that should not exist, does exist. This error is used in dynamic DNS updates and signifies a failed precondition for an update request.

  • XRRSET (RR Set Exists when it should not): Similar to YXDOMAIN, but it specifies that a resource record set that should not exist, does exist. This is also related to dynamic DNS updates.

  • NOTAUTH (Not Authorized): The server is not authoritative for the zone specified in the query, or it is not authorized to answer queries for the specified name. This can also indicate a problem with DNSSEC validation.

  • NOTZONE (Not in Zone): The name specified in the query is not within the zone that the server is authoritative for. This typically occurs in dynamic DNS updates.

  • BADSIG (Bad Signature): Indicates a problem with the DNSSEC signature. The server was unable to verify the signature on the DNS data due to a mismatch or corruption.

  • BADKEY (Key not recognized): The server cannot recognize the key used for DNSSEC or TSIG authentication, indicating a possible configuration or communication error.

  • BADTIME (Signature out of time window): This error is related to DNSSEC or TSIG and indicates that the signature's timestamp is outside the allowed time window, suggesting a possible replay attack or clock skew.

  • BADMODE (Bad TKEY Mode): An incorrect mode field was used in a TKEY query, which is part of a mechanism for establishing shared secret keys.

  • BADNAME (Duplicate key name): A request was made to create a key with a name that already exists.

  • BADALG (Bad algorithm): The algorithm specified in a DNSSEC or TSIG query is not supported or is unrecognized by the server.

  • BADTRUNC (Bad truncation): This error indicates that a truncated response was received, but the truncation was not handled correctly, leading to potential data loss or communication failure.

  • BADCOOKIE (Bad/missing server cookie): Part of the DNS Cookies mechanism, this error occurs when there's an issue with the cookie exchanged between the client and server, used to mitigate DNS amplification attacks and other issues.

@telegraf-tiger
Copy link
Contributor

@powersj powersj marked this pull request as ready for review March 19, 2024 16:24
@powersj powersj added the ready for final review This pull request has been reviewed and/or tested by multiple users and is ready for a final review. label Mar 19, 2024
@powersj powersj assigned DStrand1 and srebhan and unassigned powersj Mar 19, 2024
Copy link
Member

@srebhan srebhan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! I think it's now pretty easy to add more errors to ignore if necessary...

@srebhan srebhan removed their assignment Mar 20, 2024
@DStrand1 DStrand1 merged commit f9b1251 into influxdata:master Mar 20, 2024
26 checks passed
@github-actions github-actions bot added this to the v1.31.0 milestone Mar 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat Improvement on an existing feature such as adding a new setting/mode to an existing plugin plugin/input 1. Request for new input plugins 2. Issues/PRs that are related to input plugins ready for final review This pull request has been reviewed and/or tested by multiple users and is ready for a final review.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

When a RR does not exist anymore telegraf inputs.dns_query produces errors in its logfile.
3 participants