I’m super excited about the UDP Anycast feature and tested it out with a DNS server (https://github.com/shawn1m/overture).
To see how it’s working, I injected a record into the hosts file, like this 127.0.0.10 ${FLY_REGION}
I deployed the app to 3 regions, e.g. sjc, iad, and hkg. However, according to the following testing results, the Anycast is more like random routing. Could you please take a look at my app (overture.fly.dev) settings to see if anything is not right? Thanks.
Huh that’s strange behavior. We’ll have a look (but it might be tomorrow).
Thank you for taking a look.
I did a bit more testing from 3 external VPS in CA, NY, and HK, corresponding to the 3 regions I deployed through fly.io. The DNS server I’m using supports both UDP(53) and DOH(80/443). The HTTP routing seems to be getting the closest region for those 3 locations. Only the UDP routing has that strange behavior.
Hey! Sorry for the delayed response here. Busy weekend.
I’m pretty sure I see the problem here, it’s on our end, I should it have it fixed shortly, and will relay back what was happening when I’ve got it worked out.
Thanks for spotting this!
The test results look a lot saner to me now. 
A combination of things happened here on our side. None of them involved anycast! The anycast routing — which gets ping.pe to our edge — looked basically sane. But our backhaul routing for UDP was jacked up a bit.
The two problems were that we were using a nearness metric that was, uh, deeply imperfect — I’m now using the same metrics we use for TCP — and also we had a broken deploy that left a bunch of our edge hosts back a revision on UDP routing.
Thanks again for spotting this. Let me know if it looks right to you now!
Yes. The ping.pe results all look right now. The DNS queries from my testing locations (CA, NY, and HK) all have <10ms latency now which is excellent! Thanks a lot for your prompt attention!