Resumen

  • DNS Push permite congelar el descenso del TTL porque un servidor aceptó mantener un RRset mediante cambios asíncronos durante una sesión DSO concreta.
  • Al cerrarse esa sesión terminan todas sus suscripciones. La reanudación TLS reduce el coste criptográfico, pero nace sin estado DNS Push y exige nuevas solicitudes SUBSCRIBE y un nuevo estado inicial.
  • La evidencia debe enlazar el descubrimiento, la identidad TLS, la sesión, NAME/TYPE/CLASS, el RCODE, cada alta o baja, el reloj del caché y una prueba independiente del servicio.

El error de los dos relojes

El siguiente caso es ilustrativo. Un controlador se suscribe a un RRset SRV y recibe una dirección de servicio con TTL 120. La suscripción permanece activa durante diez minutos, de modo que el cliente no descuenta esos 120 segundos. Después el operador retira la dirección. En el mismo intervalo se pierde la conexión persistente.

El cliente usa un ticket y reanuda TLS. El monitor de seguridad vuelve a mostrar un canal válido. Sin embargo, la nueva conexión no contiene una nueva suscripción DSO. Si el controlador sigue tratando el TTL como congelado, el registro puede sobrevivir indefinidamente aunque el servidor ya no tenga ninguna obligación de enviarle la baja.

El defecto no está en ahorrar un handshake. Está en usar el éxito de una capa como prueba de otra. TCP confirma una conexión. TLS confirma propiedades criptográficas y de identidad bajo sus credenciales. DSO crea una sesión de operaciones con estado. SUBSCRIBE crea una obligación para un NAME, TYPE y CLASS. Sólo la cuarta autoriza al caché a sustituir el reloj ordinario.

Cuándo puede dejar de correr un TTL

La disciplina normal del DNS no necesita una conexión larga. El servidor publica un registro con TTL; el resolver lo almacena y reduce el tiempo restante. Cuando llega a cero, una nueva consulta debe renovar la información. Para datos muy dinámicos, sondear con frecuencia puede desperdiciar trabajo en clientes, recursivos y autoridades.

DNS Push cambia coste por estado. Cada solicitud SUBSCRIBE contiene exactamente un nombre, tipo y clase. El servidor admite o rechaza esa solicitud de forma individual. Cuando ya existe una respuesta no vacía, la aceptación va seguida de un PUSH inicial. Más tarde el servidor transmite los cambios sin esperar otra consulta.

RFC 8765 permite entonces una excepción profunda: el cliente conserva el TTL recibido con un alta, pero no lo decrementa mientras la suscripción correspondiente siga activa. La razón no es que la zona haya ampliado su promesa. Es que el servidor Push asumió un deber alternativo: anunciar una modificación del TTL, una nueva RDATA o una retirada.

El privilegio acaba con UNSUBSCRIBE o con el cierre de la sesión DSO. En ese momento el envejecimiento vuelve a correr desde el TTL almacenado. El dato se elimina al llegar a cero. El sistema debe registrar esos dos instantes —suspensión y reanudación— como decisiones explícitas del caché. Sin ellos, no existe una explicación verificable de su edad.

La ruta de descubrimiento también necesita recibo

El cliente suele empezar con su resolver configurado mediante DNS over TLS en el puerto 853. Si el resolver acepta la suscripción, puede crear otra aguas arriba y retransmitir los resultados. Si no puede hacerlo, la búsqueda del servicio puede conducir a _dns-push-tls._tcp.<zone>. Cada salto cambia quién observa, almacena y retransmite el estado.

El perfil Strict Privacy es obligatorio. Pero cifrar el enlace no corrige un descubrimiento manipulado. Un SRV alterado puede dirigir al cliente a un servidor equivocado cuyo certificado sea perfectamente válido para el nombre equivocado aprendido por el cliente. Por eso el recibo incluye respuesta y TTL de descubrimiento, resultado DNSSEC, destino, SNI, validación de certificado o TLSA y dirección final.

La conexión entra después en DSO mediante Keepalive o mediante la primera operación Push. La solicitud SUBSCRIBE tiene un MESSAGE ID no nulo; la respuesta usa ese identificador y su RCODE decide si existe la suscripción. Un socket abierto no es admisión. El servidor puede contestar que no entiende el tipo DSO, que no es autoridad para el nombre, que falló el camino aguas arriba o que no tiene capacidad.

La capacidad importa porque una suscripción consume memoria, conexiones y trabajo futuro. El servidor debe poder limitarla. El cliente no debería sostener miles de suscripciones por si algún día se abre una pantalla. La decisión localizada —quién necesita datos vivos ahora— conserva la eficiencia sin convertir el protocolo en una obligación ilimitada.

Altas y bajas que sólo valen dentro de su sesión

PUSH viaja del servidor al cliente y usa MESSAGE ID cero. No recibe una respuesta de aplicación. Cada cambio codifica un alta con TTL entre cero y 0x7FFFFFFF, una baja individual con 0xFFFFFFFF o una baja colectiva con 0xFFFFFFFE. Las bajas colectivas usan RDATA vacía y el alcance se expresa mediante TYPE y CLASS.

Antes de aplicar un cambio, el cliente debe encontrar una suscripción activa que coincida en esa misma sesión. Este control evita que una notificación tardía, llegada mientras UNSUBSCRIBE viaja en sentido contrario, modifique un interés ya cancelado. También revela qué debe conservar una auditoría: bytes, orden dentro del flujo, sesión, suscripción coincidente y resultado del caché.

