Resumen

  • RFC 1794 documenta un intento de 1995 por hacer que el orden de las direcciones DNS reflejara cambios en la carga de los servidores sin modificar el protocolo.
  • El servidor autoritativo podía publicar una preferencia, pero las cachés, las secundarias y el ordenamiento local del cliente impedían convertirla en una asignación de destino.

Una respuesta ordenada no era una conexión

Un nombre puede resolver a varias máquinas equivalentes. Si una tiene menos trabajo, parece natural poner su dirección primero. Pero DNS entrega registros; no abre la conexión de la aplicación. Esa diferencia organiza el relato de RFC 1794: el orden podía ser útil y hasta predecible, pero el protocolo no garantizaba que el cliente lo conservara.

El documento apareció en abril de 1995 con categoría Informational. Indica expresamente que no establece un estándar de Internet. Su autor se propuso registrar una exploración del grupo de trabajo DNS y las alternativas que se debatieron; también advirtió que algunos tramos de la historia podían faltar. Es evidencia de una discusión de diseño, no un recuento de sistemas instalados ni de su rendimiento.

De alternar direcciones a medir la carga

El autor sitúa hacia 1986 varias modificaciones de BIND que cambiaban la posición de los registros de dirección. Cita las adaptaciones Shuffle Address de Bryan Beecher y el código Round Robin de Marshall Rose como ejemplos que probablemente se difundieron mucho. La fecha y el alcance son parte de su recuerdo retrospectivo, no de un inventario independiente.

La rotación cambiaba qué dirección aparecía primero, pero no observaba cuánto trabajo tenía cada máquina. RFC 1794 contrasta esa práctica con cambios atribuidos a Matt Madison, de TGV: aprovechaban funciones propias de VMS para ordenar las direcciones desde el sistema menos cargado al más cargado. La clasificación atendía mejor al estado de los equipos, aunque dependía de un sistema operativo concreto y exigía cambios en el tratamiento de los registros. Una solución ofrecía portabilidad sin medir carga; la otra, carga más directa con dependencia de plataforma.

La compatibilidad trasladó la parte dinámica

Los criterios que RFC 1794 atribuye al grupo de trabajo abarcaban compatibilidad con el DNS existente, cambios frecuentes, varias direcciones por respuesta, trato coherente de otros registros, flexibilidad para distintas clases de carga y rapidez de cálculo. Cinco minutos se consideraban un intervalo de actualización normal; sesenta segundos se mencionaban como posibilidad, no como una prestación medida. Varias direcciones debían dejar alternativas si el servidor preferido fallaba antes de vencer el TTL.

Cambiar el protocolo o inventar un tipo de registro parecía una apuesta difícil frente a la base instalada. El memorando relata otra propuesta de Rob Austein: dar más inteligencia al programa que transfiere zonas. Ese programa podría obtener datos de carga, reordenar la información y entregarla al servidor de nombres sin alterar los mensajes DNS. La consulta seguiría usando el protocolo conocido; el proceso que prepara la zona se volvería dinámico.

La complejidad cambiaba de lugar. Las transferencias actualizan servidores secundarios; el servidor primario no consulta una transferencia para responder. Una subzona volátil dependía, por tanto, de la frecuencia de refresco. Los TTL entregados a los resolvers también debían ser bajos para que un nuevo orden llegara pronto. Además, el cálculo tenía que terminar antes de que caducara la información que iba a distribuir. Una clasificación reciente en origen podía estar desactualizada cuando alguien usara la respuesta almacenada.

El cliente conservaba la última decisión

RFC 1794 señala que DNS no garantiza el orden de los registros. El autor lo llama predecible: un cliente podía recibir repetidamente la misma secuencia, aunque también podía reordenar direcciones de forma local, por ejemplo mediante una lista de clasificación. El programa de transferencia no podía anticipar esas decisiones remotas. Devolver varias direcciones tampoco demostraba que el cliente probaría todas, que la siguiente estuviera sana o que la aplicación completaría su operación.

La importancia histórica no está en que DNS se transformara en un balanceador de carga, sino en cómo se delimitaron las responsabilidades. El operador podía calcular una preferencia y publicarla; las secundarias y las cachés regulaban su propagación; el cliente elegía el destino final. RFC 1794 describe una forma de trabajar dentro de esos límites, pero no demuestra cuán adoptada estuvo ni con qué resultados.

Fuentes