Project: vetnara-dk (a5352f2d-31f0-4208-bc46-c0e22f1d1f36) Environment: production (d16fcd0d-662b-47f7-9721-24a2c3a712b2) Service: vetnaer-dk (754274d3-8194-46ea-b227-4af4f2bb6e18) Region: europe-west4 A custom domain has never received a certificate. It sits at CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP indefinitely while Railway itself reports the DNS record as DNS_RECORD_STATUS_PROPAGATED. Current test host (a throwaway subdomain, nothing live on it): railway-test.vetnaer.dk -> CNAME 6n33bxwh.up.railway.app -> A 69.46.46.31 domain id c13fef52-3b16-460c-89dd-fd2ea476d5fb, created 2026-08-14 ~09:07 UTC requiredValue == currentValue == 6n33bxwh.up.railway.app, status PROPAGATED certificateStatus VALIDATING_OWNERSHIP continuously from creation to at least 09:33 UTC The strongest clue: your edge does not appear to bind the hostname at all. curl -k https://railway-test.vetnaer.dk/ -> 404 curl https://vetnaer-dk-production.up.railway.app/ -> 200 (same service, same minute) TLS to the custom host presents your default *.up.railway.app wildcard, so requests fail with ERR_TLS_CERT_ALTNAME_INVALID. Timeline: - 2026-08-13 ~00:09 UTC: first cutover of www.vetnaer.dk. DNS propagated within a minute, certificate stuck at VALIDATING_OWNERSHIP, no HTTPS. Reverted after ~12 minutes. - 2026-08-13 onward: throwaway railway-test.vetnaer.dk (plain CNAME, no apex flattening) showed the same behaviour for 20+ minutes, and then for 14 hours. - 2026-08-14 08:15 UTC: found and removed an unrelated deploy-trigger loop, leaving one stable SUCCESS deployment. Watched 24 minutes on a stable service: no change. - 2026-08-14 ~08:52 UTC: explicit customDomainIssueCertificate returned true and changed nothing over a further 5 minutes. - 2026-08-14 09:07 UTC: deleted and re-added the domain for a brand-new order (note the CNAME target changed to 6n33bxwh), repointed DNS, confirmed propagation. Watched 24 more minutes: no change. Ruled out on our side, all verified: - No CAA records at any level (checked over DNS-over-HTTPS). - DNSSEC disabled. - No AAAA records on the host or on either Railway edge target. - Cloudflare proxy OFF (DNS-only) on every record involved; SSL mode "full". - Port 80 reachable and /.well-known/acme-challenge/ is not redirected to HTTPS. - The domains GraphQL query lists exactly one required DNS record for the domain (the traffic-route CNAME, no TXT record requested), and it is PROPAGATED. Question: is certificate issuance blocked for this account or project? Nothing we can change on the DNS side appears to affect it, and the 404 from your edge suggests the domain is never attached to the router.

Custom domain stuck at VALIDATING_OWNERSHIP indefinitely; edge returns 404 for the hostname

laxen123

HOBBYOP

7 days ago

Project: vetnara-dk (a5352f2d-31f0-4208-bc46-c0e22f1d1f36)

Environment: production (d16fcd0d-662b-47f7-9721-24a2c3a712b2)

Service: vetnaer-dk (754274d3-8194-46ea-b227-4af4f2bb6e18)

Region: europe-west4

A custom domain has never received a certificate. It sits at CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP indefinitely while Railway itself reports the DNS record as DNS_RECORD_STATUS_PROPAGATED.

Current test host (a throwaway subdomain, nothing live on it):

railway-test.vetnaer.dk -> CNAME 6n33bxwh.up.railway.app -> A 69.46.46.31

domain id c13fef52-3b16-460c-89dd-fd2ea476d5fb, created 2026-08-14 ~09:07 UTC

requiredValue == currentValue == 6n33bxwh.up.railway.app, status PROPAGATED

certificateStatus VALIDATING_OWNERSHIP continuously from creation to at least 09:33 UTC

The strongest clue: your edge does not appear to bind the hostname at all.

curl -k https://railway-test.vetnaer.dk/ -> 404

curl https://vetnaer-dk-production.up.railway.app/ -> 200 (same service, same minute)

TLS to the custom host presents your default *.up.railway.app wildcard, so requests fail with ERR_TLS_CERT_ALTNAME_INVALID.

Timeline:

2026-08-13 ~00:09 UTC: first cutover of www.vetnaer.dk. DNS propagated within a minute, certificate stuck at VALIDATING_OWNERSHIP, no HTTPS. Reverted after ~12 minutes.
2026-08-13 onward: throwaway railway-test.vetnaer.dk (plain CNAME, no apex flattening) showed the same behaviour for 20+ minutes, and then for 14 hours.
2026-08-14 08:15 UTC: found and removed an unrelated deploy-trigger loop, leaving one stable SUCCESS deployment. Watched 24 minutes on a stable service: no change.
2026-08-14 ~08:52 UTC: explicit customDomainIssueCertificate returned true and changed nothing over a further 5 minutes.
2026-08-14 09:07 UTC: deleted and re-added the domain for a brand-new order (note the CNAME target changed to 6n33bxwh), repointed DNS, confirmed propagation. Watched 24 more minutes: no change.

Ruled out on our side, all verified:

No CAA records at any level (checked over DNS-over-HTTPS).
DNSSEC disabled.
No AAAA records on the host or on either Railway edge target.
Cloudflare proxy OFF (DNS-only) on every record involved; SSL mode "full".
Port 80 reachable and /.well-known/acme-challenge/ is not redirected to HTTPS.
The domains GraphQL query lists exactly one required DNS record for the domain (the traffic-route CNAME, no TXT record requested), and it is PROPAGATED.

Question: is certificate issuance blocked for this account or project? Nothing we can change on the DNS side appears to affect it, and the 404 from your edge suggests the domain is never attached to the router.

Awaiting User Response

3 Replies

Railway

BOT

7 days ago

The domain requires a TXT ownership-verification record that has not been published yet. The CNAME for traffic routing is propagated, but a separate record is also needed: a TXT record at _railway-verify.railway-test.vetnaer.dk containing the verification token shown on the domain's settings page in the dashboard. Until that record is present and verified, the certificate workflow will not advance past VALIDATING_OWNERSHIP and the edge will not bind the hostname, which explains both the 404 and the wildcard cert. Add that TXT record in Cloudflare (DNS-only, no proxy), and once it propagates the certificate should issue and routing should come online.

Status changed to Awaiting User Response Railway • 7 days ago

laxen123

HOBBYOP

7 days ago

Solved — and there is an API bug worth flagging.

The domain was missing the _railway-verify TXT record. All our domain creates and status reads went through the GraphQL API, and domains { customDomains { status { dnsRecords } } } returns ONLY the traffic-route CNAME — it never lists the TXT requirement that the dashboard's Configure DNS dialog shows. So ownership validation waited forever for a record we were never told about, and the edge 404 is just how an unverified domain presents.

Repro: create a custom domain in the dashboard and compare its Configure DNS dialog (CNAME + TXT) with the API's dnsRecords for the same domain (CNAME only).

Confirmation: on a fresh test domain we added both records and the certificate issued and served in about 60 seconds.

Suggestion: make the API return the TXT verification row too.

Status changed to Awaiting Railway Response Railway • 7 days ago

brody

EMPLOYEE

7 days ago

GQL by design only returns the fields requested, the txt value is a field that can be requested and our API will return it.

Status changed to Awaiting User Response Railway • 7 days ago

Welcome!