[LEAPSECS] stale leap second information

[Poul-Henning Kamp]

--------
In message <20150116205656.in5Lwal6%sdaoden at yandex.com>, Steffen Nurpmeso write
s:

>The IETF should [...]

Don't even get me started on what the IETF should or should not do.

I tried to find out when the last time I thought "Good job IETF"
and I realized that was soooo many years ago that it hurts to think
about.

>I consider it bad style to (1) misuse publically available A/AAAA
>records with faked addresses and then in addition (2) use
>non-private address ranges that may possibly clash real server
>addresses.

I can enumerabte the number of f**ks I give about that kind of
high-horse moral grand-standing in a single bit.  (Hint: it
won't be a one).

It is *exactly* because of impotent political standardization we
are in the shitty situation with respect to leap seconds, and at
this point in time I'll support anything that works towards making
it more manageable in the short term.

>I think having a plain 16-bit signed integer for the offset in
>seconds and a 16-bit signed integer for the number of days since
>the laster leap second (negative, no new leapsecond envisaged),
>and to the next leap second (positive, new leapsecond announced),
>respectively.  16-bit should be plenty for either counts.

Amongst many other flaws, this require a DNS TTL significantly
less than one day in order to not give trouble near leap-seconds.

My proposal could run with 6 months TTL.

>I'm sure you have a nice weekend regarding the CRC checksum...

The CRC is there to detect when DNS replies are rewritten to
point everything at captive portals, as is the case on a lot
of "free WIFI" networks etc.

Your idea offers no way to detect that...

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.