[LEAPSECS] stale leap second information

[Poul-Henning Kamp]

--------
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.

-- 
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.