[LEAPSECS] stale leap second information
sdaoden at yandex.com
Mon Jan 19 08:17:26 EST 2015
I think that Poul-Henning Kamp has had a fantastic idea and
invented a robust protocol that improves the current situation:
. Using DNS gets you caching and time-to-live for any stored
data; this is not only true on the server side, but the
necessary information is transported through to clients.
. Using DNS also means de-centralisation without reducing the
validity of the original data, because the DNS system as such
is designed to honour the validity of data in time, causing
automatic cache refreshes as necessary.
. Using DNS the data would distribute to a practically infinite
number of places, heavily reducing overall network trafic and
"reducing traceroute hops" to the next available storage
(caching DNS instance) -- without losing the property given in
the last item.
The next caching DNS instance may even be a local DNS server or
some system-wide caching facility, like mDNSResponder on OS X,
but i think Microsoft also has one, and of course Dnsmasq on
*BSD and Linux systems. This means that in order to get
a guaranteed up-to-date version of the data no network traffic
at all is necessary.
. Accessing DNS is available on low programming levels via
standardized interfaces. Practically all Unix systems ship
with command line tools that can be used to access the
necessary information from within scripting languages or shell
scripts. (In i think that the output of the tools i think of
is even portable when i recall a tool switch thread from some
FreeBSD list correctly.)
"Clive D.W. Feather" <clive at davros.org> wrote:
|Steffen Nurpmeso said:
|>|1. No IP addresses are misused, in the sense that should anybody
|>| have a valid claim to use these addresess, nothing I do will
|>| impact their ability to do so. I'm merely transmitting numbers,
|>| there will never on my behalf be an IP packet using these
|>| numbers as source or destination addresses.
|> Class E should be out-of-bounds, and if that isn't a valid "future
|> use" then maybe IANA has too many lawyers, too.
|Addresses, even class E ones, are meant to be addresses, not random bits of
|data. This is the sort of perversion that was never meant to be done. It's
|not a clever hack, it's just dumb. If you have to use DNS, use TXT records.
Yeeeaaaah, but i do think that "dumb"ness is a pretty
double-edged, culture- and zeitgeist-dependent term.
The problem with TXT records is that they cannot always be used.
I.e., the gethostbyname(3) function cannot retrieve any such
information, and the widely used Dnsmasq "network infrastructure"
for example doesn't support it either, as far as i know. Here
"doesn't support" should mean that no local caching is performed
on this very unusual DNS RR (resource record), which would cut
down the benefits of Poul-Henning Kamp's idea for no real reason.
(However, having to reach out for the next real DNS server will
still be better than downloading a complete text file from a IERS
A lot of perversion has happened on the DNS system. Just
think of that terrible IDNA, a *really* intelligent way of
encoding hostnames in fewer bytes than UTF-8. It would have
been better to extend the DNS limits for plain UTF-8 string
usage. And when i say that i really mean _already back then_.
It would be good and well today in that most likely not
a single old-style DNS server would remain, «dans le monde
entier». So to say.
I'm guilty of perverting Poul-Henning's idea by proposing misuse
of DNS "A" records for that. Doing so would introduce the
possibility of transporting this information to practically all
devices, how old the local DNS infrastructure may be, at once and
today. "A" records are also very space efficient. Nothing would
prevent noone to go IANA, write a new RFC draft (now in XML,
please) and request a new RR, say "UTCDRIFT". Let it use the same
format that Poul-Henning Kamp worked out for "A" then
administrators can provide both and as even more time goes by the
"A" version can eventually be dropped entirely. The
implementations that have choosen to go that route could almost
stay the same. (The data computation, anyway.)
The problem is again that you have no option. Maybe there are
DNS RRs that drive your coffee machine or that program your
carrier pigeon. Now there is a draft on a time zone data
distribution service, and i mean -- why not? But it requires
HTTP and iCalendar (in JSON [/ XML]). JSON parsers can be
done very efficiently. (Btw., how about a binary distribution
in CBOR format, as in iCalendar/CBOR? That collaborates nice
with JSON and is *very* easy to parse.)
But of course: that is much more bloated and requires way more
logic than a simple current UTC-time gettimeofday(2)
/ clock_gettime(2) and some gethostbyname(3) to gain the
current leap offset.
Maybe it does no longer matter now that there are mobile
phones with more resources than my laptop has, but i'd prefer
to have the _possibility_ to get necessary at a level as low
More information about the LEAPSECS