4 hours ago
Hi Railway team,
Some visitors can't open our custom domain, while most can. We believe the cause is in the DNS for *.up.railway.app, and we'd appreciate your help.
SETUP
- Custom domain: io.escolaenfermagemdevalor.com.br
- DNS (Cloudflare, DNS only, not proxied): CNAME io -> 7zkm0po4.up.railway.app, plus TXT _railway-verify.io. Both show as verified in the Railway dashboard.
- DNSSEC is not enabled on our zone. Our delegation and records are consistent across all of our authoritative nameservers.
SYMPTOM
- Some visitors in Brazil, on home Wi-Fi with their ISP's DNS, get DNS_PROBE_FINISHED_NXDOMAIN in Chrome (Chrome uses this code for any name that fails to resolve, including SERVFAIL).
- The same URL works on 1.1.1.1, 8.8.8.8, 9.9.9.9 and OpenDNS, on 12 filtering resolvers, and from 39 of 40 global check-host.net nodes (the Sao Paulo node took 0.33 s).
- Other domains open normally for the affected visitors.
WHAT WE FOUND IN up.railway.app (2026-11-12 19:54 UTC)
-
Single nameserver. The parent delegates up.railway.app to one nameserver only, ns1.railway.app, on one IPv4 address (66.33.23.33), with no IPv6:
$ dig +norec NS up.railway.app @blue.foundationdns.com
up.railway.app. 86400 IN NS ns1.railway.app.
ns1.railway.app. 300 IN A 66.33.23.33
-
No SOA and no NS at the zone apex. ns1.railway.app answers authoritatively (aa) but returns empty answers for both:
$ dig +norec SOA up.railway.app @ns1.railway.app -> NOERROR, ANSWER: 0, AUTHORITY: 0
$ dig +norec NS up.railway.app @ns1.railway.app -> NOERROR, ANSWER: 0, AUTHORITY: 0
RFC 1034/1035 require SOA and NS records at a zone apex. Without them, negative answers carry no SOA, and resolvers that check the child's NS set or apply stricter validation can treat the delegation as broken and return SERVFAIL.
-
Every name under the zone resolves (wildcard). For example, this-should-not-exist-12345.up.railway.app returns A 153.52.255.69. That alone isn't a problem; we mention it for completeness.
-
Our target resolves correctly when queried directly: 7zkm0po4.up.railway.app. 60 IN A 153.52.255.56. ns1 also handles TCP, queries without EDNS, EDNS version 1 (returns BADVERS) and mixed-case queries.
OUR SUSPICION (NOT YET CONFIRMED)
Some ISP resolvers fail to resolve 7zkm0po4.up.railway.app: they can't reach the single nameserver reliably, or they reject the zone for the missing SOA/NS. Because our custom domain must be a CNAME to that name, those visitors can't open the site. We haven't captured the failing resolver's answer yet; we'll send it once we have it.
REQUESTS
- Add SOA and NS records at the apex of up.railway.app on ns1.railway.app.
- Add redundancy for up.railway.app: two or more nameservers, ideally on different networks, with IPv6.
- Let us know if there are known resolution problems with Brazilian ISPs (Vivo, Claro, TIM and others), or a recommended setup for custom domains that avoids depending on *.up.railway.app resolution.
TO REPRODUCE
dig +norec NS up.railway.app @blue.foundationdns.com
dig +norec SOA up.railway.app @ns1.railway.app
dig +norec NS up.railway.app @ns1.railway.app
dig +norec A 7zkm0po4.up.railway.app @ns1.railway.app
Thanks!
1 Replies
4 hours ago
Your custom domain is set up correctly on our side: the CNAME points at the right target and is fully propagated, the domain is verified, and the certificate is valid. There is nothing to change in your records.
The pattern you describe, where visitors on public resolvers (1.1.1.1, 8.8.8.8) and other networks get through but some ISP resolvers return DNS_PROBE_FINISHED_NXDOMAIN, matches a failure at those resolvers rather than at your configuration. Switching an affected device or router to a public resolver, or testing from mobile data instead of home Wi-Fi, will confirm which resolver is failing.
The failing resolver's actual answer you mentioned capturing would help here: the resolver IP, the exact query, the full dig output with its status (NXDOMAIN or SERVFAIL), and the time in UTC.
Status changed to Awaiting User Response Railway • about 4 hours ago