> On 12/19/06, David Boyes <[EMAIL PROTECTED]> wrote: > > It's handy for test purposes because you could force the Linux guest to > > give any answer you wanted w/o having to convince your Windows admins to > > break the real DNS for your purpose. It's also useful in the case where > > you're hosting Linux guests that provide network services to not have a > > Yeah... depending on how fluent you are in DNS it will either bite you > very soon or only later...
Life is seldom risk free; your gun, your foot. If you don't know what you're doing, you shouldn't play with sharp objects. Cache poisoning tools are a lot more difficult to control than zone files are. It's also a lot simpler to always list a local DNS server first in the standard list in your configuration and just shut it down when it's not in use. For caching purposes it works fine, and in test or DR situations, you bring it up with a minimal set of zone files, and DNS Just Works, the way it's supposed to -- long before any of the Windows guys have gotten past reinstalling to get a fresh SID. The VM resolver code is fine with retrying the next one in the list if the first one isn't there. > The DNS protocol has been stretched and > the de-facto standard extended beyond the RFCs. And bind happens to *be* the de-facto standard implementation. Another reason to run it instead of the VM DNS server code. > For an occasional telnet or ping command, the impact of going out to > resolve the name is neglectable. True. > The best case imho for having a DNS cache local on VM is for reverse > lookup of client IP address when you run a web server on VM. The > typical visit may contain several hits and going out to the LAN for > each of them is a waste because probably the web server will wait for > the response before serving the client. Mail is another high volume one (also lots of reverse lookups, even if you just do outgoing from VM). Or LPR/LPD for heavily-used printers. Or any high-connection-volume service, really.
