[scotwells]

Summary

Create managed private zones under their DNS context. Product services discover the assigned zone and domain through context status. DNS reserves query destinations and manages downstream versions; network services supplies private connectivity. Applied access persists until confirmed withdrawal.

An established context keeps ownership when another context requests the same consumer identity. Integration-selected destinations must be unicast addresses outside the regional resolver pool, preventing overlap with another context's allocated address.

Test plan

• Ownership and allocation regression tests fail without the fixes
• Control-plane and platform package tests
• CI: API and controller tests
• CI: Lint and generated manifests
• CI: Container packaging
• CI: Repository end-to-end tests

Stacked on #232. Architecture: #229.

Related: datum-cloud/enhancements#921

[ecv]

Approving. Context lookups are namespace-scoped and UID-pinned, and withdrawal and shard selection filter on project UID, so I found no cross-tenant path. The reconciler is wired and given RBAC in #238. Follow-ups are in #261: destination claims that are never released and share no key space with generated addresses, and duplicate consumerID ownership decided by name order rather than age.

The merge-base changed after approval.

[ecv]

Re-approving at ae2a3d6. The new commits reject non-routable destinations, refuse addresses in the regional prefix or with a regional claim, and give consumerID ownership to the oldest context. Claim release and the DNSResolverBinding watch are still open, and #261 tracks them along with a zoned-address gap in ClaimDestination.

[kevwilliams]

Verified destination claims refuse the regional resolver pool and other contexts' addresses, and duplicate consumer IDs keep the older context.

[ecv]

Approve at 9a52cea. Since my last approval at ae2a3d6, the only change in this PR's own files is 2513558, which stops setting the removed DNSZoneAssociation managed flag. Everything else came in from the base branch through merges. I found no path that lets one project resolve another project's private zones. go build ./..., go vet ./internal/internaldns/... and the tests for the three touched packages pass locally, and CI is green. The envtest case skips locally, so I relied on CI for it.

Earlier findings at head

Finding	Status	Evidence
Duplicate consumerID goes to the older context, not the earlier name	Fixed	context_reconciler.go:114-128 sorts by creationTimestamp then UID; TestNewContextCannotDisplaceExistingConsumerOwner covers it
Destination claims accept loopback, link-local and multicast	Fixed	allocator.go:51 requires IsGlobalUnicast
Destination can equal another context's regional address	Fixed	allocator.go:55-69 refuses the regional prefix and any existing dns-address-claim-*; tests at allocator_test.go:80,102
Zoned or IPv4-mapped destination	Closed by the API	destinationAddress is isIP(self) and immutable (internaldns_project_types.go:95,103), and isIP rejects zones
Destination claims never released	Open, tracked in #261	allocator.go:45-48 keeps claims on purpose. Because the destination is immutable, each new access binding leaks one claim, rather than each edit
DNSResolverBinding not watched	Open, tracked in #261	reconciler.go:118-124; serving acknowledgements are seen only on the LeaseDuration/2 requeue

Blocking

None.

Non-blocking

• confirmAccessWithdrawal treats reason InvalidManagedDomain as terminal (context_reconciler.go:427), but nothing sets that reason. An invalid ManagedDomainSuffix is reported as InvalidIdentity with the message "consumerID is required" (context_reconciler.go:131-152). Withdrawal behaves the same either way, but the condition misleads whoever reads it. Set InvalidManagedDomain in that branch.
• A transient error from ClaimDestination is folded into valid = false (context_reconciler.go:279). The access binding then flips to Accepted=False / AccessRejected until the next requeue. Serving is safe, because confirmAccessWithdrawal keeps the binding when the spec still matches. Return API errors and keep InvalidOrStaleAccess for genuine refusals.
• ResolveNaming accepts any Ready context (naming.go:40-44). A context with managedNamespace.enabled: false is Ready at context_reconciler.go:139, so the canonical name gets an empty DNSZoneRef. If the context was once enabled, it gets the stale ref, because Status.ManagedNamespace is never cleared. The function also skips the ObservedGeneration check that resolverContextReady makes. No caller exists in this PR, so fix this before one lands.
• ClaimDestination's second parameter is named accessUID, but the call at context_reconciler.go:279 passes the context UID. The behavior is fine, since the claim belongs to the context. Rename the parameter so the owner key reads correctly.
• Reconcile falls back to req.Namespace when ProjectNamespace is empty (reconciler.go:99-102). It then writes bindings for that namespace under the configured ProjectUID. That is safe only with one project per control plane. Require ProjectNamespace, or say in the code that this is the deployment assumption.

[ecv]

Re-approving at a489e2d. An invalid suffix now reports InvalidManagedDomain. Only model.ErrDestinationRefused rejects a binding, so a transient API error retries instead of flipping an accepted binding to AccessRejected. ResolveNaming now requires a current Ready context with a managed zone UID.

The merge-base changed after approval.

[ecv]

Re-approving. The head is unchanged; only the base moved after the parent merged.