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

From: Ed Davies <ls_at_edavies.nildram.co.uk>
Date: Mon, 28 Apr 2003 17:17:30 +0100

In response to my proposal of using the DNS to disseminate
leap second information, "Clive D.W. Feather" wrote:

> Brief comments:
>
> (1) Yes, it's an abuse of DNS. The fact that others do it doesn't justify
> it.

You're right, the fact that others do it doesn't justify it. What
their use does show is that there is not a fundamental flaw in the
idea.

What would justify the "abuse" would be if its utility outweighs
its cost. The fixed cost, whether or not it is used, is simply a
few entries in the main DNS servers for the host domain. If it
is used then there is the additional cost of storage in the caches
of other DNS servers causing other information to be discarded
when the cache is full. If the cache algorithms are even half decent
then this will mean less popular information is discarded. In
other words, the fact that the cost penalty is paid, almost by
definition, indicates it's worthwhile.

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

> (2) If you're going to use DNS, the information ought to be in a TXT record
> rather than playing games with A records. ...
>
> (3) It doesn't provide an easy way to find out when the last and next
> leap seconds are, requiring you to do binary search or linear search.
> ...

Interestingly, my original sketchy proposal both used TXT records and
also gave a list of leap second dates rather than UTC vs TAI offsets.
I changed from these ideas for specific reasons.

A records or TXT records are both easy to deal with for code which
is directly accessing the DNS server but A records are much easier
to get hold of for application programs. This could be important
until OS or standard libraries provide proper support for UTC and
TAI.

For example, in Java you can get the list of IPv 4 & 6 addresses for
a particular domain name with one line of portable code. I don't
know how you'd portably get TXT records unless you coded up the
whole process of communicating with the DNS server using UDP or
TCP which would be:

 1. An awful lot of work.

 2. Awkward to configure, unless there is a portable way of
    getting hold of the IP addresses of the local primary and
    secondary DNS servers.

 3. Would bypass any caching in the local resolver - so if two
    programs wanted the TAI-UTC offsets two sets of packets
    would go over the network at least as far as a local DNS
    server.

I'm not really sure about all this. It's a long time since I've
done DNS lookup code on Unix and I've only done a small amount on
Windows. My knowledge is mostly from reading books - which doesn't
always survive encounters with reality.

As to getting the dates of leap seconds: the question arises as
to why one would want these dates, as such.

One use would be running a system clock accurately over a leap
second (including an implementation of smoothed times like Markus
Kuhn's UTS). However, in those cases you'd only be interested
in whether the current month ends with a leap second so you could
just look at the TAI-UTC value for this month and next month.
You wouldn't need a search, binary or otherwise.

Presumably the ultimate use for historical information of leap
seconds is to find the number of SI seconds between two UTC
timestamped events. In this case, all that you are really
interested in is the net effect of all of the leap seconds between
the two events. The simplest way to get this is to use the offsets
at each event to convert them to TAI and then do the subtraction in
TAI.

Similar arguments apply if the aim is to convert a timestamp
between UTC and one of the more specialised timescales (in either
direction) going via TAI on the way..

> There's two obvious
> approaches to this:
> (A) Have a second sub-hierarchy that returns that information.
> (B) Return more than one A record for each month in your main hierarchy.
> For example, have 127.2.N.P mean "the previous leap second was at the
> end of the month P months ago, and the next one will be at the end of the
> month in N months time" (N >= 0, P > 0). Use P = 254 for "this is before
> the first leap second" and N = 254 for "no more scheduled so far". Use
> 255 for "this field is invalid".

Returning multiple addresses with different second bytes is a neat idea
I hadn't thought of. It could be very useful if and when the proposed
scheme breaks (offset overflows or leap seconds not at month end - I
can't be bothered to estimate which will happen first).

However, I don't much like the idea of putting in too much information
in one go. The idea is to make things as lightweight as possible so
proper TAI and UTC handling can be done by any internet connected
system.

It might be good practice, though, to write code which can accept
multiple addresses and select out the one(s) with understood second
bytes.

A small disadvantage of your suggestion is that the domains for all
months after the latest scheduled leap second (e.g., all months in
2003) would have to have a shorter TTL, because ultimately, they'll
be replaced with a link to the next leap second when it is scheduled.

If your scheme was adopted then maybe values of N in the range
[200..253] could be used to mean that the next leap second has not
been scheduled yet but it is at least N-200 months ahead. E.g.,
at the moment we don't know when the next leap second will happen
but we can surmise that it will not be before the end of 2003.

> ...
> (4) To be future-proof you need to deal with IPv6. IPv6 only has one
> loopback address. However, it also has two ways of embedding IPv4
> addresses into IPv6 addresses. I suggest that you use:
>
> ::FFFF:7Faa:bbcc aka ::FF:127.aaa.bbb.ccc
>
> (that is, the equivalent IPv4 address with 80 zeros and 16 ones prefixed).

Good point. I'm not confident enough of my knowledge of IPv6 to
have included this but you are right, it should go in a complete
version of this proposal. The only thing I have about IPv6 is
IPv6 The New Internet Protocol by Christian Huitema, 1996 (which
makes it pretty old for a "future" protocol :-) ). It says IPv4
addresses are embedded by prefixing them with 96 zeros.
Presumably that's the other way of embedding them which you don't
suggest?

Thanks for your comments,

Ed.
Received on Mon Apr 28 2003 - 09:26:49 PDT