[LEAPSECS] stale leap second information

[Steffen Nurpmeso]

"Poul-Henning Kamp" <phk at phk.freebsd.dk> wrote:
 |--------
 |In message <alpine.LSU.2.00.1501161037010.23307 at hermes-1.csi.cam.ac.uk>, \
 |Tony F
 |inch writes:
 |>$ dig +short leapsecond.dotat.at aaaa | sed 's/:6:/:06:/' | sort
 |>1972:06:30::23:59:60
 |>1972:12:31::23:59:60
 |>1973:12:31::23:59:60
 |>1974:12:31::23:59:60
 |[...]
 |
 |Neat :-)
 |
 |However, I think it is a loosing strategy to send an ever longer
 |list of addresses, it's only a matter of time before some random
 |piece of DNS software does something stupid (again).
 |
 |My plan was to avoid all the redundant information:
 |
 | Year
 | Month
 | Count of leapseconds until end of that month
 | Count of leapseconds after end of that month
 |
 |Bulletin C #48 becomes:
 |
 | Date         Count before    Count after
 | 2014-12      35              35
 |
 |Bulletin C #49 becomes:
 |
 | Date         Count before    Count after
 | 2015-06              35              36
 |
 |This way we can do both postive and negative leapseconds.
 |
 |This fits neatly into a IPv4 address in even the most crude
 |format:
 |
 | 14.12.35.35
 | 15.6.35.36
 |
 |But my idea was to encode it more tight and add a CRC to detect
 |DNS-spoofing (hotels free wifi etc.):
 |
 | 8 bit unsigned year (2015...2270)
 | 4 bit unsigned month (1...12)
 | 8 bit signed int before count
 | 2 bit signed int (after - before) count
 |       10 bit CRC-10
 |
 |Obviously the IPv6 mapping can be even more robust.

The IETF should move and support TCP/TLS secured DNS manageable
via normal ca-certificates updates that distributions do rather
automatically these days.  DNSSEC however also exists.
E.g., the IPv6 listing above required TCP already.
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 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.

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

--steffen