> > > We used to say that it was a good idea to run the cache-only resolver > > > that comes with VM TCP/IP (i.e. NAMED) to avoid excessive DNS lookups > > > going outside VM. Some installations also used it to prime the cache > > > with a set of important host names (in case the outboard DNS was not > > > available). But the VM DNS implementation has become a bit dated, so > > > if you can you should probably avoid that route. > > Or replace it with a minimal Linux guest. > How will that help? > If the DNS didn't work using the servers in our LAN, > why would it work better talking to a linux guest?
In your case, it was actually a different problem (what interprets the NSINTERADDR lines is in the client VM, not the stack VM); I was commenting on Rob's comment about no longer running the caching server on VM. The reasons it helps with the issue of running the caching server on VM in that the Linux appliance allows you to cache efficiently (as the current code does), but also supply real usable DNS services that can supply answers different than the ones supplied by your external DNS for test or policy reasons, as well as support the latest security and authentication requirements. The biggest problems with the CMS DNS server are that it is based on really, really ancient interpretations of the DNS RFCs and that it requires DB/2 VM to provide anything more than caching services. Given the neglect of DB/2 VM over the past years and the cost, running DNS doesn't really work on CMS other than if it's absolutely required by some procurement wonk with a checklist. Can't do DNSSEC, can't do zone transfer restrictions, can't do DDNS, can't do a lot of things. All of which 'bind' on Linux does trivially at zero additional cost. 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 dozen different systems beating the tar out of your external DNS servers; get one internal one set up, cache results, and have all the extras consult the internal one. Significantly less network traffic for busy services that way.
