DNS issues for specific domain
I'm having some weird DNS issues causing 523 errors on a specific domain. However, it works fine for other domains with records pointing to the same server IP. I've ruled out any firewalls and issues on my server side of things, as not only have I not modified any configurations, but the host is still reachable from other domains and just one domain is affected.
It originally started occuring last Tuesday and quickly resolved itself, however as of yesterday (Tuesday) it's started again, and is now fully unreachable from the domain - yet works fine for every other record and sub/domain.
I've tried a DNS propagation check and it shows Australia is unreachable for the affected domain, yet my other domains work fine (2nd screenshot).
I doubt it would be the cause but the specific domain being affected is also the only domain I have zero trust installed on, it's worked fine for years.
Any suggestions?
8 Replies
Would you mind sharing the domain, as well as some of the domains that use the same IP but are working?
Do you have more specific times as to when the issue started/stopped? Especially, do you know the time the issue stopped the first time?
When you say "I have Zero Trust installed", what exactly do you mean? Access?
Heyo, no worries, I'll try to cover as much detail as I can:
Would you mind sharing the domain, as well as some of the domains that use the same IP but are working?Affected domain:
botfuel.m4artz.dev (walled by Zero Trust Access)
Working domains: cms.botfuel.dev & cdn.botfuel.dev 403 is a server hit (requires a query token)
Do you have more specific times as to when the issue started/stopped? Especially, do you know the time the issue stopped the first time?First noticed occurance: 21st Jan 2025 @ 2:50 PM ACDT Service resumed around: 21st Jan 2025 @ 4:00 PM ACDT This occurance was only affecting
cms.botfuel.dev. Occasionally requests would work then 523 again, I noticed this when frequently refreshing in a short period (with client-side cache disabled).
Other occurance: 28th Jan 2025 @ 3:45 PM ACDT
Service has not resumed.
This occurance is only affecting botfuel.m4artz.dev.
When you say "I have Zero Trust installed", what exactly do you mean? Access?Zero Trust Access is installed onto
botfuel.m4artz.dev to enforce Google login.
A few Ray IDs from the 523 errors if they're helpful.
909aac2ffc8ba97f
909aad6148b5a813
909aad892feba813
909acc8bacef6541From the timestamps, it doesn't seem to be related to the other problem that I had in mind.
The domain that isn't working has different Edge IPs for me from the domains that are working. Are they in the same account/ same plan level(free/paid)?
Interesting. Yep, all domains are under the same account and plan level.
Can you send some example requests to the domain that doesn't work, but use the IP of one of the domains that does work? As the domain is behind Access, I can't test myself.
I've tried a few times with the same result, here are some Ray IDs from calls to the affected domain from the server IP:
909ac5b9c8eea88f
909ac5ef68aca88f
909ac62a5a0fa88fCan you just check that you're using the Full (Strict) SSL mode on Cloudflare? Can you confirm the domain is working (from an external source) if you bypass Cloudflare and connect to the IP address directly? A 523 on one domain is just really strange if a different domain works with the exact same A record.
The only thing that comes to my mind is an actual problem with the Zero Trust IP address, that maybe it is not allowed to reach your server.
Can you try a traceroute to the last IPs that Cloudflare used to connect to the domain in question?
SSL is enabled in full strict mode, yep. I can confirm the domain works when bypassing Cloudflare via connecting to the IP directly.
I do have some IP whitelists set in place however the IP ranges listed by Cloudflare are all whitelisted (https://www.cloudflare.com/en-au/ips) - unless Zero Trust uses a different IP range?
The last IP tracert connects to is
2606:4700:3033::ac43:de8f.
After checking this morning, it seems service has resumed once again. I'll keep an eye on uptime and see if it occurs again. I'll keep you updated. 👍
A rough look at some analytics shows service resumed this morning (30th Jan 2025) around 5:30 AM ACDT.