Resumen

  • La RFC 8490 separa una conexión DNS de una sesión DSO: el estado persistente nace de un intercambio exitoso, no de un socket que continúa abierto.
  • Un TLV principal por mensaje, identificadores explícitos, dos relojes y Retry Delay permiten atribuir y limitar la vida de cada operación.
  • La pregunta de control no es si el canal respira, sino qué operación lo justifica, quién la inició y qué hecho debe terminarla.

El socket sin autoridad propia

El DNS tradicional promete una pregunta y una respuesta. TCP permite reutilizar una conexión, pero no concede por sí solo permiso para crear suscripciones, enviar cambios futuros ni guardar estado después de responder. Continuidad de transporte no equivale a autoridad de aplicación.

La RFC 8490, publicada en marzo de 2019, fue firmada por Ray Bellis, Stuart Cheshire, John Dickinson, Sara Dickinson, Ted Lemon y Tom Pusateri. Define DNS Stateful Operations, DSO, con el OPCODE 6 y actualiza las RFC 1035 y 7766. Su logro central es describir un estado que ambos extremos reconocen y pueden cerrar de manera inteligible.

Primero existe una conexión. Salvo supuestos estrechos de datos tempranos, la sesión DSO solo queda establecida cuando el cliente envía una solicitud y recibe una respuesta exitosa con el mismo identificador. Si un servidor antiguo calla, el cliente no puede inferir aceptación. Tras el límite previsto debe abortar y volver a un estado conocido.

Una operación principal

DSO reutiliza la cabecera DNS, pero transporta operaciones mediante estructuras Type-Length-Value. Cada mensaje contiene un único TLV principal. Ese tipo decide si hay una solicitud que exige respuesta o un aviso unidireccional que no debe recibirla.

Las solicitudes usan un MESSAGE ID distinto de cero; los avisos unidireccionales usan cero. Es posible encadenar solicitudes y recibir respuestas fuera de orden, aunque las acciones se procesan en el orden de llegada. La regla impide confundir señal con transacción.

Un TLV principal desconocido produce DSOTYPENI. Un TLV adicional desconocido se ignora. Así, ampliar el protocolo no obliga a fingir comprensión. Cada operación obtiene su propio mensaje y resultado, en vez de esconder varias decisiones dentro de una opción agregada.

El silencio tiene dos significados

Una conexión silenciosa puede estar abandonada o sostener una suscripción que espera novedades. Por eso la RFC distingue el tiempo de inactividad del intervalo de keepalive.

El primero mide trabajo útil. Una operación prolongada sigue activa hasta su cancelación aun sin tráfico. El segundo comprueba que el camino permanece alcanzable y puede conservar estado en NAT y cortafuegos. El pulso mantiene el canal; no renueva automáticamente la finalidad de la operación.

Si todo silencio significara abandono, las suscripciones caerían sin necesidad. Si cualquier keepalive prorrogara autoridad, el estado obsoleto sería inmortal. La operación pendiente y ambos relojes deben observarse juntos.

Salir sin avalancha

Retry Delay permite cerrar la sesión y pedir al cliente que espere antes de reconectar. Los códigos distinguen reinicio ordinario, formato fatal, agotamiento de recursos y reconfiguración. De ese modo, una parada controlada no tiene por qué provocar una tormenta de conexiones.

El código no revela toda la causa privada. SERVFAIL puede señalar descarga por saturación sin identificar su origen; REFUSED no prueba conducta indebida ni retirada permanente. DSO se limita además a transportes fiables y ordenados, DNS sobre TCP o TLS. UDP no ofrece sesión; HTTPS administra la suya de otro modo.

La RFC 8765 usa DSO para DNS Push Notifications. Ese uso demuestra que el valor no está en alargar el socket, sino en dar a otro protocolo un ciclo de vida compartido. El registro de IANA publica códigos DSO, pero no demuestra adopción ni calidad operativa.

La aportación de Ray Bellis aparece en la separación de hechos: establecer, mantener, callar, alcanzar, saturar, terminar y reintentar no son el mismo evento. La persistencia deja así de funcionar como autoridad invisible.

Fuentes