Resumen

  • RFC 3568 resume mecanismos de enrutamiento de solicitudes conocidos o usados hasta diciembre de 2000. DNS, transporte y aplicación observan identidades y campos distintos; no pueden afirmar el mismo tipo de proximidad.
  • La elección necesita conservar quién fue observado, qué candidatos existían, qué sentido y antigüedad tenía cada medida, qué política decidió y si el traspaso terminó en entrega y resultado de aplicación.

Una sesión no tiene necesariamente un solo camino. La inspección de transporte puede recibir una conexión en el sustituto escogido por DNS, seleccionar otro nodo y mantener el flujo cliente-nodo a través del primero. La respuesta, normalmente más grande, puede volver de forma directa. Medir un sentido y prometer el otro convierte la geometría en retórica.

RFC 3568 es un documento informativo de julio de 2003. No establece un estándar: cataloga prácticas de la industria conocidas o empleadas hasta finales de 2000 y las ordena en tres familias. Su valor actual está en mostrar cuánto cambia la decisión cuando cambia el punto de observación.

Antes del transporte, DNS ya cambió al solicitante

Un servidor DNS especializado puede escoger registros A, NS o CNAME según políticas y métricas. Puede entregar una dirección, varias direcciones o una cadena hacia otro decisor. Sin embargo, la consulta no suele llevar la dirección del cliente. El sistema ve el DNS del sitio. Con recursión, puede ver otro servidor que consulta en nombre de aquel.

La proximidad calculada es entonces proximidad al resolvedor visible. Varios clientes que comparten ese resolvedor reciben el mismo conjunto durante el TTL. La concentración puede sobrecargar un sustituto durante una avalancha aunque la selección original fuera coherente con sus datos.

La traza debe conservar por separado cliente, resolvedor del sitio y servidor recursivo observado. Si no conoce el primero, debe decirlo. Un campo vacío es más honesto que una coordenada inferida y convertida en certeza.

El conjunto de respuestas tampoco reparte por sí solo

Múltiples registros A ofrecen opciones; implementaciones comunes pueden recorrerlas en rotación. Eso distribuye decisiones dentro de un resolvedor, no demuestra equilibrio de carga en los servidores. El orden, la caché, la población compartida y la carga real siguen siendo variables distintas.

Las cadenas NS y CNAME permiten especializar decisiones. NS está limitado por la estructura del nombre, puede añadir demoras y deja al último servidor influir en el TTL de la resolución. CNAME abre otro dominio y otra consulta. Cada salto debe registrar autoridad, entrada, salida, caché y tiempo; de otro modo una cadena de decisiones aparece como una única respuesta sin responsables.

Los TTL cortos reaccionan antes a cambios pero elevan el volumen DNS, y algunas implementaciones no los respetan. La vida útil del dato y la vida útil de las mediciones que lo justificaron deben compararse. Una respuesta aún almacenada puede contener una política ya retirada.

Anycast ubica el selector

El RFC describe una misma dirección anycast anunciada por varios servidores DNS de enrutamiento. Los protocolos llevan la consulta al servidor que parece próximo al resolvedor. Es una solución para localizar el punto de decisión.

No demuestra cercanía al cliente. El enrutamiento no suele considerar carga; el servidor próximo por ruta puede no tener menor latencia; su propia carga queda fuera de esa primera decisión. El recibo anycast debe acabar en «selector alcanzado», no en «entrega optimizada».

DNS además ve nombres de dominio, no objetos. Codificar tipo o hash del objeto en el nombre aporta granularidad, pero una página puede necesitar varias resoluciones. El control fino se paga en consultas y demora.

El transporte revela identidad y crea asimetría

Al inspeccionar el primer paquete, la capa de transporte obtiene dirección IP del cliente, puerto y protocolo. Puede corregir una decisión DNS demasiado general y apartar tráfico de un sustituto cargado. RFC 3568 deja el mecanismo de traspaso fuera de alcance.

