Fly Machines cannot resolve one specific external hostname (enoad.nvmc.uscg.gov), but networking is otherwise healthy

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:

https://enoad.nvmc.uscg.gov/

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):

dig enoad.nvmc.uscg.gov

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

https://enoad.nvmc.uscg.gov/

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.

I don’t have an answer for the problem, but I assume a Fly machine can change its resolver, so you can switch to Cloudflare or Google. Would that get you out of the woods in the short term?


Ah, you beat me to it - you’re already doing this!

They have their own resolver, and it’s been known to not handle all corner cases correctly in the past.

That particular address is not resolving for me, either, from within an ewr Machine, so this might be another one. Possibly it’s due to it not having an AAAA record (IPv6), :thinking:…

In general, when you want to raise an issue for Fly.io staff to see, it’s best to use the Questions / Help category (which I just added to your thread). That marker has special handling within the forum.

hi, thanks for flagging this! We’ve got eyes on it. Off the bat it does appear like something might be awry with the upstream nameservers-- one of our network folks noticed timeouts to @cgns5, which I can reproduce:

 dig @cgns5.uscg.gov enoad.nvmc.uscg.gov A +norecurse
;; communications error to 152.121.50.3#53: timed out

it doesn’t look like this dns server is reachable via the public internet currently, unlike the others

you may have luck switching resolvers, but I do see cgns5 listed as a NS for uscg.gov via Cloudflare, quad9, and google’s public DNS. For the time being, hardcoding the IP for enoad might serve as a workaround.

do you have any contacts at uscg? if so, reporting this might help speed up a fix.