We may have a dedicated server to calibrate the ratio of the geoDNS query rate to actual average NTP query rate. This value is function of the zone, and probably the actual speed setting as well. So the calibrating server configuration should loop through all country zones and multiple reference speed settings as well. The IP address of this calibrating NTP server might regularly change, to remove the clients that stick to the server permanently, in order to reduce the data collection noise.
I think the appropriate way is not to give or give empty geoDNS reply in that case. Servers should not see more traffic that the server operator assigned. We must admit that the overall NTP server capacity is not infinite. Theoretically, there could be more NTP service demand, that the capacity of the whole pool is having. Mind exercise, just scale down the pool to minimal server number, even to zero. What supposed to be the asymptotic behavior of the geoDNS server software?
I think there needs to be some study done if DNS request rates correlate with load on a server. The numbers could be skewed by a number of factors like old ntpd implementations which resolve the configured servers once at startup and then keep the IP adresses indefinitely in memory or caching resolvers at major ISPs.
Both scenarios couldn’t accurately count the number of requests to one individual server from the outside. Maybe we need a way of feeding back the current number of requests of a server back to the pool to distribute the load more evenly.
I’m collecting the metrics for my servers. There are clear correlations between the amount of DNS requests containing a server IP and the amount of NTP traffic coming in. The ratio varies - periodically with the time of day, sometimes the entire curve shifts a bit up or down (presumably when servers are added or removed from zones the server is in). But the numbers tend to stay in the same ballpark of 10-20 NTP requests per DNS announcement, with smaller variation ranges for the different zones (i.e. my German server recently shifted from ratios between 11 and 13 to ratios between 12 and 15).
Having more insights into this, maybe with the suggestion @NTPman provided, could lead to the ratios being used for Pool load distribution in near real time at the cost of higher complexity and the need for the data collection infrastructure. Collecting more data on this, then making a qualified estimation as base for a zone distribution system would be more static but certainly less complex since it does not need dynamic components, only regular reevaluation.