Por eso no basta registrar el nodo seleccionado. Hace falta el nodo que recibió la conexión, el que aceptó el traspaso, el trayecto de ida, el de vuelta y el instante efectivo. Si el retorno evita al intermediario, la latencia de respuesta no valida el coste del camino de solicitud. Si los caminos son asimétricos, una medida unidireccional no representa el viaje completo.

La aplicación compra precisión con poder

La capa de aplicación puede leer URL, cabeceras, cookies, idioma o agente de usuario. Puede elegir por objeto, devolver una redirección 302, interceptar y empalmar conexiones o reescribir enlaces incorporados.

La redirección añade una ida y vuelta y depende de que el cliente la siga. El elemento en ruta introduce análisis y estado en el camino. La reescritura mantiene la primera petición en el origen y fija una selección dentro de la página. Si esa página queda en caché, sus URL pueden señalar después a sustitutos caídos o ya inadecuados. La decisión incorporada necesita una caducidad tan visible como un TTL.

TLS establece otro límite. Sin terminar la sesión, la red de contenido no ve la URL completa. Terminarla entrega claves, responsabilidad de certificado y acceso a contenido al selector. Más información puede mejorar la clasificación, pero también cambia quién tiene poder para leer y modificar. El recibo debe nombrar esa autoridad, no esconderla bajo «capa 7».

La métrica debe confesar a quién observó

El documento enumera tiempo de ida y vuelta, saltos, información BGP, carga y disponibilidad de contenido. En su uso, proximidad significa RTT; para DNS suele medirse al resolvedor local. Algunas mediciones abarcan solo ida o vuelta, en una Internet de rutas asimétricas.

Las sondas activas son periódicas. NAT y cortafuegos pueden bloquearlas; sistemas de detección pueden alarmarse. El silencio no distingue distancia, política y fallo. Las peticiones HTTP de sondeo tampoco garantizan carga en tiempo real; la información antigua puede ser inexacta. El propio RFC advierte que AS_PATH puede carecer de sentido como métrica de selección.

Cada valor necesita origen, destino, método, sentido, hora y semántica de fallo. La política necesita versión, pesos, restricciones y desempate. Solo entonces puede reconstruirse por qué ganó un candidato.

De la decisión al resultado

El expediente mínimo empieza con la identidad visible y la solicitud. Continúa con cadena DNS, caché, candidatos, disponibilidad de objeto y medidas crudas. Conserva política, elección y vencimiento. Después registra respuesta, redirección, reescritura, intercepción o traspaso; autoridad TLS; aceptación del sustituto; carga al servir; camino real; bytes y estado; reintento y desenlace.

DNS respondido no significa cliente conectado. Redirección emitida no significa seguida. URL reescrita no significa objeto entregado. Nodo elegido no significa solicitud aceptada. Una capa no puede emitir el recibo de la siguiente.

Límite de evidencia

Este Artículo no identifica CDN, operador, resolvedor, cliente, origen, sustituto, fabricante, sesión, incidente ni resultado medido. RFC 3568 es un estudio informativo de técnicas anteriores a 2001, no prueba de un despliegue actual.

RFC 3466 ofrece el modelo contemporáneo; RFC 3238 limita a intermediarios. RFC 2782, RFC 1546, RFC 1034, RFC 1035 y RFC 2181 dan contexto DNS; RFC 3272, RFC 2386 y RFC 3221, contexto de rutas. RFC 7336 y RFC 8008 son evolución CDNI posterior, no historia retroactiva.

Los ensayos de Heng Lu sobre primacía del código en ejecución y especificación mínima son lentes editoriales declaradas. Sostienen la exigencia de comprobar la entrega y limitar el contrato compartido; no prueban intención de autores ni operación alguna.

La conclusión acotada: «mejor» siempre lleva un subíndice invisible. Hay que hacerlo visible —mejor para quién, en qué sentido, durante cuánto tiempo y confirmado por qué resultado— antes de gobernar con él.

Sources