A tale of two nameservers - resolution problems

[Robert Moskowitz]

On 09/01/2015 10:38 AM, Reindl Harald wrote:
>
> Am 01.09.2015 um 16:28 schrieb John Miller:
>> On Tue, Sep 1, 2015 at 9:31 AM, Robert Moskowitz 
>> <rgm at htt-consult.com> wrote:
>>>
>>> On 09/01/2015 09:20 AM, John Miller wrote:
>>>>
>>>> If you check pcap, logs, etc., is the server's following delegation
>>>> for 0.centos.pool.ntp.org? Where do outbound packets stop?
>>>
>>>
>>> I don't believe this and I have some serious problems.
>>>
>>> Part of my challenge is I am running the new server on an armv7 
>>> board that
>>> does not have a rtc.  So when the system boots, the time is jan 1 
>>> 1970.  The
>>> first thing you want to run is ntp to set the time, but requires named
>>> running and resolving.
>>>
>>> For the 'fun' of it, I used 'date' to set the time to now, and then no
>>> problem resolving 0.centos.pool.ntp.org.  So there is something 
>>> about that
>>> resolution that does not like the early date.
>>>
>>> So I am caught in a time bind here!
>>>
>>> Is there anyway to get bind not to be particular about system time 
>>> at first?
>>
>>
>> Hopefully this isn't a production server... rtc's kind of important
>> ;-)  I'll ditto here and say: static /etc/hosts entries or static IPs
>> in ntp.conf
>
> additionally every network normally should have it's own ntpd using 
> the public pool and act as source for all other machines,

But this is the system that will be the internal ntp server  :)  At 
least at first.  One of the base boards I can add has the battery on 
it.  But I would only pay for that for this server.  This is one of the 
other obvious punts:  get a battery rtc.

> just because to be nice too the "pool.ntp.org" and hence any other box 
> needs just an IP address for doing "ntpdate xx.xx.xx.xx" *before* it's 
> own ntpd starts

There will be a lot of arm IoT boxes in the next few years needing their 
time on boot.  Of course booting will not be that frequent, but it will 
interesting to see how it plays out.   And check devices like the 
esp8266, as $6 IoT device.  It also gets its time once connected.

> so you just need to make sure the correct order
>
> * ntpdate xx.xx.xx.xx
> * start ntpd
> * start named

I will be looking more into this.  Obvious when you get ones nose 
dragged into time wrong on boot.  This is actually a broader problem on 
arm SoC booting.  Your logs all have the wrong time for the boot 
messages until there is a network to get time.  I have some ideas for a 
process that will set time a boot to the time of the last poweroff.  at 
least that is 'close enough' for starters.