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

From: Ed Davies <ls_at_edavies.nildram.co.uk>
Date: Tue, 06 May 2003 15:43:30 +0100

Steve Allen wrote:
>
> 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 two are not exclusive. While the XML version could be the master
and contain more information I think the DNS version would be
useful to many applications. It would be a nice exercise in XSLT
programming to convert an XML file of leap second dates to a DNS
zone file containing UTC-TAI values for each month.

I think the DNS version would be best for "lightweight" applications
in, for example, network connected micro-controllers and so on which
need to interact with the outside world in UTC yet need to do
timeouts and other time measuring accurately in proper elapsed
seconds.

> The proposed DNS scheme requires a separate query for each month
> being investigated,

True, but most applications would only need the current month, next
month (to see if there is a leap second looming, e.g., to implement
UTS) and the last few months (to work out the differences between
recorded UTC information).

If a time library kept a complete set of offsets then it would
only need one lookup per month for the amount of look ahead
used.

> and it presumes that DNS will be available
> upon demand.

This is a problem for non-network connected devices, of course, but,
almost by definition, they tend not to have both the requirement
to use UTC and the requirement to count in "real" time.

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

There are a couple of differences here, the ORDB is a large database
which is used by a few machines whereas the leap second data would be
relatively small and used by lots of machines. These differences would
mean that the caching would work quite differently.

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

The problem with getting the file from one of many servers is that
everybody would have to decide for themselves which server to use.
It couldn't just be hardcoded in the operating system so people
wouldn't have to worry about it.

If a major operating system did hardcode a particular server then I
suspect that the load on that server might really cause problems.

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

Even when the length of a day gets towards 86 400.030 SI seconds
there is no reason to think it will be any more irregular than it is
today so it should be possible to continue the current practice of
announcing leap seconds 6 months in advance - it would just be that
more than one would be pending (announced but not yet happened) at
a time.

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

Yes, the most important thing is to have a well-defined format
rather than a mixture of text and numbers which might change at
somebody's whim. The main advantages of XML for an application
like this are that there are well defined and understood ways of
adding more data without breaking existing code (just add new
element and attribute types) and there are lots of tools available
to manipulate the data.

Ed.
Received on Tue May 06 2003 - 08:06:10 PDT