We’ve isolated what appears to be a Fly DNS resolver issue affecting one specific hostname.
Environment
- App: voyaranova-dryrun-tf
- Machines
- Linux container
- Current date: 2026-08-07
Symptoms
Our application began failing before login with:
page.goto:
net::ERR_NAME_NOT_RESOLVED
for:
We have narrowed this considerably.
Confirmed observations
From inside the Fly machine:
getent hosts google.com
Works.
curl -I https://google.com
Works.
getent hosts enoad.nvmc.uscg.gov
Fails.
curl -I https://enoad.nvmc.uscg.gov/
Fails because the hostname cannot be resolved.
From outside Fly (our Mac):
returns:
152.121.188.89
No AAAA record is present.
Most importantly, from inside the SAME Fly machine:
curl -I
–resolve enoad.nvmc.uscg.gov:443:152.121.188.89
returns:
HTTP/1.1 200 OK
This proves:
- outbound connectivity is working
- HTTPS/TLS is working
- the destination server is reachable
- only DNS resolution of this hostname fails
Additional testing
- Restarted the Machine.
- Destroyed the Machine and created a completely new Machine.
- Same result.
Historical note
This exact application successfully connected to the same hostname from Fly earlier this year, so this appears to be a regression rather than an initial configuration problem.
Question
Is there a known issue with Fly recursive DNS resolving this hostname or this DNS zone?
Is there any additional diagnostic information you would like us to collect?
We’re currently planning to use a temporary /etc/hosts override so we can continue validation, but we’d prefer to understand and resolve the underlying DNS issue.
…