[LEAPSECS] Bulletin C and all that

[Steffen Nurpmeso]

"Steve Allen" <sla at ucolick.org> wrote:
 |The IANA tzdata now gets the complete leap second history
 |information from the file leap-seconds.list that NIST
 |has been publishing for the sake of NTP.
 |
 |The NIST version of that file can be found at
 |ftp://time.nist.gov/pub/leap-seconds.list

 |The USNO has also been providing a version of leap-seconds.list at
 |ftp://tycho.usno.navy.mil/pub/ntp/leap-seconds.list
 |again with older versions named using a timestamp on the end.s
 |
 |The IERS Paris bureau is also providing such a file.  That makes at
 |least three separate sources for this information.  Each source has a
 |different timestamp, a different expiration date, and different
 |commentary text.
 |
 |All three versions include a SHA checksum that can be used to detect
 |unintentional corruption during data transfer, but that is not a
 |digital signature that can be used to detect intentional corruption.
 |
 |This particular format of file has been deemed acceptable as input to
 |NTP daemons, for IANA tzdata, and in the experimental servers of the
 |IETF tzdist protocol.  Comparing these with the DNS mechanisms being
 |developed on LEAPSECS leads me to wonder ...
 |
 |Are there other features which would be desirable as part of a file
 |intended to robustly communicate the full known history of leap
 |seconds?

My opinion is that the complete list of leap seconds shouldn't, at
least necessarily, come over DNS.  However, a new RR (DNS resource
record) that is created for that very purpose would be something
different, and could cover leap seconds for quite a while without
even the need for extending the very default 512 byte UDP limit
(and then there is EDNS0 before the need for TCP arises).

Surely a plain TXT record in the very same format (less comments)
that is used in the text file that IERS provides could also be
used for that, but of course that doesn't exactly describe the
obligate format of the contents...

With DNSSEC or possibly a new DNS mode that uses "normal"
transport layer security via TLS, why not via the new ALPN
extension that avoids additional roundtrips (the overhead of such
negotiations being the absolute only argument i can see why DNS
doesn't use it per se) and is a requirement for HTTP/2, there
would also be a guarantee that the data that reaches a host system
is the very same that was requested from the server.

Beside that the sole reason that such a service doesn't yet exist
is most likely that noone ever proposed that before Poul-Henning
Kamp did so a few weeks ago.  Thinking about this it is actually
surprising since the benefits of distributing the data via DNS are
quite obvious.
But this is especially true for Bulletin C.

"Clive D.W. Feather" <clive at davros.org> wrote:
 |Zefram said:
 |> My concern is more about the risk
 |> of colliding with some other protocol.
 |
 |The answer is to not pervert A (or AAA) records for a purpose they are not
 |designed for. Either use TXT records or, even better, make the data
 |available as an XML file over HTML.

The complete list of leap seconds only needs to be updated after
a leap second occurred.  If there would be an efficient way to
query the current status of leap seconds, as would be available
via PHK's A record, then a system can efficiently synchronize
itself with the most minimal effort: if the UTC offset has drifted
by only one second to what the system "knows" locally, then this
local knowledge can simply be "appended" by this adjustment and no
further action is needed.  Otherwise, maybe the system was down
for several years, the missing gap must be filled by downloading
the complete list of leap seconds again -- and as above.

And again, the benefits of distributing this Bulletin
C information via DNS are really huge, because of the very nature
of DNS itself.  The "security" of fetching PHK's bulletin-c is
already "better" than the FTP based links above, since those offer
no security at all, for more data.

Misusing DNS A records as a carrier for bulletin-c information is
surely a hack in that DNS A records are ment to resolve IPv4
internet addresses.  Yet, PHK's Python script (and the C program
i've posted which carries this to a standardized and portable
low-level) uses a private class E address range that is reserved.
Such an address will not clash any real machine by definition,
therefore avoiding possible accusations from the law(yers) side.
They cannot do no harm.
But on the other hand DNS A records, because of their very nature,
will be able to cross all possible borders, like Firewalls etc..
And they usually will also be cached along the way due to it.

Is it pervert.  I think it is a pragmatic approach to allow for an
immense enhancement that can be gained for free, and immediately.
And i would rate this more important.
Querying IANA for creation of a new DNS RR that is especially
designed for carrying Bulletin C (and another one that carries the
complete list) would "legalize" the application and could be used
in succession in the future.

--steffen