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

From: Clive D.W. Feather <clive_at_DEMON.NET>
Date: Tue, 6 May 2003 16:39:54 +0100

Ed Davies said:
> 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:

This ought to be a feature of standard libraries (though I'll admit I
haven't checked).

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

I don't know, but it seems an obvious thing to make available.

> Returning multiple addresses with different second bytes is a neat idea
> I hadn't thought of.

Thanks.

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

Adding a second address isn't going to make it much heavier. And it is
*far* better to have it clear *NOW* that there could be more than one
address, than try to retrofit the feature at a later date when people have
deployed broken code.

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

Exactly. But if you don't produce such data, experience tells me that code
won't get written.

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

Any TTL greater than a week is going to mean there's so much caching and so
little load on the base server that it won't be a problem.

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

Could do.

>> (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?

Yes. That's used for IPv4 addresses reachable through IPv6 tunnels. While
you could use either, the "unreachable" version looks better to me.

--
Clive D.W. Feather  | Work:  <clive_at_demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive_at_davros.org>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646
Received on Tue May 06 2003 - 08:40:09 PDT

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