Unix machines set up by anyone with half a brain run a local caching
server, and use forwarders. IE, the nameserver process can establish a
persistent TCP connection to its trusted forwarders, if we just let it.
Organizations often choose not to do this because doing so involves more
risk and more things to update when the next vulnerability appears. In
many cases, you are suggesting additional complexity and management
requirements. A hosting company, for example, might have 20 racks of
machines with 40 machines each, which is 800 servers. If half of those
are UNIX, then you're talking about 402 nameservers instead of just 2.
Since local bandwidth is "free", this could be seen as a poor engineering
choice, and you still had to maintain those two servers for the other
(Windows or whatever) boxes anyways. On the upside, you don't need to
use a forwarders arrangement unless you really want to... but the
benefit of those 400 extra nameserver instances is a bit sketchy.
Unix machines set up by anyone with half a brain run a local caching
server, and use forwarders. IE, the nameserver process can establish a
persistent TCP connection to its trusted forwarders, if we just let it.
Organizations often choose not to do this because doing so involves more
risk and more things to update when the next vulnerability appears. In
many cases, you are suggesting additional complexity and management requirements. A hosting company, for example, might have 20 racks of
machines with 40 machines each, which is 800 servers. If half of those
are UNIX, then you're talking about 402 nameservers instead of just 2.
Of course, one shouldn't let the rest of the internet touch your DNS Cache query interface... but that's just obvious.
I mentioned this a while ago though, so I demand credit Also, I think there is probably an IETF DNS WG list where this fits on topic (I have no idea what it may be though).
Joe makes some good points here. I'd have to add one caveat though:
it depends.
It depends on the server. Busy email servers definitely depend on
having fast DNS, and benefit *greatly* from a caching DNS server using
local sockets instead. Web servers generally don't. Centralized
logging servers benefit greatly.
Usually, for a pocket of servers like Joe describes, you want
some local dedicated DNS servers (e.g. ~800 servers, add 2 more
just for local DNS) plus you would want caching DNS servers
running directly on your email, logging, etc. servers.
Yeah, 400-800 extra caching DNS servers would probably be
overkill though!
I am intrigued by the idea of persistent connections for those
2 dedicated DNS servers--only for upstream though. You wouldn't
need so much security locally (for your 800 clients), I expect.
You could use UDP for speed, and not worry too much about
poisoning. Expecially if you were using some kind of dedicated
professional DNS service that required IPSEC pipes, and had
engineers only doing DNS: security, updates, patching, uptime,
etc. etc.
It would be interesting if such professional services came about
Companies that do DNS and that is all they do. Dedicated to the
reliability and security of one of the cornerstones of the net.
We already went through that with Usenet, email, web hosting,
and other of the main services.
Also, I think there is probably an IETF DNS WG list where this fits on topic (I have no idea what it may be though).