There may be some semantics that aren't right, but say I have a Linux box, a home router, pointed at 8.8.8.8, and ask it for something not in anyone's cache. There is a "stack" of sorts when the answer isn't cached anywhere. Various caches in either resolver libraries and real DNS servers...forwarding ones, root ones, authoritative ones, etc.
And the depth of the stack is different depending on my setup.
The Linux box presumably uses the resolver as announced by the DHCP server on the router, which I would guess is 8.8.8.8. Therefore, the chain goes linux-box → 8.8.8.8 → auth servers, 8.8.8.8 being the resolver.
Or perhaps the router announces itself as the resolver, and proxies all requests to 8.8.8.8. This would not be necessary, but I guess it would be useful for the router to do proxying instead of NAT whenever the protocol (DNS in this case) makes it possible. There is still no reason to call the router a “resolver”, or even assume that the DNS proxy software on the router even has a cache.
Describing DNS as a stack of resolvers is like describing HTTP as always having a chain of caching proxies. It is not normally true, and even when it is close to true, it’s made to not look that way – i.e. it’s not useful to think of it that way, especially when explaining it to someone else.
And 8.8.8.8 may not know the answer, and may have to query for it, that's a very common "stack". A non recursive client letting a recursive server do the trawling is probably the most common home use case.
You could put a recursive resolver on your Linux desktop, and that would be different. Not common for a home PC though.
Separately, Windows, Linux (most popular distros), and MacOS all have a caching/forwarding local resolver.
A common variation, which might have been what you meant to describe, is that a home router is announcing itself as a resolver to the local network, but is, in reality, merely acting as a proxy to the actual resolver, either at the ISP or some other resolver provider. But a DNS proxy is not a resolver, and might not even have a cache. A DNS proxy is made to be transparent, i.e. invisible to both sides; the local network sees the proxy as the resolver, and the real resolver sees the proxy as the client. There are even more complex setups possible on the authoritative server side, but none of these proxy possibilities alter the fundamental DNS model of client→resolver→auth_servers.
The possibility of transparent proxies in any client-server protocol should not alter the description of that protocol from “client-server” to “client-proxy-proxy-proxy-…-server”, especially not when the protocol does not itself account for proxies. The DNS protocol has, inherently, one component between client and server: the resolver. There is no chain-of-resolvers model in the DNS protocol. The possibility of any number of transparent proxies at any point in the chain should not alter the description or explanation of any protocol.
Top comment is someone else ripping it apart. Yep. Welcome to Hacker News.
Can we please try to spend a week not using the following terms:
A few things, a few issues, actually..., I agree but, or anything else that makes you feel superior by shitting on someone else
The author is then also invited to revise their article if they agree with the feedback.
Perhaps the grandparent could have thanked the author or opened with some positive feedback first, but given the grandparent took the effort to write detailed answers in a noncondescending tone, I see it as a quality informational post. I hope others do too.
• The description is a bit vague, but the article seems to describe a model of a stack of resolvers, each resolver asking the next one in turn, the last resolver getting an answer, and the answer being then passed down the chain again. But this is not how it works. For a normal DNS query, there is ever only one resolver involved. This one resolver is the single thing asking many authoritative servers the same question, each time getting names of servers who might know the answer, and ultimately getting an actual answer. There is no stack of resolvers.
• The article completely conflates the process of a cached record expiring due to TTL expiration, with the process of an updated zone with a new serial number being transferred to slave servers. These two things have virtually nothing in common.
I also found the illustrations too detailed (i.e. confusing for non-experts). There are a lot of options to "dig" which could have been used to cut down on the extraneous output when illustrating a particular point.
The zone file was especially confusing, in that none of it was explained, and the nature of the DNS data model would have been much better illustrated with an object diagram of some kind.