Hacker News Reader

Comment by teddyh | Hacker News Reader

So where’s the stack?

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.

View on HN

The Linux box could have a caching forwarder, as could the router. There are many routers with a local cache that put their own IP in the DCHP nameserver spot.

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.

Everything is possible in theory, of course, but all of these theoretical possibilities are relatively uncommon, and, more importantly, made to not look like the aforementioned chain-of-resolvers. The normal DNS procedure is client→resolver→authoritative_server, and any deviation from this is deliberately hidden by the components which alter it.

They aren't uncommon though. The most typical home setup has a non recursive client ask their ISP to resolve a name. The ISP, if it hasn't cached the answer prior, queries someone else on the client's behalf.

Separately, Windows, Linux (most popular distros), and MacOS all have a caching/forwarding local resolver.

You’re still not describing a stack; you are describing the normal three-step client→resolver→auth_server procedure. Your “non recursive client” is the client, the ISP has the resolver, and that resolver performs many queries to many authoritative servers, which is the final step. There is still only one resolver, not a stack of them.

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.

Gross over simplification. You can have multiple authoritative resolvers, such as in the case of stub delegation.

Reply on news.ycombinator.com