From 16b20625e2cf86405587ed1aef7d1882977413ce Mon Sep 17 00:00:00 2001 From: Scot Wells Date: Fri, 9 Oct 2026 08:03:46 -0500 Subject: [PATCH 01/11] docs: Propose internal DNS for VPC resources Describe automatic private names and inherited resolver settings for VPC resources. Define ownership across project, federation, and edge APIs. Key changes: - Define regional access and trusted network identity. - Show commented API examples and rollout criteria. --- docs/enhancements/internal-dns/README.md | 306 +++++++++++++++++++++++ 1 file changed, 306 insertions(+) create mode 100644 docs/enhancements/internal-dns/README.md diff --git a/docs/enhancements/internal-dns/README.md b/docs/enhancements/internal-dns/README.md new file mode 100644 index 00000000..df2f7c58 --- /dev/null +++ b/docs/enhancements/internal-dns/README.md @@ -0,0 +1,306 @@ +--- +status: provisional +stage: alpha +latest-milestone: "TBD" +--- + +# Internal DNS for VPC resources + +Tracking issue: [Internal DNS for Galactic VPC](https://github.com/datum-cloud/enhancements/issues/921). + +- [Summary](#summary) +- [Motivation](#motivation) + - [Goals](#goals) + - [Non-Goals](#non-goals) +- [Proposal](#proposal) + - [User stories](#user-stories) + - [Risks and mitigations](#risks-and-mitigations) +- [Design Details](#design-details) + - [Control-plane boundaries](#control-plane-boundaries) + - [Network identity](#network-identity) + - [API design](#api-design) + - [Publication and lifecycle](#publication-and-lifecycle) +- [Production Readiness Review Questionnaire](#production-readiness-review-questionnaire) +- [Implementation History](#implementation-history) +- [Drawbacks](#drawbacks) +- [Alternatives](#alternatives) +- [Infrastructure Needed](#infrastructure-needed) + +## Summary + +Resources attached to a virtual private cloud (VPC) receive private DNS names and resolver settings automatically. The network services operator (NSO) provisions VPC DNS access and carries resolver settings to workload providers. Product services publish their records and endpoint eligibility. + +## Motivation + +Users need stable names for resources whose addresses and health change. Attaching a resource to a VPC should provide DNS access without requiring a zone choice or resolver configuration on each resource. + +### Goals + +- Resolve automatic resource names and multiple associated private zones within a VPC. +- Preserve tenant isolation across projects, locations, and overlapping addresses. +- Deliver resolver settings through the network-interface contract. +- Withdraw expired access and ineligible endpoints during control-plane outages. + +### Non-Goals + +- Implementing DNS serving engines or Galactic packet forwarding. +- Defining Compute APIs, guest configuration mechanisms, or application health policies. +- Discovering arbitrary services on connected networks. + +## Proposal + +NSO provisions one DNS context per enabled VPC and regional access wherever the network is used. The context selects the VPC's private zones. Workloads receive the well-known resolver address `fd53::53` through their network interfaces. + +DNS allocates a managed namespace for automatic product names. Users can associate additional private zones and naming policies through the DNS API. Shared regional fleets serve many VPCs without per-VPC deployments. + +### User stories + +A workload attaches to its VPC and receives resolver settings from its provider. The user queries the assigned names with the guest's default resolver: + +```console +$ dig +short AAAA web-01.instances.vpc-a7c9.project-p4e2.internal +fd20:1::10 +$ dig +short AAAA database.exports.vpc-a7c9.project-p4e2.internal +fd20:1::20 +$ dig +short AAAA api.prod.internal +fd20:1::30 +``` + +The first two names represent automatic Compute and Connect publications. The third belongs to an explicitly associated custom zone. Names, suffixes, and addresses are illustrative. Public names also resolve through the VPC resolver. + +### Risks and mitigations + +- Cross-VPC disclosure: authorize the VPC lifetime and service destination before lookup; test overlapping names and forged identities. +- Stale configuration: preserve authorization deadlines through every projection and enforce expiry at the edge. +- Ambiguous guest routing: qualify resolver selection for workloads with multiple network interfaces before enabling that configuration. + +## Design Details + +### Control-plane boundaries + +The diagram identifies API ownership. Controllers use authenticated, project-scoped clients regardless of where their processes run. + +```mermaid +flowchart TB + Products[Product publishers] -->|Records and eligibility| P + NSO[NSO VPC DNS integration] -->|Context, access, and resolver settings| P + P["Consumer project API
Network, NetworkContext, and DNS resources"] + D["DNS service project API
Publication state, fleet plans, and service VPC intent"] + K["Karmada API
NetworkBinding, projected NetworkContext, and placed intent"] + E["Edge API
NetworkInterface, Galactic policies, and shared DNS fleet"] + P -->|DNS reconciliation| D + P -->|Network desired-state projection| K + K -.->|Network presence reconciliation| P + NSO -->|Private-service intent| K + D -->|Service network placement| K + K -->|Placement and propagation| E + D -->|Committed DNS updates through regional transport| E + E -->|Interface resolver settings| Providers[Workload providers and guests] +``` + +- **Consumer project:** Owns the logical network, location-scoped network contexts, DNS resources, and product publications. NSO owns DNS access intent; DNS owns serving status. +- **DNS service project:** Owns shared serving plans, publication delivery, and the DNS service's VPC. DNS controllers consume DNS intent without reading product or networking APIs. +- **Karmada:** Owns network-use declarations and propagates network and workload desired state. Resolver settings follow network presence; DNS publications use regional transport. +- **Edge:** Owns local interfaces, private-service programming reports, and serving state. NSO derives interface settings from the propagated context; providers apply them to guests. + +A project UID and Network UID identify the VPC lifetime. Its network contexts share one DNS context. NSO maps locations to regions through trusted platform configuration; each active region has its own access binding in the project API. + +### Network identity + +The DNS service runs in its own VPC. Galactic exposes an authorized private endpoint in each consumer VPC and translates its destination to a unique service-side address. + +```mermaid +flowchart LR + subgraph A[VPC A: DNS context A] + CA[Client fd20:1::10] --> EA[Resolver fd53::53] + end + subgraph B[VPC B: DNS context B] + CB[Client fd20:1::10] --> EB[Resolver fd53::53] + end + EA --> GA[Galactic authorizes VPC A lifetime] + EB --> GB[Galactic authorizes VPC B lifetime] + GA --> DA[Service destination fd70:100::10] + GB --> DB[Service destination fd70:100::11] + subgraph Shared[Shared DNS service fleet] + D[Select context before cache lookup] + ZA[Context A private zones and cache] + ZB[Context B private zones and cache] + D --> ZA + D --> ZB + end + DA --> D + DB --> D +``` + +DNS selects the context from the authorized service destination before cache lookup. Client source addresses, query metadata, and client-supplied proxy headers cannot select a context. Galactic consumes generic `ServiceEndpoint` and `ServiceRoutePolicy` intent; it does not interpret DNS contexts or zones. + +### API design + +These examples are proposed contracts. NSO fields below are additions requiring API implementation. DNS examples use the [DNS control-plane contract](https://github.com/datum-cloud/dns-operator/pull/229). UIDs and deadlines are illustrative; controllers write the generated objects and status. + +#### Network policy and DNS access + +```yaml +apiVersion: networking.datumapis.com/v1alpha +kind: Network +metadata: + name: application +spec: + ipam: + mode: Auto + dns: + # Proposed optional policy. Managed is the default for enabled VPCs. + # Disabled requests withdrawal of managed resolver access and settings. + mode: Managed +--- +apiVersion: dns.networking.miloapis.com/v1alpha1 +kind: DNSResolverContext +metadata: + name: application +spec: + # NSO derives this immutable identity from project UID and Network UID. + consumerID: "11111111-1111-4111-8111-111111111111/22222222-2222-4222-8222-222222222222" + managedNamespace: + # DNS allocates the default zone and suffix for product publishers. + enabled: true +--- +apiVersion: dns.networking.miloapis.com/v1alpha1 +kind: DNSResolverAccessBinding +metadata: + name: application-us-central-1 +spec: + # Pin the DNS context lifetime in the consumer project API. + contextRef: + name: application + uid: 33333333-3333-4333-8333-333333333333 + # A trusted location mapping selects the regional shared fleet. + region: us-central-1 + queryIdentity: + type: DestinationAddress + # Authorize the service-side destination, distinct from fd53::53. + value: fd70:100::10 + port: 53 + transports: [UDP, TCP] + authorization: + # DNS issues the context epoch; NSO preserves it on renewals. + writerEpoch: 3 + # Persist monotonic renewal sequences using conditional API writes. + sequence: 27 + # Preserve the authorization deadline during replication. + validUntil: "2026-10-09T20:05:00Z" +``` + +NSO creates access only for an authorized network location. It coordinates the DNS binding with generic private-service intent that pins the consumer VPC lifetime and backend destination. Users and record publishers cannot authorize their own network access. + +#### Resolver settings delivered to workloads + +NSO writes verified resolver settings into the project `NetworkContext.spec.dns`. Federation carries that desired state to the edge. The interface controller copies it into `NetworkInterface.spec.dns`; providers consume the interface rather than reading DNS or network-context APIs. + +```yaml +apiVersion: networking.datumapis.com/v1alpha +kind: NetworkContext +metadata: + name: application-us-central-1 +spec: + network: + name: application + location: + name: us-central-1 + dns: + # Proposed NSO-owned desired state, protected from consumer writes. + contextRef: + name: application + uid: 33333333-3333-4333-8333-333333333333 + # Preserve source access identity and revision across control planes. + accessBindingRef: + name: application-us-central-1 + uid: 44444444-4444-4444-8444-444444444444 + writerEpoch: 3 + sequence: 27 + # The deadline cannot exceed either DNS or network authorization. + validUntil: "2026-10-09T20:05:00Z" + # The private-service frontend uses this address inside the consumer VPC. + nameservers: [fd53::53] + # Use the DNS-allocated managed suffix for relative names. + searches: [vpc-a7c9.project-p4e2.internal] +--- +apiVersion: networking.datumapis.com/v1alpha +kind: NetworkInterface +metadata: + name: web-01-eth0 +spec: + network: + name: application + interfaceName: eth0 + # Proposed inherited settings have exactly the NetworkContext.dns shape. + dns: + contextRef: + name: application + uid: 33333333-3333-4333-8333-333333333333 + accessBindingRef: + name: application-us-central-1 + uid: 44444444-4444-4444-8444-444444444444 + writerEpoch: 3 + sequence: 27 + validUntil: "2026-10-09T20:05:00Z" + nameservers: [fd53::53] + searches: [vpc-a7c9.project-p4e2.internal] +``` + +Admission restricts resolver-settings writes to NSO and `DNSConfigured` reports to trusted providers. Authenticate source projects through project routing and protected federation metadata. Projections preserve source identity and fencing values; UIDs assigned to replicated copies cannot replace source lifetimes. + +Publish settings only after DNS reports the access sequence ready and Galactic reports the corresponding policy generation programmed on required nodes. `NetworkContext` reports a proposed `DNSReady` condition separately from network readiness. Providers report `DNSConfigured` after applying current, unexpired settings, reconcile updates, and reject stale revisions. + +The initial guest contract supports one managed DNS context. A provider must reject unsupported combinations of managed contexts across interfaces rather than merge private resolver settings. A transient failure must not redirect private queries to a public resolver. + +### Publication and lifecycle + +Products reserve names through `DNSRegistration` and publish eligible addresses through `DNSContribution`. A trusted issuer authorizes publishers through `DNSContributionGrant`; publication credentials cannot write grants or resolver access. Compute owns instance and service eligibility; Connect owns export eligibility. DNS and NSO do not inspect Compute resources. + +Reconcile access, publication, and settings independently per project and region. Persist sequences, use conditional writes, and resume from committed state after takeover. Failure in one region must not block healthy regions. Replication and retries preserve expiry times. + +Products withdraw unhealthy endpoints; DNS also expires contributions locally when publishers stop. Withdrawal bounds include cached-answer TTLs. Removing a location's last consumer clears its settings; removing the region's last consumer stops access renewal. Network deletion retires the DNS context. Recreated networks and retained interfaces cannot inherit retired authorization. + +## Production Readiness Review Questionnaire + +### Feature Enablement and Rollback + +Gate VPC integration and product publication separately, disabled by default for alpha. Enable selected staging projects first. Withdrawal stops renewals, gates private paths, and removes guest settings through provider reconciliation. Stopping controllers alone does not remove guest settings. + +### Rollout, Upgrade and Rollback Planning + +Extend the shared NSO federation and DNS Kubernetes test environments. Release acceptance requires guest-default queries from two VPCs with overlapping names and addresses, over UDP and TCP. Test takeover, replay, API and broker outages, health withdrawal, deletion, and rollback. Public DNS must follow the configured resolution policy. + +### Monitoring Requirements + +Measure renewal failures, settings age, guest-configuration time, and withdrawal latency. Users can inspect assigned names and DNS readiness. Operators trace context, access, route programming, interface, and serving reports. + +### Dependencies + +Require DNS serving and project APIs, authenticated clients, trusted federation metadata, Galactic private connectivity, and providers that refresh resolver settings. During API outages, authorization expires locally and unverified settings stay unready. + +### Scalability + +Locations sharing a regional path share access. Interface settings scale with interfaces; publications scale with endpoints. Qualify renewal throughput, controller sharding, and bounded search lists before increasing the canary cohort. + +### Troubleshooting + +Inspect `DNSReady` and `DNSConfigured`, then correlate source project, context UID, access UID, epoch, sequence, and deadline. Querying an explicit resolver address does not verify guest configuration. + +## Implementation History + +This enhancement is provisional. Release acceptance criteria require qualification before enablement. + +## Drawbacks + +Guest DNS readiness depends on both serving and private connectivity. Frequent lease renewals and interface updates consume API capacity and require bounded fan-out. + +## Alternatives + +Users can configure resolvers and publish static records manually. That approach does not provide automatic names or health-driven withdrawal. + +## Infrastructure Needed + +Shared regional DNS fleets in a service VPC, protected publication transport, producer VPC attachments, and consumer private endpoints. Use the [staging preparation stack](https://github.com/datum-cloud/infra/pull/6862) as the infrastructure boundary. + +Related designs: [network presence](../network-in-every-location.md), [network interfaces](../network-interfaces.md), [internal DNS](https://github.com/datum-cloud/dns-operator/pull/229), and [Private Service Connect](https://github.com/datum-cloud/galactic/blob/main/docs/enhancements/networking/private-service-connect/README.md). From ed731a7ba633b3a147089040eeac7d2c9ed16563 Mon Sep 17 00:00:00 2001 From: Scot Wells Date: Fri, 9 Oct 2026 08:21:01 -0500 Subject: [PATCH 02/11] docs: Use network services product terminology Describe the VPC DNS integration as network services so the proposal uses product terminology. Key changes: - Align prose, diagrams, and YAML explanations. --- docs/enhancements/internal-dns/README.md | 32 ++++++++++++------------ 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/docs/enhancements/internal-dns/README.md b/docs/enhancements/internal-dns/README.md index df2f7c58..009fb5c5 100644 --- a/docs/enhancements/internal-dns/README.md +++ b/docs/enhancements/internal-dns/README.md @@ -28,7 +28,7 @@ Tracking issue: [Internal DNS for Galactic VPC](https://github.com/datum-cloud/e ## Summary -Resources attached to a virtual private cloud (VPC) receive private DNS names and resolver settings automatically. The network services operator (NSO) provisions VPC DNS access and carries resolver settings to workload providers. Product services publish their records and endpoint eligibility. +Resources attached to a virtual private cloud (VPC) receive private DNS names and resolver settings automatically. Network services provision VPC DNS access and carry resolver settings to workload providers. Product services publish their records and endpoint eligibility. ## Motivation @@ -49,7 +49,7 @@ Users need stable names for resources whose addresses and health change. Attachi ## Proposal -NSO provisions one DNS context per enabled VPC and regional access wherever the network is used. The context selects the VPC's private zones. Workloads receive the well-known resolver address `fd53::53` through their network interfaces. +Network services provision one DNS context per enabled VPC and regional access wherever the network is used. The context selects the VPC's private zones. Workloads receive the well-known resolver address `fd53::53` through their network interfaces. DNS allocates a managed namespace for automatic product names. Users can associate additional private zones and naming policies through the DNS API. Shared regional fleets serve many VPCs without per-VPC deployments. @@ -83,7 +83,7 @@ The diagram identifies API ownership. Controllers use authenticated, project-sco ```mermaid flowchart TB Products[Product publishers] -->|Records and eligibility| P - NSO[NSO VPC DNS integration] -->|Context, access, and resolver settings| P + NetworkServices[Network services: VPC DNS integration] -->|Context, access, and resolver settings| P P["Consumer project API
Network, NetworkContext, and DNS resources"] D["DNS service project API
Publication state, fleet plans, and service VPC intent"] K["Karmada API
NetworkBinding, projected NetworkContext, and placed intent"] @@ -91,19 +91,19 @@ flowchart TB P -->|DNS reconciliation| D P -->|Network desired-state projection| K K -.->|Network presence reconciliation| P - NSO -->|Private-service intent| K + NetworkServices -->|Private-service intent| K D -->|Service network placement| K K -->|Placement and propagation| E D -->|Committed DNS updates through regional transport| E E -->|Interface resolver settings| Providers[Workload providers and guests] ``` -- **Consumer project:** Owns the logical network, location-scoped network contexts, DNS resources, and product publications. NSO owns DNS access intent; DNS owns serving status. +- **Consumer project:** Owns the logical network, location-scoped network contexts, DNS resources, and product publications. Network services own DNS access intent; DNS owns serving status. - **DNS service project:** Owns shared serving plans, publication delivery, and the DNS service's VPC. DNS controllers consume DNS intent without reading product or networking APIs. - **Karmada:** Owns network-use declarations and propagates network and workload desired state. Resolver settings follow network presence; DNS publications use regional transport. -- **Edge:** Owns local interfaces, private-service programming reports, and serving state. NSO derives interface settings from the propagated context; providers apply them to guests. +- **Edge:** Owns local interfaces, private-service programming reports, and serving state. Network services derive interface settings from the propagated context; providers apply them to guests. -A project UID and Network UID identify the VPC lifetime. Its network contexts share one DNS context. NSO maps locations to regions through trusted platform configuration; each active region has its own access binding in the project API. +A project UID and Network UID identify the VPC lifetime. Its network contexts share one DNS context. Network services map locations to regions through trusted platform configuration; each active region has its own access binding in the project API. ### Network identity @@ -136,7 +136,7 @@ DNS selects the context from the authorized service destination before cache loo ### API design -These examples are proposed contracts. NSO fields below are additions requiring API implementation. DNS examples use the [DNS control-plane contract](https://github.com/datum-cloud/dns-operator/pull/229). UIDs and deadlines are illustrative; controllers write the generated objects and status. +These examples are proposed contracts. Network services fields below are additions requiring API implementation. DNS examples use the [DNS control-plane contract](https://github.com/datum-cloud/dns-operator/pull/229). UIDs and deadlines are illustrative; controllers write the generated objects and status. #### Network policy and DNS access @@ -158,7 +158,7 @@ kind: DNSResolverContext metadata: name: application spec: - # NSO derives this immutable identity from project UID and Network UID. + # Network services derive this immutable identity from project UID and Network UID. consumerID: "11111111-1111-4111-8111-111111111111/22222222-2222-4222-8222-222222222222" managedNamespace: # DNS allocates the default zone and suffix for product publishers. @@ -182,7 +182,7 @@ spec: port: 53 transports: [UDP, TCP] authorization: - # DNS issues the context epoch; NSO preserves it on renewals. + # DNS issues the context epoch; network services preserve it on renewals. writerEpoch: 3 # Persist monotonic renewal sequences using conditional API writes. sequence: 27 @@ -190,11 +190,11 @@ spec: validUntil: "2026-10-09T20:05:00Z" ``` -NSO creates access only for an authorized network location. It coordinates the DNS binding with generic private-service intent that pins the consumer VPC lifetime and backend destination. Users and record publishers cannot authorize their own network access. +Network services create access only for an authorized network location. They coordinate the DNS binding with generic private-service intent that pins the consumer VPC lifetime and backend destination. Users and record publishers cannot authorize their own network access. #### Resolver settings delivered to workloads -NSO writes verified resolver settings into the project `NetworkContext.spec.dns`. Federation carries that desired state to the edge. The interface controller copies it into `NetworkInterface.spec.dns`; providers consume the interface rather than reading DNS or network-context APIs. +Network services write verified resolver settings into the project `NetworkContext.spec.dns`. Federation carries that desired state to the edge. The interface controller copies it into `NetworkInterface.spec.dns`; providers consume the interface rather than reading DNS or network-context APIs. ```yaml apiVersion: networking.datumapis.com/v1alpha @@ -207,7 +207,7 @@ spec: location: name: us-central-1 dns: - # Proposed NSO-owned desired state, protected from consumer writes. + # Proposed desired state owned by network services, protected from consumer writes. contextRef: name: application uid: 33333333-3333-4333-8333-333333333333 @@ -247,7 +247,7 @@ spec: searches: [vpc-a7c9.project-p4e2.internal] ``` -Admission restricts resolver-settings writes to NSO and `DNSConfigured` reports to trusted providers. Authenticate source projects through project routing and protected federation metadata. Projections preserve source identity and fencing values; UIDs assigned to replicated copies cannot replace source lifetimes. +Admission restricts resolver-settings writes to network services and `DNSConfigured` reports to trusted providers. Authenticate source projects through project routing and protected federation metadata. Projections preserve source identity and fencing values; UIDs assigned to replicated copies cannot replace source lifetimes. Publish settings only after DNS reports the access sequence ready and Galactic reports the corresponding policy generation programmed on required nodes. `NetworkContext` reports a proposed `DNSReady` condition separately from network readiness. Providers report `DNSConfigured` after applying current, unexpired settings, reconcile updates, and reject stale revisions. @@ -255,7 +255,7 @@ The initial guest contract supports one managed DNS context. A provider must rej ### Publication and lifecycle -Products reserve names through `DNSRegistration` and publish eligible addresses through `DNSContribution`. A trusted issuer authorizes publishers through `DNSContributionGrant`; publication credentials cannot write grants or resolver access. Compute owns instance and service eligibility; Connect owns export eligibility. DNS and NSO do not inspect Compute resources. +Products reserve names through `DNSRegistration` and publish eligible addresses through `DNSContribution`. A trusted issuer authorizes publishers through `DNSContributionGrant`; publication credentials cannot write grants or resolver access. Compute owns instance and service eligibility; Connect owns export eligibility. DNS and network services do not inspect Compute resources. Reconcile access, publication, and settings independently per project and region. Persist sequences, use conditional writes, and resume from committed state after takeover. Failure in one region must not block healthy regions. Replication and retries preserve expiry times. @@ -269,7 +269,7 @@ Gate VPC integration and product publication separately, disabled by default for ### Rollout, Upgrade and Rollback Planning -Extend the shared NSO federation and DNS Kubernetes test environments. Release acceptance requires guest-default queries from two VPCs with overlapping names and addresses, over UDP and TCP. Test takeover, replay, API and broker outages, health withdrawal, deletion, and rollback. Public DNS must follow the configured resolution policy. +Extend the shared network services federation and DNS Kubernetes test environments. Release acceptance requires guest-default queries from two VPCs with overlapping names and addresses, over UDP and TCP. Test takeover, replay, API and broker outages, health withdrawal, deletion, and rollback. Public DNS must follow the configured resolution policy. ### Monitoring Requirements From caff984da3d234d57e8d614d44239a9a6c14f12d Mon Sep 17 00:00:00 2001 From: Scot Wells Date: Fri, 9 Oct 2026 09:21:01 -0500 Subject: [PATCH 03/11] docs: Name the DNS record publication API Use the DNSRecordContribution kind when describing product publication. Key changes: - Match the publication contract in the DNS API. --- docs/enhancements/internal-dns/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/enhancements/internal-dns/README.md b/docs/enhancements/internal-dns/README.md index 009fb5c5..617ae956 100644 --- a/docs/enhancements/internal-dns/README.md +++ b/docs/enhancements/internal-dns/README.md @@ -255,7 +255,7 @@ The initial guest contract supports one managed DNS context. A provider must rej ### Publication and lifecycle -Products reserve names through `DNSRegistration` and publish eligible addresses through `DNSContribution`. A trusted issuer authorizes publishers through `DNSContributionGrant`; publication credentials cannot write grants or resolver access. Compute owns instance and service eligibility; Connect owns export eligibility. DNS and network services do not inspect Compute resources. +Products reserve names through `DNSRegistration` and publish eligible addresses through `DNSRecordContribution`. A trusted issuer authorizes publishers through `DNSContributionGrant`; publication credentials cannot write grants or resolver access. Compute owns instance and service eligibility; Connect owns export eligibility. DNS and network services do not inspect Compute resources. Reconcile access, publication, and settings independently per project and region. Persist sequences, use conditional writes, and resume from committed state after takeover. Failure in one region must not block healthy regions. Replication and retries preserve expiry times. From 462b96962f5e4afc223e3cf007efdf21d4eb3998 Mon Sep 17 00:00:00 2001 From: Scot Wells Date: Sun, 11 Oct 2026 14:06:14 -0500 Subject: [PATCH 04/11] Specify the network default DNS domain request --- docs/enhancements/internal-dns/README.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/docs/enhancements/internal-dns/README.md b/docs/enhancements/internal-dns/README.md index 617ae956..bbc7c216 100644 --- a/docs/enhancements/internal-dns/README.md +++ b/docs/enhancements/internal-dns/README.md @@ -51,16 +51,16 @@ Users need stable names for resources whose addresses and health change. Attachi Network services provision one DNS context per enabled VPC and regional access wherever the network is used. The context selects the VPC's private zones. Workloads receive the well-known resolver address `fd53::53` through their network interfaces. -DNS allocates a managed namespace for automatic product names. Users can associate additional private zones and naming policies through the DNS API. Shared regional fleets serve many VPCs without per-VPC deployments. +Network services selects `datum.internal` as the default domain and requests a managed namespace from DNS. DNS allocates a separate zone for each context. Product services publish records in the allocated zone. Users can associate additional private zones and naming policies through the DNS API. Shared regional fleets serve many VPCs without per-VPC deployments. ### User stories A workload attaches to its VPC and receives resolver settings from its provider. The user queries the assigned names with the guest's default resolver: ```console -$ dig +short AAAA web-01.instances.vpc-a7c9.project-p4e2.internal +$ dig +short AAAA web-01-k7m2.datum.internal fd20:1::10 -$ dig +short AAAA database.exports.vpc-a7c9.project-p4e2.internal +$ dig +short AAAA database.datum.internal fd20:1::20 $ dig +short AAAA api.prod.internal fd20:1::30 @@ -161,8 +161,10 @@ spec: # Network services derive this immutable identity from project UID and Network UID. consumerID: "11111111-1111-4111-8111-111111111111/22222222-2222-4222-8222-222222222222" managedNamespace: - # DNS allocates the default zone and suffix for product publishers. + # Request a context-specific zone for automatic product records. enabled: true + # Network services owns the default domain policy; DNS allocates this apex. + domainSuffix: datum.internal --- apiVersion: dns.networking.miloapis.com/v1alpha1 kind: DNSResolverAccessBinding @@ -222,7 +224,7 @@ spec: # The private-service frontend uses this address inside the consumer VPC. nameservers: [fd53::53] # Use the DNS-allocated managed suffix for relative names. - searches: [vpc-a7c9.project-p4e2.internal] + searches: [datum.internal] --- apiVersion: networking.datumapis.com/v1alpha kind: NetworkInterface @@ -244,7 +246,7 @@ spec: sequence: 27 validUntil: "2026-10-09T20:05:00Z" nameservers: [fd53::53] - searches: [vpc-a7c9.project-p4e2.internal] + searches: [datum.internal] ``` Admission restricts resolver-settings writes to network services and `DNSConfigured` reports to trusted providers. Authenticate source projects through project routing and protected federation metadata. Projections preserve source identity and fencing values; UIDs assigned to replicated copies cannot replace source lifetimes. From f59a5e599d36903d85c553102b60496d4d13ae02 Mon Sep 17 00:00:00 2001 From: Scot Wells Date: Sun, 11 Oct 2026 14:09:31 -0500 Subject: [PATCH 05/11] Quote IPv6 resolver addresses in YAML examples --- docs/enhancements/internal-dns/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/enhancements/internal-dns/README.md b/docs/enhancements/internal-dns/README.md index bbc7c216..1d858d0e 100644 --- a/docs/enhancements/internal-dns/README.md +++ b/docs/enhancements/internal-dns/README.md @@ -222,7 +222,7 @@ spec: # The deadline cannot exceed either DNS or network authorization. validUntil: "2026-10-09T20:05:00Z" # The private-service frontend uses this address inside the consumer VPC. - nameservers: [fd53::53] + nameservers: ["fd53::53"] # Use the DNS-allocated managed suffix for relative names. searches: [datum.internal] --- @@ -245,7 +245,7 @@ spec: writerEpoch: 3 sequence: 27 validUntil: "2026-10-09T20:05:00Z" - nameservers: [fd53::53] + nameservers: ["fd53::53"] searches: [datum.internal] ``` From f212a332b6e88940fdd4a9f5111dbdee2ac99d9f Mon Sep 17 00:00:00 2001 From: Scot Wells Date: Mon, 12 Oct 2026 18:53:46 -0500 Subject: [PATCH 06/11] docs: Define persistent private DNS connectivity --- docs/enhancements/internal-dns/README.md | 33 ++++++++++++------------ 1 file changed, 16 insertions(+), 17 deletions(-) diff --git a/docs/enhancements/internal-dns/README.md b/docs/enhancements/internal-dns/README.md index 1d858d0e..a32799ff 100644 --- a/docs/enhancements/internal-dns/README.md +++ b/docs/enhancements/internal-dns/README.md @@ -71,7 +71,7 @@ The first two names represent automatic Compute and Connect publications. The th ### Risks and mitigations - Cross-VPC disclosure: authorize the VPC lifetime and service destination before lookup; test overlapping names and forged identities. -- Stale configuration: preserve authorization deadlines through every projection and enforce expiry at the edge. +- Stale configuration: preserve source lifetimes and version fences through every projection; explicit withdrawal removes access. - Ambiguous guest routing: qualify resolver selection for workloads with multiple network interfaces before enabling that configuration. ## Design Details @@ -136,7 +136,7 @@ DNS selects the context from the authorized service destination before cache loo ### API design -These examples are proposed contracts. Network services fields below are additions requiring API implementation. DNS examples use the [DNS control-plane contract](https://github.com/datum-cloud/dns-operator/pull/229). UIDs and deadlines are illustrative; controllers write the generated objects and status. +These examples are proposed contracts. Network services fields below are additions requiring API implementation. DNS examples use the [DNS control-plane contract](https://github.com/datum-cloud/dns-operator/pull/229). UIDs and version values are illustrative; controllers write the generated objects and status. #### Network policy and DNS access @@ -184,15 +184,13 @@ spec: port: 53 transports: [UDP, TCP] authorization: - # DNS issues the context epoch; network services preserve it on renewals. + # DNS issues the context epoch; network services preserve it across projections. writerEpoch: 3 - # Persist monotonic renewal sequences using conditional API writes. + # Advance the sequence when access intent changes; use conditional API writes. sequence: 27 - # Preserve the authorization deadline during replication. - validUntil: "2026-10-09T20:05:00Z" ``` -Network services create access only for an authorized network location. They coordinate the DNS binding with generic private-service intent that pins the consumer VPC lifetime and backend destination. Users and record publishers cannot authorize their own network access. +Network services create access only for an authorized network location. They coordinate the DNS binding with generic private-service intent that pins the consumer VPC lifetime and backend destination. RBAC controls who can publish network access intent. Galactic validates the pinned consumer VPC and supports persistent authorization for DNS private endpoints. #### Resolver settings delivered to workloads @@ -219,8 +217,6 @@ spec: uid: 44444444-4444-4444-8444-444444444444 writerEpoch: 3 sequence: 27 - # The deadline cannot exceed either DNS or network authorization. - validUntil: "2026-10-09T20:05:00Z" # The private-service frontend uses this address inside the consumer VPC. nameservers: ["fd53::53"] # Use the DNS-allocated managed suffix for relative names. @@ -244,14 +240,17 @@ spec: uid: 44444444-4444-4444-8444-444444444444 writerEpoch: 3 sequence: 27 - validUntil: "2026-10-09T20:05:00Z" nameservers: ["fd53::53"] searches: [datum.internal] ``` -Admission restricts resolver-settings writes to network services and `DNSConfigured` reports to trusted providers. Authenticate source projects through project routing and protected federation metadata. Projections preserve source identity and fencing values; UIDs assigned to replicated copies cannot replace source lifetimes. +RBAC restricts resolver-settings writes to network services and configuration reports to trusted providers. Authenticate source projects through project routing and protected federation metadata. Projections preserve source identity and fencing values; UIDs assigned to replicated copies cannot replace source lifetimes. -Publish settings only after DNS reports the access sequence ready and Galactic reports the corresponding policy generation programmed on required nodes. `NetworkContext` reports a proposed `DNSReady` condition separately from network readiness. Providers report `DNSConfigured` after applying current, unexpired settings, reconcile updates, and reject stale revisions. +Galactic private-service policies use `authorization.persistent: true` and retain +VPC identity checks. Deletion or a confirmed change to the selected VPC withdraws +access. Missing programming observations retain the applied path. + +Publish settings only after DNS reports the access sequence ready and Galactic reports the corresponding policy generation programmed on required nodes. `NetworkContext` reports a proposed `DNSReady` condition separately from network readiness. Providers report `DNSConfigured` after applying current settings, reconcile updates, and reject stale revisions. The initial guest contract supports one managed DNS context. A provider must reject unsupported combinations of managed contexts across interfaces rather than merge private resolver settings. A transient failure must not redirect private queries to a public resolver. @@ -259,9 +258,9 @@ The initial guest contract supports one managed DNS context. A provider must rej Products reserve names through `DNSRegistration` and publish eligible addresses through `DNSRecordContribution`. A trusted issuer authorizes publishers through `DNSContributionGrant`; publication credentials cannot write grants or resolver access. Compute owns instance and service eligibility; Connect owns export eligibility. DNS and network services do not inspect Compute resources. -Reconcile access, publication, and settings independently per project and region. Persist sequences, use conditional writes, and resume from committed state after takeover. Failure in one region must not block healthy regions. Replication and retries preserve expiry times. +Reconcile access, publication, and settings independently per project and region. Persist sequences, use conditional writes, and resume from committed state after takeover. Failure in one region must not block healthy regions. Replication and retries preserve lifetimes and version fences. -Products withdraw unhealthy endpoints; DNS also expires contributions locally when publishers stop. Withdrawal bounds include cached-answer TTLs. Removing a location's last consumer clears its settings; removing the region's last consumer stops access renewal. Network deletion retires the DNS context. Recreated networks and retained interfaces cannot inherit retired authorization. +Products explicitly withdraw unhealthy endpoints. Unavailable observations retain the last reported endpoint state. Withdrawal bounds include cached-answer TTLs. Removing a location's last consumer clears its settings; removing the region's last consumer withdraws access. Network deletion retires the DNS context. Recreated networks and retained interfaces cannot inherit retired authorization. ## Production Readiness Review Questionnaire @@ -279,7 +278,7 @@ Measure renewal failures, settings age, guest-configuration time, and withdrawal ### Dependencies -Require DNS serving and project APIs, authenticated clients, trusted federation metadata, Galactic private connectivity, and providers that refresh resolver settings. During API outages, authorization expires locally and unverified settings stay unready. +Require DNS serving and project APIs, authenticated clients, trusted federation metadata, Galactic private connectivity, and providers that refresh resolver settings. During API outages, applied private-service access and resolver settings persist. New settings require verified programming; unavailable observations report unknown readiness. ### Scalability @@ -287,7 +286,7 @@ Locations sharing a regional path share access. Interface settings scale with in ### Troubleshooting -Inspect `DNSReady` and `DNSConfigured`, then correlate source project, context UID, access UID, epoch, sequence, and deadline. Querying an explicit resolver address does not verify guest configuration. +Inspect `DNSReady` and `DNSConfigured`, then correlate source project, context UID, access UID, epoch and sequence. Querying an explicit resolver address does not verify guest configuration. ## Implementation History @@ -295,7 +294,7 @@ This enhancement is provisional. Release acceptance criteria require qualificati ## Drawbacks -Guest DNS readiness depends on both serving and private connectivity. Frequent lease renewals and interface updates consume API capacity and require bounded fan-out. +Guest DNS readiness depends on both serving and private connectivity. Event-driven access changes and interface projection require bounded fan-out. ## Alternatives From 9fc3bdebf8249d5e76ac873a5cba2447d1d85ae2 Mon Sep 17 00:00:00 2001 From: Scot Wells Date: Mon, 12 Oct 2026 19:07:55 -0500 Subject: [PATCH 07/11] docs: Define explicit VPC DNS rollback --- docs/enhancements/internal-dns/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/enhancements/internal-dns/README.md b/docs/enhancements/internal-dns/README.md index a32799ff..8d533003 100644 --- a/docs/enhancements/internal-dns/README.md +++ b/docs/enhancements/internal-dns/README.md @@ -39,7 +39,7 @@ Users need stable names for resources whose addresses and health change. Attachi - Resolve automatic resource names and multiple associated private zones within a VPC. - Preserve tenant isolation across projects, locations, and overlapping addresses. - Deliver resolver settings through the network-interface contract. -- Withdraw expired access and ineligible endpoints during control-plane outages. +- Retain applied DNS access during control-plane outages and withdraw it on explicit deletion. ### Non-Goals @@ -266,7 +266,7 @@ Products explicitly withdraw unhealthy endpoints. Unavailable observations retai ### Feature Enablement and Rollback -Gate VPC integration and product publication separately, disabled by default for alpha. Enable selected staging projects first. Withdrawal stops renewals, gates private paths, and removes guest settings through provider reconciliation. Stopping controllers alone does not remove guest settings. +Gate VPC integration and product publication separately, disabled by default for alpha. Enable selected staging projects first. Explicit withdrawal removes private paths and guest settings through provider reconciliation. Withdraw access before disabling integration; stopping controllers retains applied settings and paths. ### Rollout, Upgrade and Rollback Planning From e751f2d4b66e9560b3c81235f193a2692632061f Mon Sep 17 00:00:00 2001 From: Scot Wells Date: Tue, 13 Oct 2026 08:30:04 -0500 Subject: [PATCH 08/11] docs: Describe read-only interface DNS settings --- docs/enhancements/internal-dns/README.md | 30 +++++++++++------------- 1 file changed, 14 insertions(+), 16 deletions(-) diff --git a/docs/enhancements/internal-dns/README.md b/docs/enhancements/internal-dns/README.md index 8d533003..354ebbde 100644 --- a/docs/enhancements/internal-dns/README.md +++ b/docs/enhancements/internal-dns/README.md @@ -194,7 +194,7 @@ Network services create access only for an authorized network location. They coo #### Resolver settings delivered to workloads -Network services write verified resolver settings into the project `NetworkContext.spec.dns`. Federation carries that desired state to the edge. The interface controller copies it into `NetworkInterface.spec.dns`; providers consume the interface rather than reading DNS or network-context APIs. +Network services own resolver configuration. `NetworkContext.spec.dns` carries the internal delivery configuration through federation. The interface controller reports effective addresses and search domains in `NetworkInterface.status.dns`. Consumers cannot override DNS settings on an interface. Providers apply the trusted configuration and report `DNSConfigured` through status. ```yaml apiVersion: networking.datumapis.com/v1alpha @@ -210,11 +210,9 @@ spec: # Proposed desired state owned by network services, protected from consumer writes. contextRef: name: application - uid: 33333333-3333-4333-8333-333333333333 # Preserve source access identity and revision across control planes. accessBindingRef: name: application-us-central-1 - uid: 44444444-4444-4444-8444-444444444444 writerEpoch: 3 sequence: 27 # The private-service frontend uses this address inside the consumer VPC. @@ -230,21 +228,21 @@ spec: network: name: application interfaceName: eth0 - # Proposed inherited settings have exactly the NetworkContext.dns shape. +status: + # Report effective settings as read-only output. dns: - contextRef: - name: application - uid: 33333333-3333-4333-8333-333333333333 - accessBindingRef: - name: application-us-central-1 - uid: 44444444-4444-4444-8444-444444444444 - writerEpoch: 3 - sequence: 27 nameservers: ["fd53::53"] searches: [datum.internal] + conditions: + # The provider confirms application of the effective settings. + - type: DNSConfigured + status: "True" + reason: Applied + message: Resolver settings are configured + lastTransitionTime: "2026-10-13T13:00:00Z" ``` -RBAC restricts resolver-settings writes to network services and configuration reports to trusted providers. Authenticate source projects through project routing and protected federation metadata. Projections preserve source identity and fencing values; UIDs assigned to replicated copies cannot replace source lifetimes. +RBAC protects internal delivery resources and status writes. Interface status describes effective settings; it does not authorize provider actions. Providers use conditional status writes to confirm the settings they applied. Project routing and protected federation metadata retain the source identity across control planes. Galactic private-service policies use `authorization.persistent: true` and retain VPC identity checks. Deletion or a confirmed change to the selected VPC withdraws @@ -274,7 +272,7 @@ Extend the shared network services federation and DNS Kubernetes test environmen ### Monitoring Requirements -Measure renewal failures, settings age, guest-configuration time, and withdrawal latency. Users can inspect assigned names and DNS readiness. Operators trace context, access, route programming, interface, and serving reports. +Measure reconciliation failures, guest-configuration time, and withdrawal latency. Users can inspect assigned names and DNS readiness. Operators trace context, access, route programming, interface, and serving reports. ### Dependencies @@ -282,11 +280,11 @@ Require DNS serving and project APIs, authenticated clients, trusted federation ### Scalability -Locations sharing a regional path share access. Interface settings scale with interfaces; publications scale with endpoints. Qualify renewal throughput, controller sharding, and bounded search lists before increasing the canary cohort. +Locations sharing a regional path share access. Interface settings scale with interfaces; publications scale with endpoints. Qualify reconciliation throughput, controller sharding, and bounded search lists before increasing the canary cohort. ### Troubleshooting -Inspect `DNSReady` and `DNSConfigured`, then correlate source project, context UID, access UID, epoch and sequence. Querying an explicit resolver address does not verify guest configuration. +Inspect `DNSReady` and `DNSConfigured`, then trace network, context, access, and route readiness. Querying an explicit resolver address does not verify guest configuration. ## Implementation History From df222678a92ddbe6f3fd778c6f4a603e19540857 Mon Sep 17 00:00:00 2001 From: Scot Wells Date: Tue, 13 Oct 2026 12:34:13 -0500 Subject: [PATCH 09/11] docs: Describe versioned DNS access mappings --- docs/enhancements/internal-dns/README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/enhancements/internal-dns/README.md b/docs/enhancements/internal-dns/README.md index 354ebbde..0d38552e 100644 --- a/docs/enhancements/internal-dns/README.md +++ b/docs/enhancements/internal-dns/README.md @@ -183,9 +183,9 @@ spec: value: fd70:100::10 port: 53 transports: [UDP, TCP] - authorization: + version: # DNS issues the context epoch; network services preserve it across projections. - writerEpoch: 3 + epoch: 3 # Advance the sequence when access intent changes; use conditional API writes. sequence: 27 ``` @@ -254,11 +254,11 @@ The initial guest contract supports one managed DNS context. A provider must rej ### Publication and lifecycle -Products reserve names through `DNSRegistration` and publish eligible addresses through `DNSRecordContribution`. A trusted issuer authorizes publishers through `DNSContributionGrant`; publication credentials cannot write grants or resolver access. Compute owns instance and service eligibility; Connect owns export eligibility. DNS and network services do not inspect Compute resources. +Products reserve names through `DNSRegistration` and publish eligible addresses through `DNSRecordContribution`. Project RBAC authorizes product publication; publisher credentials cannot program resolver access. Compute owns instance and service eligibility; Connect owns export eligibility. DNS and network services do not inspect Compute resources. Reconcile access, publication, and settings independently per project and region. Persist sequences, use conditional writes, and resume from committed state after takeover. Failure in one region must not block healthy regions. Replication and retries preserve lifetimes and version fences. -Products explicitly withdraw unhealthy endpoints. Unavailable observations retain the last reported endpoint state. Withdrawal bounds include cached-answer TTLs. Removing a location's last consumer clears its settings; removing the region's last consumer withdraws access. Network deletion retires the DNS context. Recreated networks and retained interfaces cannot inherit retired authorization. +Products explicitly withdraw unhealthy endpoints. Unavailable observations retain the last reported endpoint state. Withdrawal bounds include cached-answer TTLs. Removing a location's last consumer clears its settings; removing the region's last consumer withdraws access. Network deletion retires the DNS context. Recreated networks and retained interfaces cannot inherit retired access mappings. ## Production Readiness Review Questionnaire From 74e0bb8a43ead7ceb60f6cf7084b4bcc259bbfc8 Mon Sep 17 00:00:00 2001 From: Scot Wells Date: Tue, 13 Oct 2026 12:40:05 -0500 Subject: [PATCH 10/11] docs: Align network access version examples --- docs/enhancements/internal-dns/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/enhancements/internal-dns/README.md b/docs/enhancements/internal-dns/README.md index 0d38552e..a2b68e85 100644 --- a/docs/enhancements/internal-dns/README.md +++ b/docs/enhancements/internal-dns/README.md @@ -213,7 +213,7 @@ spec: # Preserve source access identity and revision across control planes. accessBindingRef: name: application-us-central-1 - writerEpoch: 3 + epoch: 3 sequence: 27 # The private-service frontend uses this address inside the consumer VPC. nameservers: ["fd53::53"] From 288fbd134b6efb670bffbca6b60fd7385d1f5662 Mon Sep 17 00:00:00 2001 From: Scot Wells Date: Tue, 13 Oct 2026 13:33:04 -0500 Subject: [PATCH 11/11] docs: Define regional DNS mappings --- docs/enhancements/internal-dns/README.md | 22 ++++++---------------- 1 file changed, 6 insertions(+), 16 deletions(-) diff --git a/docs/enhancements/internal-dns/README.md b/docs/enhancements/internal-dns/README.md index a2b68e85..f51a10ce 100644 --- a/docs/enhancements/internal-dns/README.md +++ b/docs/enhancements/internal-dns/README.md @@ -177,17 +177,9 @@ spec: uid: 33333333-3333-4333-8333-333333333333 # A trusted location mapping selects the regional shared fleet. region: us-central-1 - queryIdentity: - type: DestinationAddress - # Authorize the service-side destination, distinct from fd53::53. - value: fd70:100::10 - port: 53 - transports: [UDP, TCP] - version: - # DNS issues the context epoch; network services preserve it across projections. - epoch: 3 - # Advance the sequence when access intent changes; use conditional API writes. - sequence: 27 + # Map verified VPC traffic to this service-side destination. + # DNS serves port 53 over UDP and TCP. + destinationAddress: fd70:100::10 ``` Network services create access only for an authorized network location. They coordinate the DNS binding with generic private-service intent that pins the consumer VPC lifetime and backend destination. RBAC controls who can publish network access intent. Galactic validates the pinned consumer VPC and supports persistent authorization for DNS private endpoints. @@ -210,11 +202,9 @@ spec: # Proposed desired state owned by network services, protected from consumer writes. contextRef: name: application - # Preserve source access identity and revision across control planes. + # Identify the regional DNS configuration across control planes. accessBindingRef: name: application-us-central-1 - epoch: 3 - sequence: 27 # The private-service frontend uses this address inside the consumer VPC. nameservers: ["fd53::53"] # Use the DNS-allocated managed suffix for relative names. @@ -248,7 +238,7 @@ Galactic private-service policies use `authorization.persistent: true` and retai VPC identity checks. Deletion or a confirmed change to the selected VPC withdraws access. Missing programming observations retain the applied path. -Publish settings only after DNS reports the access sequence ready and Galactic reports the corresponding policy generation programmed on required nodes. `NetworkContext` reports a proposed `DNSReady` condition separately from network readiness. Providers report `DNSConfigured` after applying current settings, reconcile updates, and reject stale revisions. +Publish settings only after DNS reports the current access binding generation ready and Galactic reports the corresponding policy generation programmed on required nodes. `NetworkContext` reports a proposed `DNSReady` condition separately from network readiness. Providers report `DNSConfigured` after applying current settings, reconcile updates, and reject stale revisions. The initial guest contract supports one managed DNS context. A provider must reject unsupported combinations of managed contexts across interfaces rather than merge private resolver settings. A transient failure must not redirect private queries to a public resolver. @@ -256,7 +246,7 @@ The initial guest contract supports one managed DNS context. A provider must rej Products reserve names through `DNSRegistration` and publish eligible addresses through `DNSRecordContribution`. Project RBAC authorizes product publication; publisher credentials cannot program resolver access. Compute owns instance and service eligibility; Connect owns export eligibility. DNS and network services do not inspect Compute resources. -Reconcile access, publication, and settings independently per project and region. Persist sequences, use conditional writes, and resume from committed state after takeover. Failure in one region must not block healthy regions. Replication and retries preserve lifetimes and version fences. +Reconcile access, publication, and settings independently per project and region. Use conditional writes and resume reconciliation from stored intent after takeover. Failure in one region must not block healthy regions. Galactic verifies network lifetimes and current programming; DNS owns publication ordering. Products explicitly withdraw unhealthy endpoints. Unavailable observations retain the last reported endpoint state. Withdrawal bounds include cached-answer TTLs. Removing a location's last consumer clears its settings; removing the region's last consumer withdraws access. Network deletion retires the DNS context. Recreated networks and retained interfaces cannot inherit retired access mappings.