Summary

  • Postel’s 28 January 1998 email asked root-zone secondaries to pull a zone copy from IANA’s DNSROOT.IANA.ORG; it said the copy would match A-root and that root-zone policy and change procedures were not changing.
  • On 3 February he said the verification test was complete and asked operators to return to A-root. The messages document requests, not a configuration receipt from every operator.

One DNS service, two kinds of traffic

A resolver asking for a name and a secondary server refreshing its copy of a zone are doing different jobs. The resolver sends a DNS query to an authoritative server. A secondary obtains the records it will serve through a separate transfer relationship with a master. The two roles can sit inside one operating system, but they do not become the same network transaction.

That distinction was already part of DNS’s operating design. RFC 1034 describes a primary server that coordinates changes and secondary servers that check the zone’s SOA serial and obtain an updated copy when the serial advances. RFC 1035 defines AXFR as a request to transfer an entire zone. A resolver asking for a record is not requesting an AXFR of the root zone.

In January 1998, one machine could be both a root server that answered queries and the source from which other root servers obtained updated zone data. Postel’s request concerned the second role. It did not ask resolvers around the Internet to send their ordinary root queries to the IANA host.

The message specified a narrow transfer request

The archived email is dated 28 January 1998 and titled “root zone secondary service.” Postel asked root-domain secondaries to pull the zone “by zone transfer” directly from IANA’s DNSROOT.IANA.ORG, at 198.32.1.98. The message said the data there would be an exact copy of the root zone then available from A.ROOT-SERVERS.NET. It also said no policy or procedure for making root-zone changes was being altered.

Its scope sentence matters as much as its server name. The instruction applied to the root zone only. Operators providing secondary service for other zones, including top-level domains, were told to keep using their existing sources. The email therefore described a proposed change to one replication path, not an instruction to redirect all DNS service or to replace every upstream relationship.

The same archive preserves a press statement in which Postel described the work as a test of rearranging the flow of root-zone information. He said the zone’s contents would continue to be decided and prepared in the same way. These statements make two separate claims: the data should remain the same, and a different IANA server should be tested as a source for secondary copies. They do not provide a record of every secondary’s configuration or the result of each transfer.

The test also sat beside a separate administrative question: who could authorize changes to the records themselves. The January email explicitly left those procedures unchanged. A transfer source can supply a copy without becoming the author of every record in it. The available messages do not show that IANA began editing or publishing a new root-zone dataset during this test.

A source request is not a query-path change

It is easy to misread the episode because A-root occupied two positions in the story: it answered queries as one of the root servers, and it was described as the established source for the root-zone file. Those functions were associated with the same machine, but the transfer protocol let the distribution source be discussed separately from the servers that answered resolvers.

The distinction can be stated as a conditional inference. If a secondary retrieves an identical zone copy and loads it successfully, changing the server from which that copy came does not, by itself, change the records returned to a resolver. The archived email says the IANA copy was intended to be identical; it does not publish a per-server comparison or query measurements proving that condition held everywhere.

NSI’s later testimony to Congress supplies context, not an operator log. It said NSI acted as the “primary” root-zone server under its government agreement, while no contracts linked the thirteen operators to one another and other operators were not required to pull the file every day. That account helps explain why the word “primary” described an operating arrangement rather than a contractual command over every secondary. It does not establish who accepted Postel’s request in 1998.

The return request bounds the event

On 3 February, Postel’s “root zone transfer verification completed” message asked operators to return to obtaining the zone from A-root. It again applied only to the root zone. RSSAC-023v2, a later Root Server System history, says Postel had asked Jim Koda and Paul Vixie to create and operate an ISI primary server for the test, notified several root-server operators to pull from it, then asked all operators to switch back a few days later.

The later account corroborates the sequence and gives the number of participants only as “several.” Neither it nor the preserved emails provide a list of operators who changed configuration, a complete AXFR log, or receipts showing when each operator returned to A-root. A request is evidence of intent. It is not proof that every recipient executed it.

The record also does not support a measured conclusion about service impact. Postel’s press statement expressed high confidence that the transition could occur without interruption, but confidence is not telemetry. No query series, outage log, or independent comparison of all serving copies accompanies the messages cited here.

Sources

The event record is a preserved copy of Postel’s 28 January request and 3 February return message. The message archive includes a PGP signature block, which this article has not independently validated. The RSSAC retrospective supplies a later institutional account. RFC 1034 and RFC 1035 define the transfer mechanism, not the configuration of each operator in 1998. NSI’s account appears in a House Judiciary hearing transcript and is attributed to the company.