Hi,

A custom domain on our service never leaves certificate status

VALIDATING_OWNERSHIP, even though Railway itself reports the DNS record as

propagated and matching. There is no errorMessage on the domain object.

Project 50abf058-2f54-4164-8f74-fda285ab48fe

Environment production / a0206739-5f52-4a73-b51f-6ce411054206

Service coordinator / bba7e1b9-6c59-43ae-b07f-b457ed9cbff4

Domain api.vorq.co (target port 8402)

WHAT HAPPENED

• 2026-09-03: added api.vorq.co. Binding 5f139700-25bf-446e-bb9b-8ee2ad33efc4,

  required CNAME target e0a7of55.up.railway.app. We created that CNAME; Railway

  moved the record to DNS_RECORD_STATUS_PROPAGATED with required == current.

  Certificate stayed in VALIDATING_OWNERSHIP for more than 12 hours.

• 2026-09-04: deleted the domain and re-added it. New binding

  304daeaa-ecde-456f-88bf-31bfbea7e75f, new required target

  vgdf3ryx.up.railway.app. We updated the CNAME accordingly. Railway again

  reports PROPAGATED with required == current, and the certificate is again

  stuck in VALIDATING_OWNERSHIP.

So the failure reproduced on two independent bindings with two different CNAME

targets, which rules out a stale or wrong record on our side.

WHAT WE VERIFIED

• CNAME api.vorq.co -> vgdf3ryx.up.railway.app, resolving to 69.46.46.93

  (the first binding resolved to 69.46.46.67). Confirmed via 1.1.1.1.

• The zone is on Cloudflare, and the record is DNS only — the proxy is OFF.

  The resolved address is Railway's, not a Cloudflare proxy address.

• No CAA records on vorq.co or api.vorq.co.

• No conflicting AAAA, TXT or _acme-challenge records.

• HTTP reaches the edge: http://api.vorq.co/healthz returns 301, and

  http://api.vorq.co/.well-known/acme-challenge/ returns 404, so

  requests are being served by Railway.

• Port 443 completes a TLS handshake and serves the default *.up.railway.app

  certificate, so the domain is routed but has no certificate of its own.

The service itself is healthy and serving normally on its Railway-generated

domain, coordinator-production-414d.up.railway.app.

Could you look at why ownership validation never completes for this domain?

SECONDARY ISSUE

The service also has a second generated domain,

coordinator-production-3799.up.railway.app, which appeared after an update to

the service's networking config and duplicates coordinator-production-414d.

We would like it removed; there is no delete operation for it in the API

surface we have access to.

Thanks.