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

Configurable exit code #238

Closed
PenelopeFudd opened this issue Apr 23, 2024 · 6 comments
Closed

Configurable exit code #238

PenelopeFudd opened this issue Apr 23, 2024 · 6 comments
Labels
enhancement New feature or request

Comments

@PenelopeFudd
Copy link

Describe the feature
I'd like to have dnspyre return a nonzero exit code if any requests failed. Different people might have different definitions of failure at different times (e.g. connect timeout, nxdomain, duplicate answers, wrong answers, bad certificate, etc), so the parameter might take an argument: --fail="timeout,nxdomain"

Why do you need this feature
I have a program that does binary searches. It'll run a specified program and fill in a specified parameter with a number, and based on the return code of the program, will search until it finds the number where the program just starts to fail:

bsearch -l low -h high -- command args args {} args args
  This will find the largest number that can be used in place of the {},
  in the range of low to high.
  
  Options:
    -l low : the low number of the range to test
    -h high : the high number of the range to test

Without this feature, I have to write a wrapper script that runs dnspyre and then greps for a success or failure string.

For an example, see the --fail argument for curl.

Thanks!

PS: This looks like the best DNS benchmarking program out there! DNSperf / DNSRes are hard to use, Flamethrower is hard in a different way, and DNS shotgun is... weird? Dnspyre looks polished, and it has all the protocols I'm looking for.

@PenelopeFudd PenelopeFudd added the enhancement New feature or request label Apr 23, 2024
@Tantalor93
Copy link
Owner

Hello @PenelopeFudd 🙂
thanks for suggesting this enhancement, I think this enhancement makes sense and I like your suggestion to introduce a new flag --fail that will configure conditions upon which the dnspyre will exit with non-zero status

I can image supporting these conditions:

  • ioerror = dnspyre exits with a non-zero status code if there is at least 1 IO error (dnspyre failed to send DNS request or receive DNS response)
  • negative = dnspyre exits with a non-zero status code if there is at least 1 negative DNS answer (NXDOMAIN or NODATA response)
  • error = dnspyre exits with a non-zero status code if there is at least 1 error DNS response (SERVFAIL, FORMERR, REFUSED, etc.)
  • idmismatch = dnspyre exits with a non-zero status code if there is at least 1 ID mismatch between DNS request and response

and I will allow users to specify any combination of these conditions (like dnspyre --fail=ioerror,error google.com)

do you think this makes sense @PenelopeFudd?

This looks like the best DNS benchmarking program out there!

Thanks, glad to hear that 🙂

@PenelopeFudd
Copy link
Author

Yes, that's exactly it, thank you!

@Tantalor93
Copy link
Owner

Hello @PenelopeFudd, I have released a new version v3.1.0 of dnspyre, that now supports --fail flag, you can check the documentation https://tantalor93.github.io/dnspyre/failoncondition.html for usage, hope it fits your use case! Thank you!

@PenelopeFudd
Copy link
Author

Er, one more request: --fail any, if any kind of error is found? Otherwise it's rather long to specify --fail ioerror --fail error --fail negative --fail idmismatch.

@Tantalor93
Copy link
Owner

hmm, I understand, that it can be a little bit tedious to list all the conditions.

I am struggling with the semantics of such option any, it can be interpreted in many ways. Should it fail if there is any IOerror and DNS error, or should it also fail when there is a negative answer ? Negative answers usually are not a problem of the server but of the client asking for something that does not exist. Should truncated answers be considered also under the any option?

@PenelopeFudd
Copy link
Author

It's true that it could be interpreted in many ways, although I was thinking of the basic "any of the errors that could be specified with --fail", as a way to see if everything is perfect or not. If I start looking into negative or truncated answers, then it'd be time to explicitly list what counts as an error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants