How are intermediate stages of an iterative DNS query cached?

Get the IP address of the .org TLD nameserver, with a TTL of 48 hours

This is slightly oversimplified. There is one level of indirection to every delegation – first you have the NS records (with their own TTL) which point to some nameserver names, and then you have the A+AAAA records (with their own TTLs) separately for each of the nameservers.

If the nameservers have "glue" records (i.e. under the name they're supposed to be serving, so the A/AAAA records are bundled), they will generally have the same TTL, but that is not guaranteed; often the nameservers are under a different branch and obtaining their IP addresses requires yet another sub-query.

For your specific example, org/NS has six nameserver names, three of which are under the same *.org and therefore the root nameservers will include their A/AAAA "glue" records as part of the answer, while the other three are under a different TLD (.info) and a resolver has to queue a whole new query to determine their A/AAAA records.

So with 6 nameservers there are at least 7 TTLs involved (the NS TTL and the individual servers' A/AAAA TTLs – and technically those too are separate per type).

(Yes, sometimes that turns into a sprawling mess of delegation after delegation after delegation. BIND as a resolver has a limit of 50 sub-queries when chasing a delegation, and even that sometimes isn't quite enough when running with cold cache.)

which parts of our query do we reuse?

This, on the other hand, is overcomplicated. The DNS server's cache is simply keyed by name+rrtype. All those intermediate steps are not "part of the query" as such. (That is to say, the results of those sub-queries are still cached as themselves, but they're not really considered as "parts" of any specific parent query.)

So if the user issued a query for www.example.com/CNAME, and there is a valid cache entry for www.example.com/CNAME with non-expired TTL, then that result will be immediately returned. But how that result was originally obtained and cached – i.e. the whole NS delegation hierarchy – is not considered when responding from cache, so even if the cache entries for individual NS delegation steps have already expired, this doesn't affect the cache entry for the name being queried.

(This is therefore the same for <3 minutes, for >3 minutes <1 hour, and for >1 hour <24 hours.)

After the TTL (24 hours in your example) of the final result expires, the nameserver will (if my understanding is correct) check its cache for the best-matching delegation results (NS and A/AAAA records), and again, if those are still valid, then all of the "higher up in the hierarchy" steps are skipped outright – there is no reason to re-query root servers about the whole of .org, if the delegated nameservers for example.org are still known.

There are some caveats, I think the results of sub-queries for delegation records are cached slightly differently – e.g. when you query the root servers, you don't explicitly query them for 'org' NS nor do you query them for 'a2.org.afilias-nst.info' A/AAAA; rather, you query them for the full domain and the server replies with a delegation with NS in the "authority" section rather than the "answer" section – and I believe that is cached differently than if it were an explicit NS query. (Something to do with cache poisoning prevention, if I understand it correctly.)

Are there any cases during DNS resolution that I would want to discard a resource record even if its TTL has not yet expired?

Some things that come to mind:

• The aforementioned isolation of delegation records in the cache separately from regular NS records. Not discarded necessarily, but considered as two separate kinds of entries. (I am not very familiar with the internals of this part.)

• Maximum TTL. Often resolvers have an option to cap the TTL to a certain maximum like 1 week, e.g. if the result claims that its TTL should be six months, it will be discarded before expiry as soon as the admin-enforced maximum has been reached.

Other than that, no, I don't think there are any special conditions where a resolver would deliberately re-query for records it still has cached.