I've posted FB8270078 (Ability to disable and monitor Optimistic DNS in URLSession), along the lines of the above-mentioned Radar.

Hi Quinn, We've instrumented a build of our app with NSURLSessionTaskMetrics to analyse the connection timings to try to infer whether Optimistic DNS is being used. What's puzzling is that all the timings from the metrics (mostly from iOS 13.5.1 clients) indicate that the connectStartDate timestamp is the same as or just after the domainLookupEndDate timestamp, which would seem to indicate that Optimistic DNS isn't being used. Do you know if there are any scenarios where Optimistic DNS is disabled by default?

Hi Quinn, a couple more questions, if you have time: Does Optimistic DNS only cache one 'good' IP address for a given host, or is it possible that it might choose from amongst a pool of recently 'good' ones? Once Optimistic DNS has cached a 'good' IP address, does it remain cached permanently until a different 'good' IP address replaces it, or do cached IP addresses have a lifetime after which they're discarded? I'm asking these because we have seen at least one scenario where a client is happily making connections to one site, DNS hasn't changed on our end, and then the next connection from the same client two seconds later goes to the second site. My current mental model of Optimistic DNS doesn't explain this, but I'm sure there are nuances I don't know about - but if this sounds like bug-report material then I'll collate it. Regards, Rob

Thanks very much for the quick reply Quinn. We're still investigating whether our problem is due to Optimistic DNS, but it seems to have started (and be only occurring) with iOS 13 clients (Android and older iOS are fine). We're seeing unexpected traffic from these clients to non-active (but still on-line) sites that the load balancers/DNS supposedly are directing traffic away from, well after TTL expiry. When we've gathered more data I'll file a radar if we think it's most likely Optimistic DNS. Under Optimistic DNS, when iOS starts establishing the network connection (but before the DNS response arrives), how far along the connection establishment process will it proceed, especially if the connection route is faster than the DNS query response? eg. If iOS successfully establishes a connection to a last known 'good', but expired IP address will it allow the app to start using it, but then if DNS replies shortly afterwards indicating the address is expired: a) will iOS terminate and re-establish a new connection to the updated IP address (not sure how NSURLSession delegates would present this to the app)? b) just continue using the old IP address for the current connection? I'm guessing b), but in that case does the Optimistic DNS update its cached IP address to the new one? (It hasn't yet actually connected to this and might not flag it as 'good' though) or just keep the old one as the last known 'good' address. If the latter, then it potentially means the cached address will struggle to be updated if DNS is typically a bit slower than the connection time to the old IP address.

My other question is whether there's any way (for NSURLSession) to tell after the fact whether it ended up using an expired answer to establish the connection used to obtain the response?

Hi Quinn, I just wanted to confirm that it is still the case that we can't control the use of Optimistic DNS via NSURLSession level APIs?

Thanks very much Quinn. (Just for other readers, which is in line with Quinn's answer, we also see this when a Touch ID prompt is being displayed.)