[ntp:hackers] NTP cores in authistrustedip.
martin.burnicki at burnicki.net
Mon Apr 25 12:56:32 UTC 2016
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,
>> 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.
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.
> 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. ;-)
>> 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
> 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
More information about the hackers