geolocation: add result destination for LocationOffsets#3480
Merged
Conversation
a822d1c to
baf7ff2
Compare
baf7ff2 to
a0d9f8e
Compare
84e4f3b to
569f815
Compare
Base automatically changed from
bdz/geolocation-alt-offset-onchain-only
to
main
April 10, 2026 20:16
Rust SDK command, CLI with client-side destination validation, display in user get, Go SDK deserialization with backwards compatibility.
a0d9f8e to
cd0e330
Compare
juan-malbeclabs
requested changes
Apr 14, 2026
Contributor
juan-malbeclabs
left a comment
There was a problem hiding this comment.
Please, review Account Order
2dfb623 to
5b74c81
Compare
juan-malbeclabs
approved these changes
Apr 14, 2026
Contributor
juan-malbeclabs
left a comment
There was a problem hiding this comment.
LGTM.Two more comments: the first is to prevent the changelog from ending up incorrect, and the second is purely semantic
28bf773 to
0073f5d
Compare
ben-dz
added a commit
that referenced
this pull request
Apr 17, 2026
## Summary - Route outbound LocationOffsets to the user's `ResultDestination` when set on `GeolocationUser`, instead of sending to the measurement target address - Skip ICMP targets that have no result destination (nothing is listening at the measurement IP) - Add DNS resolution with caching (5min TTL) for domain-based result destinations - Validate delivery addresses against public-IP scope checks to prevent DNS rebinding/SSRF attacks - Validate `ResultDestination` format at discovery time to surface errors early ## Details The `ResultDestination` field was added to `GeolocationUser` in #3480/#3501. This PR implements the geoprobe-agent side: reading the field during target discovery, carrying it through as `DeliveryAddrs` on `TargetUpdate`/`ICMPTargetUpdate`, and routing offsets to the specified address in `sendCompositeOffsets`. Key design decisions: - Delivery addresses are carried as a separate `map[ProbeAddress]string` rather than modifying `ProbeAddress` itself, to preserve Pinger map key semantics - `DNSCache.Resolve()` validates resolved IPs against `ValidateScope()` to prevent DNS rebinding - Change detection for delivery addresses triggers target updates even when the target list is unchanged Depends on: #3468 ## Testing Verification - Unit tests for outbound target with result destination → delivery override populated - Unit tests for user without result destination → no delivery overrides - Unit tests for ICMP target with result destination → delivery override in ICMP update - Unit tests for mixed users (with/without result destination) - Unit tests for domain-based result destination passthrough - Unit tests for delivery address change detection → triggers update - Unit tests for invalid result destination format → ignored with warning - DNS cache: IP passthrough, domain resolution and caching, TTL expiry, concurrent access - DNS cache security: private IP rejection, DNS rebinding to private IP rejected Fixes #3469
This file contains hidden or 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
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.
Resolves: #3468
Summary of Changes
SetResultDestinationCommandthat builds the onchain transaction with user PDA + probe account metasuser set-result-destination --destination <host:port>(or--clear) with client-side validation of IP routability and domain format before transaction submissionresult_destinationinuser getoutput (shows"none"when unset)ResultDestination stringfield onGeolocationUserwith backwards-compatible deserialization (old accounts default to"")Stacked on #3501 which adds the onchain
SetResultDestinationinstruction andresult_destinationfield.Diff Breakdown
Core logic is the CLI command (290 lines including validation + tests), Rust SDK command (118 lines), and Go SDK deserialization. Scaffolding is trait wiring and subcommand registration.
Key files (click to expand)
smartcontract/cli/src/geolocation/user/set_result_destination.rs— CLI command with clap args, client-sidehost:portvalidation (IP routability + domain format per RFC 1035), mock tests for set/clear/invalid inputssmartcontract/sdk/rs/src/geolocation/geolocation_user/set_result_destination.rs— Rust SDK command: validates code, derives user PDA, passes probe account metas toexecute_transactionsdk/geolocation/go/state.go—ResultDestination stringfield, serialize/deserialize with try-decode-default for backwards compatsdk/geolocation/go/state_test.go— round-trip and backwards-compat tests (truncated data defaults to empty)smartcontract/cli/src/geoclicommand.rs—set_result_destinationtrait method + implTesting Verification