No hay un número de secuencia persistente que una dos conexiones. El cero de MESSAGE ID no es un cursor. TCP sólo ordena los bytes de su propio flujo, y un PUSH puede agrupar cambios de distintas suscripciones. Tras una ruptura no se puede demostrar “no perdimos nada” comparando el último paquete antiguo con el primero nuevo. La recuperación correcta obtiene otra aceptación y otro estado inicial.

Cuando el RRset está vacío, una respuesta SUBSCRIBE satisfactoria no tiene que ir acompañada de un registro ficticio. La exigencia de PUSH inicial se aplica al conjunto no vacío. De modo que el silencio puede representar una suscripción aceptada sin datos actuales. Para distinguirlo de una operación estancada, el operador necesita el RCODE y el estado de sesión, no una métrica de mensajes por minuto.

Keepalive, RECONFIRM y las frases demasiado grandes

Keepalive ayuda a mantener NAT y cortafuegos y a comprobar conectividad. Una suscripción activa impide que DSO considere inactiva la sesión, aunque no se produzcan cambios. Esto permite períodos silenciosos legítimos.

Sin embargo, “Keepalive sano” no significa “RRset completo”. No prueba la suscripción del resolver hacia la autoridad, la ausencia de una baja perdida, la correcta aplicación local ni la salud del servicio anunciado. Cada una de esas afirmaciones tiene otra fuente.

RECONFIRM tampoco es una consulta universal a la verdad. Su efecto está definido para Discovery Proxy: una dirección que parece obsoleta puede provocar nuevas consultas multicast y, si desapareció, futuras bajas Push. Para otros servidores la acción queda indefinida; NOERROR no obliga a comprobar nada. Una interfaz que convierte NOERROR en “registro reconfirmado” falsea la semántica.

Reanudar sin heredar

RFC 8765 establece una línea tajante. Al cerrarse TLS termina DSO. Si TLS se reanuda, el servidor actúa como en una sesión nueva y no conserva suscripciones. El cliente sigue obligado a recrear todas las que necesita. La palabra “reanudar” describe claves y coste del handshake, no una herencia de estado DNS.

SUBSCRIBE puede aparecer en early data. Esta optimización permite que una petición repetida sea aceptada en más de una conexión; TLS 1.3 no ofrece una garantía general contra replay para 0-RTT. La operación es suficientemente pequeña y temporal para que el protocolo la permita, pero no adquiere semántica de exactamente una vez. El cliente espera la respuesta de la sesión efectiva antes de congelar el TTL.

Una secuencia de recuperación auditable marca el cierre antiguo, activa de nuevo el envejecimiento, abre TCP/TLS, identifica si el handshake fue completo o reanudado, crea DSO, envía todos los SUBSCRIBE, clasifica las respuestas y recibe los estados iniciales no vacíos. Sólo entonces vuelve a declarar datos vivos.

Si Push no se puede establecer, el cliente puede sondear. La recomendación es no preguntar por el mismo NAME/TYPE/CLASS antes del mínimo entre 900 segundos y el TTL más dos segundos, e intentar Push de nuevo antes de cada sondeo. Este modo debe mostrarse con su propia edad y riesgo; ocultarlo bajo el mismo verde eliminaría la información útil para decidir.

De la captura a la decisión

Un registro de prueba empieza con la consulta de descubrimiento, su TTL, validación y punto de observación. Continúa con nombre TLS, SNI, par, certificado o TLSA, identificador de conexión, handshake completo/reanudado, inicio DSO, temporizadores y Retry Delay.

Cada suscripción aporta MESSAGE ID, NAME, TYPE, CLASS, petición, RCODE y hora de aceptación. Cada PUSH aporta orden, bytes o huella protegida, forma de alta/baja, RR, TTL, coincidencia y cambio de caché. El cierre debe distinguir UNSUBSCRIBE, close_notify, FIN, timeout, reset y aborto fatal.

Después vienen dos comprobaciones que no deben mezclarse. Una consulta directa a una autoridad observa el DNS actual. Una sonda abre el servicio real. Si ambas difieren del caché, la cadena muestra dónde se perdió autoridad. Si el DNS coincide pero el servicio falla, la incidencia no se resuelve re-suscribiendo.

El marco de Heng Lu aplicado al flujo

La especificación mínima común debe ser firme en lo que permite interoperar: TLV, roles, identidades, temporizadores, retiros, seguridad y cierre. No necesita gobernar el presupuesto de cada servidor, el tiempo de conservación de telemetría o el umbral de una alerta. Esas decisiones futuras permanecen cerca del riesgo local.

La adopción voluntaria tampoco se prueba con un RFC publicado o un código asignado por IANA. Se prueba con servidores que admiten, clientes que reconstruyen, canarios que rompen conexiones y registros que muestran el efecto. La primacía del código exige mirar el paquete y la consecuencia; no convierte todo comportamiento ejecutado en política legítima.

La autoridad final queda repartida: la zona publica, el descubrimiento orienta, TLS protege, DSO delimita la sesión, SUBSCRIBE crea una obligación, PUSH cambia el caché y la aplicación decide si el destino sirve. El valor del diseño está en que ninguna capa necesita fingir que es todas las demás.

Fuentes