Aside: You are using "resolver" to describe the wrong thing. RFC 1034 employs "resolver" to describe the entire subsystem that user programs use to access wha

Aside: You are using "resolver" to describe the wrong thing. RFC 1034 employs "resolver" to describe the entire subsystem that user programs use to access what it calls "name servers". It theoretically allows, because it isn't intended to be Unix-centric, systems where all of the query resolution mechanism is potentially in some form of shared subsystem that runs inside each applications program. Strictly speaking, what you are talking about here, in RFC 1034 terminology, is a "stub resolver", the Unix model where there's a fairly dumb DNS client library running in the applications, talking to an external program that actually does the grunt work of query resolution by making back-end transactions and building up the front-end response from them. A "resolver" actually very much does "shop around for answers", amongst content DNS servers. There's even a (slightly faulty) description of its shopping around algorithm, in RFC 1034 section 5.3.3. "resolver" is such a confusing term, and so often used contrary to the RFCs in the way that you have here, that years ago I took to explaining the DNS to people using terminology borrowed from HTTP: proxy servers, content servers, and client libraries linked into applications. * http://jdebp.eu./FGA/dns-server-roles.html http://jdebp.eu./FGA/dns-server-roles.html