Alpha. Vary is under active development and not ready for production use. Syntax, APIs, performance, and behaviour may change between releases.

Domain proof token

The domain proof token is the value Via creates before it will route traffic for a custom hostname. It is the ownership proof material for an app-domain request.

This is a deliberately strong gate. A deploy proves that an app can run on Via. It does not prove that the app owner controls api.example.com, tracker.example.com, or any other public name. Via asks for a separate hostname proof before it sends public traffic to that app.

Why Via asks for it

Without a domain proof, any app owner with deploy permission could try to claim a hostname that belongs to another team, customer, or environment. The proof token forces the requester to involve whoever controls DNS for that hostname.

That can feel invasive because the intended proof is outside the app deploy flow. Via treats that friction as part of the security model. Public routing is not activated only because source was pushed, a process started, or a manifest named a hostname.

What the token proves

For TXT verification, Via creates a random token scoped to one app and one hostname. The app-domain response exposes the proof material under verification:

Response field	Meaning
`verification.type`	The proof kind. Current Via app-domain requests use `dns_txt`.
`verification.name`	The TXT record name Via expects, such as `_vary-domain.tracker.example.com`.
`verification.value`	The exact token value to prove. Copy it as-is.
`verification.expires_at`	The time after which the token should no longer be treated as valid.

If the Via server has app-domain proof disabled by operator policy, app-domain responses expose domain_proof_policy: "disabled", proof_required: false, and verification: null. In that mode Via marks the request's ownership proof as verified without requiring a TXT token. This setting should only be used for private/lab servers, trusted wildcard DNS delegation, or environments where an external gateway or enterprise DNS workflow proves ownership outside Via.

Example:

{
  "verification": {
    "type": "dns_txt",
    "name": "_vary-domain.tracker.example.com",
    "value": "vary-domain=app_123:tracker.example.com:random",
    "expires_at": "2026-07-02T00:00:00Z"
  }
}

The DNS record, when a DNS challenge is being used, is built from those exact fields:

DNS field	Value to use
Record type	`TXT`
Name	`verification.name`
Value	`verification.value`
TTL	Whatever your DNS process requires. Via does not encode TTL in the token.

Current alpha verification does not perform a live authoritative DNS lookup in the server. The verify request accepts observed_token, which is the TXT value observed by an operator command, automation, or deterministic DNS/test fixture. When observed_token matches verification.value, the app-domain request can move from pending to verified.

What it does not prove

The token does not grant app access, operator access, deploy permission, certificate private-key access, secret access, or permission to change unrelated routes. It only satisfies the ownership proof gate for that app-domain request.

Even after proof succeeds, route activation can still be blocked by other gates:

Gate	Why it can still block routing
Operator approval	The matched policy may require human review.
Certificate coverage	The effective certificate must cover the hostname.
Hostname or path conflicts	Via must avoid ambiguous public routing.
Route validation	The hostname, path, target service, and port rules must pass.
Load-balancer apply	The proxy table must be updated successfully.
Running release	Via needs a healthy runtime target before public traffic can flow.

Disabling app-domain proof does not disable operator approval, hostname policy, route conflict checks, certificate coverage, or load-balancer readiness.

How to verify a domain

Request or inspect the app-domain record and copy the dns value from the response:

vary app domain request my-api my-api.apps.example.com --target prod
vary app domain list my-api --target prod

In the current alpha flow, pass the observed value when asking Via to verify the domain:

vary app domain verify my-api my-api.apps.example.com --target prod --observed-token <dns-value>

If a future Via release adds live DNS lookup, this page should be updated to say which resolver path is used, which record is queried, and whether observed_token is still accepted.

Handling the token

Treat the token as operational proof material:

Practice	Reason
Publish it only for the hostname being claimed.	The token is scoped to one app-domain request.
Do not paste unrelated tokens into DNS.	Wrong tokens make verification fail and confuse audits.
Remove stale proof records after verification.	Old records can make later reviews harder to understand.
Create a new request for exposed tokens.	The new request gives Via fresh proof material.

Leaving the TXT record in DNS after verification does not by itself grant new Via permissions, but stale records can confuse audits and future ownership reviews. Use your DNS retention policy consistently.

Where this fits

The domain proof token is one step in Via route readiness:

Step	Requirement
1	The hostname must match operator-owned domain policy.
2	The app-domain request must pass ownership proof.
3	Operator approval must pass when policy requires it.
4	Certificate coverage must exist for the hostname.
5	Route validation and load-balancer apply must succeed.

See Domains and routes for the full route lifecycle and TLS, routing, and the proxy for the proxy gates that decide whether public traffic reaches an app.

Domains and routes Certificates