[ntp:hackers] NTP cores in authistrustedip.

Magnus Danielson magnus at rubidium.dyndns.org
Mon Apr 25 13:35:17 UTC 2016


Martin,

On 04/25/2016 02:56 PM, Martin Burnicki wrote:
> Magnus Danielson wrote:
>> On 04/25/2016 09:31 AM, Martin Burnicki wrote:
>>> Also the way PHK has encoded this in his approach to provide leap second
>>> announcements and TAI ofsets via DNS is nice, IMO.
>>
>> Yes, a nice complementary service, but it does not always work for all
>> scenarios, as I consider machines isolated from the Internet and
>> possibly even from internal DNS. When you have DNS and also use DNSSEC,
>> this is a lovely way to get signed and redundant information so that
>> validation can be done. The redundancy can also be used to detect
>> outliers, which helps to identify problems in the setup before the
>> event, and I see the addition of the DNS for leap second event
>> dissemination a nice complementary tool.
>
> Yes. If the node has no internet connection so it can't use DNS then it
> can't update its leap second file from one of the official locations,
> either.

Indeed. Another aspect is that in such protected environments, the 
upgrade cycle can be fairly long.

>>> Using either the DNS approach or the leap second file for leap second
>>> warnings is very good for primary NTP servers, but IMO for clients it's
>>> less error prone to get all the information via the same (NTP) protocol,
>>> admins only have to take care that announcements are updated on the
>>> server(s), and all clients jus follow these server(s).
>>
>> Depends on where they sit. A primary server having a GPS recever, should
>> use the information from the GPS receiver to update its leap second.
>
> Yes, this can be done if the GPS receiver outputs a leap second warning
> at all, and early enough.
>
> On the other hand there are 3rd party GPS receivers out there which have
> generated wrong leap second warnings.

This is indeed a problem. There is certain requirements attached to it.

> A valid leap second file can prevent ntpd from inserting a wrong leap
> second, if a faulty GPS receiver outputs a wrong warning, but if the GPS
> receiver's time is also stepped by a wrong leap second handling in the
> receiver then ntpd would follow this step 15 minutes after the wrong
> leap second time due to the sudden time offset.
>
> So it would be good if ntpd could emit a warning if the leap second
> warning from a file and from a GPS receiver don't match. Don't know if
> ntpd actually does this.

Indeed. There is more aspects where we can improve how NTPD reports issues.

>> DNS
>> and other methods can be used to validate and provide redundancy for
>> this information. Similarly can clients use this.
>>
>> Which method is the right one depends on many parameters. IMHO operator
>> errors can be a real problem.
>
> Yes, but if each client needs an operator who has to care for the leap
> second file the chance of errors is even larger. ;-)

Actually, the chance that there will be a box in a network being wrong 
will be high.

>>> Otherwise, if on a client a cron job has died or unintentionally be
>>> removed, or the DNS server has been changed, or has become unreachable,
>>> but (only) UTC time is still updated by the basic NTP protocol then
>>> operators may not easily notice there's a problem with one specific
>>> client.
>>
>> Indeed. Having redundancy for this piece of information is good, but
>> building and engineering an separate infrastructure in parallel isn't
>> what everybody manages to do, so being able to have this included into
>> the core time distribution path is more robust for most uses.
>> The more advanced users can then add redundancy configuration matching
>> their needs.
>
> Yes. AFAIK ntpd doesn't support PHK's approach, yet, but this could be
> really helpful.

Indeed. For many clients this would be a good complementary source to 
create redundancy.

Cheers,
Magnus


More information about the hackers mailing list