International Organization of Internet Clock Watchers

So, what is this domain for anyway?

Let me tell you a story...

Network Time Protocol

The Network Time Protocol (NTP), which is documented in RFC 1305, is for synchronizing computer system clocks across IP networks like the Internet, to standard time sources like the Global Positioning System (GPS) with high accuracy. Imagine being able to set your watch by your computer, instead of the other way around. It's also extremely useful for any application where multiple computers are involved - with NTP installed and configured properly on each system, they will all agree on the time of day, and that time will be correct.

When NTP was new, there weren't very many "stratum one" NTP servers. A "stratum one" NTP server is a computer system that has a reference clock attached to it (usually on a serial port); most often a "reference clock" is radio clock that is receiving a time signal from one of the official standard time transmitters (e.g. in the United States, WWV, WWVB, and WWVH, which are operated by the National Institute for Standards and Technology (NIST), formerly known as the National Bureau of Standards (NBS)). The stratum one NTP servers then provide NTP service to other NTP servers that become "stratum two" (the "stratum" number is a measure of distance from the primary time reference).

The NTP software polls the reference clock to get the correct time of day, which it uses to correct for drift in the computer system's time-of-day clock (most computers have terribly inaccurate time-of-day clocks that often gain or lose several seconds per day - this is called "drift"; it's usually caused by a combination of cheap clock chips or crystal oscillators, and operating system software which does not service the clock interrupt at a high enough priority, i.e. high interrupt latency). The NTP software also communicates with other computers running NTP on the Internet, to continuously coordinate and compare their clock accuracy & synchronization.

In fact, the majority of the stratum one NTP servers in the late 80's were small DEC PDP-11 computers, running a custom-built operating system written by Dr. David Mills (a very intelligent and engaging fellow) of the University of Delaware. The system as a whole was called a "Fuzzball" and it was his favored platform for network experimentation of various sorts. Among other things in their illustrious history, the Fuzzballs were the routers of the first NSFNET backbone.

An "Event"

On July 11, 1989, Dave made a small mistake - he released via automatic software distribution a new version of the Fuzzball OS which could only speak NTP to itself. The result was that all other non-Fuzzball, NTP-speaking systems that were peering with just the Fuzzball NTP servers stopped getting time service, and had to "run free" (i.e. try to keep good time without an external reference).

Ooops.

There were just two stratum one NTP servers at that time which were not Fuzzballs: bitsy.mit.edu, and apple.com. Those two UNIX NTP servers were providing good time to small parts of the NTP world, but by no means all of it, because most of the NTP systems were just configured to get time from one or two of the Fuzzballs. Dave fixed the bug the next day, and that was the end of that.

An Idea

Well, almost.

I spent part of that night poking around the Internet, looking at the state of the various NTP daemons out there at the time, and after doing that for a while, I had an idea: clearly, what the Internet needs is a time distribution network, configured so that the failure of any stratum one NTP server (or indeed, all but one), would not leave the remaining NTP world without a good time synchronization service.

The UNIX NTP implementation uses peering relationships configured from a static configuration file on each system which has an NTP daemon running on it. Alas, this is not a very flexible mechanism for configuring a time distribution network. After all, spreading static configuration files throughout the Internet makes it notoriously hard to get them changed in a consistent or controlled manner. However, if we want NTP to be a robust and reliable system for providing correct, synchronized time on the Internet, we need to be able to easily change the peering relationships between the NTP servers at the various strata.

So, I thought, since these configuration files have the names of various other NTP servers in them, why not play a game with the Domain Name System (DNS)? Each of those host names have to be looked up through the DNS to get an IP address at some point. We can put new, "generic" names (e.g. ntp0.barrnet.clock.org) for all the NTP servers on the Internet into a single DNS zone, and then write new static configuration files with the new names. Once those configuration files are distributed out to the NTP servers on the Internet, we can then manipulate the NTP matrix centrally (by changing the actual data in the clock.org zone file), and make sure it has enough connectivity so that nothing short of a catastrophic Internet failure will leave people without correct time for their computers.

There is a small issue in how the NTP daemon would get its peer addresses updated when the DNS zone changed; I think that changing the UNIX NTP daemon software so that it would take note of the DNS TTL of the Address record, and requery the DNS when the TTL expired would do the trick.

Copious Free Time...

Unfortunately, while I did manage to find the time to register a domain name for this purpose ("clock.org"), I haven't had the time to collect all the information I need to fill out the zone file, and make "stock" configuration files for NTP. A small matter of my free time being consumed by my employer got in the way of this noble endeavor.

So, when it came time to put my house network on the Internet, I needed a domain to use, and "clock.org" was just lying around...

The grandiose name at the top of this page was my best idea for what to call the organization that will be coordinating the information in the clock.org DNS zone file. If you want to help and you are well versed in the ways & means of the DNS (and at least a little familiar with NTP), please drop me a piece of E-mail.


Erik E. Fair <fair@clock.org>
Feburary 16, 2004