Set the AA flag and include glue in responses. #400
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Don't pass the key store around, we need only the signer when post-processing. - Get tid of the mutex, we don't need it. - Don't clone metadata when invoking a stream post-processing callback. - Add key_wrapper() fn to ServerTransaction, ServerSequence and SigningContext to allow access to the key by its original type (which might e.g. be Arc<Key> allowing the Arc to be cloned rather than a deep copy being made).
…noring the actual error code.
…f available, via a new TruncationContext type. - Truncate for TCP as well as UDP. - Return ServiceError::InternalError if truncation fails. - Implement handling of ServiceError in DgramServer and stream::Connection. - Break DgramServer and stream::Connection dispatch to service code out into helper RequestDispatcher types. - Terminate the response stream if ServiceError::InternalError occurs.
…ocused on what it is supposed to show.
…do any processing of the data other than to translate it into a different higher level language, i.e. interpret it.
…A was not set, and adds a test based on the scenario in RFC 1034 section 6.
partim
reviewed
Oct 2, 2024
partim
reviewed
Oct 2, 2024
…le instead of ZoneKey.
This PR changes zone walking and XFR to include glue records. It adds a new flag to the zone walking callback to indicate whether a record was encountered at a zone cut.
* Link to definition of DNS * Also spell out DNS. --------- Co-authored-by: Martin Hoffmann <[email protected]>
This PR adds a few trait impls and documentation. Specifically: * Add blanket `SendRequest` and `SendRequestMulti` impls for boxes. * Add `Display` impl to `tsig::Key`. * Add an `as_any` method and `Clone` and `Debug` impls to various zonetree types. * Add `AsRef<dyn ZoneStore>` to `Zone`.
…e them for processing. (#381)
… additional records to AnswerAuthority.
partim
approved these changes
Oct 3, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR attempts to fix two issues and adds a Stelline test based on the scenario in RFC 1034 section 6 to demonstrate compliance.
AA flag not set on authoritative responses. This PR sets the AA flag on zone queries whose response is not a referral. Answers at zone cuts are constructed by calling
NodeAnswer::authority()which has been updated to set anauthoritativeflag to false, while otherNodeAnswerconstructors set the flag to true.NodeAnswer::into_answer()then carries the flag through toAnswerandAnswer::to_message()sets the AA header flag based on this newauthoritativeflag.Missing glue in responses. This PR extends
AnswerAuthority::new()to take additional records (provided from glue) as well as other data, andAnswer::to_message()is extended to add any additional records to the response.This PR also extends Stelline to:
MATCH ANY_ANSWERwhereby if additional answers are supplied using theEXTRA_PACKETStelline directive then the expected response will be matched against any of them, rather than the default behaviour of treating multiple answers as one large answer (which was supported already and used for unknown ordered and split large XFR answers across multiple responses).