Assume your sources of traffic are uniformly distributed among 75000 resolvers
I think your argument is flawed because your users are not uniformly distributed among those 75000 resolvers.
In practice just ~1% of the resolvers (Comcast, NTT, Telekom, etc.) are handling >90% of your users. Consequently the benefits of caching kick in much earlier and stronger than you suggest.
Large ISPs and public DNS resolvers typically don't use a single server, but rather a fleet of DNS resolvers each with their own cache. Some providers like Google Public DNS use two-layered cache, but it's still fragmented per server location. A lot of people also have their own resolvers, think companies especially.
The 75000 was mostly a thought example, it's very hard to know what a good number is, although there is a Route 53-related reason for that number. In any case, the benefit of DNS caching is probably much less than you think due to short TTLs and the number of resolvers.
Large ISPs and public DNS resolvers typically don't use a single server, but rather a fleet [...]
I assume all major ISPs use 2 or 3 layers of cache, which makes the size of their perimeter fleet largely irrelevant.
it's very hard to know what a good number is
Could you perhaps ask your former Route53 colleagues for some log-file insight?
the benefit of DNS caching is probably much less than you think due to short TTLs and the number of resolvers.
I don't think so. The overwhelming majority of clients uses their ISPs resolver. So all it takes is one hit per major ISP per TTL to keep it zippy for almost everyone. That's why DNS works so well, after all?
I assume all major ISPs use 2 or 3 layers of cache, which makes the size of their perimeter fleet largely irrelevant.
Not really. The resolvers tend to be geographically dispersed and use anycast. Having a multi-layered cache would probably decrease performance, except within a specific location.
Could you perhaps ask your former Route53 colleagues for some log-file insight?
They see what's behind the cache, not how much traffic the resolvers are taking. Could be the same, could be 100x more, hard to tell.
So all it takes is one hit per major ISP per TTL to keep it zippy for almost everyone. That's why DNS works so well, after all?
Caching works great with long TTLs, e.g. as used for NS, MX, CNAME records. The problem is the 60 second TTLs that are commonly used for A records in cloud services. Except for reasonably high volume names, it's not highly probable that your A records will be in a given cache at a given time. Many applications also use many different domain names (e.g., one per user), which creates a long tail of low volume names.
Of course, traffic is not uniformly distributed in any way, so there might be parts of the day when your name will be constantly served from cache everywhere, or parts of the world where it is never served from cache.
I think your argument is flawed because your users are not uniformly distributed among those 75000 resolvers.
In practice just ~1% of the resolvers (Comcast, NTT, Telekom, etc.) are handling >90% of your users. Consequently the benefits of caching kick in much earlier and stronger than you suggest.