[ntp:hackers] NTPv4 Brian Version

David L. Mills mills at udel.edu
Tue Aug 16 01:40:26 UTC 2005


Brian,

I am using that version, slightly modified but not in the resolver area, 
and it works fine to resolve NIST servers. There is something wrong with 
DNS on at least the backroom net, as all my PCs but one work okay and a 
new one I lit up with identical configuation could not resolve anything 
outside the same wire. I pointer it at our deparment name server and it 
lit up just fine.

Dave

Brian Utterback wrote:

> I pulled down the 0815v snapshot and built it, and it does not resolve 
> hostnames at all. IP are a go, hostnames are nogo. With or without nscd.
>
> 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
>



More information about the hackers mailing list