[LEAPSECS] stale leap second information

[Steffen Nurpmeso]

"Poul-Henning Kamp" <phk at phk.freebsd.dk> wrote:
 |--------
 |In message <20150114115758.gvGCdclG%sdaoden at yandex.com>, Steffen \
 |Nurpmeso write
 |s:
 |>"Poul-Henning Kamp" <phk at phk.freebsd.dk> wrote:
 |>|--------
 |>|In message <54B621B5.1080909 at rubidium.dyndns.org>, Magnus \
 |>|Danielson writes:

 |>|What would be really useful would be if they provided the current
 |>|leapsecond count and the date of the next (if known) via DNS.
 |>|
 |>|DNS because it has built in caching and works almost everywhere.
 |>
 |>Or a new NTP protocol, that would only require a software update
 |>of NTP servers.
 |
 |NTP is a much more specialized protocol than DNS and it is blocked
 |a lot of places.

But you need to invent a new RR and update resolvers for that.  Or
do at least the latter if you use some existing type.
Hmm, or you get that terrible politics going and define a new
virtual A record that carries the necessary information, say 8-bit
per label, least significant last.
So i apologize, such a thing would indeed even be a great idea,
fetchable via a simple getaddrinfo(3) / dig(1) call and
automatically replicated from the DNS root servers down to the
last zone!

(Of course DNSSEC is horrible, in my humble opinion.  And your
scheme will have problems at and after the days which actually
introduce leap seconds.  But just as is today for those computers
which get their leap information only via the TZ database.)

 |>The current one is obsolete anyway in ~20 years,

Iirc NTP will get storage overflow problems in the mid (20)30s,
but that could be changed with a new protocol version, and if
there would be such a one then that could solve the problem with
TAI / UTC and their offset at the same time, even though that
would mean that some time providers would (possibly) be left
behind (though the German DCF77 radio transmitter, for example,
has seen some very strange retargeting in the last years, which
could be re-redefined and then possibly transport the necessary
changes).

For most normal -- whatever that is -- consumers NTP is more than
sufficient, and if it'd track all the necessary information with
each and every packet to get at TAI and UTC then what else is
needed for these clients?   And it's worth noting that passing the
leap offset as a regular part of a NTP packet can be compared with
a locally stored value, just like a regulary saved NTP drift can.
For example, to not reject a drift too large and possibly even
apply a Markus Kuhn smear locally, if so configured.  Anyway:
options you don't have right now.

Because you have none, and the ten thousand lobbyists that want to
introduce marsian time on earth won't change that, really.
Or scratch that last sentence if you want to.

--steffen