Jeff Janes <jeff.janes@gmail.com> writes:
> On Thu, May 31, 2018 at 8:23 AM, C GG <cgg0007@gmail.com> 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
