Re: [LEAPSECS] Proposed use of DNS to Disseminate Leap Second Information

From: Steve Allen <>
Date: Sun, 4 May 2003 16:34:10 -0700

On Mon 2003-04-28T17:17:30 +0100, Ed Davies hath writ:
> Remember, looking for the same information in another format will
> also use the DNS, this proposal trades a little more DNS traffic to
> avoid the second step (e.g., fetching an XML file or whatever).

Nevertheless, I prefer the notion of an XML file with data content
that is cryptographically signed by the IERS.

The proposed DNS scheme requires a separate query for each month
being investigated, and it presumes that DNS will be available
upon demand.

I find that DNS is often not available upon demand. The initial query
often times out. If I persist I can often get the desired data to
flow through the pipes with several more queries, or just more

I have seen the scheme being used by the ORDB fail to operate in a
timely manner, and in the case of our SMTP that meant notably delays
in determining whether a point of origin was a spammer. This meant
notable delays in delivering the mail, and notably larger memory load
on our mail server. In the case of extremely bad response by DNS it
meant that our mail server eventually gave up on determining whether
the source was a spammer and simply delivered the spam. In short, we
abandoned this as method of spam control, and I fear that we would
have to abandon it as a method of delivering leap second information.

A signed XML file could contain all of the leap second information up
until the time of its issue. The current rules for leap seconds call
for one to be announced 8 weeks in advance. If the date of issue is
included in each signed XML file then it should be adequate to obtain
that XML file only once every 4 weeks. Anyone holding a copy of a
recent leap second file would know just how soon it was necessary to
obtain a new one. And a signed XML file could be widely duplicated
and cached on many servers around the world without loss of

Even in the indefinite future where UTC would require a leap second
every month this would require obtaining the file no more often than
once every two weeks. By that time we would expect that such a scheme
and the software necessary to implement it correctly would be
completely and naturally embedded into every timekeeping device.

And, of course, XML is not necessary for this, it's just trendy and
more definitely parseable than the current products provided by the

Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064      Voice: +1 831 459 3046
PGP: 1024/E46978C5   F6 78 D1 10 62 94 8F 2E    49 89 0E FE 26 B4 14 93
Received on Sun May 04 2003 - 16:34:24 PDT

This archive was generated by hypermail 2.3.0 : Sat Sep 04 2010 - 09:44:54 PDT