definitely puzzling! happy to help troubleshoot, and thank you for frontloading all that context
As an aside, if you’re looking for email support, you might take a look at our paid plans – could be a good option if your anticipated spend aligns with the correspondingly expanded usage quota.
That said, we definitely don’t want anyone to have a fly-related problem for months! So if you do feel uncomfortable sharing certain info in the forum, you can redact your problem description-- if it’s essential info that you absolutely cannot share we’d be happy to receive that over email if needed.
This does have an important drawback-- other users will be less able to help out. Of course, as with the better part of issues on our end, that’s somewhat less of a disadvantage 
Anywayy, on to the actual problem! Being able to reproduce this is a huge help, thank you! You mentioned that you have unaffected machines on the same network as an affected one–even better. A few things I’m curious about, that might help us narrow it down:
- Can you curl those sites with the
flyio-debug: doitheader? This will, among other things, give us an idea where traffic is coming in from that network. - You’ve probably already done this, but what does
digsay about those subdomains from the affected machines? Is it returning the same answers that you get on unaffected ones? How about if you use a large public resolver like8.8.8.8? - I’m guessing the answer is “no, so far” but are you able to resolve any fly.dev domains from the problem clients? Are they able to hit debug.fly.dev?