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.
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.
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.
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.
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.
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.
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.