feat: 플랫폼 서브도메인 DNS 레코드를 서버가 관리한다 - #114
Merged
Merged
Conversation
yessjun
force-pushed
the
feat/platform-dns-records
branch
from
September 7, 2026 05:09
a834095 to
0014318
Compare
ClientIps still explained a CDN header chain, and the certificate classes still called the shared wildcard a CDN origin certificate. Both retired with the CDN: the trusted hops are the reverse proxy, which restores the peer from PROXY protocol and sets X-Real-IP, and the app tier that forwards it; the wildcard is a Let's Encrypt one. The enum label stays until it is renamed on its own.
One interface the platform-subdomain lifecycle drives (ensure an A record, remove it, list the zone) and three implementations: Google Cloud DNS through its REST API, a noop for dev and test, and the fail-closed default that reports itself unconfigured so the api boots either way. The Google client signs the service-account assertion with jjwt and exchanges it for a bearer itself; no vendor SDK is added.
A platform subdomain now gets its own A record, written outside the transaction that changes the domain, so the row has to say where that write stands: a status, the last error and the time the record was last confirmed present. The three fields reach the user and admin domain views (contract v0.67.0); custom domains stay NONE by constraint.
The record is a step of the same three-phase apply under the same generation guard: ensured before the vhost is rendered, removed after it is gone, never a 422. A failed step leaves the route for the reconciler, the reservation sweeper takes a leftover record down before it frees the name, and the admin resync adds missing records and prunes single-label orphans under a platform root only when that is enabled.
Refusing a new platform publish when no provider is set is correct and happens earlier. Running the DNS step on every PRESENT push was not: a port edit or a reconcile of an existing name failed before the agent was called, so the vhost went untouched too, on a deployment whose names already resolve. The step now runs only when a provider is configured, the posture the reconciler already had. Two more from the same review. The resync ensured records from a manifest read before the provider calls, so a name released in between had its record put back with nothing left to take it down; it now re-reads before writing. And the prune read its claim set once, which let a name freed during the scan and immediately reclaimed lose the new owner's record; it now re-checks under the same lock it deletes under. The reserved-label set is folded to match the folded names it is compared against, and the no-op provider is refused on production, where it would mark every name applied while none resolves.
This branch is waiting on an operator to place a credential, not on review, so it has no claim on the lower number and another round took 0.68.0 to ship today. The rule is that whoever deploys first gets the lower number.
Another round needs a migration and deploys today, while this branch waits on an operator. Flyway is stricter than the contract constant: out-of-order application is off, so a lower number arriving after a higher one refuses to start. Whoever deploys first takes the lower number. Safe to rename because it has never been applied: the live history tops out at V112 and that host carries one database. An applied migration could not be moved at all, which is why this was measured rather than reasoned about.
yessjun
force-pushed
the
feat/platform-dns-records
branch
from
September 7, 2026 06:41
0014318 to
407d25d
Compare
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
1 participant
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.
📝 작업내용
dnsStatus와 두 필드, 연산 수 불변⭐️ 검증
pickle-review💬 리뷰 포인트