Hi Railway team,

I'm a customer running a static site service on Railway. When I attach a root domain (example.com, not www) as a custom domain, both the dashboard and railway domain status give a single instruction: create a CNAME record at @ pointing to <hash>.up.railway.app.

That instruction cannot be followed on a standards-compliant DNS zone. RFC 1034 §3.6.2 and RFC 2181 §10.1 are explicit that a CNAME may not coexist with other records at the same owner name, and a zone apex must carry SOA and NS records. A CNAME at @ is therefore invalid by construction — this is not a limitation peculiar to one DNS provider.

The common workarounds — ALIAS/ANAME records, or CNAME flattening — are proprietary vendor extensions rather than part of the DNS specification. The IETF work in this area (draft-ietf-dnsop-aname) expired without becoming an RFC, so there is no standardized behavior that a DNS provider is obliged to implement, and none that Railway can assume its customers have.

Could you clarify the supported path for apex domains?

1. Does Railway publish stable A/AAAA addresses (or an anycast range) that customers can point apex records at? If not, is that on the roadmap?
2. Does Railway's edge support HTTPS/SVCB resource records (RFC 9460)? That is the standards-track mechanism for precisely this problem, and would let apex domains work without vendor-specific extensions.
3. If the CNAME-at-apex instruction presumes the customer's DNS provider implements flattening, could the docs and the CLI/dashboard output state that explicitly, along with the recommended alternative for providers that do not?
4. In the meantime, is redirecting the apex to www — with www as a CNAME to Railway — the configuration you recommend and support?

I'd rather configure this the way you intend than guess at it. Thanks for taking a look.

Best regards,

Victor