On our side, www.adsemi.com is verified, the CNAME to zadvery3.up.railway.app is propagated, and the TLS certificate is valid. The CNAME target resolves correctly to our edge, but public DNS resolution for www.adsemi.com itself is returning no A/AAAA records (ENOTFOUND), which means connections fail before ever reaching our infrastructure. The issue is that your registrar's nameservers (worldnic.com) are serving the CNAME but not resolving the chain to an address record. We'd suggest checking the CNAME configuration for www.adsemi.com with your DNS provider, or testing with a different DNS provider to confirm.

Thanks. Can you clarify the ENOTFOUND result? Network Solutions is authoritative for adsemi.com and is correctly returning www.adsemi.com as a CNAME to zadvery3.up.railway.app. Since the CNAME target is in the railway.app zone, I would expect the recursive resolver to follow the CNAME and obtain the A/AAAA records from Railway’s authoritative DNS rather than Worldnic returning those address records itself.

Railway also shows the CNAME as propagated and the TLS certificate as valid. The same failure occurs over a separate cellular connection with Wi-Fi disabled, so it does not appear to be specific to my local ISP/network.

Can you provide the exact DNS lookup/result showing www.adsemi.com returning ENOTFOUND, including which resolver was queried? That would help determine whether the problem is actually with Worldnic or with resolution of the Railway CNAME target.

Additional DNS testing: the authoritative Network Solutions nameservers are returning the correct CNAME. Direct queries to both NS49.WORLDNIC.COM and NS50.WORLDNIC.COM return www.adsemi.com CNAME zadvery3.up.railway.app, and the Railway target resolves to 69.46.46.79.

However, Google DNS (8.8.8.8), Cloudflare (1.1.1.1), and my ISP resolver are still returning the old www.adsemi.com A record 206.188.192.198.

So the authoritative zone appears correct, but public recursive resolvers are still serving the former A record. Can Railway confirm whether there is anything on the Railway side that could cause or prolong that stale resolution, or whether this is strictly a recursive DNS cache issue?

1. Confirm certificate status

Go to Settings → Networking → Custom Domain in the Railway dashboard. Check whether the certificate shows Issued, Pending, or Failed. If it's stuck on Pending/Failed, that's the root cause — proceed to steps 2–3 before retrying.

1. Check for a blocking CAA record

If the domain has a CAA record that doesn't authorize Railway's CA (Let's Encrypt), certificate issuance will silently fail.

bash

dig CAA adsemi.com

If it's missing or too restrictive, add:

adsemi.com. CAA 0 issue "letsencrypt.org"

1. Verify the CNAME and check for conflicting records

bash

dig CNAME www.adsemi.com

Confirm it resolves cleanly to zadvery3.up.railway.app with no typos or trailing-dot issues, and that there's no leftover A/AAAA record on www competing with the CNAME. Cross-check propagation with a tool like whatsmydns.net.

1. Force certificate re-issuance

If the cert is stuck in a bad state, remove the custom domain from the Railway project, wait a few minutes, then re-add it. This forces Railway to retry issuance from scratch.

Thank you. I ran the curl --resolve test:

curl.exe --resolve www.adsemi.com:443:69.46.46.79 https://www.adsemi.com/

It succeeded and returned the application HTML. So Railway TLS, SNI/custom-domain routing, and the application are working when recursive DNS is bypassed. That appears to confirm the remaining issue is stale DNS caching/propagation of the former 206.188.192.198 A record.

I appreciate the help.

good to hear