-
-
Notifications
You must be signed in to change notification settings - Fork 64
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
Add a TSIG client. #373
Add a TSIG client. #373
Conversation
…tain number of bytes should be reserved (to make space for post-processing adding EDNS options to the response), and (b) strongly typed passing of arbitrary metadata between middleware that produces a type and middleware that consumes the type (e.g. a TSIG key name).
…to be part of this PR branch.
…to be part of this PR branch.
…nded to be part of this PR branch.
…nded to be part of this PR branch.
… a function is no longer possible.
… fix-edns-middleware / PR #355.
…o that a wrapper client (such as a future TSIG client) can augment the message before it gets sent.
- Added a simple UDP client that doesn't interfere with requests before sending (for TSIG testing). - Added support for receiving multiple responses (for XFR testing). - Added support for connection timeout errors - Added support for connection termination errors (for EDNS testing). - Added support for specifying the TSIG key to use (for TSIG testing). - Added support for $ORIGIN in zone file fragments. - Simplified rcode checking and use it instead of the yxrrset BADCOOKIE hack. - In memory channel changes: - Fixed a trace message that incorrectly referred to client instead of server. - Fixed a too-tight connection read loop that was preventing Tokio task switching. - Added connection shutdown detection. - Fixed incorrect setting of TCP mode to true when UDP mode was requested.
…an error message.
…t' into stelline-server-testing-changes
…t' into stelline-server-testing-changes
- Ensure .done() is called.
…e. Split common functionality out into handle_result() and relax bounds to make existing code usable in both single and multi contexts.
We should decide what to do with the TSIG client extension that was added to The only public DNS server offering open XFR access with TSIG signing that I'm aware of is from Swtich but we also shouldn't configure the example code to do AXFR to that as (a) it's a bit impolite and (b) we'd have to ask users to accept the Switch terms before running the example. We could make the example take optional TSIG key name and key file base64 bytes and alg name as input ala dig, and also make the queried host configurable too, and then only run the TSIG client code if TSIG key details were provided. What do you think @Philip-NLnetLabs and @partim? |
I think it is fine if it fails. Maybe print something to that effect. I see the examples mostly as code snippets. |
- Renamed AuthenticatedRequestMessage to RequestMessage to be consitent with src::net::client::request and to shorten the name (as it is scoped by the module so is still unique). - Renamed UpstreamSender to Forwarder as it's shorter and (I thnk) better. - Replaced HandleResponseResult by Option. - Renamed handle_response() to validate_response() and simplified the option/error handling a little. - Moved some impls around in the file to be nearer the type they affect.
Done. |
Taken from the
xfr
branch in order to split PR #335 into several smaller PRs.Also extends the
client-transports.rs
example to demonstrate TSIG (requires a suitably configured server).