Summary

  • El RFC 1383 propuso consultar el DNS inverso para elegir una pasarela hacia una red periférica con varias conexiones, evitando anunciar todas sus redes internas en las tablas mundiales.
  • El prototipo descrito esperaba un ICMP de destino inaccesible para iniciar esa consulta. El RFC reconoció el riesgo de perder el primer paquete; la lista DNS tampoco acreditaba que la pasarela siguiera funcionando.

Un paquete sale hacia una red que el router no conoce. Regresa un «destino inaccesible». El gestor experimental lee el aviso, pregunta al DNS y prepara un camino para lo que venga después. En diciembre de 1992, Christian Huitema escribió esa secuencia en el RFC 1383. La primera pérdida no era la solución; era el precio de activar la búsqueda sin reescribir el enrutador IP ordinario.

El tamaño de las tablas preocupaba. El memorando citaba más de 5.000 redes anunciadas en NSFNET y más de 7.000 en EBONE en aquel momento. Cada nueva entrada reclamaba memoria en los routers de tránsito, más intercambio de rutas y decisiones administrativas. La agregación jerárquica ofrecía alivio, pero dejaba incómoda a la red conectada a más de un proveedor que quería conservar sus direcciones.

Huitema tomó prestada la forma de los registros MX del correo. Un dominio periférico D tendría dos pasarelas, I1 e I2, visibles desde Internet. Ellas conocerían las rutas internas sin publicar cada red de D al mundo. El origen consultaría in-addr.arpa para obtener una lista RX de pasarelas, escogería una y enviaría el paquete con una ruta indicada desde el origen. Al principio, RX, la preferencia y la dirección IP iban dentro de un registro TXT. Un tipo DNS propio quedaba para un diseño posterior.

La elección única evitaba una trampa. Si todos los routers intermedios consultaban el DNS, todos necesitarían cambios. Uno podría elegir I1 y otro I2, creando vueltas y quizá un bucle. El origen o un router cercano tomaba la decisión una sola vez y mantenía ese itinerario. Dos pasarelas reducían la dependencia de un único acceso y de un solo proveedor, aunque una dirección publicada no decía si el acceso estaba vivo. Había que excluir las pasarelas conocidas como inaccesibles y mantener esa evidencia al día.

El propio DNS necesitaba una ruta. Las copias de la información RX debían estar en servidores accesibles desde el núcleo de Internet; una red periférica aislada no podía responder la consulta destinada a encontrarla. Mientras el gestor esperaba, el reenviador retenía paquetes y descontaba su tiempo de vida. Si la respuesta no daba una pasarela, marcaba el destino como inaccesible y descartaba lo acumulado.

El RFC prefería integrar la decisión directamente en el código de enrutamiento IP cuando eso fuera posible: así no hacía falta esperar el ICMP que podía costar el primer paquete. El registro oficial clasifica la idea como Experimental; la conclusión del texto decía que el código se estaba desarrollando en INRIA. Su argumento comercial era una apuesta: si anunciar una red propia tenía precio, la lista DNS podía dar a un cliente multiconectado otra salida frente a renumerarse bajo un proveedor.

La autoridad cambiaba de sitio. El tránsito compartía menos información, y el origen asumía la consulta, la selección y la recuperación si el dato era viejo. El DNS podía señalar una puerta. Abrirla seguía siendo trabajo de la red.

Sources