A recursive resolver is doing two different jobs
To the application, the recursive resolver looks like a service that returns an answer or an error. Behind that interface it might behave as an iterative client, following referrals and querying multiple candidate nameservers. There may be more steps when DNSSEC validation, CNAME chains, address resolution for nameservers, or network retries are involved. The simplified root, TLD, authority path is the mental model, not a promise of exactly three packets.
The recursive resolver also caches record sets. Suppose the authoritative A record has a TTL of 300 seconds. A resolver that fetches it may reuse that result while its remaining TTL is positive. If another client asks 120 seconds later, the recursive resolver might return it with roughly 180 seconds remaining. The client is not guaranteed a fresh five-minute cache window starting from its own request. A second cache layer can make the observed timing more complicated.
This is why a packet capture from the mobile application often shows one question and one answer. It does not show the recursive resolver's earlier work. On the other hand, issuing dig directly against an authoritative server bypasses much of the path the actual application uses. Both measurements are valid, but they answer different questions.
The authoritative service is responsible for the records of the zone it serves. The recursive resolver is responsible for trying to obtain answers on behalf of clients. Confusing these roles leads to fixes in the wrong place. Adding API instances will not shorten a recursive lookup unless the change also affects the network path or endpoint selection in a relevant way.
An answer can be more than an address
An alias can appear in the chain. api.example.com might return a CNAME naming a provider-controlled hostname, and that target requires its own address lookup. The two record sets have their own TTLs and potentially different authorities. The resolver must follow the chain subject to normal DNS rules. An HTTPS resource record can additionally advertise connection hints for capable clients, including alternatives for HTTP protocols. None of this means DNS itself establishes the TLS connection or decides application authorization.
Negative answers can be cached too. If a deployment queries preview.api.example.com before the name exists and later creates it, some resolvers can continue returning the earlier authoritative negative response until its negative caching interval expires. A retry storm against the application's own DNS client does not manufacture the missing positive answer. The negative caching behavior is tied to information in the zone's SOA record, not simply the new A record's TTL.
Investigate the right stage
For the original 120-millisecond report I would split the timeline into DNS, connection establishment, TLS, and request processing. In the client I want cold and warm measurements, resolver identity when observable, address family, and whether the request reused an established connection. In controlled testing I would compare the configured recursive resolver with direct authoritative queries, but I would not call their timings interchangeable.
If only one recursive service is slow, examine its cache misses, upstream reachability and retry patterns. If the authoritative service responds slowly across independent resolvers, inspect authoritative latency and delegation health. If the client alternates between IPv4 and IPv6 results, examine address-family reachability as well as the DNS time. If DNS time is low but connection time is high, leave the DNS service alone and investigate the transport path.
A 300-second TTL is not a promise that the client asks every five minutes. Browsers, runtimes, operating systems and recursive resolvers have their own caching rules, prefetching and connection reuse. Some also provide controlled stale answers during an authority outage. Before treating a latency chart as one universal lookup path, determine which resolver and which cache produced the measurement.
The design decision is not whether to make DNS infinitely fast. It is where to keep authoritative records correct, how to make recursive lookups reliable, and how to observe the separate stages. The next incident follows naturally: the DNS answer changes during an IP migration, and not everybody hears about it at the same time.
