Skip to content

Propose internal DNS for Galactic VPC - #922

Open
scotwells wants to merge 17 commits into
mainfrom
docs/internal-dns-product-proposal
Open

scotwells wants to merge 17 commits into
mainfrom
docs/internal-dns-product-proposal

Conversation

@scotwells

@scotwells scotwells commented Oct 7, 2026 •

Copy link
Copy Markdown
Contributor

Summary

Proposes internal DNS for Galactic VPCs: automatic private names, custom zones, isolation, health-aware service discovery, and DNS status. Every VPC uses datum.internal as its default domain with independent records. The same search domain lets workloads resolve short names within their VPC; explicit DNS sharing exposes qualified peer names.

The enhancement follows the template and includes illustrative dig commands and responses. A concise architecture overview covers control-plane ownership and shows how Galactic supplies trusted network identity to a shared DNS fleet.

Component designs cover Private Service Connect and the DNS control plane and serving fleet.

Validation

Checked table-of-contents anchors, code fences, whitespace, and default-domain consistency across the enhancement and architecture overview.

Refs #921.

@scotwells scotwells added this to the October 2026 - "Hedy" milestone Oct 7, 2026
0xmc
0xmc previously approved these changes Oct 7, 2026

@0xmc 0xmc left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall a solid proposal. You may wish to add how health-aware service discovery fits into the system boundaries, and how connected VPCs might share private zones.

@scotwells

Copy link
Copy Markdown
Contributor Author

@0xmc I was going back through the original design in my head last night and I decided I didn't like the way it was coupling the DNS platform to VPCs. I've updated the design to take a new approach that lets DNS and Galactic VPC be separate and allow network services to stitch the services together.

The new design allows multiple DNS contexts to be created on the DNS platform that we can use to represent individual VPCs and the zones that should be queryable within that context. The DNS Context is selected at query time based on a unique destination address that's used when Galactic forwards the DNS request from the Consumer's VPC to the DNS platform's VPC.

The DNS endpoint would be exposed on the VPC side using a stable address so it's consistent across all VPCs. Galactic will handle translating the stable destination address exposed in the VPC to a VPC-unique destination address that maps to a DNS context.

I would refer to the trusted network identity diagram to understand the integration between Galactic VPC and the DNS platform.

@scotwells scotwells removed this from the October 2026 - "Hedy" milestone Oct 13, 2026
@scotwells
scotwells requested a review from 0xmc October 13, 2026 15:17
T -->|DNS records and configuration| E
```

| Control plane | Responsibility |

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correlation of the control planes to the diagram above would make the design more clear.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@0xmc agreed, I'll get a diagram together that shows the deployment architecture.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants