Hi Railway team,

A custom domain is permanently stuck in certificate ownership validation and

will not issue a Let's Encrypt certificate, despite DNS being provably correct.

I've done full client-side forensics (below) and it points to a stuck/stale

domain registration on Railway's side. Requesting manual intervention.

── IDENTIFIERS ─────────────────────────────────────────────

Project: NMG — f0c0e6ae-6870-408e-bb0f-32d84ed7bcad

Environment: production — db28bcdd-f779-458d-be8b-f546a72971c5

Service: Website — 29415d50-64e6-457f-a1c1-6c2a00c30ac0

          (Next.js, repo osninc/NMG-website, listens on :3000)

Custom domain: www.noisemanagementgroup.com

domain id: 752b0cf6-7f3d-4c67-9fdf-2c527ccc7fea

target: ynr5zr9p.up.railway.app

target port: 3000

Working generated domain (serves the site fine): website-production-9404.up.railway.app

── SYMPTOM ─────────────────────────────────────────────────

domain-status: verified=false,

certificate.status = CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP,

errorMessage = null. Stuck here for 2+ hours.

Over that time, domain-status.currentValue flapped between the stale value

"noisemanagementgroup.com" (REQUIRES_UPDATE) and the correct

"ynr5zr9p.up.railway.app" (PROPAGATED); it is now stably PROPAGATED but the

cert still will not issue.

── CLIENT-SIDE FORENSICS (all point to Railway, not our DNS) ─

1. Authoritative DNS is correct on both GoDaddy nameservers:

   dig @ns55.domaincontrol.com www.noisemanagementgroup.com CNAME -> ynr5zr9p.up.railway.app.

   dig @ns56.domaincontrol.com www.noisemanagementgroup.com CNAME -> ynr5zr9p.up.railway.app.

2. Public resolvers agree and resolve to a Railway edge IP:

   www.noisemanagementgroup.com -> ynr5zr9p.up.railway.app -> 69.46.46.127 (via 8.8.8.8 and 1.1.1.1)

   ynr5zr9p.up.railway.app -> 69.46.46.127

   website-production-9404.up.railway.app -> 69.46.46.125 (same edge range)

3. No CAA records (Let's Encrypt is not blocked):

   dig noisemanagementgroup.com CAA @ns55.domaincontrol.com -> NOERROR, ANSWER: 0

4. TLS served on www is the Railway HOLDING cert, not a cert for the domain:

   openssl s_client -connect www.noisemanagementgroup.com:443 -servername www.noisemanagementgroup.com

   -> issuer = Let's Encrypt (CN=YE1), subject = CN=*.up.railway.app

   (i.e. the per-domain certificate was never issued)

5. Railway edge returns HTTP 404 for this host (domain not actually routed to the service):

   curl http://www.noisemanagementgroup.com/.well-known/acme-challenge/probe -> 404

   curl -k https://www.noisemanagementgroup.com/ -> 404

   (a wrong port would return 502; a 404 means the custom domain is not active on the edge)

6. Certificate Transparency (crt.sh) shows ZERO Let's Encrypt certs ever issued

   for this domain — only GoDaddy certs from 2026-07-26. So issuance never succeeded.

── EVERYTHING WE'VE ALREADY TRIED ──────────────────────────

• Corrected the GoDaddy CNAME (www -> ynr5zr9p.up.railway.app), verified authoritative.

• The custom domain was deleted & re-added ~3-4 times during troubleshooting, which

  rotated the target (k4dm5xvf -> 31v36y0h -> ynr5zr9p). This may have tripped a

  Let's Encrypt failed-validation rate limit — please check.

• Removed the apex (noisemanagementgroup.com) custom domain from Railway; the root is

  handled via GoDaddy 301 forwarding to https://www.noisemanagementgroup.com (so MX/email

  stays intact). Only www remains as a custom domain.

• Corrected the custom domain target port 8080 -> 3000 (Next.js).

• Restarted the Website service.

• Full redeploy (deployment 4d7bfe6b-1b22-431b-9edc-480376bbbd89, SUCCESS).

• Waited 2+ hours. No change.

── REQUEST ─────────────────────────────────────────────────

1. Clear the stale/stuck domain registration and cached DNS for

   www.noisemanagementgroup.com (domain id 752b0cf6-7f3d-4c67-9fdf-2c527ccc7fea),

   then re-run ownership validation and Let's Encrypt issuance.

2. Confirm whether we hit a Let's Encrypt rate limit from the earlier re-adds and,

   if so, reset/clear it.

3. Confirm the ynr5zr9p.up.railway.app endpoint is correctly wired to the Website

   service — the edge currently 404s for this host even though the endpoint resolves.

DNS, port, endpoint, and CAA are all verified correct on our side; the block is on

Railway's cert/ownership pipeline. Thanks for any manual push you can give it.