--------
In message <[email protected]>, 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
[email protected] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
LEAPSECS mailing list
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
