Summary

  • El RFC 2606, Best Current Practice de junio de 1999, asignó funciones distintas a .test, .example, .invalid y .localhost. También dejó constancia de que IANA reservaba example.com, example.net y example.org.
  • Un nombre elegido dentro de un laboratorio puede convertirse más tarde en un dominio global. El código de prueba y los ejemplos copiados de la documentación también pueden salir a producción. La reserva evitaba que la ficción invadiera una dirección ajena.

Hay frases que nunca se quedan en el manual. «Por ejemplo» es una de ellas. El lector copia la URL que sigue, la pega en una aplicación y se marcha. La explicación que decía que el sitio era imaginario se queda en la página; la cadena de caracteres viaja con el programa. En el DNS, un nombre inventado no obtiene inmunidad por haber nacido en una nota didáctica. Si alguien acaba teniendo ese nombre, la broma le puede llegar en forma de solicitudes.

El RFC 2606 de D. Eastlake y A. Panitz, fechado en junio de 1999 y publicado como BCP 32, trató el asunto como un problema de coordinación. Imaginó una red de pruebas que crea un dominio de nivel superior aparentemente libre para ensayar su configuración. Más adelante ese mismo nombre podría entrar en el DNS global. Los equipos del laboratorio seguirían viendo su versión local y podrían perder de vista los datos del dominio real. Otra posibilidad era que el software experimental saliera de la red cerrada y siguiera usando el supuesto nombre de juguete en Internet.

La respuesta tenía cuatro rótulos. .test se recomendaba para probar código relacionado con el DNS. .example servía para documentación y ejemplos. .invalid permitía construir nombres claramente inválidos. .localhost preservaba un uso local tradicional, ligado en las implementaciones de hosts a la dirección de bucle. El reparto importaba: un ejemplo de manual, una prueba de código y una dirección deliberadamente imposible planteaban preguntas diferentes. Meterlo todo en un cajón llamado «temporal» habría perdido precisamente esa distinción.

El RFC registró además tres nombres de segundo nivel reservados por IANA: example.com, example.net y example.org. Su utilidad era muy humana. En una guía sobre un formulario o una URL, example.com se parece a un sitio normal porque termina en un dominio corriente. El escritor puede mostrar una dirección creíble sin escoger al azar el dominio de otra persona. Es una web de utilería con papeles auténticos.

Aquí hay dos pisos de reserva. En tienda.example, la señal de ejemplo está en el dominio de nivel superior. En example.com, .com sigue siendo el espacio común: el nombre concreto que queda apartado es example. Confundir ambos mecanismos borraría la precisión del acuerdo de 1999. Ni todo .com es un decorado ni todo nombre terminado en .example pretende ser una web pública.

La sección de seguridad del RFC explica por qué se tomó la molestia. El programa de ensayo puede escapar del banco de pruebas. Un ejemplo que parecía destinado «solo» a la documentación puede convertirse en código distribuido. Un nombre improvisado puede chocar con un titular futuro e incluso arrastrar disputas sobre derechos ligados a ese nombre. El remedio no requería una máquina heroica. Bastaba con reservar unas pocas etiquetas, declarar para qué servían y mantenerlas fuera de la asignación normal. El Internet de 1999 necesitó una oficina de atrezo.

La guía actual de IANA sobre dominios de ejemplo conserva la parte administrativa: estos nombres se pueden usar en documentos sin pedir permiso y no están disponibles para registro o transferencia. IANA ofrece una página informativa en los hosts de ejemplo, pero pide que las aplicaciones no dependan de que ese servicio HTTP funcione. La dirección está disponible como ejemplo; la web informativa no es una plataforma de producción para el código que la copie.