Summary

  • RFC 1794 described a 1995 attempt to make DNS address order respond to changing server loads without changing the DNS protocol.
  • An authoritative server could send a preferred order, but caching, secondary-zone refresh and client-side sorting meant that the order did not assign a request to a particular machine.

An ordered answer was not a dispatch

Imagine a name that resolves to three equivalent servers. An administrator might want the least busy one listed first. But DNS supplies records; it does not open the application connection itself. RFC 1794 put that distinction at the centre of its account. A response could carry an order that was useful and predictive, while the protocol did not guarantee that a client would preserve it.

The memo was published in April 1995 as Informational. It explicitly says that it does not specify an Internet standard. Its value as history is unusually direct: the author set out to record a DNS Working Group discussion and the approaches considered, while warning that parts of the history might be missing. The account is therefore evidence of a design debate, not a census of deployed load-balancing systems.

From rotation to load-aware sorting

RFC 1794 places the roots of the problem around 1986, when modifications to BIND began rotating the order of address records. It names Bryan Beecher’s “Shuffle Address” changes and Marshall Rose’s “Round Robin” code as likely widely distributed examples. The author’s wording is cautious, and the dates should be read as a retrospective estimate.

Rotation spread first position over time, but it did not measure a server’s actual workload. The memo contrasts it with changes attributed to Matt Madison at TGV, which used facilities specific to VMS to inspect system load and return addresses from least loaded to most loaded. That was more responsive to a host’s condition, but it depended on one operating system and required changes to DNS record handling. The two approaches exposed different limits: a portable order without live load information, or load-aware ordering tied to a particular platform.

Compatibility moved the moving part

The Working Group criteria recorded in RFC 1794 were demanding: preserve compatibility with existing DNS, permit frequent change, return multiple addresses, handle other record types predictably, represent different kinds of load and calculate quickly. Five minutes was described as a normal update interval; sixty seconds was imagined as a possible pace, not reported as a measured service level. Multiple addresses were meant to leave alternatives if the first-ranked host failed before its record’s time to live expired.

Changing the wire protocol or adding a new record type was unattractive because DNS was already widely installed. The memo recounts a different proposal from Rob Austein: make the zone-transfer program smarter. A program could obtain load information, reorder the zone data and present it to a name server without changing what DNS messages looked like. In this model, the live query path stayed familiar while the process preparing zone data became dynamic.

That moved complexity rather than removing it. Zone transfers update secondary name servers; the primary does not use a transfer from itself to answer queries. A rapidly changing subzone therefore depended on refresh settings, while records handed to resolvers needed short TTLs if changed rankings were to propagate quickly. The calculation also had to finish within the lifetime of the information it produced. A quick ranking at the source could still be old by the time a cached answer was used.

The last selection stayed local

RFC 1794 says DNS did not guarantee ordering. Its author describes order as predictive: a client might see the same order repeatedly, but it could also reorder addresses locally, including through a sort list. A zone-transfer agent could not anticipate those remote choices. Nor did returning several addresses prove that a client would try them all, that an alternative was healthy, or that an application request would succeed.

The episode is less a story of DNS becoming a load balancer than of a boundary being made explicit. The operator could choose how to calculate and publish a ranking. Secondary servers and caches governed how quickly it travelled. The client retained the final choice. RFC 1794 records one way to work inside those boundaries; it does not establish how widely that method was adopted or how well it performed.

Sources