Summary

  • A 19 May 1997 notice moved one experimental root server from NSI to LINX in London and assigned K-root operations to RIPE NCC.
  • The notice changed K-root’s placement and address, not the public root’s contents or authority. Amsterdam standby followed soon after; anycast began in 2003.

The change notice was a small operational document

The announcement appeared in a root-server change message forwarded to the RIPE DNS working group. Its explanation was narrow: one of the experimental servers for the dot zone, then at Network Solutions (NSI), had moved to London and would be housed within LINX. RIPE NCC would manage K-root. The hostname k.root-servers.net received the address 193.0.14.129. The message says the change followed coordination between IANA and InterNIC, which were updating the information files used by DNS software.

That file matters because it shows what an operator or resolver could be told, not every packet that crossed a network. The message included the root-server list and said the related root-zone version was 1997051700. Its K-root entry named the server and address, with a comment that it was housed in LINX and operated by RIPE NCC. The record therefore places a change at the service and hint-file layer. It does not show a replacement root zone or a transfer of the global naming authority to London.

The distinction can seem overly fine until “the root server moved” becomes “the root moved.” DNS uses a hierarchy with a root at its top. Root name servers make root-zone data available; their names and locations identify the serving system. A change to one server’s location or address is not by itself a change to the zone data that servers provide. The contemporary file’s zone serial and server address are separate pieces of evidence, and the notice itself treats them separately.

A London site changed the service map

The location was operationally meaningful. LINX offered a point of interconnection in London, while the prior server was at NSI. The notice’s stated aim was to make service more geographically disparate. RSSAC’s later history dates K-root’s launch at LINX to 19 May and says a hot standby set was deployed at AMS-IX in Amsterdam shortly afterwards. The first step created a London operating site; the standby added another continuity option. The retrospective does not give a precise date for that second deployment.

This was not yet the anycast arrangement often associated with a distributed root service today. RIPE-268, published in February 2003, proposed serving K-root from multiple points in the Internet topology while using the same IP address. RSSAC dates K-root’s anycast deployment to 2003, based on the Amsterdam standby. The order matters: a London installation in 1997, a standby in Amsterdam, and an anycast service are related steps, but they are not one event.

Nor does a server’s geography settle the question of authority. RIPE NCC became the operator of K-root; LINX supplied a place in the network; IANA and InterNIC coordinated the announced change. Those roles describe service operation and the publication of technical records. They do not establish that RIPE NCC could alter the root zone, that the UK governed DNS names, or that a new public root existed. The later IAB statement in RFC 2826 explains the technical idea of a globally unique public namespace served by coordinated root servers. It can frame the distinction, but it is not evidence of the 1997 decision.

What the chronology can support

The primary notice documents an intended move, a named operator, a new address, and an updated root-server list. RSSAC’s retrospective supplies a dated launch and the later standby and anycast milestones. RIPE-268 explains the subsequent proposal and its operational logic. Together they show a sequence in which the public root service gained another location before the design began directing clients among multiple K-root instances through routing.

The sources do not measure how much latency changed for users, how many queries London served, or whether the move prevented a specific outage or attack. RIPE’s later design memo describes connectivity and redundancy as concerns, but that is not a 1997 before-and-after measurement. The most defensible claim is narrower: root service could be operated from a geographically different exchange while the shared naming system remained a single root. A server’s address was evidence of where its service could be reached, not a map of who possessed authority over the namespace.

Sources