Summary

  • RFC 2606, published as a Best Current Practice in June 1999, set aside four top-level labels for tests, examples, visibly invalid names and local loopback use. It also documented IANA's reservation of example.com, example.net and example.org.
  • The RFC identified a particular hazard: a made-up name in a local test or a manual can later become a live global name, while test code and copied examples can leave their intended setting. Reservation gives those examples a durable address boundary.

The most dangerous sentence in a technical manual can be “for example.” It looks harmless on the page. A reader copies it into a configuration file, a tutorial becomes a deployment recipe, and yesterday's fictional destination starts receiving real software's attention. DNS adds another twist: a name invented for a private lab may be available in the global root today and delegated to somebody else tomorrow. The manual does not get to summon its readers back for a correction.

D. Eastlake and A. Panitz took that mundane problem seriously in RFC 2606, published in June 1999. The document was BCP 32, a Best Current Practice. Its goal was to reduce conflict and confusion around names used in testing and documentation. It described a laboratory that chooses an unused top-level domain for its own DNS tests. Later the same label might enter the global DNS. The local setup would then sit in front of the real zone for its users. Or a test program might travel beyond the test network and aim requests at a destination its author thought existed only on a whiteboard.

The answer was a small piece of reserved real estate. RFC 2606 listed four top-level labels: .test, .example, .invalid and .localhost. They had different jobs. .test was recommended for testing DNS-related code. .example was for documentation and examples. .invalid gave software and writers an obviously invalid name. .localhost preserved a familiar local convention associated in host implementations with the loopback address. One cabinet had four drawers; the labels on the drawers mattered.

Then came three second-level names with a different shape: example.com, example.net and example.org. RFC 2606 recorded that IANA had reserved them for examples. They let an author demonstrate a normal-looking name under familiar real TLDs without borrowing a stranger's actual address. That is a remarkably generous service for something imaginary. It asks the naming system to make room for a fictional website so an instruction sheet can safely look plausible.

The distinction between the four top-level labels and those three second-level domains is practical. store.example signals an example-only namespace from the top-level label onward. example.com looks like an ordinary address in .com, but the specific second-level name is reserved. A reader copying either string can still write bad code. At least the document has stopped aiming that code at an unwitting domain holder.

The RFC's security section sharpened the point. Experimental software can escape into the operational DNS. Examples marked as “only” documentation can be programmed and released. A casually invented example can also acquire a real-world owner and create disputes around that use. Those are the risks the 1999 authors designed for. Their remedy was delightfully unglamorous: choose a few names, record their purpose and keep them out of the ordinary allocation queue. The Internet needed a stage set, so somebody filed the deed.

IANA's current example-domain guidance shows the continued administrative shape of that decision. It maintains example domains for documentation, permits illustrative use without prior coordination and keeps them unavailable for registration or transfer. The page itself warns application builders against relying on an operating HTTP service there. The 1999 RFC supplied the boundary; the present administrator still tends the sign on the door.