Apex Domain Verification Bug, write-up

Question

Hi -- I was trying to get DNS set up on Squarespace and it wasn't working. Claude Code spat out the following analysis... it seems there is some contradiction between the docs in your verifier and the actual behavior. See below.

-----

# Apex domain verification never completes with ALIAS / CNAME flattening

Verifier requires a literal CNAME RRset that these mechanisms never publish.

## Summary

Railway's documentation states that apex domains are supported via CNAME Flattening and

dynamic ALIAS records:

> When adding a root or apex domain to your Railway service, you must ensure that you add
> the appropriate DNS record to the domain within your DNS provider. At this time, Railway
> supports CNAME Flattening and dynamic ALIAS records.

>

> — https://docs.railway.com/networking/domains/working-with-domains#adding-a-root-domain

In practice the domain verifier appears to require a literal `CNAME`-type answer at the

apex. ALIAS and CNAME flattening never expose a CNAME to resolvers by design — that is

their entire purpose, since a real CNAME is illegal at a zone apex that also holds MX/TXT

records (RFC 1034 §3.6.2). The verifier is therefore waiting on a record type that cannot

exist in a configuration the docs recommend.

## Environment

| | |

|---|---|

| DNS provider | Squarespace (`ALIAS` record type) |

| Domain | `userockwell.com` (apex) |

| Railway target | `vczqpfby.up.railway.app` |

## Actual behavior

`domain status` output, stable indefinitely:

```
"recordType":        "DNS_RECORD_TYPE_CNAME",
"currentValue":      "",
"requiredValue":     "vczqpfby.up.railway.app",
"status":            "DNS_RECORD_STATUS_REQUIRES_UPDATE",
"certificateStatus": "CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP"
```

Certificate issuance never leaves `VALIDATING_OWNERSHIP`. The domain serves Railway's

generic `*.up.railway.app` fallback certificate, producing browser security warnings for

real visitors.

## Evidence the DNS side was correct

- `dig userockwell.com A` → `69.46.46.23` (Railway edge)
- `dig vczqpfby.up.railway.app A` → `69.46.46.62` (Railway edge)
- Identical answers from Google, Cloudflare and Quad9 resolvers — fully propagated and

globally consistent

- `_railway-verify` TXT ownership token verified successfully
- `dig CNAME userockwell.com` → **empty, as expected.** ALIAS never publishes a CNAME

So `currentValue: ""` is not propagation lag. It is the verifier looking for an RRset that

structurally cannot appear.

## Secondary issue: no recovery path

Certificate retry is gated on status `FAILED`. Because the domain sits in

`VALIDATING_OWNERSHIP` indefinitely rather than failing, the retry path is permanently

unreachable. There is no lever to break the stall from the CLI.

## Suggested fix

Have the apex verifier accept an address-level match — resolve the target hostname and

compare against the apex's resolved A/AAAA set — instead of requiring a literal CNAME

RRset. Note the Railway edge returns multiple addresses (we observed `.23` and `.62` within

the same `/24`), so the comparison should be against the target's full current address set

rather than a single pinned IP.

Separately: either expose retry during `VALIDATING_OWNERSHIP`, or time that state out into

`FAILED` so the existing retry path becomes reachable.

## Current status

Worked around by serving the site from `www` and forwarding the apex at the registrar. The

ALIAS configuration can be recreated on request to reproduce.

## Out of scope

Noted for completeness; neither is a Railway defect:

- Squarespace refuses `ALIAS` records on a DNSSEC-signed zone (*"ALIAS records are not

allowed on a zone using DNSSEC"*), so following the apex guidance above requires

disabling DNSSEC on that provider. Worth a caveat in the docs.

- Squarespace's registrar-level domain forwarding drops the query string, which constrains

the workaround.