Resumen

  • Las tablas conjuntas de ARPANET y DCNET superaban los 400 nombres y apodos. Mills propuso dominios de nombres para que cada computadora no tuviera que llevar un directorio plano de todos los futuros equipos.
  • Una computadora podía reenviar correo de COMSAT y de INTELPOST. Mills@HOST podía nombrar buzones distintos en cada dominio, y la dirección de la máquina no bastaba para escoger el destino de una respuesta. El nombre completo y la ruta de vuelta debían preservar el dominio.

El cartero encuentra dos sobres para Mills@HOST sobre la misma mesa. Uno corresponde a COMSAT y otro a INTELPOST. Si alguien retira las etiquetas de origen, la máquina que administra la mesa sabe menos que antes, por mucha memoria que tenga. D. L. Mills convirtió este problema en un caso preciso de su RFC 799, de septiembre de 1981. Las tablas combinadas de ARPANET y DCNET ya contenían más de cuatrocientos nombres y apodos. Partir el directorio prometía alivio; no perder el dominio al reenviar y responder era la condición para que ese alivio funcionara.

Mills llamaba dominios de nombres a agrupaciones que podían corresponder a instituciones como ARPA, UCL o COMSAT. Podían superponerse y no tenían que cubrir todas las direcciones. El documento analizaba un único nivel de dominios, aunque la forma completa <user>.<host>@<domain> se leía como tres niveles desde la derecha. Dentro de COMSAT, Mills@COMSAT-DLM podía bastar. Fuera de allí, Mills.COMSAT-DLM@COMSAT añadía el contexto necesario. Distintos dominios podían repetir apodos locales. El dominio no era un adorno del final: decía en qué libreta había que buscar.

Cada dominio tendría uno o más procesos reenviadores. Uno de ellos mantendría los nombres de todos los equipos de su propio dominio y al menos un reenviador de cada dominio ajeno. Los equipos corrientes guardarían las referencias a esos reenviadores y cualquier otro nombre que les conviniera. Mills permitía que un equipo perteneciera a varios dominios, tuviera varias direcciones de Internet o alojara varios procesos de reenvío. La organización local seguía siendo flexible; el proceso que cruzaba fronteras tenía que conservar la etiqueta correcta.

Los reenviadores no iban a recibir todo el correo por defecto. Mills esperaba que la mayor parte viajara directamente del equipo de origen al de destino. Un relevo intermedio era útil si ambos no podían estar conectados al mismo tiempo, si el emisor carecía de recursos para resolver el nombre, si una conexión directa tropezaba con límites regulatorios, económicos o de seguridad, o si los extremos empleaban transportes distintos como TCP y NCP. Un relevo podía almacenar y enviar sin poseer la tabla completa que se exigía a un reenviador. Eran oficios relacionados, pero distintos.

El documento prueba el diseño con dos rutas: MRCP to:<@COMSAT,Mills@HOST> y MRCP to:<@INTELPOST,Mills@HOST>. Pueden llevar a buzones diferentes incluso cuando una sola computadora ejecuta los reenviadores de los dos dominios. Si esa computadora se llama FORWARDER en ambos, la ruta abreviada MRCP to:<@FORWARDER,Mills@HOST> deja al proceso sin el dato que separaba las dos cartas. Consultar su dirección de Internet tampoco recupera ese dato. La dirección identifica la computadora; no indica bajo cuál de sus dos funciones recibió esta carta.

La ruta de respuesta corría el mismo peligro. Según el procedimiento de RFC 780 que Mills examinaba, el receptor construía el nombre del remitente a partir de la dirección de Internet del equipo que le entregó el mensaje. Si aquel equipo representaba varios dominios, la reconstrucción eliminaba el contexto. Mills pidió que el emisor actualizara tanto la ruta del destinatario como la del remitente, copiando al principio de la ruta de regreso la primera entrada de la ruta del destinatario que había recibido. El recibo debía recordar la ventanilla concreta por la que pasó la carta.

Quedaba el problema de los sistemas antiguos. Mills evitaba editar encabezados RFC 733 a lo largo de todo el trayecto: modificar su contenido requería un análisis invasivo. Los sistemas nuevos podían adoptar la dirección completa desde el inicio. En el correo ARPANET existente, un <anything>@<host> local se convertiría en <anything>.<host>@ARPA cuando el mensaje entrara por primera vez al sistema de correo de Internet. Los nombres <anything>@<domain> ya reconocidos permanecerían igual. Es en la puerta de entrada donde aún se sabe qué significaba el apodo corto.

RFC 799 acababa pidiendo discusión; era una propuesta. Su ejemplo del equipo con dos dominios, en cambio, dejaba una lección comprobable sobre el diseño: una dirección de 32 bits puede identificar una máquina sin identificar el papel postal que desempeña en un mensaje. Más de cuatrocientos nombres habían hecho incómoda la lista plana; dos buzones detrás de una sola dirección enseñaban por qué también importaba el camino de vuelta.