Repository navigation
Prevent users from redirecting a network to another network’s private DNS #702
Description
Summary
Protect the internal settings that decide which private DNS answers a network can receive.
Why it matters
Permission to edit a network must not allow a user to bypass the separation between private networks.
Acceptance criteria
- Only authorized components can change the internal DNS settings on a network context.
- The network controller checks that the destination matches the access approved by DNS, rather than trusting an editable setting alone.
Related work
Parent: Connect private networks to Private DNS automatically.
Original report and engineering evidence are preserved in the discussion.
Activity
scotwells commentedon Oct 29, 2026
The description now explains the problem and expected outcome in plain language. The original report is preserved below for the observations, diagnostics, and implementation details behind this work. It describes the situation when the issue was reported; later comments and the issue state record subsequent progress.
Original report and engineering evidence
Requested by Scot Schuchert-Wells · project thread
A project member who can edit a network context can still change the internal DNS annotations on it. Those annotations decide which DNS view the network is routed to and which binding readiness is checked against, so editing them could point one network at another network's private DNS.
The DNS settings on the context are now protected by an admission policy (feat: Restrict who can change network DNS settings). The annotations need the same protection, and the cell should also check that the destination matches what DNS accepted for the context instead of trusting the annotation alone.
Both are needed before internal DNS is enabled outside staging.
Related to Internal DNS for networks: unenforced writes, broad permissions, branch pin
Generated by Claude Code
[-]Protect the internal DNS annotations on network contexts[/-][+]Prevent users from redirecting a network to another network’s private DNS[/+]scotwells commentedon Nov 5, 2026
Done in #859, #864 and #866.
Verified in staging after each merge: no operator write was refused, no partial or unverified settings remained, and DNS readiness was unchanged.