Problem: While TCP routing is functioning flawlessly with 100% accuracy (nearest fly node response), UDP routing exhibits randomness. Tests using UDP show requests from three test machines being unpredictably routed to Fly.io apps in Miami (MIA), Narita (NRT), and Singapore (SIN) regardless of their actual locations.
Test setup:
- A Fly application is deployed with dedicated IP, listening on UDP port 53, in three locations: MIA, NRT, SIN.
- Test servers are located in the corresponding regions (MIA, NRT, SIN) from a different provider, used specifically for latency testing.
- The application is a DNS server, which returns the
FLY_REGIONenvironment variable in its TXT record. This is done through direct UDP queries, bypassing any DNS caching mechanisms.
Reference: This issue mirrors a problem discussed three years ago on the Fly community forum https://community.fly.io/t/udp-packet-routing-testing/495
Also tested:
- Port 53 Usage: The issue persisted even after switching to another port, indicating that the problem is not specific to port 53.
- ISP Factors: Tests conducted over a home internet connection yielded the same inconsistent routing results, suggesting that the problem isn’t related to ISP-specific routing quirks.
My Objective: Set up a custom DNS server on Fly.io’s anycast network. This server should consistently respond to queries from the geographically nearest location among the available regions (MIA, NRT, SIN).