[ntp:hackers] NTPv4 Brian Version

Brian Utterback brian.utterback at sun.com
Mon Aug 15 19:20:56 UTC 2005


Something is seriously wrong if killing nscd stops the resolver 
entirely. Let me know when the game is once more afoot, and I
will look more closely at it.

David L. Mills wrote:
> Brian,
> 
> As I said, when stopping nscd the ntpd resolver didn't work at all, much 
> less return duplicates.
> 
> As I was typing on whimsy the display faded to black and could not be 
> resurrected. I must put this quest off until the display can be replaced.
> 
> Meanwhile, I can in fact fiddle the controls on my own nest of 
> munchkins, but I cannot on the department and campus machines. In other 
> words, if ntpd resolver in whatever form doesn't perk, pool is not a 
> sustainable agenda here or in other like minded institutions.
> 
> Dave
> 
> Brian Utterback wrote:
> 
>> Yes, but did you deconfigure ypserv from doing the DNS lookup? Check 
>> the ypserv
>> process, if it has a "-d", then it will do the DNS lookup and provide 
>> a cache. Since the
>> entry will be found, it will not proceed to the DNS service. To avoid 
>> any caches in Solaris,
>> the "-d" must not be on ypserv.
>>
>> However, as I said, I think that the only long term general solution 
>> is to grab multiple addresses
>> from the same gethostbyname lookup. David L. Mills wrote:
>>
>>> Brian,
>>>
>>> I did try the hosts nis dns with the same result. The Solaris 9 had 
>>> the same configuration. The only thing I can find to explain why 
>>> dig/nslookup worked but ntp did not is that apparently those programs 
>>> go directly to the name server rather than indirectly via the system. 
>>> In any case and for whatever reason, pool is not an option and the 
>>> only way I can see is for the ntpd resolver to use some or all 
>>> addresses returned..
>>>
>>> Dave
>>>
>>> Brian Utterback wrote:
>>>
>>>> Findings:
>>>>
>>>> Pogo has nscd configured with a hosts cache time of 1 hour.
>>>> Any application using gethostby* will check this first, and
>>>> will get the same answer back for one hour. You could reduce
>>>> the cache time or turn off caching for the hosts map.
>>>>
>>>> BUT...
>>>>
>>>> Even if you turn off caching in nscd, the way pogo is set up,
>>>> it lets the ypserver do the DNS lookups. The ypserver process
>>>> keeps a child process around to do async lookups (sound familiar?)
>>>> and this child caches the answers returned from DNS. It is supposed
>>>> to cache for 30 minutes or the TTL of the answer, but there is a
>>>> bug so it always caches for 30 minutes. So, you will get the same
>>>> answer for 30 minutes unless we get this fixed.
>>>>
>>>> BUT...
>>>> Even if we get it fixed, the TTL for pool.ntp.org is 240 seconds,
>>>> so it will return the same answer for each 240 seconds.
>>>>
>>>> This is arguably the correct behavior, since that is the purpose of
>>>> the TTL, hence the need for the various sub-domains of pool.ntp.org.
>>>> However, some versions of gethostbyname and friends randomize the
>>>> order of the answers if there is more than one IP address. That is
>>>> probably something that the ntp resolver could do explicitly and
>>>> not have to rely on what the gethostby* routines do.
>>>>
>>>> What you probably had pre-upgrade is nscd was configured to not cache
>>>> hosts and ypserv was configured to not do the DNS forwarding, and
>>>> the nsswitch.conf files on the clients had a line like this:
>>>>
>>>> hosts: files nis dns
>>>>
>>>> Thus each naming service would search in turn without any caching.
>>>>
>>>> David L. Mills wrote:
>>>>
>>>>>
>>>>> Brian, help!
>>>>>
>>>>> I'm not interested in taking this discussion off list. I want this 
>>>>> discussion to be completely public on the hackers list.
>>>>>
>>>>> Dave
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> hackers mailing list
>>> hackers at support.ntp.org
>>> https://support.ntp.org/mailman/listinfo/hackers
>>
>>
>>
> 
> _______________________________________________
> hackers mailing list
> hackers at support.ntp.org
> https://support.ntp.org/mailman/listinfo/hackers


-- 
blu

Remember when SOX compliant meant they were both the same color?
----------------------------------------------------------------------
Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom


More information about the hackers mailing list