Jeff Janes <jeff.janes@xxxxxxxxx> writes: > On Thu, May 31, 2018 at 8:23 AM, C GG <cgg0007@xxxxxxxxx> wrote: > > In the meantime, I did what I promised Adrian Klaver I would do and I added >> the AD servers to the /etc/hosts file. That had an immediate and dramatic >> effect on the performance. That confirms (at least to me) that DNS >> resolution was playing a large part in the slowdown. I'm going to >> experiment with running a local DNS caching server to see if that will give >> the same effect. >> > > I had this problem at one site, and with the same solution. As best as I > could tell, Windows was not using DNS as the main way of resolving > hostnames. (People assure me that NetBIOS and WINS are almost completely > dead, but WireShark tells a different tail--I don't recall the exact name, > but it was certainly something other than DNS). So the fact that AD's > built in DNS sucks was not a problem for Windows users, which means there > was no impetus on the Windows admin to fix it. And the delay on resolution > was always 5 seconds plus a very small handful of milliseconds. So it was > clearly some kind of designed throttling or timeout, there is no way random > congestion could get you so close to 5.00 every time. > We had particular problems with a specific client. In the end, it turned out that this client used a DNS resolve library which, unlike most other libraries, did not use local DNS cache. Every name lookup involved a full DNS resolution process. Temporary solution was to use IP addresses until admins/devs could work out how to fix the client or find a more robust solution where address isn't 'hard coded'. At the time, the admins responsible for managing the DNS were getting frustrated as their service was being blamed for a local client problem. Key take away, this stuff can be complex to diagnose and a systematic evidence based investigation is often required - problem is, that takes time and is seldom welcomed. -- Tim Cross
