I think a more typically structured recursive resolver is built around a read-through cache structure. Each step of the query asks the cache for more records, which you may or may not already have fetched; if you have, they're just served from the cache.

That's describing how a cache hit stops the cycle, not how a cache miss doesn't encounter one.

The standards tell you specifically to handle not going into infinite resolving loops and such.

So "Q: how do you handle resolver loops?" is "A: you handle them."?

I mean, probably true and accurate for many things. But if so that's not really a standard for how to handle it. It just means that, to be compliant, you need to figure it out and doing something about it.

It's why a cycle doesn't just DOS the server.

Er. Not with that explanation. The cache won't be hit until a result is found, instead each request produces another request back to through the cycle to try to get that request. Hence DoS.

In this implementation yes, in a full implementation the standards expect the client to handle multiple different scenarios that can result in loops as an error.

A query on a localhost name server is processed in a matter of milliseconds, so it's really not going to cause a DoS. When you put your name server on the public internet, it becomes a network address, which you can only get from an authoritative source. But even then, the response is going to be processed by a DNS query processor before it is handed over to your application layer, so you're going to see that it's processed before it is presented to the end user.